Please test: FG99 firmware for both non-QI and QI

[+OLD CS1]

40 minutes ago, arcadeshopper said:

Pacman has an interesting issue on the 2.2qi
Other games like defender don't have this issue so it must be something they're doing grabbing the font from a memory location maybe and it's off a little

 

Nothing to be concerned about.  Just the Y3K release.

 

[JJB]

19 hours ago, mvancopp said:

I downloaded v1.3 from Ralph's FG99 site and put it on the SD cards and the same failure and symptoms occur.

I opened the FG99 case and checked the components and the chips match the requirements in GitHub. Both FG99 I hv=ave were bought from the same place at the same time and use the SD socket and not the SD shield. Maybe yours uses the shield and this introduces a small timing difference???

Also, one of my FG99s is never ready when powered up, you must always press the FG reset. The other comes up nearly all the time on power-up (but not quite 100%). The 1.1 update added .5ms delay trying to correct this (happens on all SD cards). Just FYI in case the info helps.

 

Mark

 

Looking at the schematic I don't believe it should make a difference if the SD socket or slot is used.

 

The delay info is interesting, I can see in the source it is applied before opening the SD card. When the AVR update file is found a jump is made to the bootloader update code which opens the SD card again. If that open fails it flashes like various members are reporting. 

 

If it is a timing problem with the AVR bootloader code we have a chicken-egg problem; the only way then to actually update the AVR code would be to connect an external programmer to the card's SPI socket.

 

We'll keep on searching.

Edited July 3, 2022 by JJB
spelling

[+mizapf]

You don't know Pac Man if you have not played it in the Klingon original.

[+OLD CS1]

1 hour ago, mizapf said:

You don't know Pac Man if you have not played it in the Klingon original.

https://stexpanded.fandom.com/wiki/Pac-Man_dreadnought

 

[mvancopp]

18 hours ago, JJB said:

Looking at the schematic I don't believe it should make a difference if the SD socket or slot is used.

 

The delay info is interesting, I can see in the source it is applied before opening the SD card. When the AVR update file is found a jump is made to the bootloader update code which opens the SD card again. If that open fails it flashes like various members are reporting. 

 

If it is a timing problem with the AVR bootloader code we have a chicken-egg problem; the only way then to actually update the AVR code would be to connect an external programmer to the card's SPI socket.

 

We'll keep on searching.

If there are brief instructions on the required SPI cables, connection, and programming software/steps I can solder on a SPI header and try any variations you may want to try.

I'll look on GitHub a see what I can find.

 

Mark

Edited July 3, 2022 by mvancopp

[JJB]

3 hours ago, mvancopp said:

If there are brief instructions on the required SPI cables, connection, and programming software/steps I can solder on a SPI header and try any variations you may want to try.

I'll look on GitHub a see what I can find.

 

Mark

My FG99 came with a SPI header and I have a programmer for it; I'll start experimenting and share my notes.

[JJB]

OK, I can now successfully update the bootloader through SPI. I am using a CH341A USB programmer (I think I bought it on Amazon, lots of choice there) and used the supplied connector to link up to the FG99:

 

 

 (the programmer supplies power to FG99, don't stick it in the console ?)

 

Your best bet is to use NeoProgrammer as it has native support for the AVR 328p microcontroller:

 

- Click "Detect" and make sure it detects the proper AVR chip

- Click "Read" (top menu) and check it can read the complete chip memory ok

- Click "Erase" (top menu); without this I had verify errors

- Load the hex file

- Click "Program" (top menu)

 

That should be all. The attached hex file update has an adjusted SD card check:

 

 if (pf_mount(&sd_fs)) {               //original code
    _delay_ms(5);                         //update; wait for SD cards to settle
     if (pf_mount(&sd_fs))              //update
       flash_error(1);                      //original code
  }

 

It will show version "1.B" in FG99 so you can check if the update has successfully installed. If it has been installed correctly your FG99 should be running ok on both consoles.

 

Cheers

 

 

 

 

fg99blsd.hex

[mvancopp]

20 minutes ago, JJB said:

OK, I can now successfully update the bootloader through SPI. I am using a CH341A USB programmer (I think I bought it on Amazon, lots of choice there) and used the supplied connector to link up to the FG99:

 

 

 (the programmer supplies power to FG99, don't stick it in the console ?)

 

Your best bet is to use NeoProgrammer as it has native support for the AVR 328p microcontroller:

 

- Click "Detect" and make sure it detects the proper AVR chip

- Click "Read" (top menu) and check it can read the complete chip memory ok

- Click "Erase" (top menu); without this I had verify errors

- Load the hex file

- Click "Program" (top menu)

 

That should be all. The attached hex file update has an adjusted SD card check:

 

 if (pf_mount(&sd_fs)) {               //original code
    _delay_ms(5);                         //update; wait for SD cards to settle
     if (pf_mount(&sd_fs))              //update
       flash_error(1);                      //original code
  }

 

It will show version "1.B" in FG99 so you can check if the update has successfully installed. If it has been installed correctly your FG99 should be running ok on both consoles.

 

Cheers

 

 

 

 

fg99blsd.hex 59.76 kB · 2 downloads

Thanks @JJB. I've ordered the CH341A and downloaded the software. While I wait for the programmer I need to find the jumper wires... there around here some where ?

 

I'll give feedback as soon as I know anything. Thanks for the effort!

 

Mark

[JJB]

16 minutes ago, mvancopp said:

Thanks @JJB. I've ordered the CH341A and downloaded the software. While I wait for the programmer I need to find the jumper wires... there around here some where ?

 

I'll give feedback as soon as I know anything. Thanks for the effort!

 

Mark

Awesome, thanks for testing. BTW mine came with the jumper wires so you may get lucky ?

[mvancopp]

On 7/5/2022 at 2:05 AM, JJB said:

Awesome, thanks for testing. BTW mine came with the jumper wires so you may get lucky ?

@JJB,

I was not lucky with wires being included but I found my stash, so all is good.

 

It was hard to find the CH341A drivers. I kept finding drivers that did not work. I didn't expect that. Once installed everything worked great and your directions allowed me to update the FG successfully!

Testing:

1. Update FG following your instructions with 1.Q hex file.

2. Success, the screen displayed the 1.Q logo.

3. Cleared a SD card and put your original jjb_update.avr file on it.

4. Ran the update from the SD card. The lights now behaved as you previously indicated, light up for ~2 secs and then off.

5. Success, the logo now displayed 1.3.

6. Cleared a SD card and put the AVR 1.Q (not the hex version) update.avr file on it.

7. This failed to update as described earlier and as expected without your new delay.

8. Update FG following your instructions with 1.Q hex file.

9. Success, the screen displayed the 1.Q logo.

10. Tried many carts and all worked. I did not try any auto start carts, the ones that take control immediately to see if the delay affects them. What carts do this?

 

So far so good. If someone can test the delay for the auto-start carts or let me know what carts do this and I can test, that would be great!

 

Thanks for all the effort @JJB!

 

Mark

 

[+dhe]

So my upgrade options start with "Purchase a CH341A USB programmer"? ? LOL...

 

I see lots of CH341A - but not so much on something that looks like the cable mentioned?

[mvancopp]

1 hour ago, dhe said:

So my upgrade options start with "Purchase a CH341A USB programmer"? ? LOL...

 

I see lots of CH341A - but not so much on something that looks like the cable mentioned?

Hi @dhe,
The cables are just breadboarding jumper wires, female-to-female. These are the ones I bought:

Amazon.com: Alinan 120pcs Dupont Cable Breadboard Jumper Wires 20cm Length Dupont Wire Kit 20pin Female to Female for DIY : Electronics

You can find smaller quantities and also male-to-male, male-to-female, and some packages have a mix of different types.

 

I hope that helps,

Mark

 

 

[+dhe]

Thanks @mvancopp - I have a  couple of dozen that came with my 1001 Arduino kit, I was thinking there was a standard wiring on both ends of the connectors, but it looks like a roll your own.

 

It doesn't look like we have cracked the mystery of why the update from SD card doesn't work, because clearly your hardware took to the reprogramming via CH341A?

 

 

[mvancopp]

4 minutes ago, dhe said:

Thanks @mvancopp - I have a  couple of dozen that came with my 1001 Arduino kit, I was thinking there was a standard wiring on both ends of the connectors, but it looks like a roll your own.

 

It doesn't look like we have cracked the mystery of why the update from SD card doesn't work, because clearly your hardware took to the reprogramming via CH341A?

 

 

The reprogramming from SD did work, see steps 3 + 4 in my post above. Once the FG is running the latest 1Q update (the hex file above) the SD card update works. I used to "downgrade" and after downgrading the update failed again (as expected). This proves the 1Q hex update fixes the SD update issue and wasn't a random event. Unfortunately you need the CH341A to get the 1Q update in FG. Once the "official" FG updates come with those same changes you should be able to update from SD then and going forward.

 

I hope I made that understandable.

 

Mark

 

[+dhe]

Thanks @mvancopp - so the people that got 'lucky' and upgraded via SD Card without problem - did they start with a later AVR code then you and I?

[mvancopp]

40 minutes ago, dhe said:

Thanks @mvancopp - so the people that got 'lucky' and upgraded via SD Card without problem - did they start with a later AVR code then you and I?

I don't think they had different AVR versions, 1.3 has been around awhile and I think that was stated earlier??? I think it is a race condition when the SD card becomes ready to be opened and read and when the software is trying to communicate with SD card. When the SD is ready could vary by console, and/or SD card, (power supply start-up timing and some small/tiny variation in TTL timing. Also, when the PS voltage reaches the TTL "turn-on threshold and all the chips begin drawing current the voltage can dip from the sudden change in current demand. Many of the TTL chips will be uninitialized and will come-up in states that vary from console to console and therefore have different current demands. The uninitialized start-up state is very often repeatable and is majorly determined when the chip die was mfr'ed) and in FG part timing (one chip, or set of chips, in the FG have varying start-up timing or slightly higher sensitivity to the console power start-up or start-up voltage dip, it "reset" if the voltage drop is too big).

My two FGs were bought from the same vendor at the same time so the chips used are likely from the same mfr and lot (I haven't verified that). I have dealt with many start up power issues. It's why any large machinery farms, electronic and otherwise, have only a limited number of units start at the same time and walk through the different units over a predetermined time and with appropriate gaps.

All conjecture/theory until measured, but we don't need to know the exact cause. The fact that it is a "glitch" in the start up and it is avoidable is enough information (at least me me).

 

Mark

 

 

[HOME AUTOMATION]

I noticed that JBB's update.avr file is 16 bytes longer than the original. Perhaps that's enough to overwrite some of the bootloader. When I temporarily bricked my FG99, it was because I had mistakenly loaded a double sized file.

[JJB]

1 hour ago, HOME AUTOMATION said:

I noticed that JBB's update.avr file is 16 bytes longer than the original. Perhaps that's enough to overwrite some of the bootloader. When I temporarily bricked my FG99, it was because I had mistakenly loaded a double sized file.

It's not enough by any means, there is still a lot of empty space between the code and the bootloader.

[mvancopp]

Small update: I reported earlier with the original pre-loaded AVR from console power-up one of my FG99s always came up in the TI main menu but the second required me to push the FG99 reset before it would appear on the menu. After the 1Q hex update both FG99s now come up in the main menu from power-up without my intervention. A small issue but nice to have that resolved also ? 

 

Mark

[JJB]

@mvancopp I am slightly confused here  ? the hex file contains the unchanged 1.Q code + the updated bootloader. Once it is installed, any "normal" AVR update file won't overwrite the bootloader as it doesn't contain bootloader code.

 

In other words, once the hex update has been installed, normal AVR updating should either work because the extra SD card delay is the proper fix or should fail as before ...

 

Maybe with the extra delay AVR updating it is now flakey / working sometimes?

 

BTW I expected the hex file to show version 1.B but I must have forgotten to include the changed graphic; I have attached an updated hex file for it.

 

Would you be able to re-test with this one?

fg99bl1B.hex

[JJB]

26 minutes ago, mvancopp said:

Small update: I reported earlier with the original pre-loaded AVR from console power-up one of my FG99s always came up in the TI main menu but the second required me to push the FG99 reset before it would appear on the menu. After the 1Q hex update both FG99s now come up in the main menu from power-up without my intervention. A small issue but nice to have that resolved also ? 

 

Mark

That's great; this could mean the re-defined GROM read/write timing could potentially fix other random problems some members were experiencing.

[mvancopp]

6 hours ago, JJB said:

@mvancopp I am slightly confused here  ? the hex file contains the unchanged 1.Q code + the updated bootloader. Once it is installed, any "normal" AVR update file won't overwrite the bootloader as it doesn't contain bootloader code.

 

In other words, once the hex update has been installed, normal AVR updating should either work because the extra SD card delay is the proper fix or should fail as before ...

 

Maybe with the extra delay AVR updating it is now flakey / working sometimes?

 

BTW I expected the hex file to show version 1.B but I must have forgotten to include the changed graphic; I have attached an updated hex file for it.

 

Would you be able to re-test with this one?

fg99bl1B.hex 59.76 kB · 2 downloads

I will retest with this new file and I will write down the steps I take as I do them to ensure the results I list are accurate. Maybe my anticipation of the behavior clouded my testing. 

I will post here later today.

 

Mark

 

[+dhe]

Thanks @JJBfor debugging this - I know from my limited coding - updating other people's code is much harder than updating your own.

Thanks @mvancopp for the detailed explanation of why some people with the same hardware and same firmware versions could update and some could not.

[HOME AUTOMATION]

20 hours ago, JJB said:

It's not enough by any means, there is still a lot of empty space between the code and the bootloader.

Any idea how much?

[JJB]

1 hour ago, HOME AUTOMATION said:

Any idea how much?

10860 bytes / 5340 words to be exact ?