The FinalGROM 99

[HOME AUTOMATION]

It's not so easy to brick the FG99, to the extent that it can't be updated from the SD card. I know because I've done it! So, it seems less than likely that you completely bricked it on your first attempt, unless your power connections are terribly unstable, or you're somehow doing it wrongly.

 

When I bricked mine, the TI still powered up normally, but with no FG99 menu. I bricked mine while updating the .avr, which can be more difficult to restore than when updating the .pld.

 

Though you may believe that you followed the instructions accurately, there are several places where one can go astray.

 

"immediately saw the steady blinking led, which seems to be an issue w/ the SD card", seems somewhat vague to me. A detailed step-by-step description, if you can recall,  may reveal something more relevant.

 

Did you verify that your FG99 worked correctly immediately before you tried the update procedure, and are you using the same SD card for the update(s), as you do for general use?

[telengard]

25 minutes ago, HOME AUTOMATION said:

It's not so easy to brick the FG99, to the extent that it can't be updated from the SD card. I know because I've done it! So, it seems less than likely that you completely bricked it on your first attempt, unless your power connections are terribly unstable, or you're somehow doing it wrongly.

 

When I bricked mine, the TI still powered up normally, but with no FG99 menu. I bricked mine while updating the .avr, which can be more difficult to restore than when updating the .pld.

 

Though you may believe that you followed the instructions accurately, there are several places where one can go astray.

 

"immediately saw the steady blinking led, which seems to be an issue w/ the SD card", seems somewhat vague to me. A detailed step-by-step description, if you can recall,  may reveal something more relevant.

 

Did you verify that your FG99 worked correctly immediately before you tried the update procedure, and are you using the same SD card for the update(s), as you do for general use?

Totally true, I may have not followed the steps perfectly, and yup it was working right before I did it.  I had played a game of Car Wars and Wumpus.

 

The steady blinking LED seems to be matching what the documents say for error codes, which is why I mentioned the SD card.  I used the same SD card I use for my games, etc.

#U1  (o)........(o).........(o)........(o)........(o)........(o) ...
indicates a bad SD card reader, a bad SD card, or the wrong filesystem,

 

These are the steps I did:

 

Put the 1.3 avr file as update.avr on the SD card at the top level.  While the finalgrom was powered off put the SD card in and turned the TI on.  Waited a little bit and saw the blinking LEDs as I described.

I then put the update pld as update.pld on the SD card at the top level and while powered off put the SD card in and turned the TI on.  Waited a long time and the LEDs blinked like pretty soon after turning on.

I tried this a 2nd time after cycling power to the TI and now I get a black screen with the high pitched noise when turning it on and the Finalgrom inserted.

[HOME AUTOMATION]

1 hour ago, telengard said:

Waited a long time and the LEDs blinked like pretty soon after turning on.

Hmm, Mine only has one LED. blinked?

You can only process one update.xxx, file at a time, and each update.xxx, file must be deleted manually after the update.

 

What should happen when you turn the TI on with an update.xxx, file present on the SD card is... The LED should illuminate for about 8 to 16 seconds, then go off.

[+arcadeshopper]

Pretty sure you need to have nothing on the card except for the update file

Sent from my Pixel 6 Pro using Tapatalk

[telengard]

4 minutes ago, HOME AUTOMATION said:

Hmm, Mine only has one LED. blinked?

You can only process one update.xxx, file at a time, and each update.xxx, file must be deleted manually after the update.

 

What should happen when you turn the TI on with an update.xxx, file present on the SD card is... The LED should illuminate for about 8 to 16 seconds, then go off.

Yes, single led blinking in that pattern (not LEDs, sorry).  I did each step separately, removing the previous file first.

 

When I did the update.xxx I just had the constantly blinking LED.

[telengard]

3 minutes ago, arcadeshopper said:

Pretty sure you need to have nothing on the card except for the update file

Sent from my Pixel 6 Pro using Tapatalk
 

Oh geez, I didn’t realize that.  I will try again doing that.

[HOME AUTOMATION]

Many devices want the SD card empty during an update, but I haven't had that issue on my FG99.

 

Still, couldn't hurt ...keeping in mind that you may need some .bin files on the sd card to get the FG99 menu up. Recently, I got my menu up with no .bin files on the SD card, but that seemed unusual.

[HOME AUTOMATION]

I would certainly try the update procedure again... .PLD first. Although, if the .avr update went awry, you might need to redo both, .avr first.

[telengard]

Some progress, that error message wasn't lying.  For some reason, it no longer liked the SD card I've been using all along, this is even after re-formatting it and putting the update.pld on it.  I switched to a different one and both updates seemed to go OK (LED on for a little bit steady, and then off).  The machine no longer has a black screen and the noise when turning on, but no option for FinalGrom99 even resetting the TI w/ the right button to ensure SD card reads are done.

[telengard]

It's working again!  I re-did the updates in that order, and re-populated this new SD card and it is working fine now.

 

thanks everyone!!

[HOME AUTOMATION]

I had a new SD card once, that would not tolerate reformatting ... getting worse with each attempt!

Edited November 21, 2021 by HOME AUTOMATION

[+dhe]

> I re-did the updates in that order,

For the record what order do you do the update in, and what files where on the fresh SD card each time?

[telengard]

5 minutes ago, dhe said:

> I re-did the updates in that order,

For the record what order do you do the update in, and what files where on the fresh SD card each time?

I did the update.avr first, with only that file present

then did update.pld with only that file present

[HOME AUTOMATION]

The order normally doesn't matter. But, the AVR must be functional, in order for it to update the PLD. So, if the .avr, update fails catastrophically, you can't update the PLD.

 

Also, the AVR contains the boot loader, which if overwritten, results in an inability to do further updates from the SD card!

Edited November 21, 2021 by HOME AUTOMATION

[wierd_w]

5 hours ago, HOME AUTOMATION said:

I had a new SD card once, that would not tolerate reformatting ... getting worse with each attempt!

 

More recent SDCards, with their larger capacities, often have "Enormous erase block sizes".    For instance, a 256gb card I have, has an erase block size of 4MB!!!

 

This prompts very fast wear when using an older filesystem, like FAT, that wants a 16kb to 32kb cluster size.  Write amplification goes way through the roof, and in some cases, the controller inside the SDCard wont even let you do a write that small.

 

The SDCard Assn wants you to use eXFat for this very reason. (It can let you use such an absurdly large cluster size.) The FG99 does not know how to deal with eXFat though.

[ralphb]

6 hours ago, telengard said:

For some reason, it no longer liked the SD card I've been using all along, this is even after re-formatting it and putting the update.pld on it.

SD cards are weird.  I also experienced the behavior you mentioned, and I don't really know why.  The SD cards rejected by the FinalGROM work seemingly fine on a PC.

 

The FinalGROM doesn't support any kind of fallback in case the serial I/O doesn't work any more.  Most PCs (and the SDD 99) rely on 4-bit parallel I/O, which (speculation mode on) might use different logic inside the flash controller.

 

Fortunately, SD cards are cheap enough to not worry much about these rare failures.

[+dhe]

Quick Google came up with:

>Most SD cards won't retain data for more than about five years. The best practice for keeping your data safe is to copy it from your SD card to your computer as soon as you can

>We recommend replacing the CF cards after 2 years or so, depending on how many images you have shot on them and how big the CF card is.Jun 12, 2014

 

About every 7 years I buy a new home computer, I tend to get the largest drive available at the time, that makes it fairly easy to copy my old machines in to a directory on the new machine called /Machine_Archives/compaq92-03

                                                   /vostro04-11

                                                        {etc}

 

I was think about storing them on an ssd, but found out via research ssd drives start getting bit rot fairly quick if not used. I ended up with synology ds218 - and have the drives mirrored with a compare that happen's once a month to ensure data integrity.

 

[wierd_w]

4 minutes ago, dhe said:

Quick Google came up with:

>Most SD cards won't retain data for more than about five years. The best practice for keeping your data safe is to copy it from your SD card to your computer as soon as you can

>We recommend replacing the CF cards after 2 years or so, depending on how many images you have shot on them and how big the CF card is.Jun 12, 2014

 

About every 7 years I buy a new home computer, I tend to get the largest drive available at the time, that makes it fairly easy to copy my old machines in to a directory on the new machine called /Machine_Archives/compaq92-03

                                                   /vostro04-11

                                                        {etc}

 

I was think about storing them on an ssd, but found out via research ssd drives start getting bit rot fairly quick if not used. I ended up with synology ds218 - and have the drives mirrored with a compare that happen's once a month to ensure data integrity.

 

 

BitRot will be a problem in SSDs for the same reason it is in SDCards.  It is fundamental to how flash memory works. (basically, trapped charges inside a logic gate array.) The major difference in technology in an SSD vs an SDCard, is in how the flash memory cells are addressed and accessed, not the cells themselves. (Arrangement, rather than basic technology).

 

Magnetic recording gets dicier these days, with SMR being a thing.  CMR drives are more reliable and get less wear but hold significantly less, and are not manufactured in as large of numbers these days.

 

Really, there isn't a good archival format in the modern era. 

 

A RAID array can deal with these medium specific issues through redundancy and parity data correction technologies, but that just adds more price and complexity.  Something that you can just sit on a shelf and forget about?  Not with anything modern.

 

[+dhe]

I think what we really need is a utility that will go out and resilver drives once a year - since we are migrating to flashy stuff in ide/scsi/final groms/DREM/tipi/?/.

Unless intelligence was built in, that would fix file corruption, but it would recharge bits.

[ralphb]

11 minutes ago, dhe said:

I think what we really need is a utility that will go out and resilver drives once a year - since we are migrating to flashy stuff in ide/scsi/final groms/DREM/tipi/?/.

Unless intelligence was built in, that would fix file corruption, but it would recharge bits.

At least for the FinalGROM I never intended the SD card to be sole container for important files.  With the exception of write back (e.g., Mini Memory), all files are read-only anyway.

 

And for the upcoming *cough* SDD 99 it's easy to backup files on microSD to your PC.

[wierd_w]

Honestly, the size of the cart archive is not that big.

 

I would earnestly suggest ordering small capacity industrial sdcards, in the 128-512mb range.

 

They will have much smaller erase blocks, and play much nicer with FAT filesystem.

[+Ksarul]

As to archival storage, your best bet is to use an M-Disk. It looks like a CD/DVD, but it uses a completely different substrate for the data (and any recent CD/DVD writable drive supports them). The disks will hold the data for at least 100 years, and are reputed to last for up to 1,000 years without data loss. The disks are a bit expensive, but worth it for data you are interested in preserving for time periods longer than the recording format is likely to last. . .

[+OLD CS1]

20 hours ago, wierd_w said:

The SDCard Assn wants you to use eXFat for this very reason. (It can let you use such an absurdly large cluster size.) The FG99 does not know how to deal with eXFat though.

I still buy used cards in MB sizes off eBay (256MB and smaller for some applications.)  They check out fine and the limited writing is right up my alley.  I have not looked at the specs for exFAT, but I assume it is capable of allocation units which align with the 4MB underlying sectors but are more accommodating to our small cartridge file sizes.

 

3 hours ago, Ksarul said:

The disks are a bit expensive, but worth it for data you are interested in preserving for time periods longer than the recording format is likely to last. . .

I have placed a bunch of scanned documentation and photos on DVD M-DISC.  Not inexpensive, but good stuff.  Speaking of expensive media, I am frustrated that I bought a 128GB BluRay drive but the media is stupid expensive.

[wierd_w]

2 hours ago, OLD CS1 said:

I still buy used cards in MB sizes off eBay (256MB and smaller for some applications.)  They check out fine and the limited writing is right up my alley.  I have not looked at the specs for exFAT, but I assume it is capable of allocation units which align with the 4MB underlying sectors but are more accommodating to our small cartridge file sizes.

 

 

Smaller SDCards that are smaller, should follow SDCard Assn spec, which would specify FAT32 as the preferred format. (if under 64mb).  Larger cards (64mb and larger), the SDCard Assn wants you to use ExFAT.  Yes, ExFAT lets you use absurdly enormous (4mb and larger!!) cluster sizes.

 

I get around the issue on my linux based devices by abusing the RAID features of the EXT4 filesystem.  While the FS itself has a 4k allocation unit, it has "Stride and Stripe" features that are meant to have "entire stripes written", such as for a hardware RAID controller, and you can juggle some math so that these write and read sizes align with the native block size, and thus evade the write amplification.

 

The PROBLEM, is that the card makers DO NOT TELL YOU THE BLOCK SIZE.  You have to either 1) Investigate and see what the allocation unit size of the initial ExFAT FS from the factory is, and sharpie that shit on top of the card for reference, or 2) Use the byzantine and voodoo process of using flashbench on it to determine what the page size and erase block sizes are of the flash controller baked in.

 

Again, you will have much smaller erase block sizes (usually around 64kb or so, for a 256mb module, which is 2 clusters of huge-fat, or 4 clusters of normal 16kb cluster size FAT, and thus not at all that bad), and will play much nicer, even though it is out of spec, according to SDCard Assn.

 

This is why I would suggest using the smaller, industrial cards.

[JJB]

Update on FG99 on the QI:

 

 

 

Cheers,

 

Jochen