Jump to content
DirtyHairy

UnoCart firmware update(s)

Recommended Posts

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.

 

IMG_20200816_000032.thumb.jpg.4d9c1439d8e09025f0c7b90d47fe1cf1.jpg

  • Like 1

Share this post


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

Share this post


Link to post
Share on other sites

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:

 

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

      

Share this post


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

  • Like 3

Share this post


Link to post
Share on other sites
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 by Mr SQL
test roms added

Share this post


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

  • Like 5

Share this post


Link to post
Share on other sites

 

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

Share this post


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

 

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


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

  • Like 1

Share this post


Link to post
Share on other sites

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... 20201016_204616.thumb.jpg.c51e629e2ff7172b99a6bda2c71aa8ed.jpgCan someone verify that?

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.

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...