Extended Basic II Issues
Disambiguation: This page does not refer to Myarc Extended BASIC II
It may well be that the TI-99/8 prototypes have different releases of their system ROM, so probably some systems could work, others won't. I am now referring to the operating system release as represented by the source code on WHTech.
Crash on startup
When entering Extended Basic II, the computer clears the screen and locks up. This only happens when a floppy controller card is available.
The following lines will show that the TI-99/8 very likely does not work with any peripheral card of the TI-99/4A which uses DSRs. Probably only hexbus devices are supported with the existing prototype consoles.
Why is that? Please have a look at 998SourceDisk6.dsk, file "FMEX".
FMEX is the executor part of Extended Basic II. It is located at G>4000. Line 36 contains the entry point of the "RUN" command. On entry, Extended Basic II autoexecutes the command RUN "DSK1.LOAD".
RUN DATA XML3,CHKEND ONLY RUN ENTERED ???? BS RUN2 YES $IF @CHAT .NE. LN$ THEN must be string to load file PARSE TREM$ Parse the string to EOS CALL CLSALL *--------------------------------------------------------- * NOW BUILD A PAB IN SCRATCH PAD * CLR @SLPAB MOVE 100 FROM @SLPAB TO @SLPAB+1 Clear out PAB DATA XML3,MAPSTR Map the string into STRWN2 ST @FAC+1,@SLPAB+NLEN MOVE @FAC FROM @STRWN2 TO @SLPAB+NAM DATA XML2,KILSYM SB @GONOGO,1 Come back to start running the program B OLD$0 Load in the program $END IF
After the CLSALL subroutine you find the comment "NOW BUILD A PAB IN SCRATCH PAD". According to my dump from the emulation, this is exactly what happens. Note that the scratch pad of the TI-99/8 is bigger, reaching from 8000 to 87ff (excluding the mapper and sound).
The file name is first written from GROM to address >E000 (physical: >00000906), before these lines are reached, then copied from there to >8712 by the MOVE command.
Later, there is also the code of the OLD command (line 2146). It starts with CALL GPNAME. GPNAME is in the section "utility routines" of the same file. Again, if you look at that it seems obvious that the code builds a PAB in the CPU address space.
The problem now is that all DSRs from our known peripheral cards assume that the PAB is in VDP memory. Remember that >8356 points to a location in VDP RAM, as described in the E/A manual (section 16.2.4).
If you check the source code of the TI disk controller (for instance, on Thierry Nouspikel's website) you will find lots of locations in the code that require that the PAB is in VDP (using lines like MOVB @>FBFE(15),2).
While DSRLNK may cope with a PAB in CPU memory (it does, actually, while it checks for the device name), the DSRs in the cards surely do not. MDOS allows for CPU address space PABs, but it also replaces the DSRs. Of course, all of the above is true for the RS232/PIO card.