Weird issue with UberGROM

[jdgabbard]

So, as some of you have noticed, Ive started posting again in the TI section... its because I bought a new house and have room for my TI gear now (sadly, it had been in storage). That said, Ive been going through my gear getting everything together.

 

I had bought an early UberGROM, but had never set it up. It had just been in a box with several other 512K boards. So I decided to dust it off and get it going. I made sure I had a decent understanding of the software, then began trying to load up the GROM slots. But this is when I discovered a problem...

 

When loading anything into the 1-2 slot of any base, it doesnt appear to load the data. Instead, it looks as though it is the internal UberGROM code. Last few pages seem to work. And ultimately, when reboote, the GROMs appear to function normally. But there is obviously some time of bug.

 

Now I was using the original software that came on the UberGROM, originally purchased at ArcadeShopper. But thinking it was an issue with that version, I downloaded the file from Tursis website and reflashed the 1284p. However, when I booted it up, it appears to have the same issue. I made a short video to show the problem, link below.

 

Again, it would appear that the GROMs work. However, I havent been able to fully test everything. Currently EA Complete, and RXB2015. The issue appears to be with the viewer not showing the data properly... Maybe Tursi or Karsul can weigh in.

 

[jdgabbard]

Note on my setup, Im loading the files from a NanoPEB v1. Just in case anyone has questions about the file storage. Volumes were written with TI99DIR.

[+Lee Stewart]

Though I have vanishingly little expertise with the uberGROM, I do know that console GROMs 0, 1 and 2 respond at all GROM bases. Without disabling them, I doubt you will ever be able to see anything you load there—if it even loads.

 

...lee

[jdgabbard]

Thanks for the response, Lee. In the package that Tursi uploaded (I think in the .BIN Repository thread) it has a picture in the pack download that shows these GROMs loaded in the same base with GROM0-3. So Im wondering if that is simply in emulation... If that is the case, Im not sure why the UberGROM would even offer those options, as it seems like it would be more destructive than helpful. Since those are TTL devices, having two devices talking on the bus at the same time would be a bad idea.

[jdgabbard]

I just double checked Tursis video. And it does appear that he uses GROM 0-3. And it loads the data. So I do not think that is the issue here. But he is using Classic99, so maybe that was just for demonstration.

Edited October 24, 2018 by jdgabbard

[RXB]

Hmm WTF?

 

GROM 0 = >0000 to >1FFF (GPL GROM)

GROM 1 = >2000 to >3FFF (TI Basic GROM 1)

GROM 2 = >4000 to >5FFF (TI Basic GROM 2)

GROM 3 = >6000 to >7FFF (Any cartridge)

GROM 4 = >8000 to >9FFF (Any cartridge)

GROM 5 = >A000 to >BFFF (Any cartridge)

GROM 6 = >C000 to >DFFF (Any cartridge)

GROM 7 = >E000 to >FFFF (Any cartridge)

 

I have no idea what kind of number system is being used in this screen shot but TI defaults are what I am using.

Edited October 24, 2018 by RXB

[+arcadeshopper]

the manual for the ubergrom is here: http://www.harmlesslion.com/cgi-bin/onesoft.cgi?29

[+Ksarul]

If you go into the Advanced settings, you have to uncheck one of the selections there that protects the loader software. Once you've done that, data loads normally into those slots. Note that this is only necessary to do if you are filling a lot of slots, as there are 15 of them in the cartridge, and the loader only eats four of them.

[Tursi]

How are you starting GROMCFG?

 

If you are using the recovery console (holding space on power-up), it overwrites the first couple of slots. This was just a bad decision on my part but doesn't hurt the UberGROM nor your ability to load into those slots -- it just sort of hurts the ability to see if you did it right. I didn't notice it till much, much later since I do tend to build my images on Classic99.

 

The recovery does not impact the flash device, so writes still go to the correct place and should be visible on reboot.

 

At one point we were going to make a version of GROMCFG that loaded via the Playground exploit, so you could get in without needing recovery... but I don't think we got it done. You could load Editor/assembler into the first slot (or an alternate base), and then reboot to come up without the recovery override. Once you're up it's safe to overwrite it again.

 

Recovery was really meant as a last-ditch recovery mechanism so the overload didn't feel like a big deal to me, but if I were to revise it I'd do it a little differently (or at least allow GROMCFG to turn it back off!)

 

Still, to reiterate, if that is what you are seeing then the problem is cosmetic only. When you load a file into those slots, it's really being loaded, and you should see it after you power cycle.

 

Rich: all the numbers in there are the indexes into the GROM space of the UberGROM. Those are /indexes/ not TI addresses. That's why the software calls the TI GROM space "6, 8, A, C, E", based on the addresses they are accessed at. There are too many numbers and its too easy to be confused. There's 120k of GROM space in the UberGROM and the pages are numbered 0-F. Likewise, you can have RAM (0-1), GPIO (0-3), etc etc.

 

Ksarul: if you disable the recovery console in that advanced option, you prevent being able to use the recovery at all. It doesn't protect the memory or turn it off, it simply controls whether the startup code even looks. If you don't provide a way to load GROMCFG after doing that, you are essentially bricked and need to reprogram the AVR. (Again, a Playground loader can fix that). You should only set the advanced options when everything else is working to your satisfaction. The recovery console does not eat /any/ slots, except when it's actually been activated for that specific cycle, it lives in the permanent code.

[jdgabbard]

How are you starting GROMCFG?

 

If you are using the recovery console (holding space on power-up), it overwrites the first couple of slots. This was just a bad decision on my part but doesn't hurt the UberGROM nor your ability to load into those slots -- it just sort of hurts the ability to see if you did it right. I didn't notice it till much, much later since I do tend to build my images on Classic99.

 

The recovery does not impact the flash device, so writes still go to the correct place and should be visible on reboot.

 

At one point we were going to make a version of GROMCFG that loaded via the Playground exploit, so you could get in without needing recovery... but I don't think we got it done. You could load Editor/assembler into the first slot (or an alternate base), and then reboot to come up without the recovery override. Once you're up it's safe to overwrite it again.

 

Recovery was really meant as a last-ditch recovery mechanism so the overload didn't feel like a big deal to me, but if I were to revise it I'd do it a little differently (or at least allow GROMCFG to turn it back off!)

 

Still, to reiterate, if that is what you are seeing then the problem is cosmetic only. When you load a file into those slots, it's really being loaded, and you should see it after you power cycle.

 

Rich: all the numbers in there are the indexes into the GROM space of the UberGROM. Those are /indexes/ not TI addresses. That's why the software calls the TI GROM space "6, 8, A, C, E", based on the addresses they are accessed at. There are too many numbers and its too easy to be confused. There's 120k of GROM space in the UberGROM and the pages are numbered 0-F. Likewise, you can have RAM (0-1), GPIO (0-3), etc etc.

 

Ksarul: if you disable the recovery console in that advanced option, you prevent being able to use the recovery at all. It doesn't protect the memory or turn it off, it simply controls whether the startup code even looks. If you don't provide a way to load GROMCFG after doing that, you are essentially bricked and need to reprogram the AVR. (Again, a Playground loader can fix that). You should only set the advanced options when everything else is working to your satisfaction. The recovery console does not eat /any/ slots, except when it's actually been activated for that specific cycle, it lives in the permanent code.

Tursi, thanks for the response. I was using the recovery menu, yes. I was prettty sure I was doing it correctly. And did notice the menu showed E/A Complete was present on the boot menu after power off. But even when loading back into the recovery menu, the data still showed the previous data. Which in this particular case doesnt seem to be an issue (as it is some type of E/A GROM from the information in the viewer). But it the option to load EA was present. And selecting option 3 allows to switch to other GROMs, RXB2015 in my case. So I assumed there was a version of GROM present in the AVR code. I havent looked at your source, so it was just my best guess.

 

One other issue I did notice, and thought I would ask about:

 

I decided to move E/A to GROM 4-7 last night, due to the issue noted here, since GROMs 4-7 show the changed data. And placed RXB to 8-B. And unmapped 0-3. However on power up there were no options present except for TI Basic after power off. I confirmed this 3x times. However, if I entered recovery and turned GROM0 on (which shows the default data that never changes), I can power cycle and the options reappear. Note that this is without adding any data to GROM 0. So it apparently has a bug that doesnt look for GROMs unless GROM 0 is present. Not a big deal, since I know about it and can make sure there is something present. But could be a trap for the new guy playing with these older carts. Were you aware of this? Was it intentional?

[Tursi]

Since you have E/A complete on the GROM already, my advice to you is to just use THAT to launch GROMCFG. Then you will stop being confused by seeing the recovery code. When you hold spacebar at powerup, the AVR redirects reads to the >6000 GROM to the built-in GROM code, which contains part of EasyBug and the EA#5 loader from Editor/Assembler. Only READS are redirected, which is why you can write to that slot but the data doesn't appear to change.

 

Again, the recovery mode is meant only for /recovery/ of a mistake, not daily use, which is why that tradeoff felt okay. You CAN use it to install new code, just remember that you won't be able to see the over-ridden slots while it's active. Whether that was a smart decision can and has been debated enough that I dropped the project.

 

I can't explain your lack of seeing menu options without seeing your configuration -- did you reconfigure the slots to point to the new pages? There's no reason I can think of for that.

 

The AVR code doesn't pay any attention to which slots contain data nor does it pay attention to which slots are mapped. When a read request arrives from the TI, it looks at the map and passes the request to the appropriate handler (GROM, RAM, EEPROM, etc etc). The GROM handler looks at which page is mapped and returns the appropriate byte. There's nothing magical about "GROM:0" through "GROM:2", they are NOT the console GROM0, GROM1 and GROM2 -- GROMCFG would call those 0,2,4 based on their TI addresses. As you can see, the tool doesn't let you map 0,2,4 (and even if you did, they are locked out in the code so can't be interfered with).

[jdgabbard]

Ok, that makes a lot more sense. I cant explain why the card acted the way it did with not mapping GROM 0, its very possible I just missed something. Whatever the case, I got it working. And the point about using E/A Complete to load the configuration tool makes a lot more sense than trying to enter the recovery mode.

 

As for dropping the project, meh, its a decision you made. If it was due to criticism of the functions, I that those criticisms were without merit. I think you did a fine job at implementing it. The only thing really missing, unless Im unaware of the implementation, is writing to the Flash ROM from the tool itself. Which isnt a big deal, and could be handled in a separate tool if someone has the know how. I know it was discussed in the past. But I dont think it was ever developed. And that point is moot since we now have the newer carts available. Which I need to buy...

 

The main reason I wanted to dig is this out was to get access to software I dont own the cart for. And so far it serves that purpose.

 

Thanks for the responses though, it really helped me understanding the tool.

Edited October 25, 2018 by jdgabbard

[Tursi]

 

 

The only thing really missing, unless Im unaware of the implementation, is writing to the Flash ROM from the tool itself.

 

Writing to the flash was something we discussed, but we didn't really have the I/O pins available. It's worth noting that the UberGROM and the PCB it's usually sold on were separately developed items.

[RXB]

 

 

Rich: all the numbers in there are the indexes into the GROM space of the UberGROM. Those are /indexes/ not TI addresses. That's why the software calls the TI GROM space "6, 8, A, C, E", based on the addresses they are accessed at. There are too many numbers and its too easy to be confused. There's 120k of GROM space in the UberGROM and the pages are numbered 0-F. Likewise, you can have RAM (0-1), GPIO (0-3), etc etc.

 

 

 

Well OK did not know that my mistake.

 

 

Should have called it UGROM and URAM as that would not use the same name for something else entirely.

 

It is annoying as someone that calls everything "THINGY" when pointing at a problem of equipment and EVERYTHING is "THINGY" to them!

 

Or in this case everything is GROM or RAM. New names are much more instructive to devices.

Edited October 26, 2018 by RXB

[Tursi]

Should have called it UGROM and URAM as that would not use the same name for something else entirely.

 

It is annoying as someone that calls everything "THINGY" when pointing at a problem of equipment and EVERYTHING is "THINGY" to them!

 

Or in this case everything is GROM or RAM. New names are much more instructive to devices.

 

 

From now on all my hardware components will be called 'THINGY'. Jim, can I update my part of the UberGROM, I mean, THINGY manual?

[+acadiel]

 

From now on all my hardware components will be called 'THINGY'. Jim, can I update my part of the UberGROM, I mean, THINGY manual?

[emoji23]

 

Sent from my Moto Z (2) using Tapatalk

[+Ksarul]

You can always make updates, Tursi! :grin:

[Omega-TI]

Here's a cover for the manual...

[Tursi]

Saved, thank you!

 

Sorry Rich, this amuses me a lot and I'll probably carry it on for too long. I'm not teasing you!

[HOME AUTOMATION]

Saved, thank you!

 

Sorry Rich, this amuses me a lot and I'll probably carry it on for too long. I'm not teasing you!

I'm sorry too... I like you Rich... But I don't like this...

 

 

 

I LOVE IT!!!!!!!!!!! :twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted: :twisted:

 

Edited October 28, 2018 by HOME AUTOMATION

[RXB]

Nothing worse then to get a new device and the nomenclature used is for something entirely separate that is similar.

 

Example is THEORY in Science vs how it is used normally. They are not even close, but people just assume they are same.

 

Or another example is COMPUTER for EVERYTHING ELECTRONIC even if it has no CPU or RAM.

[+Lee Stewart]

Example is THEORY in Science vs how it is used normally. They are not even close, but people just assume they are same.

 

I do not wish to derail this thread, but, as a scientist myself, I just cannot let this one pass. The normal use of the word “theory” is the way science uses it. And not just science, but the arts as well, especially in its sense as a body of guiding principles for any discipline, e.g., physics theory, mathematical theory, music theory, dance theory, medical theory. After all, the first definition in the Oxford English Dictionary (OED) is “a mental scheme of something to be done, or of a way of doing something; a systematic statement of rules or principles to be followed.” A related definition (the first in the American Heritage Dictionary) is its sense as “a set of statements or principles devised to explain a group of facts or phenomena, especially one that has been repeatedly tested or is widely accepted and can be used to make predictions about natural phenomena.”

Using “theory” to mean “assumption”, “conjecture” or “hypothesis” is considered by the OED as a loose or imprecise application of the word—certainly not “normal”.

The word’s meaning can generally be discerned from its context—except where it is intentionally subverted as it is in certain political/religious disputes.

I now return you to this thread’s original topic of discussion.

...lee

[Tursi]

No need, the original topic was resolved!