Jump to content

STLRunner

New Members
  • Content Count

    13
  • Joined

  • Last visited

Posts posted by STLRunner


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

    • Like 1

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


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

    • Like 1

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


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


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


  7. 5 minutes ago, eightbit said:

     

    Thanks for the reply. I guess I will not bother then...as I don't own RRII anyway. But thanks for the reply. I guess no UNO for the H6 :(

    DirtyHarry was kind enough to tweak the firmware for me. We tried two or three different versions but they didn't help. I also acquired a different power supply with a higher current output but that didn't help either.

     

    I did purchase the ST-Link v2 programmer and someday we're going to use it to monitor what happens during boot. If anything is found, I will post it here.


  8. 10 minutes ago, eightbit said:

     

    Did you ever try this fix? It seems it would be a good thing to do anyway in order to add support for more games like River Raid II. But I am curious to see if it resolved your UNO cart issue? This fix will take me all but a few minutes....I just wonder if it will help.

    Yes, I did solder a jumper across that inductor but it did not make the UNOcart work. I didn't try it with River Raid II, but it had no negative effects either.


  9. Just so everyone knows, I removed the circuit board from the case and it still did not help on my Heavy Sixer. It works fine on a 2600 Jr and also a 7800. Be warned that it may not work on a Heavy Sixer no matter what you do.


  10. 5 hours ago, -^CrossBow^- said:

    Could it also be related or similar to the hardware hack that used to be required on some H6 units for some of the homebrews to work properly? I seem to recall it was cutting a trace or jumpering past some component that was later removed from the 2600 schematics.

     

    I found that thread and the fix:

     

    I am waiting to see if there's a fix to the firmware that will help before I modify my Heavy Sixer. I realize that the hardware mod is simply soldering a wire across an inductor, which I am open to.

     

    My question would be whether or not the UNOCart-2600 was tested on six switch consoles before it went to market.


  11. Hi, all. I just acquired a Heavy Sixer and about 40 original games. They all play fine but the UNOCart 2600 cartridge will not boot on it. I tried it in a friend's 7800 and the UNOCart works flawlessly. Is there anything that I can check or do on my 2600 console? I am mechanically and technically savvy so opening it up is no issue.

     

    I tried all of the standard troubleshooting stuff - remove UNO from its shell, inserted it with varying depths, different SD cards. It won't boot even with no SD card. The UNO is also on the latest firmware.

     

    Any suggestions are much appreciated.

     

    And, as an aside, I am loving the 40+ year old technology. I could not afford it back in the 70s or 80s.

    • Like 1
×
×
  • Create New...