Extended Basic II Issues - Revision history

Stephen Shaw: /* Crash on startup */ remove dead external link and replace with internal link

2014-12-24T19:17:57Z

Crash on startup: remove dead external link and replace with internal link

← Older revision		Revision as of 19:17, 24 December 2014
Line 52:		Line 52:
	described in the E/A manual (section 16.2.4).		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		If you check the source code of the TI disk controller (for instance, on [[Thierry\|Thierry
	Nouspikel's website~~, file http://nouspikel.group.shef.ac.uk/ti99/dc2.txt~~) you		Nouspikel's website) ]] you
	will find lots of locations in the code that require that the PAB is in VDP		will find lots of locations in the code that require that the PAB is in VDP
	(using lines like MOVB @>FBFE(15),2).		(using lines like MOVB @>FBFE(15),2).

Stephen Shaw: Clarify this article does not refer to Myarc XB II

2014-09-16T19:52:33Z

Clarify this article does not refer to Myarc XB II

← Older revision		Revision as of 19:52, 16 September 2014
Line 1:		Line 1:
			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		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		their system ROM, so probably some systems could work, others won't. I am now

Mizapf: Protected "Extended Basic II Issues" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

2010-12-29T18:31:12Z

Protected "Extended Basic II Issues" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

← Older revision	Revision as of 18:31, 29 December 2010
(No difference)

Mizapf: Created page with "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 sys..."

2010-12-29T18:30:43Z

Created page with "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 sys..."

New page

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.