Saturday, April 17, 2010

Size DOES matter

As well as Lunar Jetman, Knight Lore and various other projects I'd already got on the go I decided to have a crack at some Beeb coding. What I'm doing will be useful for porting a C64 game to the A8 as well as the Beeb.

The game I have in mind (I'll keep it quiet for now) is going to be somewhat tight for RAM on the Beeb (in fact unless I do some disk loading it probably won't fit) and as such I've already got into the mindset of smaller is better for the Beeb code so I'm kind of writing things twice and counting bytes as I go. Eg is it better to have a lookup table or some code to do the same? Of course it depends on the complexity of the calculation that would be replaced with the lookup and if that table can be small enough to be worth replacing code with. One routine I just wrote worked out as 31 bytes of code Vs 24 code+table. Win for tables that time then :) It might even be possible to make that 23 bytes by shortening the table and masking the index into it as it's a repeating table.

Anyway, I've got the Beeb displaying a custom screen mode, 16 colours (ok, technically that mode is 8 + 8 flashing) 38 "chars" wide and 25 lines high. I think I can get away with the 32 pixel high panel being 4 colour which will save another bit of precious RAM. Screenines when something is displaying properly..


Pete

Wednesday, April 14, 2010

C64/Beeb

I did some more work on a version of my Beeb jacket for the C64 so I can do ports to that and A8. Got Knight Lore working yesterday as I knew it worked on the A8 and a few people have been requesting it after the previous attempt by someone suddenly went quiet, which was a shame as it looked almost finished.

Here's a vid of it running..



Some bits and bobs needed to finish it, a bit of colour on the panel, some sound (my beeb code is probably trying to make sounds but I've not told it how to do so on the C64), title/loading screens etc.


Pete

Monday, April 12, 2010

Loony Jetman

So it looks like my first Beeb to A8 release will be Lunar Jetman. It's an easy one because the screen is only 256 wide, a mode which maps exactly to the A8 so there's been no need to hack drawing code (almost no need anyway) to make it display properly. The only bit of drawing code hacking has been the power/fuel/time whatever they are bars which draw with code but thanks to nice debuggers with "break on write" commands I found the code and converted it to A8 pixel format. There was a bit of multicolour graphic for my conversion routine to run over (the top display "panel") and now everything looks pretty spot on...

I've asked someone to attempt to convert the loading screen to A8 so while I'm waiting for that I decided to hack on something else for a while. I chose Cybernoid, for a couple of reasons, one being I'm contemplating a Beeb port while I'm at it (doing a port to A8 that is). Once again thanks to debuggers with break on write I stopped the code as it wrote the first byte of a new screen then traced it backwards down to the point it enters some code with a "screen" number. From there I found the screen pointer index, the screen tile maps and tile graphic data. Also worked out a simple runlength flag in the maps. So, I can now draw levels on any machine I fancy :)

I've messed around with a couple of Cybernoid screenshots in Gimp, recolouring and stippling them and I think a Beeb version is certainly possible graphically although it'll have to be 8 colour mode, something that's rather a memory hog and while there isn't a lot else to the game the screen maps alone take about 8k! I think a disk stream for each new screen might be the only way to go. afaik you can only ever go one way through Cybernoid?! so it's just a linear thing. Go to new screen, read some bytes (each screen would only be a maximum of 190 bytes) whilst that screen is flown through and have that new screens map ready for when you exit the current one.

Oh well, lots to think about, lots to do, lots of games being worked on or at least thought about.


Pete

Sunday, April 4, 2010

Been a while, been foreveeerrrr!

Not been updating as regularly as I'd like (nobody is reading anyway but it's nice as a kind of diary).

I've been constantly busy checking out the best of the best of Beeb games that don't already have A8 versions, dumping the files off the disks and including them in my code. I've now got the code down to 2 main files, a global "Beeb jacket" which handles all the gubbins and a game specific file that has the incbins, the execution address and a couple of macros called from the jacket file that allow pre-beeb setup (patching files etc) and a VBI routine.

I've probably got about 15-20 games running now and pretty much playable but they all still need the in-code hacks to make them draw nicely. Half of them I've found the graphics in the file dumps with my beeb graphics finder app (posted about last time) and fix those up pre-execution.

Over the last week, as well as taking a few days off coding due to burn out, I've written some custom SIO code for the A8 (basically disk loader) which means I can load files at beeb game runtime without upsetting the system too much by turning the ROMs back on and trashing over 1/2 the Beeb's lower area RAM. To go with that code I've written a commandline ATR creator that lets you specify the boot sector file, an autorun file (that the SIO code will boot), some other files (whatever else is needed for multi-load games etc) and the output filename. It's all working as expected so far it just needs additional A8 code to actually do file loading rather than just sector reading.

Once all the file stuff is done I'll go back and start hacking around with the Beeb games code and start fixing draw routines.

P.S. Yes the title of this post is a clue to one of the working games.

Pete