GK MSAVE

[FDOS]

Three questions for everybody

I originally posted the following on the TI-99/4A at yahoogroups.com, but I didn't get much feedback, so I'm going to try it here.

Bill R Sullivan <br911sullivan@gmail.com>

Feb 7

to ti99-4a
Currently, I'm keeping busy getting some of my TI/Geneve systems back in reasonable operation. Mainly trying to catch up on F18A development (I have two working TI consoles), and the status of CF7A+/NanoPEBv1/NanoPEBv2 (I have one of each, and they're each attached to a TI Synthesizer, so easy to switch out without concern of damaging one or more of these delicate devices), as this is the system(s) that I will use to continue TIB+ development, for the time being.

Before the questions, I would like to take this opportunity to thank Ben Yates & Mark Wills, for the code they contributed, Tim Tesch for finding and fixing a bug in the EA5 loader code, Jeff White for all of his excellent expertise and advice on "how to", Mike Brent who solved and fixed, what appeared to be another MSAVE/MSAVE6 problem (see paragraph #1 below), but was actually a flaw in the TI E/A module, more amazingly he added the fixed code to Rich Gilbertson's TI BASIC, allowing me to use MSAVE6 without an EA or MM module or similar support in Myarc/Corcomp w/Myarc EPROMs from MG DSR's, to support all the AL code that makes up TIB+. Otherwise the only hope for the CF7/NanoPEB is the MM module (with only 4K RAM) or EA+8K RAM (EA SuperCart using BCART), if they don't have a GK (there was another mfg that produced a variation after MG quit production) or MAXIMEM, and another I don't recall the name of, as no DSR support is possible w/o a TI PEB attached.

1. Ben Yates warned me about this issue way back when he and Mark Wills were helping me develop TIB+. My big goal at that time was to use my SNUG TI-99/4P & the SNUG 16 bank HSGPL card to store TIB+ programs that would appear on the TI main selection menu using the GK MSAVE feature, as many TI modules would not work in the HSGPL banks beyond the first two. However Tony Knerr had developed a GRAM loader for the HSGPL card that would load those (all) TI modules into the first RAM bank (there are 2 RAM banks that simulate GRAM; they are not battery backed), and map it to the first GRAM bank location thus alleviating the problem. This, however, left me with all 16 actual HSGPL banks for non-troublesome modules or a ton of space to store my own MSAVEd Basic programs. Mind you TI BASIC is not my first choice for any programming effort. It's just the only choice for this project.

Ben informed me that there was one serious problem with MSAVEd Basic programs when they are run from GRAM locations; DATA statements don't work! Actually, I have found that they do work. The problem is that RESTORE line_number doesn't work, in fact it's so bad that if a RESTORE line-number is encountered before the first line with a READ the program is exited immediately. However, if a READ is before the first RESTORE line-number the operation will work fine, as long as subsequent READs are in order of the consecutive DATA statements, all will continue to go well, but anytime a RESTORE line-number is necessary, the wrong DATA will be processed, and you know what that means; kaboom!

My question regarding this problem; is there anyone out there willing to help me solve the problem? I do have several work a-rounds, but they take a lot more effort to implement, and I always prefer to FIX problems rather than do work a-rounds, if feasible.

At his point I received a text message, and had to take care of an important personal matter. Before I could resume this message I lost video, so forced to take care of this problem as this monitor is shared by my TI and TI support PC. I switched out the monitor to no avail. In order to bypass the 4 port switch, which is clipped to the bottom of the shelf that the TI & monitor reside, so above and behind the PS/2 keyboard, and it took me awhile to figure out if inserting the flat blade screwdriver should be above or below the clip mechanism. All the cables, 3 sets, at this time, + actual monitor, keyboard, mouse cables, kept me from moving it and turning it, so I could easily disconnect the monitor cable, and directly connect it to the TI, thus proving that it was a switch problem and not a monitor failure. Fortunately, after all this, I noticed that the 4 port switch has a reset button! Voila, all back to normal.

2. My current F18A TI console has been developing an audio problem that kept me fiddling with the TI 5 pin DIN connector to stop the irritating sounds that replaced "Beep" & "Honk". This reminded me that the F18A spare TI console was having sticking keys problem, so I decided to fix it first as I have lots of TI keyboards, purchased at Radio Shack for $3.95 each, years ago after TI stranded us. However, to my dismay, the keyboard is worse than that, as not only do 3 keys on the top row stick, the space bar is the only output. At least ways the "Beep" & "Honk" are nice and crisp. I changed the keyboard twice, no more sticky keys, but only the space bar works with all 3 keyboards! Now what? I have the TI console schematics, so I can see that the matrix for the space bar is INT 4 by 2Y0, but how can that be the only operational output? I don't think that even the Teensy USB keyboard adapter can fix this. Why doesn't it include a USB mouse? I'm hoping someone can give a clue as to how this simple matrix can fail in this manner. I see no evidence of damage to any of the RCR components. I'm hoping someone can point me in the right direction to solve this problem.

3. Whether or not, a solution to the MSAVE DATA problem is found & fixed, the real problem will be; how to do I save a basic program in VDP RAM to 40K of GRAM when I have to do it in 16K chunks? MSAVE saves multiple programs in 8K of GRAM just fine, and will do the same in 40K of GRAM. I can design the program, so that all DATA (in the event the DATA problem is fixed) is in a single program of 16K using line numbers in a range not used by any other program segment, likewise with GOSUB routines, leaving 8-16K for mainline code (depending on the size of the GOSUB segment). However, the question is; how to link the three separately saved programs, so that they function as a single coherent program?

That's it. I should mention that I live in the REAL windy city of Bullhead City, Arizona, and when the wind blows hard our ISP goes with it, and the wind blows frequently here, often very hard. I will always respond to messages, just not always timely. Email is best, as it gets in and out between gusts, but checking messages and replying on websites is another matter.

Anyway this is:

Bill R Sullivan (fdos) signing out.
br911sullivan@gmail.com or text me at:
928-201-2073

ThreeQuestions.txt

[Tursi]

I don't know if I can help right now with 1 and 3, but for the keyboards - if they are the (now infamous) Mitsumi keyboards with the plastic membrane contact sheet instead of individual mechanical keys, they are well known for faulting. A solution was found relatively recently, as well. If you carefully peel the contact sheet off then replace it, that will often get it working. (I've tried this myself, but careful, it's easy to tear). The problem seems to be that over the years the sheet sticks to the contacts, and shorts many of the keys out permanently, rendering them inoperative.

[RXB]

Well problem is you would need to use RXB to fix this problem.

 

But I that will not work if you have Assembly in it.

 

Does anyone have the source for the GK MSAVE so it can be repaired?

Edited March 29, 2017 by RXB

[FDOS]

Obviously, this GramKracker MSAVE issue is not a "HOT" topic. I would have thought with the Uber Cart and FinalGROM 99 about to come on the scene that this topic would be of some interest to current users of Uber Cart, and all those panting, but waiting impatiently for the arrival of FinalGROM 99.

 

In any case, my first TIB+ app of 13312 bytes has just hit the wall, even with CALL FILES(1). This means I will probably have to relegate all DATA to disk files any way.. Making the RESTORE [line-number] issue mute. I still need help with the other two issues.

 

Bill R Sullivan (fdos)

[FDOS]

Tursi, I have a few TI (made in Korea) keyboards, a few by Stackpole, and some with Mitsumi stickers, they are the easiest to install, as they have a longer cable. All 3 types don't work, except for the space bar. I've been thing that it may be the 9901, but I would have to pull it from another TI console to test that theory. Thanks for the response.

 

Bill R Sullivan (fdos)

[FDOS]

RXB, does RXB occupy any part of GRAMS 3-7 or RAM at >6000->7FFF? If so, I can't use it for this project. MSAVE6, in this case saves TI Basic programs in GRAMS 3-7, and BCART saves TI Basic programs of less than 8K in RAM at >6000->7FFF (both banks). I've not heard much about GK MSAVE except from Ben Yates, and he never said anything about source code that I recall. Thanks for the response.

 

Bill R Sullivan (fdos)

[RXB]

RXB, does RXB occupy any part of GRAMS 3-7 or RAM at >6000->7FFF? If so, I can't use it for this project. MSAVE6, in this case saves TI Basic programs in GRAMS 3-7, and BCART saves TI Basic programs of less than 8K in RAM at >6000->7FFF (both banks). I've not heard much about GK MSAVE except from Ben Yates, and he never said anything about source code that I recall. Thanks for the response.

 

Bill R Sullivan (fdos)

RXB uses 3-7 but 7 is for EA only. So you could still use RXB and use GRAM 7 for MSAVE6 to save in GRAM instead. If you do not need EA than this works fine for you.

[FDOS]

As previously stated, I use all of GRAMS 3-7 for TI Basic+ programs, including RAM at >6000->7FFF (both banks or 4 banks in some case) for BCART TI Basic+ programs, and all of the 32K for AL code that makes TI Basic TI Basic+ (TIB+). Obviously GRAM 7 is insufficient, as my original goal was to use all the GRAM in my 16 bank SNUG HSGPL card for TIB+ programs I write myself. I'm not especially fond of programming in TI Basic, even as enhanced as TIB+ is. I would rather program/code in Forth, but also not suitable for this project/goal.

 

Bill R Sullivan (fdos, Forth Developed Original Software)

[RXB]

I made a version of RXB that resides in page of GROM at >9802 and calls a bank in GROM at >9800 using the GPL command SWAP GROM.

 

Maybe this would work.

[FDOS]

RXB, right now I'm limited to my GramKracker, so no Review Library Module capability. Down the road, once I have my TI-99/4P operational again (lack of RGB monitor, a replacement RGB monitor for it and two Geneves is not on my priority list, yet), and no time table established for this purchase. I have set my priorities and I''m sticking with it. I replaced Windows 10 on my HP laptop with openSUSE, and I have a lot to learn, as many changes have occurred since I retired my Red Hat Linux server to the garage over 10 years ago. My only operational TI systems are; 2 x F18A consoles, along with 1 CF7A+, 1 NanoPEB V1 and 1 NanoPEB V2, with a bad serial port. I have no appropriate PIO cable for the CF7A+, so no communications. Only the V1 is fully functional, as the spare F18A TI Console has a keyboard issue, but I do have another nice TI Console that I was doing a TMS 9928 conversion until the monitor issue popped up. However, a third F18A is on my priority list, so whatever comes first will be the solution to that dilemma. Soon I hope. I have to get back to a very important project, and that is a permanent installation of the solution to my Internet problem.

 

Bill R Sullivan (fdos)

[RXB]

The GRAM module Switch using SWAP does not need Review Libary Module to work, it just switches to that GROM/GRAM bank address and executes.

 

The reason I mentioned this is built into the TI Console GROM 0 is a routine to Execute BASIC and as you said it is in another bank this would solve that problem.

 

The mod would sit in the unused section of TI Basic GROMs and could be accessed by DSR or CALL from TI Basic.

Edited March 31, 2017 by RXB

[FDOS]

Woa, If I have TIB+ in GRAMS 2 & 3, and MSAVEd TIB+ programs in GRAMS 3-7 of my 80K GK where will the second set of, say BOOT MENU in Grams 1 & 2, and RXB in GRAMS 3-7 actually be? As only GRAM 0 is still available (unless I choose to have an alternate TI OS with lower case characters and a screen saver). Meaning only 8K or 0K of the 80K GK memory is available. What am I missing?

 

FDOS

[RXB]

Woa, If I have TIB+ in GRAMS 2 & 3, and MSAVEd TIB+ programs in GRAMS 3-7 of my 80K GK where will the second set of, say BOOT MENU in Grams 1 & 2, and RXB in GRAMS 3-7 actually be? As only GRAM 0 is still available (unless I choose to have an alternate TI OS with lower case characters and a screen saver). Meaning only 8K or 0K of the 80K GK memory is available. What am I missing?

 

FDOS

The TI99/4A allows 16 pages of 40K GROM with the first bank at >9800, next at >9802, next at >9804 .... so on up to 16 banks.

Even the original PG or GK or GRAMULATOR had 2 pages of GROM i.e. >9800 & >9802 which is why it was called a 80K GK

Other devices even had as many as 16 banks of 40K GROM per page.

 

So....

GROM 0 Console

GROM 1 & 2 TI BASIC (This is where you can put in the call SWAP page routine to Execute a TI BASIC routine is only 60 bytes long and only 6K is used out of 8K.)

 

Page 1 GROM 3-7 (>9800) MSAVED TI BASIC programs

Page 2 GROM 3-7 (>9800) MSAVED TI BASIC programs

Page 3....up to 16th page of GROM 3-7

[FDOS]

I will put this very simply now, but I will go into greater detail when I have more time, if necessary. My 80K GramKracker has 8K at GRAM 0 (for modified or alternate TI OS, 8K at GRAM 1 and 8K at GRAM 2 for modified TI Basic or stored 16K AL program or packed small AL programs (Gram Packer, which can all load very fast from GRAM), and 8K at GRAMS 3-7 for MSAVEd Basic programs or stored AL programs packed or not. So GRAMS 0-2 is 3 x 8K = 24K, GRAMS 3-7 is 5 x 8K =40K, 2 RAM banks to support TI XB or other similar paged memory modules or Super Cart AL programs or in my case BCART saved Basic programs, so that is 2 x 8K of RAM for a total of 80K. I need another 80K to do what you advocate. I really wish my GK had it! I would certainly use it. Of course, that would be just two banks versus my SNUG 16 bank HSGPL card, which is the original target for my TIB+ effort.

 

FDOS

[RXB]

I am the GPL guy in the current TI world. RXB is written in GPL and I have GPL tutorials on AtariAge.

Yes I have owned and written GPL on the GRAMKRACKER, PGRAM and GRAMULATOR. RXB was originally written on these.

I know how they work and how they function. I am afraid you did not understand my point.

 

Now again let me explain that TI BASIC occupies GROM from >2000 to >37FF and >4000 to >57FF which means you have >3800 to >3FFF and >5800 to >5FFF EMPTY!

 

In case you did not know this I created Editor Assembler Assembly Support that fits into that space for others to not need a EA cart to access these.

So again my point was a SWAP GROM routine would Execute a TI BASIC from any page of your HSGPL card or GK as this was your original question without packing it.

 

I also wrote my own GPL package that would save TI Basic programs or XB programs to other pages of GRAM and run them, my PGRAM had 4.

 

 

[FDOS]

OK, I've given this a great deal of thought before writing this reply. I've always acknowledged your GPL expertise since you introduced RXB. I've never programmed anything in GPL, and probably never will. I never heard of this SWAP GROM routine, and I see no mention of it in the GK manual. I'm stuck with MSAVE saving TI Basic programs in GRAM 7, and MSAVE6 saving TI Basic programs in GRAMS 3 - 7. These programs are limited to 8K or less in GRAM 7, and theoretically 12K or 13K if CALL FILES(1) is used in GRAMS 3 - 7. In both cases, multiple TI Basic programs can be individually saved, up to the 8K GRAM limit or up to the 40K limit of GRAMS 3 - 7, all having their own set of line numbers, etc, and each with a name provided when MSAVEd that will appear on the main TI selection menu.

I see this process being more like "chaining programs" due to different line number tables and variables, etc. Selecting one TI Basic program from the TI Menu that runs to it's end, and then executes the SWAP GROM routine that starts at it's beginning. How do I specify the specific program in an MSAVE segment with multiple TI Basic programs?

I'm trying to understand how to implement this method of "chaining" programs. This was not what I had in mind, as I do intend to implement actual "chaining" of TI Basic programs in TIB+. I really want o creat a single TI Basic+ program of 40K. Or is there some other way of saving TI Basic programs in GRAM?

FDOS

[RXB]

SWAP GROM only is mentioned by Miller Graphics a couple of times and as far as i know I am the only one that ever wrote anything to make use of it.

I wrote a version of REA that had the Editor, GPL Assembler, and Assembler all in one package fitting into one 40K GROM 3-7 but of course no room for RXB.

My solution was normal RXB was in page >9800 and new REA in page >9802 and from RXB you could SWAP GROM to the other Cart or from REA back to RXB.

I do not know of anyone else that ever pulled this off.

 

 

As for what you are doing I did create something like it using RXB and my SWAP GROM routine using TI Basic unused GROM as a place to store the SWAP GROM.

As for other problems you have....

You need to set up GROM menus for each TI Basic program and then you can access them from TI Basic or a main menu like a Cart.

You need the modified TI ROM 0 like GK or GRAMULATOR uses or Classic99 uses to access other GROM pages and see them in menus.

 

These Video show what I did with SWAP GROM routines:

 

 

 

This was all for the project explained above. Anyway RXB in >9800 and REA with support Editor, Assembler and GPL Assembler all in >9802

[FDOS]

OK, I watched the first 2 videos, but GRAMreset3.avi is still trying to load as I write this. I also went back and reviewed the earlier videos, so I can use CSAVE to save TI Basic programs in GRAM as if they're a single GPL module, thus allowing me to split them up as separate disk files with contigious line numbers and appropriate module names, like; PROG, PROG1, PROG2, PROG3 then CSAVE to GRAMS 3 - 6, etc.? I used CSAVE when I was heavy into MDOS GPL mode early on, but not in decades now. If you agree, I won't even have to use the SWAP GROM routine until i have the SNUG 16 bank HSGPL operational.

 

FDOS