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, file http://nouspikel.group.shef.ac.uk/ti99/dc2.txt) 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.