Extended Basic 2.7. She never CALLs!

[PeBo]

 

You shouldn't ever load GROMCFG again after upgrading the cart, that may be the source of your problems. When GROMCFG is loaded, it changes the advanced options. The update process sets the advanced options the way they need to be for the XB v2.7 Suite cart to work properly. I have a hunch that people were reloading GROMCFG after they upgraded their carts, then complaining that the cart didn't work. But I'm here sitting in my chair, and I can't see what others are doing sitting in their chairs, so I can only guess.

 

Gazoo

 

Then would it not stand to reason that updating my cart would reset those advanced options to the correct settings for 2.7 to work again??

 

And believe me, I had no idea I was loading a GROM configuration program. I thought I had downloaded a tweaked copy of BOOT for use with 2.7 and fully expected the familiar White on Blue BOOT menu. When the GROMCFG menu appeared I didn't know what the heck it was (which is why I didn't touch anything). If I had known I was loading something that would alter the contents of the cart unassisted I would have exercized more caution or at least done some reading first.

 

I'll try upgrading over the next few days and see what happens. At least I'll get the fixed DM2 call out of the deal (of course, only if the CALLs works after the upgrade). Whatever happens, I will start reading first!

Edited June 1, 2015 by PeBo

[Tursi]

There are two problems with GROMCFG, and they're both my fault. The first is that GROMCFG changes options without asking permission (or telling you), but it was NEVER intended to be used by the general public on released cartridges. My lack of foresight there. The second is that although the UberGROM has a write-protect, it doesn't protect the configuration space, and it should. (So, even if you set the write protect, it wouldn't fix this.)

 

The only issue with the theory is, only the two last slots and the power-up option are ever modified by GROMCFG. XB27 doesn't appear to use these two slots, and it functions regardless of the setting of the power-up recovery routine.

 

I did some troubleshooting using Classic99. First, I loaded the cartridge up (051315XB27), and this worked fine. I did the verification (Fctn-6) and all was successful. I started XB2.7 (option A), then entered CALL CHIMES, and it locked up. The GPL interpreter is still running, but the GROM addresses are all over the map. I did a soft reset (File->Reset won't work in Classic99 because this reloads ROMs), and re-verified the ROMS with Fctn-6, they still passed. At this point, GROMCFG has NOT been run again.

 

I'm not too familiar with how the interpreter processes a CALL command, but since the XB calls work, something else must be up. So I looked at the GROM, and this is interesting - there is no such call as CALL CHIMES.

 

There /is/ a CALL CHIME, and it works just fine. I looked at the data further to see if it was just a missing link, and to be honest, I don't understand how the search is working. It seems like the 'next item' link on every subprogram is set to >0000, so Gazoo might have to chime in there. It's also possible that the search code doesn't deal with multiple GROM banks correctly - I know if you have no GROM programs on a multi-bank cartridge that the master program selection code locks up. If that's true, there's got to be a way around it.

 

I further tried "CALL BOOGA" as one that I knew was absent, and that also locked up. I tried "CALL chime" and that was successful, so it's not case sensitivity.

 

Still, this suggests that any invalid CALL is crashing the search routine... could this be what's happening to you PeBo? Also, since the NanoPEB adds a call, try without it attached?

Edited June 1, 2015 by Tursi

[Gazoo]

'CALL CHIMES' and 'CALL BOOGA' give a SUBPROGRAM NOT FOUND error in the real cartridge. Just tested it in Classic99 and on a real TI.

 

Only the last CALL in the CALL list's 'next item' link contains >0000. XB calls are in a different format that Basic or DSR calls. The format, in order is 'next subprogram address', 'length byte','name', 'subprogram start address'. Basic or DSR calls are in the format 'next subprogram address', 'subprogram start address','length byte','name'. The GPL interpreter for XB alters the format so as to not confuse BASIC calls with XB calls of the same name. Only DSR calls are searched for in more than one Grom page (or Base).

 

Are you loading the ROM in Classic99?

 

My Ubergrom cart entry is this:

 

[usercart20]

name="Ubergrom"

rom0=U|6000|2000|G:\classic99\MODS\EA2k.BIN

rom1=8|0000|80000|G:\632k XB27 Cartridge\XB27 Suite 512k Rom 051315.bin

And I load the Groms from DSK1 using BASICLOAD.

Gazoo

 

 

 

Gazoo

Edited June 1, 2015 by Gazoo

[Tursi]

'CALL CHIMES' and 'CALL BOOGA' give a SUBPROGRAM NOT FOUND error in the real cartridge. Just tested it in Classic99 and on a real TI.

Yes, I used "the real cartridge" on Classic99 - that's why I included the filename, so you could check whether I used the correct one.

 

Only the last CALL in the CALL list's 'next item' link contains >0000. XB calls are in a different format that Basic or DSR calls. The format, in order is 'next subprogram address', 'length byte','name', 'subprogram start address'.

That makes a lot more sense - Thierry's page doesn't cover the difference there (or it's not immediately obvious). I knew I was reading something wrong.

 

My Ubergrom cart entry is this:

Good point, I was using my original configuration which replaced TI BASIC with Editor/Assembler. So I tried using this config - now I get the correct SUBPROGRAM NOT FOUND. The hyperspace crash I found was likely caused by my configuration lacking TI BASIC.

 

(I did, as an aside, test with several Extended BASICs and no TI BASIC. TI Extended BASIC, Super Extended BASIC, and XB2.5 all worked correctly. RXB 2001, RXB 2012, and XB2.7 (tested in the full cartridge) all required TI BASIC to be present. Those are all I have at the moment. I thought we found a clue, but seems to be a red herring since I doubt people are running without TI BASIC.)

 

If it fails again, Pebo, try going back into GROMCFG and /save/ the UberGROM off (to a new disk), and post the save file for us to compare? If we can see WHAT is corrupted, perhaps it will give a clue.

[Asmusr]

I did a simple but rather masochistic test:

 

I took my XB 2.7 cartridge, which has been working perfectly for a while now, and verified with F6 that GROM and ROM were still OK. I then ran GROMCFG and quit out from the opening screen *without updating anything*. Now the GROM is no longer valid when I press F6, and Bin2Hex and XB CALLs are not working.

 

If this cartridge is not working with the Flash device switched on that's the simple explanation.

[Asmusr]

... and the fix: open GROMCFG, press F7, set 4 options to on, off, on, off. Pull out cartridge.

 

When I inserted the cartridge again it was back to normal.

[Gazoo]

Tursi,

 

Could you possibly build a program that is a subset of GROMCFG? It's sole purpose would be to write a complete backup file to the cartridge.

 

When it is started, it would immediately display only the "This will overwrite the entire GROM and All configuration! ... Are you sure? Y/N" message. N would quit and Y would prompt for a filename. After it completes it would give a successful or not message and then quit upon a keypress.

 

This would make updates for anyone producing future cartridges easier without some having to go through some extra rigamarole. It should be pretty simple for you to do as you are intimate with the code. I would do it, but you wrote it in C, which looks like Chinese to me. If it was assembly, I would have already done it and submitted it to you for approval.

 

Gazoo

[PeBo]

If it fails again, Pebo, try going back into GROMCFG and /save/ the UberGROM off (to a new disk), and post the save file for us to compare? If we can see WHAT is corrupted, perhaps it will give a clue.

 

Won't be for a couple days, but will do.

 

Really appreciate the attempted assists and suggestions. If worse comes to worse ofcourse, I can always just get another 2.7 cart.

 

Also as suggested I tried the CALL MOUNT and CALL UNMOUNT commands without the nanoPEB connected and both locked the system rather than returning an error. For a lark I tried CALL with random commands (some standard XP, some 2.7 and some imaginary) all the standards commands work fine with or without the nanoPEB. But the nanoPEB's mount/unmoiunt, 2.7 CALLs and random fakes all lock the console rather than returning an error.

 

also tried it with & without 32k expansion still no go.

[PeBo]

... and the fix: open GROMCFG, press F7, set 4 options to on, off, on, off. Pull out cartridge.

 

When I inserted the cartridge again it was back to normal.

I avoided doing this yesterday since it was not recommended, but...

 

IT WORKED!!

 

I'm assuming that CTL F (Flash Dev OFF) made it work, but I will again hide beneath my ignorance of such things, and just extend a huge THANK YOU! (not the first time you've come to my rescue).

 

Can't test with F6 since that features not in my current version, but all the calls are back and functioning.

 

hooRAH! All is once again right with the world (or at least that tiny portion of it that I chose to acknowledge)

[Gazoo]

I couldn't resist this one. Click Help, and then check for known issues.

 

 

 

Gazoo

[Omega-TI]

 

... and the fix: open GROMCFG, press F7, set 4 options to on, off, on, off. Pull out cartridge.

 

 

 

IT WORKED!!

 

FANTASTIC! I figured if it worked for you guys, I'd give it a shot! SUCCESS! All is well with the world once more!

[Tursi]

I would like to know WHY it fails, though. I would still like to see a dump of the failed cartridge to know what has 'changed'. With the information I currently have, nothing that GROMCFG changes should break the cart. So some information is missing. In the meantime, PeBo, congrats!

 

All it changes is:

-Add the flash device to the last slot (which XB2.7 does not map anything to by default)

-sets the advanced options to default (which turns on the recovery program, which ONLY takes effect once after a power cycle, not after reset or FCTN-=).

 

The fact that just changing the options made it work is interesting. That suggests the GROM itself wasn't problematic... I'll have to look closer at those defaults versus what you're setting it to. At the very least, knowing what's going on may reveal another bug I need to fix.

 

I will fix the bugs in GROMCFG, and I will also fix the bug in UberGROM for future cartridges so that they can properly be write protected at the 'factory', and no more accidental user modification can happen.

 

The dedicated "upgrade" tool is probably feasible too, although it's not the direction I wanted this device to go either. I don't get a lot of free time, so give me some time.

 

The compatibility notes will always say 'no known issues' for a user defined cartridge unless you define a known issues string in the INI file.

 

BTW, in case it was not clear - I don't recommend pulling out the cartridge while it's hot. Power off the machine if that's what you really want, but FCTN-= should be fine too.

[PeBo]

I would like to know WHY it fails, though. I would still like to see a dump of the failed cartridge to know what has 'changed'. With the information I currently have, nothing that GROMCFG changes should break the cart. So some information is missing. In the meantime, PeBo, congrats!

 

I'm sorry I didn't save the uberGROM out to disk before I fixed the problem...just too damned anxious to see if the solution would work.

 

Of course it shouldn't be too hard to break it again!

 

(unfortunately I want to bask in the glory of a working cart again...and finally figure out how to use BOOT - which got me into this mess in the first place.)

 

But buddy, I just sat through the youtube instructional video for uberGROMCFG, and you've created an amazing tool (which you have said yourself was never intended for a general audience...if a 10 year old gets a hold of a rifle, you can't blame Smith and Wesson if she shoots her dog!)

 

I don't think your tool is as problematic as the folks who are having trouble with it. Case in point: it fixed the problem it seems to have caused - even if you're not quite clear how it worked!

[Asmusr]

I would like to know WHY it fails, though. I would still like to see a dump of the failed cartridge to know what has 'changed'. With the information I currently have, nothing that GROMCFG changes should break the cart. So some information is missing. In the meantime, PeBo, congrats!

 

All it changes is:

-Add the flash device to the last slot (which XB2.7 does not map anything to by default)

-sets the advanced options to default (which turns on the recovery program, which ONLY takes effect once after a power cycle, not after reset or FCTN-=).

 

The fact that just changing the options made it work is interesting. That suggests the GROM itself wasn't problematic... I'll have to look closer at those defaults versus what you're setting it to. At the very least, knowing what's going on may reveal another bug I need to fix.

 

I will run some more tests to see if the problem is with the Flash device or the Recovery program alone. Any other suggestions for things to test?

[Tursi]

PeBo - don't worry at all about it! Enjoy your working cart by all means! We'll eventually figure out what happened. XB2.7 jumped the gun on the release so things ended up being released in a funny order, and we're just sorting it all out.

 

Rasmus -- just the advanced options, it seems very likely that's where the issue happened. The flash device, as the configuration tool calls it, is always "present" in the code, all that option does is configure it to exist in the last slot of the device or not. There's nothing magical about the last slot, nor about the flash device itself (you can map it anywhere you like, and that advanced option won't look for it or touch it anywhere else). It is just there because GROMCFG itself looks for it at that address, and the 'advanced' option was to give me a fast way to turn it off if I was worried about other software trying to hit it.

 

Recovery activates a bit of a hack - if you are holding space bar on the very first boot of the GROM after power up, then it soft-reconfigures some of the mappings (ie: it does not alter EEPROM) to add Easy Bug and Run Program File to the selection menu in the early GROM slots, ignoring whatever is there. This works by using a GROM power-up vector in one of the later GROMs (>E000, I think), which is again only present in software, it doesn't modify the actual memory. After that first boot is complete, neither the power-up vector nor the space bar is checked again - so if you aren't holding space when you power up, all that code is gone. Disabling the option prevents it from running even on that first power-up. (The intent was to ensure there was a way to load software even with the UberGROM in place, so you could reconfigure a bad cart. Disabling it was meant for final release carts not intended to be end-user reprogrammed, along with the hardware write-protect. Even so, the TI BASIC loader is a better solution since you don't need a two-step process like the recovery code does, but it's there. ). Gazoo's early release hacked this code in the AVR binary to disable it, but I don't know if that's true on the final/shipped carts. I don't know what the hack would have done to this option - I assume it would not have any effect, honestly... unless the modified code doesn't hit all the same GROM addresses. That's how the AVR knows which path was selected by the console.

 

Rollover yes/no, I'm not sure what the final cart shipped as, but frankly it probably doesn't matter. Despite all the fighting over it, GPL doesn't need it, and I'm inclined to remove it. Still - worth testing so we know - it does have an effect on what the console MAY do.

 

I can't remember what the fourth option was and I'm at work, but I think it was pretty trivial. I'll try again in emulation after work and see if I can reproduce the issue as well. Again, if nothing else, knowing what the error is may uncover another bug, and I need to do a bugfix pass anyway!

[Gazoo]

Gazoo's early release hacked this code in the AVR binary to disable it, but I don't know if that's true on the final/shipped carts. I don't know what the hack would have done to this option - I assume it would not have any effect, honestly... unless the modified code doesn't hit all the same GROM addresses. That's how the AVR knows which path was selected by the console.

 

Rollover yes/no, I'm not sure what the final cart shipped as, but frankly it probably doesn't matter. Despite all the fighting over it, GPL doesn't need it, and I'm inclined to remove it. Still - worth testing so we know - it does have an effect on what the console MAY do.

 

 

All I did to remove the spacebar power up code was zero out bytes >04 & >05 in the header, which point to the power up that checks for the held spacebar. I never noticed any ill effects from it. Carts from about the time of the Chicago Fair had this option restored, but with the key changed to 'equals', so as to not interfere with my spacebar power up.

 

Rollover really doesn't matter, as the only time it would be of importance would be when moving code from Grom to Cpu memory, and the console Rom doesn't give 2 hoots about whether there's such a thing as rollover or not.

 

It appears the setting causing the problem is Flash on/off (#4). The cart should still work with Bases (#1) turned off, but only with XB 2.7, as if there were a normal XB cart plugged in. Settings 2 & 3 are pretty irrelevant.

 

The question is, though, why is this an issue only for a few people?

 

Gazoo

Edited June 2, 2015 by Gazoo

[+Schmitzi]

Hi,

not following the whole thread up to here, as it is too much for me at this time:

Are only nanoPEBs/F18A involved, or PEBs too ?

Sorry if dumb/p question.

schmitzi

[+Ksarul]

Gazoo, it may have been the simple curiosity check: maybe those who had no problems never loaded GROMCFG to check their load and those who had the problems did load it again. . .as no one knew that the second loading of the software could cause an issue until we figured out what was going on.

[PeBo]

Hi,

not following the whole thread up to here, as it is too much for me at this time:

Are only nanoPEBs/F18A involved, or PEBs too ?

Sorry if dumb/p question.

schmitzi

The only dumb question is one that is not asked.

 

My second console is down right now, so I was unable to test a system without an F18A installed. Unplugging the nanoPEB and pluggng in the PEB however made no difference. The 2.7 specific CALL commands faled to function in either case. CALL CAT wouldn't work if it was cataloguing a physical drive or a CF volume.

 

Now that everything is working (fixed in under 48 hours no less!), and folks continue analysing what happened, the obvious can now be stated...the most powerful diagnostic tools any of us have for our 4A's are the people in this Forum!

[globeron]

BOOT is great to have. I have mine setup almost exactly like Ω does.

 

Hahaha. That's funny. I was so busy to figure out how to get the XB suite stable that I forgot the whole purpose...which was the Boot utility! Thanks!

[globeron]

... and the fix: open GROMCFG, press F7, set 4 options to on, off, on, off. Pull out cartridge.

 

When I inserted the cartridge again it was back to normal.

 

 

Exactly that's the procedure (see the other forum with all the options).

 

F7 on, off, on, off and press FCTN-= (quit) then turn-off the TI, turn-off the nano-PEB (if any), plug out the module)

(turn on nano-peb, turn-on TI, plug in the module) does it for me.

 

The strange thing is 1x module still shows the errors on the groms (red screen) (but everything works)

and 1x module is perfect (all green screens)

 

Everything works means: CALL NYANYA, CALL MOUNT(x,y) for nanopeb, and DEC2HEX, etc.

 

 

Latest version (I did yesterday) = 051315XB27 (if I am correct? 13 May version)

Edited June 2, 2015 by globeron

[Tursi]

All I did to remove the spacebar power up code was zero out bytes >04 & >05 in the header, which point to the power up that checks for the held spacebar. I never noticed any ill effects from it.

Okay, I vaguely remember talking about this. That will leave the boothack active past boot, and the detailed effects of this is that access from >E000 through >FFFF will be replaced with the "boothack" miniheader (and garbage data after that). This will continue until address >E019 or >E01A is accessed, followed by >E00D.

 

>E019 activates the recovery programs (Easy Bug and Load Program File), while >E01A will disable them. Only the FIRST access to either is recorded. After that, the miniheader remains active until >E00D is accessed, that will finally turn it off.

 

So, if the powerup link and the code I put there never executes, the behavior is somewhat unpredictable in that GROM space. Fortunately, you restored the code in later builds, so it's fine (although I reserve the right not to support unauthorized hacks ).

 

Rollover really doesn't matter, as the only time it would be of importance would be when moving code from Grom to Cpu memory, and the console Rom doesn't give 2 hoots about whether there's such a thing as rollover or not.

It's unfortunate you didn't feel that way two years ago, but we move on.

 

It appears the setting causing the problem is Flash on/off (#4). The cart should still work with Bases (#1) turned off, but only with XB 2.7, as if there were a normal XB cart plugged in. Settings 2 & 3 are pretty irrelevant.

 

The question is, though, why is this an issue only for a few people?

Yeah.. so the next step is to try to reproduce... were you able to reproduce on hardware by turning on the Flash device in GROMCFG? Under emulation, nothing I do breaks the cartridge - even the integrity verification continues to pass. I confirmed the behavior you mentioned with bases disabled (XB 2.7 runs normally), I turned bases back on, everything still worked fine.

 

This doesn't rule out a bug in the AVR code, of course. Classic99 does not run the AVR code, it simply reproduces the effect. Classic99 also doesn't have support for the powerup routine. It does seem to confirm that the things that GROMCFG automatically changes on you do not in and of themselves cause a problem, but clearly more digging is needed. A dump from a cartridge made to fail is the next thing I can think of to look at. :/

 

One other thing that came to mind, and I don't remember if I ever asked - are people setting the AVR fuses properly for internal 8MHz clock with fast startup? (I was particularly thinking of the person who said that his GPL programs were slow on the AVR). Again, it /should/ be fine, I tested the code in the early days with very slow clocks (mostly to watch the TI run slowly ), but any variable is worth considering.

[Tursi]

In the meantime, I built and uploaded a new set of code for UberGROM.

 

-Don't overwrite user's config unless completely unconfigured -- it will now jump straight to the advanced menu if GROMCFG is started or a new image loaded which does not have both GROM bases and Flash Device active. This prevents you from browsing but ensures that any changes done are yours. I may remove the ability to configure the last slot in a future version so that turning Flash device on never accidentally overwrites anything, but for now, I'll just recommend not to configure anything there. There are lots of others to choose from.

 

-write original EEPROM bytes for >C000 on base 15 on full device save -- the device save had a bug that the second-to-last slot would always save as EEPROM, as that is the slot used for saving (even though the original data is restored after the save). It now writes the correct data to the save file.

 

-add build date at startup -- so you can tell which version you have

 

-Add load only version of configuration tool -- hope that works for you, Gazoo! It's much smaller too, just 6k. Run "GROMLOAD" instead of "GROMCFG". It will go through the same prompts as the main tool (it's the same code, just reformatted), so it asks if you're sure, gets a filename, etc.

 

-Also, new version of the AVR code that makes the hardware write-protect pin also write protect the configuration part of the EEPROM (first 258 bytes). So if you make a cartridge with this one, you can ground that pin and it can't be reprogrammed. You can still write to the rest of the EEPROM, assuming it's mapped in. No other change to the AVR code at this time - I wanted to keep that change small.

 

I haven't tested the new code works properly on hardware, though I did what I could. Anyone willing to be brave?

 

http://harmlesslion.com/software/ubergrom

[Asmusr]

I haven't read Tursi's post yet, but my test shows that the problem is not with the flash device but the recovery program. If the recovery program is enabled the problem will appear after turning off the power, but not only after quitting.

 

Edit: More tests confirm the above, and please note there is no need to pull out the cartridge in order to fix it, simply go into GROMCFG and turn off recovery, then quit.

[Gazoo]

I haven't read Tursi's post yet, but my test shows that the problem is not with the flash device but the recovery program. If the recovery program is enabled the problem will appear after turning off the power, but not only after quitting.

 

Edit: More tests confirm the above, and please note there is no need to pull out the cartridge in order to fix it, simply go into GROMCFG and turn off recovery, then quit.

 

Okay, I vaguely remember talking about this. That will leave the boothack active past boot, and the detailed effects of this is that access from >E000 through >FFFF will be replaced with the "boothack" miniheader (and garbage data after that). This will continue until address >E019 or >E01A is accessed, followed by >E00D.

 

>E019 activates the recovery programs (Easy Bug and Load Program File), while >E01A will disable them. Only the FIRST access to either is recorded. After that, the miniheader remains active until >E00D is accessed, that will finally turn it off.

 

So, if the powerup link and the code I put there never executes, the behavior is somewhat unpredictable in that GROM space. Fortunately, you restored the code in later builds, so it's fine (although I reserve the right not to support unauthorized hacks ).

 

 

 

 

AHA!!!!

 

1+1=2

 

Rasmus,

Please try the attached disk without doing anything but quitting after you do a ctrl-L and reload the cartridge Grom. I'm betting that you have a pre-Chicago Fair cart and this 2 byte change will correct the upgrade process. I haven't changed the date in the F7 screen in the cart (that's a lot of work), but changed the date on the disk and the upgrade file.

 

I had re-enabled the recovery program (with equals instead of spacebar) in the carts made after the Chicago Fair and set the config bytes to reflect that change. So if you have a pre-Chicago Fair cart with the recovery program disabled in the AVR code but set as enabled in the config there's a problem according to Tursi's explanation quoted here. This new disk image should reconcile the problem, but disable the recovery program for everyone.

 

Gazoo

 

060215XB27.dsk