XeO3: Little or no progress at 30,000 feet.

Damn planes. The seats were just too close together to allow me to do any work when flying back, which is a real shame. 11hours of watching tv when I could have been doing XeO3.
I have started the weapons system which should be table driven so pretty easy to alter, but I didnt get very far as I couldn't even open the laptop fully as the guy in front had reclined his seat a little. The flight from Amsterdam to Edinburgh was so bad, I couldn't even put the little try down properly!! I wonder what the chances of flying busness class would be, the extra room would make these trip bareable, especially if I had room to code!

On a more positive note, I sent Luca the version I'd fixed to try and break, and he said it was working great under both emulation and on the real machine so it looks like I may well have fixed the really nasty bug when done!

Its been a great trip though, I've really enjoyed it down here. Seoul is huge and theres loads to see/do. I guess we were fortunate to have such good escorts because they've helped make the whole experiance just great fun. It'll be a blast when they come over and we can take them on a tour of scotland!

More 'o the same....

I've not had much chance to do XeO3 stuff as our Korean hosts have been taking good care of us and keeping us busy! I did get a chance to help Luca briefly last night with a bug he's had for a while; he seemed quite happy about finally solving it. We've had a good day today going over all the stuff with the programmers here, so its been a very constructive day. They took us out for a really nice meal last night that seemed like an indoor barbeque, which was fab! I'm looking forward to returning the favour when they all come up to Dundee in the near future.....

Seoul...day 2

Had a lite day today, morning meeting and then a tour of the city....well, half a tour. We started later, so missed some of it. Good to see though. Today is a full day of meetings and discussions - should be fun! Our Korean hosts are great fun, and we're all enjoying things hugly at the moment - lets see if that lasts as they start to ask for the impossible! :)

Seoul!

First day here....Grabbed something to eat - a nice simple stalke, we want a tour guide before we try any native stuff! Pretty good though. Its now around 8pm here, so early night and ready for work tomorrow. I dont think I'll get much done tomorrow either though, as we're getting taken out on the town - Karaoke becons I think :)

It was good to finally meet the guys that I've been speaking to for the past year! Sangwook (the coder I've talked to mainly) is much younger than I thought.....or perhaps Im just older. :(

XeO3: 29,000 feet up!!

I managed to do a couple of hours work on the flight over here, and with all that work I only managed to find found 1 nasty bug, and 1 very minor one.... seems like a lot of effort for that! I still havent found the major but, although this one "could" have caused it as it was writing to rubbish locations. I discovered a random memory overwrite and this bug could have made it, but Im not sure as it was no wher near the sprite system, and I was almost certain it was in there.

This bug was pretty simple and was just a matter of the player ship graphic not being reset after the death sequance, which meant it was trying to render a random graphic outwith the 167 sprites, and since they are now all done with sprite lookups, it was reading a doggy address. So one done, and I'm sure one still to go.....

Ready.....set.............GO!

Almost time to go, Im collecting all the bits I need for the trip, including minus4 source and of course XeO3. I dont think I'm going to get much done, but I hope to at least fix the bug thats holding me up. I'm also taking the RetroEdit source and might try and get basic editing done - I hope so at least.

New toys!!!

I just recieved my new Dell Laptop! Its very cool, it has great battery life and is much lighter than the one I got from the work. When I head off to Seoul next week, I'll be able to take some Xeo3 fun with me! I'm looking forward to using it on the plane, and as its an 11hour flight, I should manage to get a full 6 or 7 hours use from it. After that I have my Cowan video player which runs for 10 hours!

So even if the flight sucks, I should have some fun on it anyway!

Minus4w - debug

I've finished updating the debugger with everything I wanted (for now), and it feels pretty good now - kinda like the old debugggers we used to have in the old days when we used PDS (a remote PC to C64/Amiga/ST/etc. devkit). I've listed all the new changes below, and the only thing missing as I said yesterday is a watch window, which I could get by without for now.

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

Minus4w

I've been updating minus4w to allow better debugging, so now I can scroll the disassembly view around and have the current PC update the window as needed. This makes it easier to follow code and debug. I should have done this ages ago, but as usual I couldn't be bothered. Still, its a good change and with the symbol table output by SNasm, it makes for a pretty good devkit. The only thing missing now is a watch window. Theres not a lot of space for that, so I may not add it... but I could toggle the watch window with the memory dump....

Im not sure who else would use this as most folk dont really use SNasm and Minus4 for development, so I dont know when I do a new relase....

Theres a couple of other changes I think I'll make later to allow a bit more ease of use, but these are minor compared to these, but it's all good!

6502'ing...

I was doing my demo for the demo-comp, and I came across an instruction my debugger didn't know about. It was a simple omission but got me thinking about undocumented opcodes and memory in general. Minus4 nukes memory to 0 before starting up, but this is hardly ever correct, Yape uses a $ff,$ff,$00,$00 pattern which is much closer to the real thing. But in actual fact, each Plus/4 is totally different. I have one here that hardly wipes memory at all. In fact, I can switch the machine off/on and still have the program completly in memory. I used this a lot when growing up to get around the "no software reset" hacks software houses used to put in, and it let me hack them quite a bit more than I should have been able to.

I was also looking for ways to get more bang for my buck in my demo, and looked at the XAA opcode. This is listed on various sites as a normal 6502 undocumented op, but doesn't appear to work on the Plus/4 - or mine at least. Yape also doesnt use it, so I started to wonder what the plus/4 does have. I use lax in XeO3 to help speed up my sprite routine, and that appears to be working fine, but I may be treading on thin ice as it were, as you never know when you cross the line.

Still, I guess as long as you try these out on a real machine, it shouldn't be too bad....