Jump to content
playsoft

Atari robot CES demo

Recommended Posts

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

  • Like 16

Share this post


Link to post
Share on other sites

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

  • Like 1
  • Haha 2

Share this post


Link to post
Share on other sites

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

 

 

IMG_6167.JPG

  • Like 3

Share this post


Link to post
Share on other sites
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. 

 

 

IMG_6167.JPG

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 [email protected] 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.

 

 

  • Like 2

Share this post


Link to post
Share on other sites
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! :)

 

 

 

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites
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

  • Like 2

Share this post


Link to post
Share on other sites
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).

  • Like 1

Share this post


Link to post
Share on other sites
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 ?

 

 

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites
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 😮

Share this post


Link to post
Share on other sites
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? 

  • Like 3

Share this post


Link to post
Share on other sites
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

 

 

  • Like 1

Share this post


Link to post
Share on other sites
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

  • Like 3

Share this post


Link to post
Share on other sites
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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...