WIP : @!#?@!

[@username@]

thank you very much, looks great. Will go now in the source code. I send you later my VBL based sprite routine with also the SAT rotate function to avoid 5th sprite flicker. Maybe help you.

Look forward to it! Sprites will be next to work out!

In the meantime, here's the latest with all custom characters defined.

If you have a Salora Manager, Laser 2001 or CSL, you can check out the colour cycling discs and flashing arrows on a real machine!

[MADrigal]

Wow that looks impressive!! Just like the arcade game!

Great!

[@username@]

Wow that looks impressive!! Just like the arcade game!

The graphics are actually from the SG-1000 and TI99/4a.
To me, the TI99/4a graphics, as they are in Graphics Mode 1, are more suited to our slow 6502 - and the general concensus is that the TI99/4a looks best of the TMS99xx variants.

[@username@]

Damnz! - no sprites yet and already I have exceeded the 4K ROM boundary!

My initial thought was to use good old pucrunch and keep going.

Then my mind wandered, as it often does, to thoughts of is there a better compression scheme?

The biggest problem is lack of memory, so that ruled out most dictionary based compression schemes.

In the end I have come up with a fairly easy to implement compressor, as there's little computation and not too much bit crunching.

Note that this is a prototype only

I came up with the idea of having three stage, basic algorithm compression, and for a graphics mode 1 character set, the results are pretty cool.

The three stages are Move-To-Front, ZeroRunning and finally Elias gamma coding.

With respect to Q*Bert, I have called this creation - WTF!

These are the results for the 2048 byte mainpat.bin file.

• 7Zip - 452 bytes

• WinZip - 486 bytes

• PuCrunch - 621 bytes

• WTF! - 380 bytes

Next step - is writing the 6502 decompressor.

[Mobsie]

WOW!
Thats great, i will be happy to use in my coming Escape game and the Shamus clone because the maps and the multicolor take a lot space.

[@username@]

Ok - working 6502 decompressor!

Currently v0.4 uses 432 code bytes - which is not so bad.

[@username@]

WTF! works really well on small data sets.

Attached is the latest BIN which contains > 4K graphics, sprites and music!

[MADrigal]

Wow it works great!!!

A part from the graphics and sound, that are both perfect, what is your approach to the actual game routines (movement, score, AI, etc.)?

Are you willing to code everything from scratch, or do you feel that a "conversion" of the original TI99/Z80 code into 6502 code would be feasible?

Or do you believe that an approach through the C64 version (written in 6502 ASM) would be easier, and/or interesting?

[@username@]

Wow it works great!!!

Did you run it on real hardware? I'm never 100% sure of the VDP timings.

A part from the graphics and sound, that are both perfect, what is your approach to the actual game routines (movement, score, AI, etc.)?

The logic of the game is very well described here http://www.atarimagazines.com/cva/v1n2/qbert.php, so scoring etc will be the same as the table at the end of the article.
The modes of attraction, or not, are also described in good detail.

Are you willing to code everything from scratch, or do you feel that a "conversion" of the original TI99/Z80 code into 6502 code would be feasible?

I think we will end up with a hybrid. Parts which make sense to me will be coded, then verified against the other versions. This helps when I'm unsure, or they have a better solution.
An example of this is with the main Q*Bert sprite. Logically, you would change the sprite number in the attribute table when Q*Bert changes direction.
However, this is not how the original developers coded it.
They decided to just change the actual sprite data. While this may seem more time consuming, moving 32 bytes instead of 1, it does make managing the game play easier - as you are only tracking a single virtual Q*Bert's position.

Or do you believe that an approach through the C64 version (written in 6502 ASM) would be easier, and/or interesting?

Hmm. I prefer to stick with the SG1000/TI99/Coleco, mostly because the video and sound are the same - so no problem working out what's actually going on

[MADrigal]

Did you run it on real hardware? I'm never 100% sure of the VDP timings.

Unfortunately not. I have no hardware here in Canberra. I tested it on emulator only.

The logic of the game is very well described here http://www.atarimagazines.com/cva/v1n2/qbert.php, so scoring etc will be the same as the table at the end of the article.
The modes of attraction, or not, are also described in good detail.

Wow that's a saucerful of information and hints!

An example of this is with the main Q*Bert sprite. Logically, you would change the sprite number in the attribute table when Q*Bert changes direction.
However, this is not how the original developers coded it.
They decided to just change the actual sprite data. While this may seem more time consuming, moving 32 bytes instead of 1, it does make managing the game play easier - as you are only tracking a single virtual Q*Bert's position.

What you write makes perfect sense. I'd go with the sprite data change method. I suppose that's the standard method in 8-bit computer games. Also, moving 32 bytes inbetween two consequent VDP-cycles shouldn't be a big issue on a 2MHz cpu.

Hmm. I prefer to stick with the SG1000/TI99/Coleco, mostly because the video and sound are the same - so no problem working out what's actually going on

Will it be easy to "translate" the "jumping" routines from Z80 to 6502? I suppose there should be no big difference between the two as it's just math calculation, should use more or less the same ASM commands.

Thanks for the information.