Good Ninja

Found the bug in LN that was causing the game to draw a corrupt screen and loop round an odd sprite routine. Basically after lots LOTS of debugging I found out I was storing a byte in RAM riiiight where the 1st byte of the table of screen maps for LN was. It was "left over" from Arcadians code and should never have been happening.!

Anyway, that's working and running the game now and I dumped out the LN 1 files as well and tested that. Seems to work as well and just needs all the usual graphics munging, line address fixing, sprite code hacking.

I also wrote a tool to find graphics in beeb files. It'll let you change screen mode (the different modes have different graphics formats), change the width of the display and an offset into the data. It's been quite useful already for finding stuff in the LN files.





I reaaaaaaaly should get back to Arcadians!! :)


Pete

Badninja

Last Ninja 2 now "runs".

Not sure why I chose 2 and not 1, oh well it was there on my drive. It's another faaaairly easy load the parts and run it thing apart from the fact it wasn't drawing the 2 sprites on the title screen then crashed when I went to the game. Turns out that I'd flummoxed myself watching the beeb code use the ROM commandline interpreter to load in level data (something other games also do) but I couldn't work out wtf was going on until I realised the app I use to extract the files from the beeb disk images had renamed 1.LEVEL-A and 1.LEVEL-B to LEVEL-A1 and LEVEL-B1. I was ignoring the LEVEL-B1 file because I presumed it was for level B, as you might. Now I realised it's actually 1-LEVEL then A and B files and they do load at their normal DFS load addresses it all suddenly worked.

All this means atm is there's yet another game to hack through the data to find the relevant graphics stuff to be munged into A8 format and the draw routines so that it'll draw in the correct RAM locations. I have actually found the code that calculates the new charline offsets so at least that's something :) Not sure people want beeb Last Ninjas though, they're not exactly astounding to look at, although with some palette changes it isn't quite as garish as it looks on the beeb.


Pete

Seemed like a sound idea

Urghh!!

That's all I've got to say for a whole day wasted rewriting the sound code when I was 1/2 asleep :) Then faffing around with MESS because a) it's multi format b) it's got a fairly nice debugger and I'd rather deal with remembering one set of debugger commands instead of one lot for BeebEM, one for A800Win and sometimes Altirra as well. After messing around for a few hours and finally asking on the MESS forum I find out disk images haven't worked in the last 3 versions of MESS, tape images have never worked. Kind of important to be able to LOAD things into an emulation :( Oh well.

So today I rewrote the sound code AGAIN and this time it actually spits out sound again and sounds pretty much like it did before I decided to rewrite it but with one important difference, the arpeggio type sounds on Exploding Fist work now :) It now buffers up to 5 notes for each channel just as the beeb is supposed to.

Now to add envelope support. Yeesh! I'm not totally sure why I'm bothering with this stuff as the beeb tends to play notes in tune no matter which octave and the atari doesn't. I suppose it'll be ok for sound effects and if music (what little there is in beeb games) is really off I can just intercept the calls, ditch the data and play a RMT tune instead.


Pete

Fisting !?

After some shenanigans over the past few days I'd almost ditched all this BBC porting stuff, but decided to carry on with it regardless :)

I thought I'd give some other games a try and after some sliiightly more difficult hacking I managed to get exploding fist working...



The screen is all messed up (as with the other games I've been working on) because the BBC draws to it's own RAM in a linear character bitmap format (like the C64) but that's impossible to display on the Atari so everything is currently offset AND the pixel formats are different so everything looks like garbage :) The most CPU friendly way to fix this is hack the BBC game code, find where it stores graphics data and do the old jiggle pixel pass on it.

I've also done a bit of work on sound but it's off at the moment. The second part of the Exploding Fist tune doesn't play correctly, it should be more of an arpeggio and instead it's got pauses between each note.

I'm pretty sure after some investigating and hunting down docs that this is because the Fist code calls a ROM function to do with the sound channel and waits for it to return 0x0F. I presumed that meant "sound has finished playing" when after just finding some more docs on it it's actually the free buffer space. SO, I didn't realise/remember you could (or rather, do) queue sounds to a buffer on the beeb which kind of explains what's going on with the odd sound timings. Basically MY code should be triggering new sounds from the buffer NOT playing them one at a time as they come in from the Beeb code. :)

Some other games I tried quickly and seem to be running ok are Alien 8 and Starship Command. Starship particularly is a great little game (or at least my terrible long term memory tells me so).


Pete

BBC Micro?

So, I couldn't sleep a couple of nights ago and was (for some reason I can't remember) watching a video of a BBC Micro game called Ghouls. I remember always quite liking it but that it was too hard and from watching people's progress (or lack thereof) on youtube I think my memory served me correctly :)

Anyway, I began to ponder how I would go about porting a BBC (beeb) game to the Atari 800. I know some games have their source code available and people have hacked at that, rewritten parts, added bits and pieces and got a working Atari game as they are after all the same CPU. I decided to try (for a laugh) just loading in the file for Arcadians (Acornsoft's Galaxian clone) straight into the A8's RAM at it's beeb load address and run it, see what happened...

Of course not much happened because it was expecting a different computer to be there with ROM functions it was trying to call etc. So, I got some beeb docs and manuals/websites and worked out where these ROM functions vectored through and wrote a couple of the more important ones (basically ones Arcadians was calling and expect a reply from). I knew from the docs I'd found the normal text screen was at address $7C00 in RAM so I pointed an A8 display list at it and loaded in a font for it to use and PRESTO there was the title/instruction screen for Arcadians :)

A few more hours work and I had the game running although with messed up graphics and no proper screen display in the bitmap mode it was using. By the next night (last night) I'd realised why the sprites weren't drawing correctly and had written a routine to alter the sprite data in the beeb file to an A9 friendly version.

Today I'll be writing a proper OSWRCH routine. OSWRCH handles all text printing (printing as in to the screen) and it's used for stuff like the score, rank etc in Arcadians. That shouldn't take long (although needs a few other ROM functions writing as well) so after that (or maybe before, so I can see what's happening a bit better) I'll do up a proper display list with DLIs every 3 lines to change the character base to give a close approximation to the beeb bitmap screen mode (something more akin to the C64 bitmap mode). To get the screen displaying totally correctly though I'll need to hack the beeb sprite code to alter the way it calculates a new line. I know where all the code for the sprite drawing is so hopefully that won't be too hard.

Hopefully with not much more work I'll have a fully working beeb conversion done :)

Pete