I should post...

It's been a while. Been rather busy. I took a few weeks off from coding as I'd got to overload point then I had "life" things to do..

Not much to do to finish the two Beeb ports (one to A8 one to C64) but in the meantime I've taken on a bounty to port Taipan from the Apple to C64 although with a current bounty total of a massive $12 I'm thinking it might not actually progress much more..

I'm also helping out an old school (70s/80s) Atari employee to get his project done in time for CGE (Classic Gaming Expo) in Las Vegas at the end of the month.

Once the Atari project is out of the way I can get back to the ports and plod along with Taipan.


Pete

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

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

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

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

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

Progress

This is some simple cobbling together of codes from different A8 projects plus some Paradroid specific stuff. It's not as impressive as it looks, the sprite is just dumped on (no masking) just to see what it looks like with everything scaled down to 2:1 pixel AR.

Anyway, quick screeny...




Pete

RAM

Worked out some RAM usage for Paradroid. As it's going to have to be done a totally different way to the C64 I've ditched the 16k "map" that gets expanded into RAM and I'll have to do all the stuff he was doing using that via the tile maps instead. So far I'm up to about 32k with possibly some more savings but that's without the big robot graphics that are displayed on the console screen. Also missing from the calculation so far are bullets and explosions but they shouldn't be toooo much.

Looking quite good so far then for fitting on a base machine (when I say base I mean 64k, not 48!)


Pete

Mappy

Paradroid level maps, tiles, tile graphics etc are all ripped out and put in my code so now I can chose which level to display. I've got to do a multi-way remap of the tiles to get Ste's multicolour versions remapped to the same ones as the hires ones as he just redrew the tiles from a bitmap with all the tiles on so nothing actually matches up to the C64 charset. More PC app code there methinks but still all useful stuff as I can see this case coming up again in other games/graphics conversions.

Getting in the basics of the visual stuff for Paradroid should be fairly easy once the chars are remapped. The levels are done, I can do the console stuff (Robot display, level map etc) and the lift side on ship view. Even the sub/transfer game stuff is easy to drop in.

I really should do this mid-scanline image conversion as well at some point..


Pete

Bits and Bobs

As I've got sidetracked with Paradroid instead of just writing the probably small amount of code it would be to handle this mid scanline image stuff I'm having to add some more functionality needed for the app for it's main purpose, game creation/graphics manipulation rather than bitmap/image conversions.

I've re-worked my octree code to work in a simpler method to just count colours in an image and even using the slow VB.NET getpixel function it's still surprisingly fast, which is good. The idea is for most game graphics manipulation you'll want to be in some kind of indexed mode but there shouldn't be anything to stop people loading PNG or other non-indexed formats. Then before the code kicks in doing it's thing (remapping tiles, shrinking charsets, whatever) it needs to check the file format for indexed and if it isn't, be able to create some data from it that is, so knowing if there are too many colours (256) will let it know if some colour reduction is needed. For a fixed system (A8, C64, etc) that's not a massive problem because they'll be a fixed palette anyway and just running the image through the remapper will sort it out, other stuff will need to be allowed it's own palette.

Next up is the bitpattern selection box (sounds like chocolates). This will display a palette swatch, a dropdown (or other display) for available bit patterns (eg hires = 0 or 1, multicolour 2bpp = 00,01,10,11) and then let you select which colours on the loaded image match those machine internal bit patterns displaying the bitpattern over the colour as you click and probably doing a remap of the image to show what's happening. Probably also a good idea to have a colour picker to select the base colours for each bitpattern from the image.

Lots to do still but all this stuff goes well towards getting the app ready for Exploding Fist and some other projects I want to work on.


Pete

Paranoid Android

While I'm fiddling with the image stuff (and the long road to getting the app in a state where it's usable for it's original purpose) I decided to start messing around with doing an A8 version of Paradroid :)

Ste (STE'86 aka Steve Day) has already converted the hires graphics to multicolour, something which involves lowering the horizontal res by 1/2 and it looks pretty good. The A8, not having a colour attribute system just can't display Paradroid in hires. It would need more and better sprites (PMGs) and you'd basically have to build the screen out of those. Impossible.

All I've done so far is some setup code, a Display List, a couple of interrupts and set the top part of the screen to hires (I CAN use the PMGs there to change the text colour) and the bottom part to a mutlicolour scrolling window. I'll dump out the charset and a level later and drop it in and add some joystick based scrolling control so you can move around a level :)


Pete

Split decision

I've knocked up some 6502 source for the A8 display app. It has a couple of blank lines just before the picture (as well as the usual ~30) the first of which kicks off the displaylist interrupt. That enters, does a WSYNC then a few dozen NOPs which allows timing the start of the cycle counted line routine to a position I want it to start.

To begin with I've turned off PMG DMA so there's an extra few cycles on the line (most at the start) so there's plenty of room to do the 4 changes before the start of the visible screen. Then there's the positions across the screen to cope with. The problem with that is there are quite a few options on where those colour changes can take place. I think a simplest fixed approach will do to begin with and I'll see where it goes from there.

Now to change the code to a partial line version. That'll split the line into the same positions the splits happen and I'll have to come up with a couple of methods to decide which colour to change.


Pete

At a loss

One of the hardest things to do when reducing a high colour image down to VERY few colours is actually picking those colours. My original line remap code just used a histogram of most popular colours, took the top 4 and remapped each line to a palette of those. That's great for some images (lower colour source) but for high colour images with a lot of detail in it tends to lose a lot.

I'm now investigating original and modified diversity algorithms. Pretty simple code and it seems to sometimes produce an image that with dithering would turn out really nice. Other times it's nowhere near as good as that original most popular method.

I suppose I can leave all methods in the code and allow multiple passes, outputting an image for each and let the user decide. I'd also imagine most of these routines will produce a lot better result once a) dithering and b) PMG/mid scanline colours are added.


Pete

Quantification

I was pondering adding some auto line based A8 conversion to my app using the already written colour remapping when I saw Quantizator over on AtariAge forum so I thought there was no point, then last night I got bored of working on what I was doing so thought I'd just drop it in anyway. Turned out to be pretty easy to get the basics going, an hour of coding (plus some time for a blatant bug that took me ages to catch) and I'd got a 4 colour per line remapper.

It's not amazing so far and doesn't quite produce results that are as good as quantizator. I'm presuming that uses a method to find top used colours that are different hues whereas mine is a simple "most used" formula atm. I've also got no dithering to help spread colour matching errors.

Here's an example with a fairly simple C64 image.

Original


Converted


I think I'll continue messing with it as it's taken less time than I thought and add better colour choosing, F-S dithering/error spreading, PMGs for extra colour, maybe and/or mid-scanline colour changing.


Pete

The Colour of Magic

After adding colour matching to the app based on code I've written many times over the past couple of decades, stuff I've found on the web etc and then tweaking it a bit and thinking I was done, I ended up spending more and more time on colour.

An argument on a certain forum over which machine had a better palette, the Atari 800 or the Atari ST got me geared up to add some more functionality to the app. Simple things like the fact that none of the high end image apps seem able to remap to a fixed palette of anything over 256 colours because that's the most sensible maximum size for a fixed palette, it having one byte per pixel. A 512 colour palette would need 2 bytes per pixel (without bit packing) which is 16 bits which means you may as well write some raw RGB values in that pixels data instead. All that meant there didn't seem to be a standard image app that would remap to the ST's palette (9bit 333RGB = 512 colours). Also despite what one member (and I use that term with more than one sense) thinks just masking off bits of a 24bpp image doesn't have the desired result.

After faffing with all of that and posting remapped images in all kinds of formats and palettes and APAC 256 colour Atari 800 versions I thought I was done with colour. Wrong again :) The matter of picking complementary colours whilst designing a game came up as just having a shade of colour a bit "off" can ruin the look of a perfectly well done image. Soooo I've now added some more colour conversion functions: RGB to XYZ, XYZ to CIE-L*ab, CIE-L*ab to CIE-L*CH, some others, and all the functions to convert back. CIE-L*CH seems to be the one to use for automatically finding complementary colours so now the functions are all there I'll be able to fiddle with some kind of gui colour picker thing in that colourspace..

No more colour now! Different code!! :)


Pete