65816: Aaaaaaaannnnnnnddddd we're done..........

Well, I appear to have now finished 65816 support. I had some nasty little bugglets that were messing with my REP/SEP commands which is exactly the reason I couldn't swap in/out of it easily! Basically, even in 16bit mode, Rep/Sep are 8bit commands, but it was saving 16bit immediate values, which meant it would then hit a $00 (brk) as the next instuction.

So, this is pretty cool, as I'm now done with the core supprt for 65816 and 65c02. It still needs heavy testing, but looks like its mostly there.

While I was at it, I also fixed a couple of other instructions in normal 6502 mode that were broken ( jmp($1234), and lax $00,y). So that helps me anyway for XeO3.

So all I need to do now is release this version and then back onto paths for xeo3!
(have I mentioned just how much I HATE doing paths???)

65816: Problems....

Okay....I was a bit peeved that I released the latest SNASM with only partial 65816 support, so I've decided to finish it off. While doing this, I've hooked up my SuperCPU again along with my fab new Heavy Duty PSU.

I'm pleased to say my MMC64 and Ethernet still work on the super CPU, so downloading is a doddle. You know...I was halfway through this post, moaning that nothing was working, and then I noticed a REALLY stupid mistake, and now all is well....

So now I have a full 65816 - 16bit program running!! COOOOOOL!

Slight problems still exist however....If I'm in 16bit mode, I cant go into 16bit mode. (yes you read that right). Its a bit strange. As its not that big, I've done a HEX dump on the code and it all lookgs fine!

*sigh*........What the hells wrong now.......

New Release!!!!

I have just done my first new release of Minus4 in about 2-3 years!! Yes all these new features I keep going on about are have now been released into the wild. So if you head on over to THE MINUS4 HOMEPAGE you'll be able to download new versions of Minus4w, Minus4wsrc and the new Snasm.

The new Snasm also has a lot of 65816 assmbler support in it, but mre importantly outputs symbols for Minus4's built in debugger.

If theres any cool features you can think of, let me know.... Minus4 has moved from being the best emulator (now easily beaten by YAPE) to being the best for development - by far!

XeO3 is being developed using SNASM as the assembler, and Minus4 as the debugger. Yape provides more realistic playback, and the uploader provides real hardware downloading! All I really need to do is finish the remote debugger and we'd have a full devkit!!

XeO3: Profiled!

I'll get into this in a bit, but I just wanted to show the basic XeO3 profile. As expected sprite drawing is coming out on top with the HUGE spike inside ZeroBlock which is the bit that draws sprites when they are over an empty character. This is the fastest path through the sprite system.

The 2 big peaks to the right are the screen copy used for scrolling (but also wipes the display). Theres 2 seprate peaks as its double buffered and it flips from one to the other.

This is pretty good as it means code is taking its time in the areas expected; as is usually the case for 8bit stuff. However, I'll start looking at things like collision and zeropage next. Theres something funny happening in zeropage that I'll need to track down, it looks like something it over writing a couple of bytes of unallocated memory down there.

Oh...The reason I was able to pick this bit out is that I've impemented the ZOOM feature. So now all you do is click and drag over an area of interest and then click ZOOM. I'll need to change the Execute buffer as when you zoom in to byte level, it only counts the OPCODE bytes as being used. This means you get a peak, 0, peak, 0,0 peak etc. as the paramaters aren't tagged. All I need is a 256 byte table of how big each opcode is then fill in each location of an instruction.

Minus4: More on profiling....

You know, the one thing I really like about machines getting bigger and better, is that it lets you be lazy. In Minus4 I could do special functions to hunt quickly for symbols as quickly as possibly, arranging it all in a nice binary tree, while at the same time maintaining a 2D linked list so that I can find the symbol closest to an address.

Or.... being lazy and having a big machine....I can create a 256K table of symbol pointers.

I like lazy. Code is easy, and I can get onto what matters.

So I've only a couple of bits left of the Minus4 profiler. One is a ZOOM function; which it does actually do just now but I need a user interface, and the second is a symbol look up so that the addresses make sense to a developer. The blurb above means I can do the symbol lookup REALLY easily, so that will just leave the zoom and scroll bit (to let you view around the window area easily).

Then I can get back onto XeO3 and rearrange memory to be more efficiant.

Minus4: Profiling other games!!

Now this gets really cool.... I was busy flicking though other peoples demos and games and its amazing what a basic profiler does. In Elite, you can clearly see where the linedraw (I assume) is called as theres a huge spike in the Execute map, while in Monty on the Run shown in this new image, you can clearly see that monty is rotated in Zeropage!!

72 bytes appear to be set aside for the monty graphic in zero page, and as you run about it goes up and down in time. Really cool.

It also shows up some odd patterns, for example in one of Luca's demos, it looks like he's using ZeroPage oddly as something is reading through zeropage overtime, and the read bar runs up smoothly through memory.

On XeO3, you can clearly see where both the sprites and scroll occur in memory, AND you can tell when its drawing tiles as theres a noticable spike every few frames.

The thing a static image can't get over, is that fact that becasue its in realtime, you see spikes as they happen - and where! Really neat.

Great fun this :)

Minus4: Profiling.

I've added the basics to the profiling kit and its really interesting to see memory access at work. With machines being so fast these days I can afford to put in profile access for everything without worrying about it, which is pretty neat in itself. So I can currently profile read, write and execute all seperatly (or accumulate them for a combine profile).

The REALLY cool thing is that I can watch the profile in real time!! When selected a new window pops open and you can sit and watch any area of memory and see what the access is like. This is very very cool, and a tool I wish I had in my day to day development! The piccy on the right shows the profile in action and the bars bump up and down over time as the system hits memory differently. I have a reset option so that I can averate the profile over a little bit of time and clear it. This gives some really cool feed back.

What I really need to do now is allow symbol lookups so you can see where time is being spent. This shouldn't be too hard but will prove to be amazingly cool! I still have most of the editor functions to add, but even now I can see that vast areas of ZeroPage (which is shown) are virtually unused!

Of course, a huge spike does not mean that you HAVE to put something in zero page, as things like my frame sync variable gets hit thousands of times a second, but can be slow as its the end of a frame!But for the most part, if theres a spike in memory access, thats a good variable to move to ZeroPage if you can.

Plus4: The expansion port...

Oh.... and as a little side note.... I was wondering.... The big problem with the plus4 is that theres no female edge connectors that now FIT the plus4. Sure we can make cards that plug into the machine, but we can't do THROUGH connectors. So I was wondering, why not make a new standard?

We could do a convertor that goes in the current port, but then expands into a new size; a new width that there ARE connectors for. Then we make the cards fit the new size - say the PC ISA card size, as these are big enough and easy to get (or something like that). This way you can add through connectors and allow cards to be connected together.

This means all we need is one card to plug into the expansion, and from then on we make stuff for the NEW port.

Other machines like the Spectrum and C64 can have through ports - like the MMC64 which still allows the retroreplay to be plugged in. That would be cool.

Minus4: An old friend....

While getting a little bored of doing paths (MAN! I hate doing paths...) I decided to take a break from that and add some basic profiling under Minus4. This was suggested a while back by TNT in his Paradriod blog, so I'd thought I'd take the plung now and see if I can't save some zero page memory; or at least shuffle it around so I get better use out of it. I currently have around 50 bytes of zero page left but I'm fairly sure some of it really doesn't have to be there.

Anyway, while browsing the source I had a look at the last release of Minus4 and what's been added since, and theres actually quite a bit. I'm sure I posted this a while back, but here it is again.

V2.6
----
1)   Debugger now loads symbols (-p "symbol.sym" on the command line). SNASM format.
2)   Source now builds under VS2005
3)   Updated Debugger to allow disassembly view movement. 
     Page up/down, line up/down now moves disassembly view
     SHIFT+Page up/down, line up/down now moves memory dump view
4)   Dump of most of the hardware registers
5)   Added a menu switch for undocumented opcodes. They are now OFF by default....
6)   Added a scrollable BAR to the disassembly view to allow the placement of breakpoints and nicer navigation
7)   New debugger keys:
            Cursor Up/Down              Move user bar
            Page   Up/Down              page disassembly up/down
    Shift + Cursor Up/Down              Move memory dump up/down a line
    Shift + Page   Up/Down              page memory dump up/down
            B                           Set Break point at current user bar address
    Shift + B                           Set Break point at address/symbol
            Enter                       Step a single instruction. If JSR/Branch then follow if need be.
            Space                       Place a breakpoint after current instruction and RUN.
            Cursor Right                If user bar is on a JSR/JMP, then read address and set window address to that.
            Cursor Left                 If CursorRight has been used, then pop last address off and reset window.
            M                           Set Memory window address
            G                           Set Disassembly window address
8)   Basic Profiling

With profiling being added I think its probably time to release this one so others can make use of it. I dont really use Minus4 for running games anymore, Yape has long since taken that crown, but I do use it for debugging as the built in debugger is much nicer to use (although I do now wish I'd opened up a new window for it so I could have a bigger area). Anyway... With the profiling about to be added, I think its now a nice enough release that others may like to use it for development, so once Im done with profiling, you can play with it for yourself.

My assembler (SNasm) outputs the symbol file format needed for Minus4 although I'll try to workout what the format was so you can use others and convert if you need to.

XeO3: Scripting....

As you may have noticed from Luca's blog, we've decided to not only release a demo, but the script for level 1, and a way to build it.

So... what does this mean? Well, it basically gives you a chance to get a taste and see whats coming in the full release. This means you can start to build your own paths, and do your own level. I suspect we'll see a couple of new 1 file demos with other peoples scripts, and who knows..... some folk might hack it a little more and try and extend it; although that would be a little tricky and Id wait for the full release.

Anyway, I'll try and post some stuff about the scripting, the limitations and what you'll be able to do with it soon.

XeO3: Demo

I've been doing more waves for the demo level and I'm now halfway, although it suddenly occured to me last night that I do still have code to do. I've not done the weapon energy bar yet! If you've watched the video you'll notice your shields take up both bars, but the plan is now that the one on the right will be your weapon power and it'll slowly drain over time. This means you HAVE to go in and collect coins to buy more power. IF you manage to get a load of coins before say the final 1/4 has gone, then you get a power up.

It'll be interesting to hear what you all think of this mechanic when you play it, as we both feel its whats going to make the game fun/difficult/annoying. Most games you can stand back and blast away, but with this one you have to get in there to pick up coins which means you will always be in danger!

Slow progress....

Well, after listening to the Scotland v Italy match on the Radio I'm wondering if I'll ever speak to luca again!! Oh well, its our own fault - as usual. We should have beat Georgia. Everyone was complaining about the refereeing, but I think it swings both ways. Never mind....We've improved loads and had a great campain - Well done Scotland! Ya done us proud!

Oh well, after that how have I been doing...... slowly. Not had a lot of chance to do much, but I hope to do some more paths tonight. I really hate doing them, but Luca (SPIT!) is still learning the script so I'll be doing these one, but I hope he can start doing some for the actual game.

I was also thinking about the MMC card stuff. I really screwed up here. By not doing a schematic first, I have no idea where all the wires are going, so now I either need to start again, or revese engineer what I had started. Im also thinking I need to do a Plus4 user port version so that I can test out code and allow SID usage. A userport card would be much easier, and if I supplied a ROM (or ROM image) then it could still boot properly.
It does mean this version wouldn't have the clockport so couldnt' do the ethernet/serial addon's. Im still trying to get a milling machine what would let me make real boards, and if this was possible then I could make the card here....Oh well... Still lots to do first.


Oh, and theres a new POLL. The results of the old one were pretty predictable with no one really interested in an external RAM expansion.

XeO3: Demo level progression.

I'm slowly progressing with the alien waves for the demo level and I think it's going okay. If I play without wanting to power up, you can more or less run through without getting hit (so far). But if I get greedy and want all the coins, then it starts to get tricky; which is the idea.

I've mapped out about one third of the level, although I've extended the start a little to make the introduction a little simpler - mainly so theres no backgrounds while you get used to moving around.

I also fixed the 2nd bug in my list from yesterday, where the collision radius wasn't being used.

So.... the demo is progressing slowly. Slow but steady! which is of course better than it has been; stopped and dead.

XeO3: Demo level....

I managed to get Luca to send the test level again, so I've now put that in and have started making new alien wave's. Heres the current plan for the demo.

1. Have the front end as is
2. Only have 1 weapon type but allow you to power it up.
3. Have the full weapon power up/down sequence


4. Only a couple of baddie types.
5. fix all current bugs before release.

Speaking of bugs, I've found another couple.

1. If you shoot a "group" of sprites too quickly, its possible to get multiple pickups. A group is only supposed to leave 1 item.
2. The baddie radius isn't used! This means all baddies have a fixed bullet collision area
3. If you collect a weapon pickup you appear to lose a bullet.
4. 2 character wide bullets don't always appear to hit baddies.

I've fixed the 1st and I'm about to fix the radius one, but I'll fix the rest later. I want to try and get some paths going.

XeO3: Demo level

I've been hunting around trying to find the demo level Luca built, and unable to find it, I went back to Luca's web page to see what it looked like. I was somewhat shocked to discover that he actually made it just over a YEAR ago!! So much for 2007 being the year of XeO3! I've done even less this year than last year! bugger.

XeO3: Here we go again.....

I've not done nearly as much as I'd hoped on XeO3 this year. I was convinced THIS was going to be it's year. A few things got in the way, my new found electronics hobby - which should still prove interesting to others once I start to finish things, and the fact I HATE makeing levels. Always have. Hate it! Hate it! Hate it!

But I think at the VERY least, I need to get the test level done so we can at least make some progress. For those that don't know, the plan is it make a 1 level demo with simple graphics but the game playing. This lets us (Luca and I) test the game mechanics out and at the same time, make sure we're not aiming to high (or low) on the difficulty side.

So...... to this end, I've decided to try and force myself to produce a new 1 level playable demo, and to release it AT THE VERY LATEST for Christmas. I really hope it'll be WAY sooner than that (a couple of weeks would be better), but Christmas at the latest.

Then once I get some feedback from everyone that's played it, we can both start to try and put the final game together.

..........well, thats the theory. So hands up if you believe one word of it?