New 512 bytes demo released: Gar Nix

[+SvOlli]

Hello everyone,

 

just wanted to let you know that I released another 512 bytes demo. This time the focus is on getting a lot of raster splits while still displaying some logo (which hasn't been done before, as far as I can tell).

 

The platform used is CommaVid, so I can pre-calculate some data. There is also a version running on SuperCharger available, but since RAM access there requires more effort, so that version is more that 512 bytes in size. It won a forth place in the 512 bytes compo competing with systems like Amiga and TIC80.

 

The homepage of the demo is https://xayax.net/gar_nix/. You can also watch the demo in the browser thanks to Stellerator.

[JetSetIlly]

Nice! I love to see scene demos on the 2600. But newbie question, what is CommaVid?

[+Al_Nafuur]

12 minutes ago, JetSetIlly said:

Nice! I love to see scene demos on the 2600. But newbie question, what is CommaVid?

CV is a bank switching type with extra RAM:

https://github.com/stella-emu/stella/blob/19da02fb9c8dc48f4f9634e4a5e9ed02ab395a60/src/emucore/CartCV.hxx

[JetSetIlly]

8 minutes ago, Al_Nafuur said:

CV is a bank switching type with extra RAM:

https://github.com/stella-emu/stella/blob/19da02fb9c8dc48f4f9634e4a5e9ed02ab395a60/src/emucore/CartCV.hxx

Interesting. Thanks.

[+SvOlli]

Back in the days, the CommaVid bankswitching has only been used in two carts. One is an implementation of Conway's Game of Life, the other one implements a very simple interface to type in your own code and run it.

 

I used it, because instead of dumping tables into ROM, I can use the RAM to create those tables there. So without the CommaVid RAM, this same demo needed to be implemented in 1K of tables + ~256 bytes of code.

 

And if you like 2600 demos, you might want to take a look at the Atari VCS section on pouet.

[JetSetIlly]

1 minute ago, SvOlli said:

I used it, because instead of dumping tables into ROM, I can use the RAM to create those tables there. So without the CommaVid RAM, this same demo needed to be implemented in 1K of tables + ~256 bytes of code.

Thanks for the answer. Does CommaVid offer any advantage over other cartridges with onboard RAM?

 

[Mr SQL]

7 hours ago, SvOlli said:

Back in the days, the CommaVid bankswitching has only been used in two carts. One is an implementation of Conway's Game of Life, the other one implements a very simple interface to type in your own code and run it.

 

Awesome demo! At 512 bytes is this small enough to be keyed in through the CommaVid interface?

[+SvOlli]

On 10/5/2022 at 12:45 AM, JetSetIlly said:

Thanks for the answer. Does CommaVid offer any advantage over other cartridges with onboard RAM?

It comes as a deal package: advantages with disadvantages.

pro: 1k is the largest I've seen so far with "direct access" via STA. (SuperCharger offers 6k, but the way data is written to RAM is strange and definitely due to a simple hardware design.)

pro: you can execute code in it (the original SARA chip does not allow that, it's too slow.)

con: only 2k of ROM, no switching in/out of RAM, no ROM banks to choose from.

 

On 10/5/2022 at 7:48 AM, Mr SQL said:

Awesome demo! At 512 bytes is this small enough to be keyed in through the CommaVid interface?

Nope, because my code needs to reside in the ROM using the RAM for data. Also have you ever tried the CommaVid interface. Yes, it's better than nothing, but everything else is better than that CommaVid.

If you want to type something in using the CommaVid interface, I suggest to go for the 32 byte demos implemented using my dipswitch board. See hard2632 for details. Those should be easy to type in, being only 32 bytes in size, and you might also skip the initialization code, since the hardware is already set up properly.

[JetSetIlly]

24 minutes ago, SvOlli said:

pro: you can execute code in it (the original SARA chip does not allow that, it's too slow.)

Gosh. That's really interesting. I'd not considered that as an issue at all.

 

I'd like to model what the results of that look like in emulation. @Thomas Jentzsch is the limitations of the SARA chip with regard to speed something the Stella team have thought about at all?

[Thomas Jentzsch]

31 minutes ago, JetSetIlly said:

I'd like to model what the results of that look like in emulation. @Thomas Jentzsch is the limitations of the SARA chip with regard to speed something the Stella team have thought about at all?

No, I don't think so.

[+SvOlli]

I'm pretty sure it isn't implemented in Stella. Also because other solutions mimicking the SARA chip, like the Harmony and Uno 2600, do not have this limitation. There calling into SARA RAM just works like the CommaVid (only less RAM). About other carts with RAM besides from the ones mentioned above (CBS comes to mind), testing will be rather problematic, because I haven't seen any option so far to run custom code on them.

[Mr SQL]

8 hours ago, SvOlli said:

It comes as a deal package: advantages with disadvantages.

pro: 1k is the largest I've seen so far with "direct access" via STA. (SuperCharger offers 6k, but the way data is written to RAM is strange and definitely due to a simple hardware design.)

pro: you can execute code in it (the original SARA chip does not allow that, it's too slow.)

con: only 2k of ROM, no switching in/out of RAM, no ROM banks to choose from.

 

Nope, because my code needs to reside in the ROM using the RAM for data. Also have you ever tried the CommaVid interface. Yes, it's better than nothing, but everything else is better than that CommaVid.

If you want to type something in using the CommaVid interface, I suggest to go for the 32 byte demos implemented using my dipswitch board. See hard2632 for details. Those should be easy to type in, being only 32 bytes in size, and you might also skip the initialization code, since the hardware is already set up properly.

Wow that programmable board with 256 dip switches is really cool! You can see the whole tiny program just like on a punch card.   

 

I have not tried the CommaVid yet but it is very intriguing, why can't your demo code run in RAM next to the RAM table if the CommaVid RAM is fast enough to run code? 

[alex_79]

13 hours ago, SvOlli said:

I'm pretty sure it isn't implemented in Stella. Also because other solutions mimicking the SARA chip, like the Harmony and Uno 2600, do not have this limitation.

There are other cases where modern implementations have less restrictions. E.g., according to US patent 4,485,457, CBS scheme requires data bus D0 = 1 when accessing the hotspot:

Quote

...In the present embodiment. the logic is responsive to the data line D0 being in a high state (i.e., the signal on data line D0 is a binary “1") and the other data lines inactive. To select Page 0, the microprocessor accesses the hexadecimal address 1FF8 with data line D0 in a high state, causing page select decode logic 82 to generate a strobe signal on one of its three output strobe lines....

So bankswitching should only happen when you write to the hotspot address a value with bit 0 set (not sure if bits 1-7 are relevant). IIRC, modern flashcarts and emulators implementations only check if the hotspot is accessed and ignore the data bus, thus allowing bankswitching also on read operations.

 

 

13 hours ago, SvOlli said:

About other carts with RAM besides from the ones mentioned above (CBS comes to mind), testing will be rather problematic, because I haven't seen any option so far to run custom code on them.

In case of CBS carts, the ram, rom and bankswitching logic are integrated into a single chip, so reusing that for an homebrew game would require some extra address decoding to select the chip only in the ram area, and separate eprom and bankswitnching logic.

 

If the goal is only to test if code can be run from the cbs ram, you can copy the test code into riot ram and then swap cartridges before it gets copied into cart ram and the actual test starts, similar to how some cartridge dumpers work.

 

 

 

 

As a side note, I played with the Magicard a bit in the past, and I actually like it a lot. Inputting code with it is not that bad, IMO. I concur that the keypads aren't the best for fast typing, but they're usable nonetheless, and I find the keys layout more intuitive than the one e.g. in the Kim-1 (which in its basic configuration shares quite a few similarities with the Magicard). The audio "beeps" compensate for the lack of tactile feedback of the keys. The "hex dump" and especially the disassembly function help to check the typed code for errors.

In my past attempts I couldn't make the cassette interface described in the manual to work, but I plan to give it another shot some day.

You only have about 750 bytes for  code, as part of the ram is used by the monitor program, but I think that it is a great learning tool. Having to assemble your code by hand with paper and pencil (at least you don't need to calculate relative addressing for branch instructions, as the monitor has a built-in function that calculates those on-the-fly! 😄) gives a better understanding on how an assembler works, which might be useful.

 

[+SvOlli]

19 hours ago, Mr SQL said:

why can't your demo code run in RAM next to the RAM table if the CommaVid RAM is fast enough to run code? 

I'm using four tables, 256 bytes each: sinewave, color table, flash effect, decoded XAYAX logo for speed access. With some overlapping those can be wrestled down to 768 bytes, leaving 256 for the code running. It might be possible to overwrite some generation code after it's been used. But I'm not interested in optimizing the code that way, it was enough effort to shrink the code to 512 bytes.

You've got the code, feel free.

11 hours ago, alex_79 said:

As a side note, I played with the Magicard a bit in the past, and I actually like it a lot. Inputting code with it is not that bad, IMO.

You're right. It was outstanding for it's time. But with the arrival of the SuperCharger (and makewav), the Magicard became somewhat obsolete as a tool for a hobbyist.

 

Also, thanks for your details about the CBS carts. Very interesting to read, also realizing that emulation (Stella/Harmony/Uno2600) is a bit simplified, as with the SARA chip.

[JetSetIlly]

10 hours ago, SvOlli said:

Also, thanks for your details about the CBS carts. Very interesting to read, also realizing that emulation (Stella/Harmony/Uno2600) is a bit simplified, as with the SARA chip.

 

It's an interesting point. However, for practical purposes, we might argue that the CBS protocol as it exists today under emulation is "correct". There are no consequences with the simplified protocol when applied to Omega Race, Tunnel Runner and Mountain King, that I can see. In other words, it seems that those ROMs were created without the additional detail in mind.

 

(Are there any other CBS/FA ROMs?)

 

On the other hand, if there are practical advantages for the data bus restriction then there is a good case to be made for implementing the "full" protocol in emulation, so that new developers might explore it further.

 

But it's unclear to me whether any advantage exists; or whether the data bus detail described in the patent is simply a novelty introduced for purposes of the patent.

 

 

[+SvOlli]

I agree to that. There is no benefit from implementing the restrictions artificially. For the ones who want to code "historically correct", they can still take it into consideration. I did this with "Bang!" and it worked out well, when building a cartridge with an original SARA.

41 minutes ago, JetSetIlly said:

(Are there any other CBS/FA ROMs?)

There is at least one demoscene production. And I can remember seeing a techdemo done by Andrew Davie.

[Thomas Jentzsch]

54 minutes ago, SvOlli said:

I agree to that. There is no benefit from implementing the restrictions artificially.

I am not so sure here. IMO an emulator which is (also) used for development, should at least fail if e.g. code is run in SARA RAM. Else people might develop "zombie" code, which is meant to work on original hardware, but only works in an emulator.

 

IMO the situation is similar to ROMs missing proper RAM initialization. They run perfectly in Stella as long as RAM initialization is not randomized. But they (may or may not) fail on real hardware and definitely in Stella if RAM initialization is set to random. Same with varying scanline counts, which cause problems on real hardware.

 

Unfortunately there are still too many developers which are not using Stella's developer settings.  E.g. the @ZeroPage Homebrew streams are full of screen rolls or complete sync losses. Even Audacity Games missed this as you can see from some of the reported bugs of Circus Convoy.

 

@SvOlli & @alex_79 Do we know which extended RAM is too slow for code execution (besides SARA) and which is not (besides CommaVid)?

Edited October 8, 2022 by Thomas Jentzsch

[+SvOlli]

I totally agree to that, except for the SARA chip, since everyone who uses RAM on a cartridge does not use the original SARA chip anymore, but a reimplementation without the limitation. You can even the latest Perifractic Retro recipes, even Atari branded carts don't do this.

Maybe one could think about using the term "SARA+" for the ones that allow code execution.

 

Nevertheless, I'm also outraged on bad sync stuff and hoping for an initialized system. I'm maintaining a collection of all scene demos released on the 2600. Stuff that only works in an emulator does not get included there. I always ask myself: don't they have any pride in their work?

[Thomas Jentzsch]

2 minutes ago, SvOlli said:

I totally agree to that, except for the SARA chip, since everyone who uses RAM on a cartridge does not use the original SARA chip anymore, but a reimplementation without the limitation.

But are they aware of the original limitation? Would a demo running code in new SARA RAM be accepted as running on original hardware?

[Thomas Jentzsch]

3 minutes ago, SvOlli said:

Nevertheless, I'm also outraged on bad sync stuff and hoping for an initialized system. I'm maintaining a collection of all scene demos released on the 2600. Stuff that only works in an emulator does not get included there. I always ask myself: don't they have any pride in their work?

Totally agree on this. Not only for demos but also for homebrews. And usually the laziness also shows in the whole result. So when a homebrew rolls in @ZeroPage Homebrew streams, I lose a lot of interest immediately. And my first impression is very frequently correct. 

[JetSetIlly]

1 hour ago, SvOlli said:

I agree to that. There is no benefit from implementing the restrictions artificially.

 

I think implementing the CBS protocol as per the patent is maybe artificial but in the case of SARA RAM I think there are benefits to implementing the limitations in some way - even if it's just a warning on the screen in "developer" mode.

 

26 minutes ago, SvOlli said:

Maybe one could think about using the term "SARA+" for the ones that allow code execution.

Are there any examples of SARA ROMs (meaning F4 etc.) that have made the assumption that it's okay to execute code from the cartridge RAM?

 

Edited October 8, 2022 by JetSetIlly

[+Andrew Davie]

17 hours ago, SvOlli said:

And I can remember seeing a techdemo done by Andrew Davie.

I'm obviously getting too old to remember things. It's worrying.

[+SvOlli]

I also might be wrong, but I think it was very similar to what Shadow did in his demo: using the 256 bytes as a framebuffer for 48x something graphics, rendering something from Elite. But it was already not new, when I started VCS coding in 2011.

[Thomas Jentzsch]

6 minutes ago, SvOlli said:

I also might be wrong, but I think it was very similar to what Shadow did in his demo: using the 256 bytes as a framebuffer for 48x something graphics, rendering something from Elite. But it was already not new, when I started VCS coding in 2011.

Which demo are you referring to?

[+SvOlli]

It was some kind of tech demo that I saw once like more than ten years ago. I vaguely remember that did some rather nice stuff, displaying an animation, also remembering it being something like ship of the game Elite, but I might mix that up with something else.