New 512 bytes demo released: Gar Nix

[Thomas Jentzsch]

I did an Elite 3D graphics demo, but I suppose you mean something different.

[alex_79]

On 10/8/2022 at 10:22 AM, JetSetIlly said:

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.

Those games work fine with the simplified protocol, but they actually store values with D0 set to the hotspots, and since this involves using a little bit of extra rom and cycles, it suggests that the real CBS scheme works as indicated in the patent. So the original games work with the simplified method, but new games written for the simplified scheme wouldn't have worked in an original CBS chip.

 

I agree that there's not much point in implementing this now (and it might break homebrews, hacks and demos that use the simplified method), but maybe it could be documented and/or generate a warning. The same could be done with the code executed from SARA ram.

The difference is that while you can actually build a cartridge with original SARA ram, by scavenging the old chips form original carts, or if you find some new old-stock ones, you cannot realistically reuse the original CBS bankswitching circuitry, as it was built-in a single chip together with the mask rom.  Even in case of SARA, though, it doesn't make much sense to go that route when modern implementations such as "Melody" and "Aria" boards are available.

 

On 10/8/2022 at 10:22 AM, JetSetIlly said:

(Are there any other CBS/FA ROMs?)

There are a couple of "Wings" prototypes. You can find them on Atarimania.

 

On 10/8/2022 at 11:49 AM, Thomas Jentzsch said:

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

I don't know. For SARA, there's a scan of a page from original Atari internal documents that describes this behavior, but I'm not aware of similar docs from the other companies.

[JetSetIlly]

50 minutes ago, alex_79 said:

Those games work fine with the simplified protocol, but they actually store values with D0 set to the hotspots, and since this involves using a little bit of extra rom and cycles, it suggests that the real CBS scheme works as indicated in the patent. So the original games work with the simplified method, but new games written for the simplified scheme wouldn't have worked in an original CBS chip.

 

I agree that there's not much point in implementing this now (and it might break homebrews, hacks and demos that use the simplified method), but maybe it could be documented and/or generate a warning. The same could be done with the code executed from SARA ram.

 

Indeed. I do think it's important to acknowledge the original limitation in emulation in some way. A simple "lint" check in developer mode would be a good start. eg. Will this ROM run on hardware available in 1977? (How much would it cost to build?)

 

FWIW, I've implemented the stricter protocol in Gopher2600. It seems fine but without knowing what other homebrew CBS ROMs are out there, there's a risk it will break those ROMs for no good reason.

 

50 minutes ago, alex_79 said:

The difference is that while you can actually build a cartridge with original SARA ram, by scavenging the old chips form original carts, or if you find some new old-stock ones, you cannot realistically reuse the original CBS bankswitching circuitry, as it was built-in a single chip together with the mask rom.  Even in case of SARA, though, it doesn't make much sense to go that route when modern implementations such as "Melody" and "Aria" boards are available.

 

One idea that could be developed is the separation of the two concepts - "bankswitching" and "cartridge package". Currently, emulators implement cartridges in an ideal way and are only really concerned with which bankswitching method is being used. But as we've discussed, the bankswitching "protocol" is affected by the cartridge "package". I'm thinking that emulators should allow the user to select the "package" that the ROM is "contained" in.

 

The package option might simply be: (1) Idealised and (2) Period Accurate. But it could be extended to (3) Harmony/Melody or (4) Uno/PlusCart etc. with full firmware emulation.

 

A really good emulation would be able to answer the question: Which cartridge packages will this ROM work with?

 

... Anyway, just thinking out loud.

 

50 minutes ago, alex_79 said:

There are a couple of "Wings" prototypes. You can find them on Atarimania.

Interesting. Thanks

 

50 minutes ago, alex_79 said:

I don't know. For SARA, there's a scan of a page from original Atari internal documents that describes this behavior, but I'm not aware of similar docs from the other companies.

Do you have a link for that document?

Edited October 10, 2022 by JetSetIlly

[Thomas Jentzsch]

53 minutes ago, JetSetIlly said:

Indeed. I do think it's important to acknowledge the original limitation in emulation in some way. A simple "lint" check in developer mode would be a good start. eg. Will this ROM run on hardware available in 1977? 

Yes, that seems like a feasible approach.

53 minutes ago, JetSetIlly said:

FWIW, I've implemented the stricter protocol in Gopher2600. It seems fine but without knowing what other homebrew CBS ROMs are out there, there's a risk it will break those ROMs for no good reason.

I am only aware of a recently release demo. 

53 minutes ago, JetSetIlly said:

One idea that could be developed is the separation of the two concepts - "bankswitching" and "cartridge package". Currently, emulators implement cartridges in an ideal way and are only really concerned with which bankswitching method is being used. But as we've discussed, the bankswitching "protocol" is affected by the cartridge "package". I'm thinking that emulators should allow the user to select the "package" that the ROM is "contained" in.

 

The package option might simply be: (1) Idealised and (2) Period Accurate. But it could be extended to (3) Harmony/Melody or (4) Uno/PlusCart etc. with full firmware emulation.

 

A really good emulation would be able to answer the question: Which cartridge packages will this ROM work with?

I think that's a bit over the top, especially for normal users. And for flash carts even moving target, because the firmware may change or even differ depending on the user.

 

And it might not even be sufficient. E.g. there exist bankswitched ROMs which require to be started in a fixed bank (e.g. Congo Bongo our the homebrew Four-Play), while other ROMs using the same scheme are prepared to be started in any bank (e.g. most F8/F6 ROMs). For the former, the hardware used would have to make sure that the fixed bank is selected. For the latter, the hardware could do the same or not. If a ROM was developed for the latter, it will run on both types of hardware. The former ROMs will most likely randomly crash at startup.

[JetSetIlly]

1 hour ago, Thomas Jentzsch said:

I think that's a bit over the top, especially for normal users. And for flash carts even moving target, because the firmware may change or even differ depending on the user.

 

There's a lot to think about for sure. But in the case of the Harmony type cartridges, I don't see any reason why you couldn't have the different firmware files on disk for testing purposes. For a developer it would be useful to know if their particular ROM is incompatible with a particular firmware.

 

1 hour ago, Thomas Jentzsch said:

And it might not even be sufficient. E.g. there exist bankswitched ROMs which require to be started in a fixed bank (e.g. Congo Bongo our the homebrew Four-Play), while other ROMs using the same scheme are prepared to be started in any bank (e.g. most F8/F6 ROMs). For the former, the hardware used would have to make sure that the fixed bank is selected. For the latter, the hardware could do the same or not. If a ROM was developed for the latter, it will run on both types of hardware. The former ROMs will most likely randomly crash at startup.

 

Indeed. There are awkward cases like startup-bank to consider.

[+Al_Nafuur]

 

2 hours ago, JetSetIlly said:

One idea that could be developed is the separation of the two concepts - "bankswitching" and "cartridge package". Currently, emulators implement cartridges in an ideal way and are only really concerned with which bankswitching method is being used. But as we've discussed, the bankswitching "protocol" is affected by the cartridge "package". I'm thinking that emulators should allow the user to select the "package" that the ROM is "contained" in.

 

The package option might simply be: (1) Idealised and (2) Period Accurate. But it could be extended to (3) Harmony/Melody or (4) Uno/PlusCart etc. with full firmware emulation.

 

A really good emulation would be able to answer the question: Which cartridge packages will this ROM work with?

 

... Anyway, just thinking out loud.

 

2 hours ago, Thomas Jentzsch said:

I think that's a bit over the top, especially for normal users. And for flash carts even moving target, because the firmware may change or even differ depending on the user.

 

The Uno/PlusCart firmware is open source and about 27 versions of the firmware are currently in use:

https://pluscart.firmaplus.de/statistics.php?stat_id=3 (page loads very slow!)

 

So you can basically include Uno/PlusCart in the emulation package (although I don't recommend this way). The Harmony/Melody firmware is not open source, so it will be much harder to implement this in the emulation.

 

[Thomas Jentzsch]

14 minutes ago, JetSetIlly said:

There's a lot to think about for sure. But in the case of the Harmony type cartridges, I don't see any reason why you couldn't have the different firmware files on disk for testing purposes. For a developer it would be useful to know if their particular ROM is incompatible with a particular firmware.

Sure. But since e.g. Harmony is closed source, we do not know how each scheme is emulated and what is different between the version. Everything is a black box. Unocart/Pluscart are different here.

[JetSetIlly]

Just now, Thomas Jentzsch said:

Sure. But since e.g. Harmony is closed source, we do not know how each scheme is emulated and what is different between the version. Everything is a black box. Unocart/Pluscart are different here.

I'm meaning emulating the ARM chip in its entirety to run the firmware. In that way, you don't need to know the details of the implementation.

[Thomas Jentzsch]

6 minutes ago, JetSetIlly said:

I'm meaning emulating the ARM chip in its entirety to run the firmware. In that way, you don't need to know the details of the implementation.

If you want to go that way. I doubt we will do this for Stella as the additional requirements will most likely break support for multiple weaker platforms.

 

Maybe as a developer option, but I am not so sure here too. We are lacking resources already. 

Edited October 10, 2022 by Thomas Jentzsch

[JetSetIlly]

1 minute ago, Thomas Jentzsch said:

If you want to go that way. I doubt we will do this for Stella as the additional requirements will most likely break support for multiple weaker platforms.

The underlying hardware requirements will be significantly higher, for sure.

[+Al_Nafuur]

12 minutes ago, JetSetIlly said:

I'm meaning emulating the ARM chip in its entirety to run the firmware. In that way, you don't need to know the details of the implementation.

then you have to emulate the hardware (GPIO) too, but this is also not open source in case of the Harmony/Melody.

[JetSetIlly]

5 minutes ago, Al_Nafuur said:

then you have to emulate the hardware (GPIO) too, but this is also not open source in case of the Harmony/Melody.

Indeed. To be clear I'm only throwing around ideas here but (unless the Harmony developers ask for it not to be re-implemented in software) it's not an impossible task. Difficult and challenging but not impossible.

[Thomas Jentzsch]

7 minutes ago, JetSetIlly said:

Indeed. To be clear I'm only throwing around ideas here but (unless the Harmony developers ask for it not to be re-implemented in software) it's not an impossible task. Difficult and challenging but not impossible.

Sure. But is it really worth the effort?

[JetSetIlly]

Just now, Thomas Jentzsch said:

Sure. But is it really worth the effort?

Maybe not 🙂

[alex_79]

On 10/10/2022 at 10:38 AM, JetSetIlly said:

Do you have a link for that document?

Sorry for the late reply, I missed that question.

It's just this short paragraph on a single page. I think it was part of scans of one of the various versions of the Stella programmers guide, but I usually split / clean / ocr those scans when I get them, so I don't remember where I downloaded it from.

Sara_Programming_Instructions.pdf

 

[Ecernosoft]

On 10/8/2022 at 6:17 AM, Thomas Jentzsch said:

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. 

Speaking of Sync issues, during the screen flash in It's Conner time 2, the screen goes out of sync. Is this a page boundary issue?

I can show you the code if you want.

I might just get rid of it if I can't fix it. It was only tested on 7800 since I don't feel like pulling my 2600 out for this. And plus, it was also on a Flatscreen, so that could be the reason.

If I ever send @ZeroPage Homebrew a game to review (Soon ICT2) I will watch out for this.

It's also the reason for my lack of interest in Grizzards. Sure, it's a great game, but the screen is so darn bouncy! (or it is on the ROM I played)

[Thomas Jentzsch]

14 minutes ago, Ecernosoft said:

Speaking of Sync issues, during the screen flash in It's Conner time 2, the screen goes out of sync. Is this a page boundary issue?

Do you have a ROM? 

[Ecernosoft]

1 minute ago, Thomas Jentzsch said:

Do you have a ROM? 

Well... I did...

[Thomas Jentzsch]

On 10/6/2022 at 6:59 PM, SvOlli said:

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

I have enhanced Stella to prevent code execution in RAM using SARA chips (F8SC, F6SC, F4SC). 

 

Do you maybe also know about M-Network (E7), CBS (FA) and Wickstead Design (WD) RAM?

[JetSetIlly]

2 hours ago, Thomas Jentzsch said:

Do you maybe also know about M-Network (E7), CBS (FA) and Wickstead Design (WD) RAM?

 

🙂 I'm literally just implementing Wickstead Design for Gopher2600. Never really heard of it before today and now you've mentioned it here!

 

Do you happen know anything about the history of the Stella implementation of WD? For example, how was it discovered that the bank switch takes three cycles to take effect? Was it discovered through an analysis of the Pink Panther prototype or some other way?

 

What about the bad ROM dump? Where did that come from?

[Thomas Jentzsch]

41 minutes ago, JetSetIlly said:

What about the bad ROM dump? Where did that come from?

That was the original dump. It also had three extra bytes at the end. After analyzing the ROM a bit more, I found that the three bytes are superfluous and the bank order was slightly wrong.