UnoCart firmware update(s)

[+Andrew Davie]

5 hours ago, SvOlli said:

Hmmm.. mine is a tight fit, but it works. Would adding another millimeter "on the inner side" be enough?

 

A picture tells a thousand words.

 

[+SvOlli]

On 8/12/2020 at 8:44 PM, SvOlli said:

I know this is rather far from firmware, but I chose this space for easy finding...

 

As @Andrew Davie asked for my modification of a thingiverse design of a 2600 cartridge shell done for a UnoCart 2600, I decided to pick them up from my tinkercad account. So here they are, happy printing.

UnoCart-2600_case.zip 42.89 kB · 5 downloads

Hmmm... It seems that I can't update the file in the post, so I've got to add the updated version here.

I went with 2mm more space for the jumpers and 1mm on the SD card reader, just to be sure.

 

 

UnoCart-2600_case.zip

[Mr SQL]

I just released the sequel to KC Munchkin which supports the UnoCart and the Atari Flashback Portable

 

I tested the sequel on the Retron77 console with the community build of Stella and patched a new Stella bug before releasing where the decimal flag gets set on startup.

 

That generally doesn't happen on the real hardware, and it seems as ARM game support is increased existing compatibility goes down. This isn't so surprising as it's easy to introduce new bugs with new development; emulators that are finished (Z26) or focus on supporting only classic Atari 2600 games are starting to show greater compatibility, the Flashback Portable is a good example in not needing the special fix the Retron77 required.  Stella could evolve into an ARM game only platform that simply cannot support classic Atari games if the trend continues;  quality control and testing is important when frequently releasing new builds. 

 

The ROM is here:

 

 

[Mr SQL]

More interesting information on this bug - it looks like the UnoCart can be triggered to different read state on a write-only register as shown in the test program here that shows the read value and yellow screens when this condition occurs.

 

To reproduce this condition insert a sega-pad or paddles into the left joystick port while the program is running, then power off and put a regular joystick back in; power back on and reload the program - the different state is maintained as illustrated when it yellow screens again.

 

To resolve the condition it is necessary to remove the UnoCart and reinsert it, and run the test program again (no yellow screen).

 

What is still very elusive however is that these same steps cannot be used to fix KC once the sega-pad breaks the game - the yellow monster will still continue breaking even after the UnoCart is removed and the game is reinserted, however there is a workaround: the test program can be used to restore the UnoCart, then KC runs again

 

The KC II SuperCharger version does not exhibit this issue as it does not try to read from a write only register.

 

This is an important bug to fix imo because for many write only registers, the same read value is returned as would be for a literal so that " lda 24 " is effectively no different than " lda #24". This is a very common mistake so the safety-catch built into the original hardware needs to be mirrored for full compatibility.

 

@DirtyHairy I have been working on Survival Islands multiload compatibility with @Al_Nafuur and have a question about the RIOT RAM, is it preserved on subsequent loads for the SuperCharger? If not this may be may be why the codes entered are not passed to the next stage of the multiload. Or maybe this odd bug has something to do with it.

      

[+batari]

1 hour ago, Mr SQL said:

This is an important bug to fix imo because for many write only registers, the same read value is returned as would be for a literal so that " lda 24 " is effectively no different than " lda #24". This is a very common mistake so the safety-catch built into the original hardware needs to be mirrored for full compatibility.

There is no "safety-catch" built into the hardware to return the same value for LDA 24 as LDA #24. It just sometimes works because 24 was the last value on the bus after reading the operand and nothing else is driving the bus, so the value might stay just long enough to be read on the next cycle. A programming mistake by writing LDA 24 when LDA #24 is just that, a mistake. It is a bug in the program and it isn't the hardware's fault that the program has a bug, nor is it the job of the hardware to compensate for a programming bug. If anything, the bug should be exploited by hardware so it can be corrected in the program.

 

This is just coincidence that it works sometimes and isn't reliable by any stretch of the imagination, and different EPROMs, ROMs, TIA/RIOT variations or console differences, temperature changes, even putting your hand near the console can cause it to fail on one system and not another.

[Mr SQL]

3 hours ago, batari said:

There is no "safety-catch" built into the hardware to return the same value for LDA 24 as LDA #24. It just sometimes works because 24 was the last value on the bus after reading the operand and nothing else is driving the bus, so the value might stay just long enough to be read on the next cycle. A programming mistake by writing LDA 24 when LDA #24 is just that, a mistake. It is a bug in the program and it isn't the hardware's fault that the program has a bug, nor is it the job of the hardware to compensate for a programming bug. If anything, the bug should be exploited by hardware so it can be corrected in the program.

 

This is just coincidence that it works sometimes and isn't reliable by any stretch of the imagination, and different EPROMs, ROMs, TIA/RIOT variations or console differences, temperature changes, even putting your hand near the console can cause it to fail on one system and not another.

I don't think this is a coincidence, this has been observed before with another write only register by @vdub_bobby :

 

Here is another test ROM to illustrate with GRP0 but it is more stable because a paddle or sega-pad does not change the read value ReadGRP0.bin

 

Are there any write only registers that don't follow this rule when reading them? It is a fairly common bug so there could be multiple titles to support by emulating the clever design.

 

EDIT: Added a test ROM that iterates through all the low write-only registers - multiples of 10 crash the Atari and the emu, all other numbers seem to follow the design, at least on my Atari's. I let it crash on 60

ITERATE_WRITEONLY_REGS.bin ITERATE_WRITEONLY_REGS.wav

Edited August 24, 2020 by Mr SQL
test roms added

[+batari]

18 hours ago, Mr SQL said:

I don't think this is a coincidence, this has been observed before with another write only register by @vdub_bobby :

 

Here is another test ROM to illustrate with GRP0 but it is more stable because a paddle or sega-pad does not change the read value ReadGRP0.bin

 

Are there any write only registers that don't follow this rule when reading them? It is a fairly common bug so there could be multiple titles to support by emulating the clever design.

 

EDIT: Added a test ROM that iterates through all the low write-only registers - multiples of 10 crash the Atari and the emu, all other numbers seem to follow the design, at least on my Atari's. I let it crash on 60

ITERATE_WRITEONLY_REGS.bin 8.25 kB · 0 downloads ITERATE_WRITEONLY_REGS.wav 287.53 kB · 0 downloads

It is positively a coincidence, and it's an unfortunate one because it leads to programming bugs that are hard to find. Just because it works sometimes does not mean it is "correct" behavior by any stretch. It is not reliable across various systems and hardware or even on the same hardware. I don't need to see test ROMs to know what is going on.

 

This situation has been compared to a feather on the ground. It's not a stable condition and can't be relied upon. If it works sometimes on one of your systems, then in that particular case, the feather is just happening to stay put, but the *slightest* perturbation is enough to cause it to blow away.

[Mr SQL]

 

3 hours ago, batari said:

It is positively a coincidence, and it's an unfortunate one because it leads to programming bugs that are hard to find. Just because it works sometimes does not mean it is "correct" behavior by any stretch. It is not reliable across various systems and hardware or even on the same hardware. I don't need to see test ROMs to know what is going on.

Well when I run the test program on my Jr and my Vader using the Harmony, Uno or the SuperCharger, or on the emu I'm getting consistent results except for the paddle/bad breaking $18.

 

I'm very curious why reading any increments of 10 from the write registers will freeze the Atari - but if the programmer makes that mistake they know right away.

 

 I'm also curious what others systems look like because so far it looks like a consistent design; I agree temperature can change $18 too but it takes hours with the Harmony cart and many hours with the SuperCharger - two unanswered questions we have so far related to this interesting design are related to the edge case $18:

 

 Why does the UnoCart need to be unplugged to stop from floating $18 (AUDV1) after a paddle/Pad is inserted into the left port to trigger it during the attached AUDF1 read  demo and the Harmony only needs to have the Atari powered off and back on to return register $18 to read $18 again?

 

And what else is my KCMM ROM doing that it needs either the Harmony inserted in the interim or the demo program to be run to restore it? Seems perhaps another value is being floated?

 

4 hours ago, batari said:

 

This situation has been compared to a feather on the ground. It's not a stable condition and can't be relied upon. If it works sometimes on one of your systems, then in that particular case, the feather is just happening to stay put, but the *slightest* perturbation is enough to cause it to blow away.

I have to leave KC running for hours to trigger a temperature change to the register $18 read on the Harmony and it's even more stable with the SuperCharger. 

Folks are playing a game not running a mission critical app so it looks good enough from what I've seen so far.

 

 You say you don't need the test program, I'm skeptical anyone with just a joystick plugged into the left port is not going to see the iteration test program in my last post counting up evenly from 2 until it freezes at 60 (skipping the other 10's).   

 

Anyone get a different result?? Please try the test and share info on your Atari model, this is pretty interesting.

 

READAUDF1.bin

[Mr SQL]

21 hours ago, batari said:

It's not a stable condition

We ran across what looks like a stable hardware initialization for register 24 ($18) that appears to be part of the SuperCharger BIOS and your Harmony BIOS, but not present in the PlusCart.

 

Looping through the write only regs prior to 24, performs a hardware init (discharges a cap likely) and register 24 comes up correctly initialized to 24 when read.

 

If the hardware init isn't done it can stay floated so the readAUDF1.bin test will continue to yellow screen when run on the pluscart after a paddle is inserted into the left joystick port with the power on (charges a cap) and it stays high even if the Atari is unplugged and the cart is unplugged. It will stay high until a SuperCharger or a Harmony is inserted and their startup BIOS reinitializes it like the second test program is doing to trigger a hardware init - 

 

imo there is a part of your Harmony menu routine startup routine that touches the low registers, I just have to insert the Harmony same as the SuperCharger to trigger the init - they both loop through the low regs and set them to zero as part of the init routine, either that or they are touching at least one of the low regs somewhere that discharges the cap like we see happening in the test examples above?

 

[+batari]

I realize you are getting fairly consistent results. But, there is really no argument here that can successfully argue that this situation should be relied upon or that any hardware should ever support this situation.

 

Basically, reading from a write-only register puts the bus in a high-Z, or high-impedance state, and no engineering document in existence would support relying on any value there, even if you can repeat results on 90% of hardware, or something like that.

 

There isn't really anything else to say about it, as it's not only a fundamental part of electrical engineering that the value read here can not be relied upon, but, the fact that it fails on some consoles or some hardware or even on the same 2600 or 7800, has been directly observed.

[Mr SQL]

11 hours ago, batari said:

I realize you are getting fairly consistent results. But, there is really no argument here that can successfully argue that this situation should be relied upon or that any hardware should ever support this situation.

 

Basically, reading from a write-only register puts the bus in a high-Z, or high-impedance state, and no engineering document in existence would support relying on any value there, even if you can repeat results on 90% of hardware, or something like that.

 

There isn't really anything else to say about it, as it's not only a fundamental part of electrical engineering that the value read here can not be relied upon, but, the fact that it fails on some consoles or some hardware or even on the same 2600 or 7800, has been directly observed.

I had a similar error in my iterate readonly registers program, so my consistent results are due to programming error, that very same error actually! 

 

I've attached a corrected iteration program that goes through the first 99 addresses and shows the values, they are mostly zero but when the cap is charged by the paddle or the sega pad register 24 (AUDF1) goes high and a few others may change as well I haven't finished comparing.

 

 Charging the cap changes the environment the program sees from by plugging in a paddle or a sega-pad as we see, and you are able to somehow discharge the cap with the harmony menu (maybe when you read the paddle to see if it is being used??) and the supercharger GUI also discharges the cap similarly.

 

In the instance with KC breaking, we can get the cap to discharge with another program and then KC runs again - my program with the error was discharging it as well, but for best compatibility the capacitor discharge init in the menu like you are doing grants closer emulation to the SuperCharger because it is doing it too.

 

The closer we can get to making the environment a 100% match, the closer we get to running all of the SuperCharger classics and homebrews - Harmony is doing that and Uno is very close, so any differences where Harmony and Stella are matching the SuperCharger environment and Uno is not are important to tune to match. 

 

FIXED_iterate_writeonly_regs.bin

[DirtyHairy]

Another firmware update: v16 fixes 3E+ banking  to support ROMs that use more than RAM.

[DirtyHairy]

And another update: this fixes issues with some heavy sixers that would not previously run the Uno firmware.

[Anapan]

Tho I haven't actually enjoyed any of these recent updates as I just received all my hardware, I just want to thank you for your contributions.

I finally received all the parts of my new Atari 2600 ultimate system.  A Sears Telegames heavy sixer in near mint condition, Tim Worthington's RGB mod, and the UnoCart.  With the UnoCart on stock (recent original) firmware, everything I tried runs fine through RF.  I read somewhere (the manual?) that the UnoCart might not run okay on an RGB modded system.  Given that the console I bought is near factory new - used so little and kept packaged, I want to know if I ought to only mod it for new caps and S-Video and stick the RGB mod in another system, or is there a good chance of the UnoCart working on it through this or another update?  OT (sorry), I read that the Harmony cart with a firmware update can run on an Viletim RGB modded system.  I bought one of those back in the day, but lent it to a friend and it's gone now.  Would buy again... Can someone verify that?

[alfredtdk]

I don't know if this has been reported, but of all the old roms, 
the Pleiades prototype is the only rom that runs with bugs in Unocart.
Harmony does not. Could this error be corrected in Uno's new firmware in the future? Thanks!

P.S:

Despite being a prototype, Pleiades and an excellent shooting game from the 2600.
One of the best, I venture to say.?

Edited December 15, 2020 by alfredtdk

[+Al_Nafuur]

2 hours ago, alfredtdk said:

don't know if this has been reported, but of all the old roms,

the Pleiades prototype is the only rom that runs with bugs in Unocart.
Harmony does not. Could this error be corrected in Uno's new firmware in the future? Thanks!

I just tested Pleiades with the PlusCart and it's runs with the same bug. What bank switching type is it?

[Thomas Jentzsch]

5 hours ago, Al_Nafuur said:

What bank switching type is it?

UA

[+Al_Nafuur]

7 hours ago, Thomas Jentzsch said:

UA

UA is not supported by the UnoCart or PlusCart..
.. but Stella code looks like it can be ported to the UnoCart and PlusCart

?

[Thomas Jentzsch]

Yes, it is a pretty simple bankswitching type.

[+ZeroPage Homebrew]

On 10/16/2020 at 8:50 PM, Anapan said:

I read somewhere (the manual?) that the UnoCart might not run okay on an RGB modded system.  Given that the console I bought is near factory new - used so little and kept packaged, I want to know if I ought to only mod it for new caps and S-Video and stick the RGB mod in another system, or is there a good chance of the UnoCart working on it through this or another update?  OT (sorry), I read that the Harmony cart with a firmware update can run on an Viletim RGB modded system.

 

You might be referring to this thread. I have an RGB modded light-sixer and the UnoCart works just fine in it (it had issues but worked after cleaning, read back in the thread).

 

The Harmony Encore cart also works well out of the box in my RGB system except for Encore games but @batari is looking into that right now with a system the exhibits that issue (surprisingly an s-video modded system that had the issue too).

 

I'd like to add that the etim RGB mod can introduce minor timing issues that can cause weird pixel placements in some games, most noticeably in PF pixels. It's very minor, it seldom shows up and and you may not notice it in most games.

 

- James

 

 

[+SvOlli]

18 hours ago, ZeroPage Homebrew said:

I'd like to add that the etim RGB mod can introduce minor timing issues that can cause weird pixel placements in some games, most noticeably in PF pixels. It's very minor, it seldom shows up and and you may not notice it in most games.

Yes, I ran into that problem with my demo "Bang!" during one part. I noticed that an STA BGCOL,X is triggered on cycle to early, so a colour change that was hidden with a sprite is now visible. That led me to switching back to a composite modded 2600 jr again.

[Thomas Jentzsch]

47 minutes ago, SvOlli said:

I noticed that an STA BGCOL,X is triggered on cycle to early, so a colour change that was hidden with a sprite is now visible.

Too early, are you sure?

[+Al_Nafuur]

On 12/16/2020 at 12:17 AM, alfredtdk said:

I don't know if this has been reported, but of all the old roms, 
the Pleiades prototype is the only rom that runs with bugs in Unocart.
Harmony does not. Could this error be corrected in Uno's new firmware in the future? Thanks!

P.S:

Despite being a prototype, Pleiades and an excellent shooting game from the 2600.
One of the best, I venture to say.?

 

22 hours ago, Al_Nafuur said:

UA is not supported by the UnoCart or PlusCart..
.. but Stella code looks like it can be ported to the UnoCart and PlusCart

?

UA bankswitching is added and tested to the PlusCart dev firmware. I copied the code to my UnoCart fork (untested), so @DirtyHairy if you like I can send a pull request:
https://github.com/Al-Nafuur/UnoCart-2600/commit/f5e3588633457e6377476385f4b476e1c8df6256

 

[+SvOlli]

23 hours ago, Thomas Jentzsch said:

On 12/17/2020 at 1:33 PM, SvOlli said:

I noticed that an STA BGCOL,X is triggered on cycle to early, so a colour change that was hidden with a sprite is now visible.

Too early, are you sure?

You're right. One CPU cycle too late. Just checked with actual hardware. I was assuming that the shadow read from the ",X" was triggering the FPGA instead of a write. Nevertheless, I reported the bug and got a "sorry, no time, won't fix" as a reply. Sadly the project is not open source, so no one else can try to fix it. I even found someone at our hackerspace who would have helped me to get into FPGA coding.

[Thomas Jentzsch]

11 minutes ago, SvOlli said:

You're right. One CPU cycle too late. Just checked with actual hardware. I was assuming that the shadow read from the ",X" was triggering the FPGA instead of a write. Nevertheless, I reported the bug and got a "sorry, no time, won't fix" as a reply. Sadly the project is not open source, so no one else can try to fix it. I even found someone at our hackerspace who would have helped me to get into FPGA coding.

Too bad. The output quality is brilliant, but the (multiple) delays are really bad. Especially for a usually tight coded platform like the 2600. Have you asked for making the project open source?

 

BTW: Stella is trying to emulate some of these timing glitches, so that you can check your code for compatibility (see Options/Developer settings/TIA).

Edited December 18, 2020 by Thomas Jentzsch