Subject: Editor Assembler bug found and squashed

From: fdos <[email-masked]>
Date: Wed, 09 Nov 2011 11:35:55 -0700

CAUTION: Another Bill Sullivan rant begins here.

As many of you may recall back in April a concentrated effort was 
launched to determine why TI BASIC programs running in module space (G7 
by use of the GK MSAVE utility) could not successfully make EA CALLs in 
GROM 3.

On April 23, 2011 Tursi (Mike Brent) delivered to me a patched EA module 
that totally fixed this problem.  Later on, in early May, he also 
performed the same fix on Rich Gilbertson's TI BASIC with full EA 
subprogram support.  A few days later he also provided me with a fully 
patched Winfried Winkler 80 column EA module that had many additional 
subprogram CALLs for TI BASIC programs running in gram 7.  All of this 
made me extremely happy, so I went back to MMLS development for TurboForth.

And then in October I received an eviction notice to vacate the premises 
by 1-2-2012 as the house I'm renting was foreclosed and sold.  So far 
I've not managed to get any extension since the inspection which will be 
two weeks ago this Thursday, and I've left voice messages, but no 
return. Therefore I decided to document the process for loading and 
testing the EA and TI BASIC fixes done by Tursi, so once I get moved I 
wouldn't have to rely on my old gray matter to continue this project.

I still have the problem with my 80K Gram Kracker slipping in to error 
mode after days or sometimes just hours of operation in the case of TI 
BASIC mods in GRAMS 1 & 2, but no problems with the mods to the EA 
module in GRAM 3 after days and a week of operation.  This made me 
decide to move the operation and testing to an HSGPL system and verify 
the same or better results.

After some struggles with an 80 column GROM0 issue in my 40 column four 
bank HSGPL TI-99/4A system, simply because my SNUGTI-99/4P system is 
being packed up for the coming move, I was finally able to convert all 
the necessary files from GK format to HSGPL format in the normal way. 
As all, AFAIK, HSGPL cards have, in addition to the GROM/ROM pages, two 
GRAM/RAM pages ideally suited for doing modifications and testing, I 
loaded my converted TI BASIC and EA along with appropriate MSAVE/MSAVE6 
files into these two pages for testing in the same manner as I tested 
the RPK files in MESS and the GK files in my Ti NanoPEB with 80 GK 
system.  Total success after days of continuous running and periodic 
testing.

Now it was time to load these files into GROM/ROM pages, but to my 
complete surprise I kept getting "ERROR writing EEPROM" on every 
attempt.  Thinking back to when might have been the last time that I 
loaded any nodules in either HSGPL card, 1999 came to mind and that was 
the 16 bank card.  In any case, I happen to have a complete spare set of 
chips for a four bank HSGPL card due to the fact that my original HSGPL 
card was a four bank unit that was upgraded by Tony Knerr to 16 banks 
way back when.

Believe it or not, considering what was left stored in the garage and 
the up coming move confusion, I found them.  I replaced both U1 & U4 
although I believe all my write attempts were to U4.  Now I could load 
the selected files to the bank desired and not get the write error.

I thought I could save TI BASIC programs into the MSAVE/MSAVE6 GROM page 
by just using CALL GWRON before CALL MSAVE, and after the return to TI 
BASIC, CALL GWROFF, but for some unknown reason this did not work--no 
TIB+ selection on the TI main menu.  This meant that I would have to 
MSAVE the TI BASIC programs in the GRAM/RAM pages, save to disk, then 
load these files into the desired GROM/ROM page.  This upset me a 
little, but not nearly as much as that the resultant programs would not 
run successfully when selected from the Ti main menu.  Why?  I didn't 
know why immediately.

This is the process that works in my 80K GK.  CALL MSAVE displays a 
screen with three choices.  Usually, I use the first one which is "Add a 
program", and then I'm prompted to set the R/W switch on the GK to Bank 
1, after this I'm prompted for a program name that will be placed on the 
TI main menu.  I always restore the R/W switch to the normal position 
before typing BYE.  Now I will find my TI BASIC program on the main menu 
for selection, and it works as it should, including EA CALLS.

I recall back in the beginning of trying to use CALL MSAVE for loading 
my most often used EA opt5 programs, and it worked as long as the 
programs were located on an HRD and I could use an HRD CALL, but these 
one line TI BASIC programs were slow starting, so I did the same thing 
with Gram Packer and it's CALL function for the HRD CALLS as it's EA 
opt5 loaders don't work for some of my EA5 program choices.

Why doesn't this process work as well on the HSGPL as it does with the 
GK device?  What are the differences that should be considered?  The GK 
only has GRAM & RAM while the HSGPL has GROM & ROM in addition to the 
GRAM & RAM.  The GRAM/RAM scenario does work.  Only the GROM/ROM process 
fails even if I use files made from the GRAM/RAM process, so we can 
discount the CALL GWRON as a likely problem (ha!).  What other 
difference could matter in this case?  Perhaps the multi-page capability 
of the HSGPL is a problem for the GK MSAVE/MSAVE6 utilities?  They were 
designed for a single GRAM/RAM page operation.  We know there are some 
modules (even TI produced) that don't work well when they are loaded in 
HSGPL GROM/ROM pages other than the one at G>9800.

With this idea in mind I proceeded to loading the modified TI BASIC and 
MSAVE6 file in GROM/ROM page 0 where I quickly learned that I was still 
unable to MSAVE my TI BASIC+ loader program in GRAM 3 using GWRON before 
MSAVE and GWROFF after MSAVE.  Still not willing to give up I loaded the 
MSAVE6 with TIB+ already MSAVED.  This Works!

I'm disappointed that the GWRON - MSAVE - GWROFF procedure doesn't work, 
and that I will have to use a more complex process, but if a method of 
modifying MSAVE/MSAVE6 to be GROM/ROM page neutral it will still be 
viable for my project.  Even if a neutral MSAVE/MSAVE6 is not doable it 
should still be possible to modify both to be specific to a GROM/ROM 
page of choice.  I'm not sure about how to find out what makes 
MSAVE/MASVE6 GROM/ROM page 0 (G>9800) specific, so I'm hoping someone in 
the community can point me in the right direction.

As always any assistance in this matter will be greatly appreciated.

Bill S

On 4/23/2011 3:35 PM, Tursi wrote:
> Finished.
>
> The net result is that it was a bug in Editor/Assembler caused by slightly
> inconsistent behaviour between VDP and GROM execution in the interpreter.
> For details, read on! Follows is my log as I worked, so expect it to read
> somewhat oddly. It's a mental log of discoveries, rather than a write-up. :)
> It does cover the patches needed.
>
> For CALL INIT, the subprogram search executes normally, and in fact it finds
> CALL INIT. So the INCORRECT STATEMENT is not caused by a search failure!
>
> It jumps into the E/A cartridge "CALL INIT" function correctly. In fact, the
> error is actually coming from the Editor/Assembler cartridge itself.
>
> When the subprograms exit, they call this block of code (from Thierry's
> disassembly):
>
> G6DED XML>1B                     next token
>        CZ    @>8342
>        BR    G@G6EF3                 incorrect statement
>        CALL  G@>0012                 00 ret to basic
>
> All XML>1B does is read the next byte from the program, and store it at
>   >8342. Editor/Assembler is making sure that it is a>00 byte before it
> returns.
>
> With VDP, this is a>00 byte, and all is well.
>
> With GROM, this is a>43 byte, which causes the error.
>
> As for why... the packed GROM code looks correct enough. INIT is terminated
> with a>00 byte. The>43 is actually the first letter of CLEAR in the /next/
> line. This is the GROM version:
>
> E678: 04 49 4E 49 54 00 09 9D .INIT...
> E680: C8 05 43 4C 45 41 52 00 ..CLEAR.
>
> and this is the VDP version (I realize neither is the complete program, it's
> just the area between INIT and CLEAR I want to focus on):
>
> 37C8: 04 49 4E 49 54 00 09 9D .INIT...
> 37D0: C8 05 43 4C 45 41 52 00 ..CLEAR.
>
> So that's identical, but somehow the GROM pointer is getting advanced too
> far. (Note that CLEAR is the first line in the program, so this isn't a
> problem for finding the next line.)
>
> The GROM pointer is at>832C (which is the same address used for finding the
> token in a VDP-based CALL). On entry to CALL INIT, it is pointing at the>00
> byte after INIT. However, the first thing that E/A does is skip over by the
> token length:
>
> *                                   init
> G6B82 OR>08,@>8348              ====
>        DADD>0005,@>832C            token pointer
>
> It appears to assume that on entry, it is pointing at the length byte, and
> skips it all. In truth, for VDP, this assumption would be correct. This
> appears to be a difference between VDP and GROM execution.
>
> It looks like only INIT does this explicitly. Other functions call a little
> subroutine at>6BBE to do the skip:
>
> *                                   skip sub name
> G6BBE CLR   @>834A                  -------------
>        ST    V*>832C,@>834B             size
>        DADD  @>834A,@>832C
>        DINC  @>832C                  e o name
>        XML>1B                     next token
>        CEQ>B7,@>8342
>        BR    G@G6EF3                 not ( incor statement
>        XML>1B                     next token
>        RTN
>
> Obviously this function assumes that everything is in VDP. It also assumes
> there will be an open parenthesis, which is probably why INIT doesn't use
> it.
>
> I think we can patch these functions to work with both VDP and GROM. There's
> some free space at>6FEA, so:
>
> * INIT patch
> 6FEA:    B6 48 08    OR>08,@>8348    still need to do this!
>          8E 80 89    CZ @>8389        check GROM flag
>          6B 85        BS G@>6B85        VDP, go back to the add
>          4B 89        BR G@>6B89        skip the add
>
> * skip patch
> 6FF4:    86 4A        CLR @>834A        still need to do this!
>          8E 80 89    CZ @>8389        check GROM flag
>          6B C0        BS G@>6BC0        VDP, go back to the add
>          4B C9        BR G@>6BC9        jump down to the XML token parse
>
> then, of course, we patch the functions with branches:
> 6B82:    4F EA        BR G@>6FEA
>          00                            padding, we replaced 3 bytes
>
> 6BBE:    4F F4        BR G@>6FF4        no padding needed on this one
>
>
> With these patches, both my test and Jeff's test appear to work, as well,
> the functions still work from regular TI BASIC, so the E/A cart is
> compatible with both.
>
>

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: fdos <[email-masked]>
Date: Fri, 11 Nov 2011 12:32:49 -0700

I'm still hoping for serious assistance in what might make the 
MSAVE/MSAVE6 programs page/bank 0 specific.  I have searched these HSGPL 
files for the page/bank 0 specific addresses: >9800, >9802, >9C00 & 
 >9C02 without success, but I do see that the MSAVE6 does begin with 
 >6000, >0000, >AA56 and MSAVE begins with >E000, >0000, >AA56.  Which 
is probably the HSGPL format headers.  Nothing that would make them 
page/bank 0 specific.

Bill S

On 11/9/2011 11:35 AM, fdos wrote:
> BASIC mods in GRAMS 1&  2, but no problems with the mods to the EA
> the up coming move confusion, I found them.  I replaced both U1&  U4
> only has GRAM&  RAM while the HSGPL has GROM&  ROM in addition to the
> GRAM&  RAM.  The GRAM/RAM scenario does work.  Only the GROM/ROM process

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: [email-masked]
Date: Sat, 12 Nov 2011 00:54:03 +0000 (UTC)

Bill S 

In REA (Rich Editor Assembler 2012) from a Catalog you can go to RXB that is loaded at the second bank >9804 

So this means the REA can be loaded into any GRAM bank >9800 to >9832 except >9804 which expects RXB to be in that bank. 
This routine is the one that goes from >98xx to >9804 and executes GRAM address >6372 that is the start address of XB or RXB. 

You could put XB instead of RXB at GRAM bank >9804 (Bank 2) and it would still work. 

RTRXB   DST   >9804,@ARG         * FIRST PAGE 
GORXB  DSWGR RXB,@ARG       * GO TO RXB 
******************************************** 

So if you change the above and put it into MSAVE this would fix the problem of changing GRAM bank from another GRAM bank. 

LABEL DST           >98xx,@SCRATCHPAD 
              DSWGR   address,@SCRACTHPAD 

SCRATCHPAD is address >8300 to >836D as above this are hard coded. 

address is the GROM/GRAM address you want to go to in the other GROM/GRAM bank. 

>98xx is the GROM/GRAM bank address to go to. 

The opcodes bytes would be: 

>BF,>xx,>98,>xx 

>FB,>xx,>xx,>xx 

If you have the GPL source I could fine the place it switches and add the GROM/GRAM bank switch code. 

Rich 

----- Original Message -----

From: "fdos" <[email-masked]> 
To: [email-masked] 
Cc: [email-masked], [email-masked] 
Sent: Friday, November 11, 2011 11:32:49 AM 
Subject: [TI994A] Re: [TI-99/4A] Editor Assembler bug found and squashed 

Bill S 

-- 
Bill R Sullivan (FDOS) 
Go Forth+ or X4th99

---

From: fdos <[email-masked]>
Date: Sat, 12 Nov 2011 10:33:04 -0700

Rich,

I can't do this as there are no GRAM page (0 ~ 15) addresses contained 
in MSAVE/MSAVE6, so I'm not able to make this change, as doing so was 
exactly what I was looking to do to make an MSAVE or MSAVE6 specific to 
each GRAM page 1 ~ 15 leaving the originals set to page 0.  As I said 
earlier, I don't know what makes MSAVE/MSAVE6 page 0 dependent.  I just 
know that it is.

Bill S

On 11/11/2011 5:54 PM, [email-masked] wrote:
>
>
> Bill S
>
>
>
> In REA (Rich Editor Assembler 2012) from a Catalog you can go to RXB that is loaded at the second bank>9804
>
> So this means the REA can be loaded into any GRAM bank>9800 to>9832 except>9804 which expects RXB to be in that bank.
> This routine is the one that goes from>98xx to>9804 and executes GRAM address>6372 that is the start address of XB or RXB.
>
> You could put XB instead of RXB at GRAM bank>9804 (Bank 2) and it would still work.
>
> RTRXBÂ  Â DSTÂ Â>9804,@ARGÂ Â Â Â Â Â  Â  * FIRST PAGE
> GORXBÂ  DSWGR RXB,@ARGÂ Â Â Â Â Â  * GO TO RXB
> LABEL DSTÂ Â Â Â Â Â Â Â Â Â>98xx,@SCRATCHPAD
> Â Â Â Â Â Â Â Â Â Â Â Â Â  DSWGRÂ  Â address,@SCRACTHPAD
>
>
>
> SCRATCHPAD is address>8300 to>836D as above this are hard coded.
>
> From: "fdos"<[email-masked]>
> Â
> files for the page/bank 0 specific addresses:>9800,>9802,>9C00&
>> 6000,>0000,>AA56 and MSAVE begins with>E000,>0000,>AA56. Which

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99