Atari robot CES demo

[+playsoft]

This is kind of pointless but it was an exercise in learning 7800 programming and a chance to dig into how the Atari robot demo worked (basically loads of graphics data).

 

Thanks to @TIX for the new graphics, @Fragmare for the NES TMNT POKEY music. @dmsc for the LZSS compressor/POKEY player and @rensoup for RMT2LZSS.

 

You can take control of a robot by moving the joystick left or right, port #1 for the Atari robot, port #2 for his lady friend. Pressing the trigger will change their respective colour, pressing select will change the road colour.

 

Edit: to get audio on Concerto I padded it out to a 144K supergame cartridge.

 

werobots.a78

we_sg.a78

[BydoEmpire]

That looks really nice, I like all the detail like the orange robot's legs moving in a little bit as she walks.

[rensoup]

Looks like more folks are using LZSS on the A7800 than on the A8... how ironic considering Pokey isn't standard on the A7800 ?

[+DrVenkman]

Looks gorgeous on real hardware with a real CRT through S-video (UAV), but no audio when played on my Concerto with POKEY installed. 

 

 

[+playsoft]

7 hours ago, DrVenkman said:

Looks gorgeous on real hardware with a real CRT through S-video (UAV), but no audio when played on my Concerto with POKEY installed. 

 

 

Great, I did set the brightness for CRT as that is my setup too (but without the UAV). As she has thinner components the new robot needed to be slightly brighter than the Atari one.

 

You do get audio with Dragonfly and the A7800, JS7800 and BupSystem emulators. The first three worked straight out the box - I set the pokey@450 bit in the header and I could access POKEY at $450. BupSystem remained silent; the help says that for 48K ROMs nothing else is mapped. However it does support the XBoard interface and enabling POKEY through XCTRL got it going.

 

I'm holding off getting a Concerto until it is ready for final production and don't want to spend too much time second guessing what might be wrong. It could be that it sees the write to XCTRL and assumes that an XBoard will be providing the POKEY. Or possibly like BupSystem it might not map anything else for 48K ROMs. These are both simple things to try, I'll PM you some test builds to see if any of those work.

 

 

[+DrVenkman]

5 hours ago, playsoft said:

, I'll PM you some test builds to see if any of those work.

*ding ding ding* We have a winner!

 

 

 

[Jinks]

Nice to see real hardware tests on a Crt the only way it should be. Looks awesome! 

[rj1307]

On a regular, cheap LCD it is also great  

 

 

[+ZeroPage Homebrew]

1 hour ago, DrVenkman said:

*ding ding ding* We have a winner!

Damn, wish I had that build last night for the stream when I showed it off through the Concerto. I did play the music separately through the browser emulator so it was almost the same experience.

 

- James

[pacman000]

Looks like something from a 16-bit system. Cool!

[+playsoft]

I added @DrVenkman's winner to the first post.

[+playsoft]

On 2/26/2021 at 11:19 PM, rensoup said:

Looks like more folks are using LZSS on the A7800 than on the A8... how ironic considering Pokey isn't standard on the A7800 ?

Something that's more of an advantage on the 7800 than it probably is on the A8, is that with the LZSS8 player you only need a 256 byte buffer which is a benefit with limited RAM. However that does tend to increase the size of the data quite a bit. I was thinking of taking the SAP-R data and running a standard RLE on each stream to see how much data that generates, see if it's more or less than LZSS8 (I suspect more).

[rensoup]

On 3/8/2021 at 2:25 PM, playsoft said:

Something that's more of an advantage on the 7800 than it probably is on the A8, is that with the LZSS8 player you only need a 256 byte buffer which is a benefit with limited RAM. However that does tend to increase the size of the data quite a bit. I was thinking of taking the SAP-R data and running a standard RLE on each stream to see how much data that generates, see if it's more or less than LZSS8 (I suspect more).

here's the thread where LZSS originated: 

I actually tried RLE and yes the results were worse...

 

Wouldn't LZSS12 be a reasonable compromise ?

 

A perhaps interesting variation would be to compress each channel separately and use different buffer sizes ?

 

 

[Eagle]

@rensoup I used 12 bit compression and it takes 1152 bytes for buffers.  You have to remember that the Atari7800 only has 4kb of ram. 

[+playsoft]

It looks like it's the match offset bits that determines the size of the buffers required.

 

For a quick test I took @dmsc's lzss.c code and hacked the maximum offset macro (max_off) so that it was half the normal size (1<<(bits_moff-1)). I then changed lz12.s so that each stream had a 64 byte buffer and it played OK. This does waste a bit in the match offset and (I presume) it would be better to set both the match offset and match length to 6 bits but I couldn't figure out the changes to lz12.s for that.

 

With @Fragmare's TMNT track, LZ8 results in 6509 bytes of song data, LZ12 is 3080 bytes and LZ16 is 2796 bytes. With the above hack the LZ12 data increases to 3772 bytes but halves the amount of RAM required, 576 bytes of RAM instead of 1152. This seems like a reasonable compromise to me.

 

Wasting another bit resulted in 4376 bytes with a total buffer size of 288 bytes, which is still quite a bit smaller than the LZ8 data with more or less the same buffer space.

[rensoup]

On 3/10/2021 at 5:52 PM, Eagle said:

@rensoup I used 12 bit compression and it takes 1152 bytes for buffers.  You have to remember that the Atari7800 only has 4kb of ram. 

I didn't know that ?

[+DrVenkman]

On 3/10/2021 at 10:52 AM, Eagle said:

 You have to remember that the Atari7800 only has 4kb of ram. 

 

7 minutes ago, rensoup said:

I didn't know that ?

Still substantially more than the poor VCS with it's 128 bytes. ? But definitely an odd step backward from the 5200 with its 16K worth of DRAM. I guess GCC was building to a very small footprint and using SRAMs avoids the need for RAS and CAS signals and the support logic needed for that. Of course, I guess too the 7800 cartridge boards allow for on-cart RAM too though, right? 

[rensoup]

13 hours ago, playsoft said:

With @Fragmare's TMNT track, LZ8 results in 6509 bytes of song data, LZ12 is 3080 bytes and LZ16 is 2796 bytes. With the above hack the LZ12 data increases to 3772 bytes but halves the amount of RAM required, 576 bytes of RAM instead of 1152. This seems like a reasonable compromise to me.

Nice!

13 hours ago, playsoft said:

This does waste a bit in the match offset and (I presume) it would be better to set both the match offset and match length to 6 bits but I couldn't figure out the changes to lz12.s for that.

Weird, Shouldn't 

 

                        bits_moff = 6;
                        bits_mlen = 6;
                        bits_set |= 8;
 

do that ? I've not really played much with custom settings though

 

 

[Trebor]

3 hours ago, DrVenkman said:

Of course, I guess too the 7800 cartridge boards allow for on-cart RAM too though, right? 

Allowed and present in the original retail library:

Impossible Mission, Jinks, Tower Toppler = 8K RAM
Summer Games, Winter Games = 16K RAM

[+playsoft]

9 hours ago, rensoup said:

Nice!

Weird, Shouldn't 

 

                        bits_moff = 6;
                        bits_mlen = 6;
                        bits_set |= 8;
 

do that ? I've not really played much with custom settings though

 

 

Yes that comes down to 3489 bytes so the wasted bit is costing 283 bytes here. The lz12.s player would need changing for this, which sounds simple enough with one extra bit in the length and one less in the address, but I had a quick look and it wasn't completely obvious.

 

The other thing I tried was using LZ16 with 2 wasted offset bits for a total buffer space of 576 again. It indirectly wastes 2 length bits too as it won't find a match longer than the offset, so it's like moff = 6 and mlen = 6 but using 16 bit records. This comes out at 3986 but there could be a slight processing benefit since it deals in whole bytes.

 

In another project I took a 5.5K RMT file and that came out at 14.5K with LZ8. I put this in a switchable 16K bank and figured if I wanted more music I'd throw more 16K banks at it. Using LZ16 with 2 wasted offset bits bring this down to 6K. Using standard LZ12 it's 5K. So this seems like a good compromise; the RAM buffer is 50% smaller but the music data is only 20% larger and 2 such tracks would easily fit in a single 16K bank.

 

[rensoup]

I remember now vaguely that I tried different settings last year when I was adding sound to PoP, in my case because it's all RAM (128KB) it never made sense to use the smaller playback buffers... I have lots of small tunes tunes so it's better to just use the best compression with the biggest buffers as all the tunes benefit.

 

10 hours ago, playsoft said:

Yes that comes down to 3489 bytes so the wasted bit is costing 283 bytes here. The lz12.s player would need changing for this, which sounds simple enough with one extra bit in the length and one less in the address, but I had a quick look and it wasn't completely obvious.

 

Yes I think it's because it's not purely a bit stream where the 7bits offset is followed by the 5bit length...

 

if you look at the compressor for the case where the total bits is between 8 to 12, the offset is output as a byte with 1 bit from the length, then the length is combined with some bits of the next(previous?) length... 

 

This allows the decompressor to read full bytes all the time, it'll read the control byte which tells what the next 8 "items" are (single new bytes or buffer copies). If it's a copy, it'll read the offset byte + 1 bit from the length then read the length byte and combine it with the unused length bits from the previous length byte (nib_data)

 

Or something like that I believe... But yeah it'll be a little messy to change it to 6/6

 

[CrazyChris]

On 2/25/2021 at 7:12 AM, playsoft said:

This is kind of pointless but it was an exercise in learning 7800 programming and a chance to dig into how the Atari robot demo worked (basically loads of graphics data).

 

Thanks to @TIX for the new graphics, @Fragmare for the NES TMNT POKEY music. @dmsc for the LZSS compressor/POKEY player and @rensoup for RMT2LZSS.

 

You can take control of a robot by moving the joystick left or right, port #1 for the Atari robot, port #2 for his lady friend. Pressing the trigger will change their respective colour, pressing select will change the road colour.

 

Edit: to get audio on Concerto I padded it out to a 144K supergame cartridge.

Do you by any chance have the source code for the original demo?

[CrazyChris]

I'd love to see the original version of the Demo ported to more systems!

[+playsoft]

On 10/19/2023 at 6:12 PM, CrazyChris said:

Do you by any chance have the source code for the original demo?

No I don't.

[CrazyChris]

1 hour ago, playsoft said:

No I don't.

Thanks anyway.