Gazoo Posted June 2, 2015 Share Posted June 2, 2015 Quote 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. Well, I was violently opposed to the new Grom behavior you were introducing 2 years ago because it would have broken virtually all the software ever created by GRAM PACKER, as well as all the similar software created 'by hand' such as my DSKU/ARCHIVER/MCOPIER pack. I then discovered and pointed out to you, which you reluctantly confirmed, that the TI ROM (which includes the GPL interpreter) doesn't give a s--t about rollover. Your modification to the Grom behavior would only apply to the actual execution of code across an 8k Grom boundary, which is easy enough to check for as there are only 4 places on each page (you call them bases) to check if the execution of code crosses those boundaries. So I feel exactly the same way I did 2 years ago, but I can easily adjust to the 'new rules' of the Ubergrom cart. No 'moving on' required. Gazoo Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 2, 2015 Share Posted June 2, 2015 (edited) -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. Thank You!!! I'll definitely check it out!!! That may actually fit 'in' a TI BASIC program, I'll have to check with that Senior-Bird-Guy. Gazoo Edited June 2, 2015 by Gazoo Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 3, 2015 Share Posted June 3, 2015 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. Yup, we're still figuring it out. I didn't know that could cause an issue until it was reported. All we can do is keep trying to make this thing actually work the way we want it to...we'll get there...little bumps in the road...I think I need my rims straightened... Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 3, 2015 Share Posted June 3, 2015 In the meantime, I built and uploaded a new set of code for UberGROM. ... -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. Did the restore operation work correctly in the previous version(s)? I assume it did as the F6 verification utility would report bad Grom if it didn't. I never created the update files using the save option, they were created 'by hand' using the specifications you posted. Gazoo Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 3, 2015 Share Posted June 3, 2015 I then discovered and pointed out to you, which you reluctantly confirmed, that the TI ROM (which includes the GPL interpreter) doesn't give a s--t about rollover. Interesting tint on that history. My only reluctance was /adding/ rollover support to the GROM. I was violently opposed to it and nearly dropped the project over your behavior regarding it. I had the GROM emulation code done and proven nearly two years before you popped into the thread, insisting that I didn't know what I was talking about. After I did it, you then took a bow for "improving" the product. I'm getting used to you, but your rules of social conduct are occasionally one sided. As a good example - this case. You don't like people modifying and redistributing your code, but you have no qualms doing it to someone else's. So yeah, moving on is required. Maybe not for you, but certainly for me. I'm helping out because despite all that crap, you still produced something genuinely useful to people, and everyone should get to enjoy it. Did the restore operation work correctly in the previous version(s)? I assume it did as the F6 verification utility would report bad Grom if it didn't. I never created the update files using the save option, they were created 'by hand' using the specifications you posted. Yes.. the only thing was that incorrectly saved on a save operation was the second-to-last slot would be written as EEPROM, regardless of what it actually was. (Load I took great pains to ensure it didn't leave traces of itself in EEPROM). I assume you didn't checksum ports you were not using, in which case it wouldn't care. Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 3, 2015 Share Posted June 3, 2015 (edited) I'm getting used to you, but your rules of social conduct are occasionally one sided. As a good example - this case. You don't like people modifying and redistributing your code, but you have no qualms doing it to someone else's. Actually I don't mind people improving my code. And I generally post the source so they don't have to disassemble it. A recent example is the TI Basic EA5 loader. Senior Falcon and you helped to get it working. At this point it doesn't work on a Nano/CF7, so I posted the code hoping that someone with one of those devices would take on the task of altering it to work with those devices. No one has done so yet, but I wish they would. Let's go back as far as April 5, 1999. I posted the HSGPL MENU code so people could modify it for their own use. I had hoped someone would find a way to improve the speed of the required VDP to GRAM block moves. Jeff White helped improve the speed a little, but it's inherently slow as 2 memory mapped devices are being accessed. So your theory of my social conduct is flawed, it's been consistent for quite some time. I shoot from the hip and tell it like it is, and I don't take any BS. Gazoo Edited June 3, 2015 by Gazoo Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 3, 2015 Share Posted June 3, 2015 Actually I don't mind people improving my code. And I generally post the source so they don't have to disassemble it. But then, you'd have to pry loose the programming files for the chips from me. And that's just because I want it to work correctly. I found a chipset and a procedure that works. I'd rather there not be half-assed versions floating around out there. And you might not have the correct chipset that works together correctly, my main reason for making them myself - I don't want an inferior product floating around out there. So your theory of my social conduct is flawed, it's been consistent for quite some time. I don't think that word means what you think it means. Anyway, nobody cares. Are we done with this issue, is it all tested and confirmed? Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 3, 2015 Share Posted June 3, 2015 I assume Rasmus is going to test my update, so we'll have to wait for his conclusions. Posting a bunch of out of context quotes that have nothing to do with the issue proves... sorry, I can't figure that out. If no one cares that you keep attacking me and I have to continue to show those attacks to be meaningless, people probably do care. I'm sure they'd rather that the nonsense stopped. But that's not my decision to make, you are the one that has to stop. I hope you decide to do it sooner than later. If you could just help with the issue at hand without bringing the smarmy snarkiness into the conversation, I think we'd all be better off. Gazoo Quote Link to comment Share on other sites More sharing options...
Shift838 Posted June 3, 2015 Share Posted June 3, 2015 (edited) 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 how do we know if we have a pre-Chicago Faire cart? Edited June 3, 2015 by Cschneider Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 3, 2015 Share Posted June 3, 2015 Hi Gazoo, I've been having some memory issues lately and have been having a hard time keeping up with all the new key presses, new features and updating protocols. Would it be possible to make a CARTRIDGE UPDATER'S GUIDE, of a page or so to help out us forgetful codgers and the noobs that will arrive in the future? Thanks. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 3, 2015 Share Posted June 3, 2015 If you could just help with the issue at hand without bringing the smarmy snarkiness into the conversation, I think we'd all be better off. I think we're done. 2 Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 3, 2015 Share Posted June 3, 2015 how do we know if we have a pre-Chicago Faire cart? Hold down the equals key when powering up the console with the XB v2.7 Suite cart in the slot. If you get the normal menu, then it's pre-Chicago. If you get and EA5 file loader and Easy Bug it's post-Chicago. But I changed the config in the cart dump so it doesn't matter, nobody will get the restore option in the newest release. It really wasn't needed anyway. Gazoo Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 3, 2015 Share Posted June 3, 2015 Hi Gazoo, I've been having some memory issues lately and have been having a hard time keeping up with all the new key presses, new features and updating protocols. Would it be possible to make a CARTRIDGE UPDATER'S GUIDE, of a page or so to help out us forgetful codgers and the noobs that will arrive in the future? Thanks. The docs have been updated with the new keypresses. There's a message here somewhere explaining the update process. I'd prefer to keep them separate. I doubt there will be any more updates. I'm in the midst of making the update process easier, so you probably won't even need instructions. Gazoo Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 4, 2015 Share Posted June 4, 2015 060315XB27.dsk To use the XB v2.7 Suite upgrade disk image: Make a real 40 track DSSD floppy disk from the 051315XB27.dsk image provided and put it in the DSK1 drive. Do not put this disk in an 80 track drive when used with the TI disk controller, I've taken steps to insure it will fail if you do so. (and that's just a dumb thing to do, anyway) If you have an 80 track drive as DSK1, contact me and I will provide you with an appropriate disk image. Load the GROMLOAD program with the XB v2.7 Suite cart in the cartridge port. You can do this 3 ways: 1. Select the TI Writer/Assembler cart (B), press 6, type 'DSK1.GROMLOAD', and press enter. The program will load. 2. Select Extended Basic v2.7 (A), and the program will load automatically. 3. Select TI Basic (Z), type 'OLD DSK1.BASICLOAD', type 'RUN', and the program will load automatically. The 3rd option is the most cool, as you can recover from a bricked cart with this, thanks to Tursi and Senior Falcon with their assistance on this. Now that you've got the program loaded, follow these steps to upgrade/restore your XB v2.7 Suite cartridge. You'll be asked a question, press 'Y'. Type 'DSK1.060315XB27', and press enter. Let the process complete! It will take some time. One the process has completed successfully, press the spacebar to quit, and you'll be presented with the XB v2.7 menu. At this point you can check the upgrade with the cartridge verification program. Press fctn-6 from the main menu to run it. When it has completed successfully, you will see a green screen with a success message. If you get a red screen, something is amiss, do the upgrade again being sure to follow the directions carefully. If the process didn't work correctly, do not despair. Use the TI Basic load option for GROMLOAD and repeat the process until you are successful. Press fctn-7 and you'll see the green credits screen with the dark blue edges for the updated cartridge. Gazoo 06-03-2015 3 Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 4, 2015 Share Posted June 4, 2015 ^ This ^ works ^ for ^ me, but I haven't gotten any feedback from anyone yet. Can someone that was having 'The Problem' let me know for sure this fixed it? Thanks, Gazoo Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 4, 2015 Share Posted June 4, 2015 060315XB27.dsk To use the XB v2.7 Suite upgrade disk image: Make a real 40 track DSSD floppy disk from the 051315XB27.dsk image provided and put it 061215XB27 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 4, 2015 Share Posted June 4, 2015 (edited) 061215XB27 060316XB27 Edited June 4, 2015 by schmitzi 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 4, 2015 Share Posted June 4, 2015 060316XB27 Ooops! 060315XB27 1 Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 4, 2015 Share Posted June 4, 2015 Great. Just great. There's now 2 Rodney Dangerfields in the group. 4 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 4, 2015 Share Posted June 4, 2015 (edited) (this "error" was especially for you, Omega Edited June 4, 2015 by schmitzi Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 4, 2015 Share Posted June 4, 2015 Gazoo, sorry, but I claim to be Chevy Chase (my favorite) 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 4, 2015 Share Posted June 4, 2015 Great. Just great. There's now 2 Rodney Dangerfields in the group. I dunno about Schmitzi, but I'm MUCH better looking than this guy.... Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 4, 2015 Share Posted June 4, 2015 ♫ ♫ Moooon Rivvvver ♫ ♫ 1 Quote Link to comment Share on other sites More sharing options...
globeron Posted June 5, 2015 Share Posted June 5, 2015 My ("buggy") module upgrades okay, everything works okay, but still the GROM verifier shows that it is comprimised (red screen) * CALL functions work okay (after plug in / out the module) * F6 has blue borders, but still shows May 13th. (not June 3rd) (This one I never got it to work somehow) * Selecting Z = TIBASIC the old DSK1.BASICLOAD RUN (green screen) hangs the system, it does not load the program Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 5, 2015 Share Posted June 5, 2015 Yes it works. Both Gazoo's update that doesn't turn on Recovery and Tursi's new version of GROMCFG. When I open the latter with my XB27 cart inserted it simply skips to the F7 menu, which is expected. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.