UNOCart-2600 issues

[eightbit]

Well, patch applied, but no dice I had a ray of hope at one point after applying the fix however. After power cycling a few (or more than a few) times I did ONCE get the UNO screen! It was stuck though...and said "SD Status" at the bottom of the screen and that was it. I have not been able to get that screen to come up on this heavy sixer again. Every time I power cycle it is just random color bars and a siren noise.

 

I am thinking this is a firmware issue of some type. I just received this cart and the firmware is older and apparently you cannot update the firmware via SD.

 

Oh well, at least the fix is in place. No telling if it did anything worth while however

[DirtyHairy]

In order to get to the bottom of the failing heavy sixers I have created a special firmware that will dump the initial bus activity of the console to a file on the SD card. The firmware works like a normal firmware as long as the jumper is set to PAL or NTSC, so you can reflash an ordinary firmware version again by running an update binary from the menu.

 

If you have a console on which the UnoCart fails to start and want to help, please do the following:

1. Flash the firmware from the attached archive, either by using a ST-LINK programmer (firmware.bin) or by running the update from the menu (update.bin, provided that your firmware is new enough)
2. Set the jumper to either PAL or NTSC and turn the console on. The menu should come up as usual, but identify as "BUSDUMPER 16" at the bottom
3. Turn the console off and set the jumper to PAL60. Turn the console on. The TV will now show display garbage or nothing at all, and some noise may come from the speakers.
4. After a few seconds, turn off the console. The SD card will now contain a 64k file called "bus_dump.bin" at its root. It contains a protocol of the bus activity when the console starts up. Post the file here.
5. Put the jumper back to PAL or NTSC. The Uno will now boot into the menu again. You can now revert to an ordinary firmware by flashing any of the releases on github from the menu.

The process is as safe as any other upgrade of the firmware. It is not possible to damage the cart this way, but if anything goes wrong during flashing, you'll need a ST-LINK programmer to restore it (or someone with a programmer who does that for you ? ).

 

 

 

 

dumper16.zip

Edited September 15, 2020 by DirtyHairy

[eightbit]

Thanks! I actually sent my UnoCart to MacRorie to update the firmware as I had an old firmware in which I could not update from SD. The cart is in the mail on the way back to me now (Thanks MacRorie!) and if it does not work in this heavy sixer when it arrives I will use this dumper and let you know!

[eightbit]

Ohh, question. I will have to use my 7800 to flash this initially with this dumper firmware if the cart does not work at all (or reacts the same) in the heavy sixer. What do I do after if after it is flashed and I bring it over to the heavy sixer if I don't see a menu (or anything but bars) on step 2? I guess I would have to do this blindly on the heavy sixer I assume?

[DirtyHairy]

7 minutes ago, eightbit said:

Ohh, question. I will have to use my 7800 to flash this initially with this dumper firmware if the cart does not work at all (or reacts the same) in the heavy sixer. What do I do after if after it is flashed and I bring it over to the heavy sixer if I don't see a menu (or anything but bars) on step 2? I guess I would have to do this blindly on the heavy sixer I assume?

Yes. In order to create the dump, the only thing that is necessary is running the firmware with the jumper set to PAL60. I only added step 2 in order to make sure that the flash worked and the new firmware is running --- it is not required to create the dump ?

[eightbit]

Perfect. I will report back my results as soon as it arrives. Thank you for helping look into this!

[STLRunner]

5 hours ago, DirtyHairy said:

In order to get to the bottom of the failing heavy sixers I have created a special firmware that will dump the initial bus activity of the console to a file on the SD card. The firmware works like a normal firmware as long as the jumper is set to PAL or NTSC, so you can reflash an ordinary firmware version again by running an update binary from the menu.

 

If you have a console on which the UnoCart fails to start and want to help, please do the following:

1. Flash the firmware from the attached archive, either by using a ST-LINK programmer (firmware.bin) or by running the update from the menu (update.bin, provided that your firmware is new enough)
2. Set the jumper to either PAL or NTSC and turn the console on. The menu should come up as usual, but identify as "BUSDUMPER 16" at the bottom
3. Turn the console off and set the jumper to PAL60. Turn the console on. The TV will now show display garbage or nothing at all, and some noise may come from the speakers.
4. After a few seconds, turn off the console. The SD card will now contain a 64k file called "bus_dump.bin" at its root. It contains a protocol of the bus activity when the console starts up. Post the file here.
5. Put the jumper back to PAL or NTSC. The Uno will now boot into the menu again. You can now revert to an ordinary firmware by flashing any of the releases on github from the menu.

The process is as safe as any other upgrade of the firmware. It is not possible to damage the cart this way, but if anything goes wrong during flashing, you'll need a ST-LINK programmer to restore it (or someone with a programmer who does that for you ? ).

 

@DirtyHairy I am sorry that I did not respond to your PM concerning this. Anyway, I followed all of your instructions starting with flashing update.bin with my 2600 Jr. Upon rebooting the Jr. it did show "BUSDUMPER 16" at the bottom of the screen. I changed the jumper to PAL 60 and tried booting the UNOcart my Heavy Sixer but no bus_dump.bin was created anywhere on the SD card. I left the console on for 10 seconds the first time and 45 seconds the second time, after removing and reinserting the UNOcart. As a last-ditch effort, I removed the UNO from its plastic shell and tried booting it on the Heavy Sixer for 60 seconds. Unfortunately, no bus_dump.bin was created anywhere on the SD.

 

I did try the process on my 2600 Jr. and a bus_dump.bin was created on the root of the SD as expected. If you'd like to review that to see if there are any anomalies with my UNOcart, please let me know.

 

Thanks for helping the community with this!

[DirtyHairy]

9 hours ago, STLRunner said:

 

@DirtyHairy I am sorry that I did not respond to your PM concerning this. Anyway, I followed all of your instructions starting with flashing update.bin with my 2600 Jr. Upon rebooting the Jr. it did show "BUSDUMPER 16" at the bottom of the screen. I changed the jumper to PAL 60 and tried booting the UNOcart my Heavy Sixer but no bus_dump.bin was created anywhere on the SD card. I left the console on for 10 seconds the first time and 45 seconds the second time, after removing and reinserting the UNOcart. As a last-ditch effort, I removed the UNO from its plastic shell and tried booting it on the Heavy Sixer for 60 seconds. Unfortunately, no bus_dump.bin was created anywhere on the SD.

 

I did try the process on my 2600 Jr. and a bus_dump.bin was created on the root of the SD as expected. If you'd like to review that to see if there are any anomalies with my UNOcart, please let me know.

 

Thanks for helping the community with this!

That's not good and certainly not what I expected. The bus dump does not interact with the console in any way and should even run if only power is provided to the cart. This suggests that the STM (the MCU on the UnoCart) does not even boot in your sixer, which sounds like an electrical issue to me.

 

My best guess is that your sixer does not provide sufficient power to run the UnoCart. From the STM datasheet I would suspect that the UnoCart does consume something around 50 mA, which does not sound much to me, but I do not know how much excess power the Atari can provide (and I don't know how the STM's power consumption really behaves in this application). If you like to continue troubleshooting, there are two things that come to my mind

• Iirc you have a ST-LINK programmer --- in this case, you could try to see if you can communicate with the UnoCart while it is powered by your sixer.
• There's a LD33 voltage regulator on the UnoCart board. If you feel adventurous, you could measure the output voltage of the regulator with a multimeter. It should be stable at 3.3V. The datasheet of the regulator can be found for example here

Maybe @electrotrains or @MacRorie have an idea, too. If you still have the dump, feel free to post it nevertheless, I am curious how it looks like on another console ?

Edited September 16, 2020 by DirtyHairy

[eightbit]

What a strange thing. My UNO cart is set to arrive to me on Saturday so I am very curious to see if mine is the same way. Now I wonder if it is a power issue (lack of power from the cart port) if there may exist an internal system mod to increase it.

[STLRunner]

6 hours ago, DirtyHairy said:

That's not good and certainly not what I expected. The bus dump does not interact with the console in any way and should even run if only power is provided to the cart. This suggests that the STM (the MCU on the UnoCart) does not even boot in your sixer, which sounds like an electrical issue to me.

 

My best guess is that your sixer does not provide sufficient power to run the UnoCart. From the STM datasheet I would suspect that the UnoCart does consume something around 50 mA, which does not sound much to me, but I do not know how much excess power the Atari can provide (and I don't know how the STM's power consumption really behaves in this application). If you like to continue troubleshooting, there are two things that come to my mind

• Iirc you have a ST-LINK programmer --- in this case, you could try to see if you can communicate with the UnoCart while it is powered by your sixer.
• There's a LD33 voltage regulator on the UnoCart board. If you feel adventurous, you could measure the output voltage of the regulator with a multimeter. It should be stable at 3.3V. The datasheet of the regulator can be found for example here

Maybe @electrotrains or @MacRorie have an idea, too. If you still have the dump, feel free to post it nevertheless, I am curious how it looks like on another console ?

I've attached the bus_dump.bin from my Jr. I will attempt to measure the voltage later.

 

Update: I checked the voltages at the regulator: 5V in, 3.2V out. Both voltages are steady. I tested this on both my Heavy Sixer and 2600 Jr.

bus_dump.bin

Edited September 16, 2020 by STLRunner
More details

[DirtyHairy]

2 hours ago, STLRunner said:

I've attached the bus_dump.bin from my Jr. I will attempt to measure the voltage later.

 

Update: I checked the voltages at the regulator: 5V in, 3.2V out. Both voltages are steady. I tested this on both my Heavy Sixer and 2600 Jr.

That dump looks very weird. It doesn't show anything that looks like the normal startup sequence anywhere. In particular,  the  reset  vector is not read. On my own Jr., dumps look similar to this:

0x00ff x 1212652
0x017d x 18
0x017c x 20
0x017b x 21
0x1ffc x 20
0x1ffd x 20
...

That means that the bus reads 0x00ff for 1212652 reads, and then the CPU goes through the startup sequence and finishes by reading the reset vector from 0x1ffc/0x1ffd . Your  dump  looks  like this: 

0x1ffe x 190323
0x1dfe x 14
0x1dfc x 20
0x18fc x 20
0x18f7 x 20
0x1ff7 x 20
0x1ffe x 1081
0x1ffc x 20
0x1dfe x 1
0x18fe x 19
0x1ff7 x 1
0x1df7 x 19
0x1ffc x 20
0x1ffe x 1
0x18fe x 19
...

It takes much less cycles before there is activity on the bus, and the reset vector is not accessed anywhere in the dump. I don't know what to make of this. My best guess would be that the CPU has not come out of reset yet and the bus holds an unstable 0x1ffe. But it still looks weird.

 

The voltages don't seem suspicious. There is one thing I forgot, though: the dumper will wait for the bus to change before logging the values. If the bus never changes, it stays in a loop. The attached dumper firmware will start dumping immediately. The dump will be useless, but it should produce a dump file under all circumstances. Could you test that in your sixer?

 

 

modified_dumper.zip

Edited September 16, 2020 by DirtyHairy

[STLRunner]

16 minutes ago, DirtyHairy said:

That dump looks very weird. It doesn't show anything that looks like the normal startup sequence anywhere. In particular,  the  reset  vector is not read. On my own Jr., dumps look similar to this:

0x00ff x 1212652
0x017d x 18
0x017c x 20
0x017b x 21
0x1ffc x 20
0x1ffd x 20
...

That means that the bus reads 0x00ff for 1212652 reads, and then the CPU goes through the startup sequence and finishes by reading the reset vector from 0x1ffc/0x1ffd . Your  dump  looks  like this: 

0x1ffe x 190323
0x1dfe x 14
0x1dfc x 20
0x18fc x 20
0x18f7 x 20
0x1ff7 x 20
0x1ffe x 1081
0x1ffc x 20
0x1dfe x 1
0x18fe x 19
0x1ff7 x 1
0x1df7 x 19
0x1ffc x 20
0x1ffe x 1
0x18fe x 19
...

It takes much less cycles before there is activity on the bus, and the reset vector is not accessed anywhere in the dump. I don't know what to make of this. My best guess would be that the CPU has not come out of reset yet and the bus holds an unstable 0x1ffe. But it still looks weird.

 

The voltages don't seem suspicious. There is one thing I forgot, though: the dumper will wait for the bus to change before logging the values. If the bus never changes, it stays in a loop. The attached dumper firmware will start dumping immediately. The dump will be useless, but it should produce a dump file under all circumstances. Could you test that in your sixer?

@DirtyHairy The Heavy Sixer finally produced some output! It's unfortunate that it is useless but I've attached it

bus_dump.bin

[eightbit]

Now the question is, why does the dump look strange on a 2600 Jr.? UNO-Cart specific issue? Maybe SD card used?

 

It's good to know that the voltages look OK on the sixer, so not a power issue I assume.

 

All of this testing has me itchy to test mine, Come on postal service!

[STLRunner]

Just now, eightbit said:

Now the question is, why does the dump look strange on a 2600 Jr.? UNO-Cart specific issue? Maybe SD card used?

 

It's good to know that the voltages look OK on the sixer, so not a power issue I assume.

 

All of this testing has me itchy to test mine, Come on postal service!

@eightbit Good luck. I hope yours works well.

[DirtyHairy]

43 minutes ago, STLRunner said:

@DirtyHairy The Heavy Sixer finally produced some output! It's unfortunate that it is useless but I've attached it

That's 32k of 0x1fff ? Still, that shows that my initial assumption was wrong: power supply is fine, and the STM starts up alright. However, it seems that the UnoCart keeps the CPU from coming out of reset, as the bus never changes. The UnoCart configures pulldowns on the GPIOs that connect to the address bus, I wonder if those are to blame....

 

Could you give the attached firmware a try, both in dumper and in non-dumper mode? It is build with the GPIOs in high-impedance state, maybe that works.

 

 

dumper_no_pull.zip

[DirtyHairy]

10 minutes ago, eightbit said:

Now the question is, why does the dump look strange on a 2600 Jr.? UNO-Cart specific issue? Maybe SD card used?

Dunno, maybe a dirty connector. The SD card cannot be related, though.

Edited September 16, 2020 by DirtyHairy

[STLRunner]

18 minutes ago, DirtyHairy said:

That's 32k of 0x1fff ? Still, that shows that my initial assumption was wrong: power supply is fine, and the STM starts up alright. However, it seems that the UnoCart keeps the CPU from coming out of reset, as the bus never changes. The UnoCart configures pulldowns on the GPIOs that connect to the address bus, I wonder if those are to blame....

 

Could you give the attached firmware a try, both in dumper and in non-dumper mode? It is build with the GPIOs in high-impedance state, maybe that works.

It was worth trying but it doesn't boot in non-dumper mode, and does not output any data in dumper mode.

Edited September 16, 2020 by STLRunner

[+batari]

29 minutes ago, DirtyHairy said:

That's 32k of 0x1fff ? Still, that shows that my initial assumption was wrong: power supply is fine, and the STM starts up alright. However, it seems that the UnoCart keeps the CPU from coming out of reset, as the bus never changes. The UnoCart configures pulldowns on the GPIOs that connect to the address bus, I wonder if those are to blame....

 

Could you give the attached firmware a try, both in dumper and in non-dumper mode? It is build with the GPIOs in high-impedance state, maybe that works.

 

 

dumper_no_pull.zip 56.23 kB · 2 downloads

Just an observation from playing with the Visual 6502: if the 6502 hits a JAM instruction, the address bus will almost immediately jump to FFFF and stay there forever. Could it be doing this before the dumper starts?

[DirtyHairy]

3 minutes ago, batari said:

Just an observation from playing with the Virtual 6502: if the 6502 hits a JAM instruction, the address bus will almost immediately jump to FFFF and stay there forever. Could it be doing this before the dumper starts?

Hmm, good point, that would explain the 0x1fff on the 6507s bus. I don't see how this could happen, though, from the datasheet I would assume that the STM sets the GPIOs to high impedance during reset, and the firmware explicitly configures it to input during startup. Still, I'll think I'll give it a try and modify the bootup code to set the GPIOs to input as the first thing before memory is initialized and the C code is called. May take a week or two though before I get to it.

 

It would be really interesting to hook up a logic analyzer too the console and watch what is happening on the bus...

[DirtyHairy]

55 minutes ago, STLRunner said:

It was worth trying but it doesn't boot in non-dumper mode, and does not output any data in dumper mode.

OK, too bad. One last try: the attached dumper firmware speeds up startup by not zero filling 96k of data  If the sixer comes out of reset earlier than the Jr. and encounters a JAM, then this might do the trick. If not, then I'm afraid it'll be some time until I can look into this again.

 

dumper_fastboot.zip

[+batari]

28 minutes ago, DirtyHairy said:

Hmm, good point, that would explain the 0x1fff on the 6507s bus. I don't see how this could happen, though, from the datasheet I would assume that the STM sets the GPIOs to high impedance during reset, and the firmware explicitly configures it to input during startup. Still, I'll think I'll give it a try and modify the bootup code to set the GPIOs to input as the first thing before memory is initialized and the C code is called. May take a week or two though before I get to it.

 

It would be really interesting to hook up a logic analyzer too the console and watch what is happening on the bus...

If you float the bus then likely you won't hit a JAM in cart space. But if the PC hits a location outside of cart space, the TIA or RIOT could easily drive the bus with a JAM instruction.

[DirtyHairy]

6 minutes ago, batari said:

If you float the bus then likely you won't hit a JAM in cart space. But if the PC hits a location outside of cart space, the TIA or RIOT could easily drive the bus with a JAM instruction.

You're right, that may really be what's happening. If the sixer comes out of reset while the Uno is still starting up and not emulating the firmware ROM (or running the dumper), then it could end up executing garbage from RIOT and TIA and hit a JAM.

Edited September 16, 2020 by DirtyHairy

[STLRunner]

22 minutes ago, DirtyHairy said:

OK, too bad. One last try: the attached dumper firmware speeds up startup by not zero filling 96k of data  If the sixer comes out of reset earlier than the Jr. and encounters a JAM, then this might do the trick. If not, then I'm afraid it'll be some time until I can look into this again.

@DirtyHairy Nice work, Christian! I played Quadrun to celebrate! Thank you very much for all of the hard work!

[DirtyHairy]

14 minutes ago, STLRunner said:

@DirtyHairy Nice work, Christian! I played Quadrun to celebrate! Thank you very much for all of the hard work!

Now that's good news. Thanks alot for testing, and thanks alot to @batari for the hint about JAM --- that was the key. I'll release the fix as v17.

Edited September 16, 2020 by DirtyHairy

[DirtyHairy]

Released v17.