Subject: MESS: TI-99/8 problems with Exbasic II and floppy support

From: "Michael Zapf" <[email-masked]>
Date: Tue, 02 Nov 2010 09:56:45 -0000

Hi all,

I have been rewriting lots of code of the TI emulations, also including the TI-99/8. One hope was that this could eliminate some known and also unknown issues.

Unfortunately, one problem persisted with the TI-99/8. When I start up Extended Basic II with a plugged-in disk controller card in the P-Box, I get a lockup. It does not happen when there is no disk controller. It happens for the classic TI FDC as well as for the HFDC.

As I rewrote the mapper from scratch, and it yields the exact same problem as the previous implementation (which came from Raphael Nabet and which I did not reuse, even for small parts), I suspect that the problem is somewhere else. It could be that either there is a bug in Extended Basic II, or there is a documentation error, or some unmentioned feature. 

One thing that was quite surprising for me was that the debug build of MESS did not show the lockup, but the normal build did. (The debug build has debugging code in it like logging commands and should certainly *not* change the behavior of the system except to make it slightly slower). 

What I found out was that the debug build showed some differences during runtime while accessing RAM memory locations. I noticed that I forgot to memset the RAM to 0 on initialization (clear the newly allocated memory). One I added the memset, the debug build behaved equally to the normal build. That is, the emulation seems to depend on random values in RAM cells. 

What I noticed in my printf outputs of the memory accesses was that some (GPL) XML >B0 happened after the disk access before the system goes astray. At A000 there is no data at that time, so the GPL interpreter gets a 0 and BLs there. After some more lines, it repeatedly BLs at an address that has just a RT, staying in this look infinitely. (With the debug build there seemed to be different data at A000 which may have caused some minor fault that did not result in a crash, and Extended Basic II showed up.)

Well, and there's the question now whether it makes sense to further investigate. Can anyone of the TI-99/8 owners state without doubts, according to tests, that Extended Basic II starts up when a TI floppy controller or a HFDC is plugged into the P-Box which is connected to the TI-99/8? To have similar test situations, no other device should be connected (like Hexbus) and no cartridge shall be plugged in. And if it boots, whether it is possible to load a program from the disk or to do a CALL DIR with the HFDC.

Michael

---

From: "Ksarul" <[email-masked]>
Date: Tue, 02 Nov 2010 06:52:58 -0400

Michael, this behavior is definitely different than it is with my 99/8, but
that is not a guarantee that mine is different.  I had to design an adapter
to connect a round-cable Armadillo Interface to my Flat-Cable 99/8, using a
pin out I received from Steve Eggers a few years ago.  It might effectively
replicate your debugger random memory contents at >A000-or it might not.  In
any case, I have used TI DSSD controllers, TI DSDD controllers, and MYARC
FDC (but not the HFDC) controllers with it.  All boot to XB II.  If I have a
128K or 512K card in the box (I have both), it also recognizes the
additional memory in XB II.  I have done tests with and without a memory
card in the PEB.  The chip you want to take a close look at is the AMIGO-it
is the one that handles the interface to the PEB and the addressing for the
majority of the system memory.  POLLO (the Memory Mapper in the 99/8
diagrams) handles a somewhat different set of memory problems.  I had a
number of conversations with the designer of these a while back (Mike
Bunyard).  The documentation on WHT is just about everything that survives
on the 99/8-and the Mapper and You document actually refers to functions of
the AMIGO chip, not to POLLO.  

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Zapf
Sent: Tuesday, November 02, 2010 5:57 AM
To: [email-masked]
Subject: [TI994A] MESS: TI-99/8 problems with Exbasic II and floppy support

Hi all,

I have been rewriting lots of code of the TI emulations, also including the
TI-99/8. One hope was that this could eliminate some known and also unknown
issues.

Unfortunately, one problem persisted with the TI-99/8. When I start up
Extended Basic II with a plugged-in disk controller card in the P-Box, I get
a lockup. It does not happen when there is no disk controller. It happens
for the classic TI FDC as well as for the HFDC.

As I rewrote the mapper from scratch, and it yields the exact same problem
as the previous implementation (which came from Raphael Nabet and which I
did not reuse, even for small parts), I suspect that the problem is
somewhere else. It could be that either there is a bug in Extended Basic II,
or there is a documentation error, or some unmentioned feature. 

One thing that was quite surprising for me was that the debug build of MESS
did not show the lockup, but the normal build did. (The debug build has
debugging code in it like logging commands and should certainly *not* change
the behavior of the system except to make it slightly slower). 

What I found out was that the debug build showed some differences during
runtime while accessing RAM memory locations. I noticed that I forgot to
memset the RAM to 0 on initialization (clear the newly allocated memory).
One I added the memset, the debug build behaved equally to the normal build.
That is, the emulation seems to depend on random values in RAM cells. 

What I noticed in my printf outputs of the memory accesses was that some
(GPL) XML >B0 happened after the disk access before the system goes astray.
At A000 there is no data at that time, so the GPL interpreter gets a 0 and
BLs there. After some more lines, it repeatedly BLs at an address that has
just a RT, staying in this look infinitely. (With the debug build there
seemed to be different data at A000 which may have caused some minor fault
that did not result in a crash, and Extended Basic II showed up.)

Well, and there's the question now whether it makes sense to further
investigate. Can anyone of the TI-99/8 owners state without doubts,
according to tests, that Extended Basic II starts up when a TI floppy
controller or a HFDC is plugged into the P-Box which is connected to the
TI-99/8? To have similar test situations, no other device should be
connected (like Hexbus) and no cartridge shall be plugged in. And if it
boots, whether it is possible to load a program from the disk or to do a
CALL DIR with the HFDC.

Michael

---

From: "fredkaal" <[email-masked]>
Date: Tue, 02 Nov 2010 15:50:11 -0000

Hi Michael,

Stupid question: But is there a program file called LOAD in DSK1.?
If so what happens if you remove/rename that file?

Fred ;-)

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 03 Nov 2010 10:57:43 -0000

Hi Fred,

> But is there a program file called LOAD in DSK1.?

good idea - I tried all options, but it seems to have no effect. Actually, I tested first without a disk in the (emulated) drive, so LOAD could not be found.

The "good" thing is that although the performance gets down to a crawl with the printf lines, the effect persists (would be really evil otherwise, with greetings from Heisenberg). The bad thing is that I need to record every single memory access, and this delivers about 3 million lines before the problem occurs, including GROM access. And also a problem is that I cannot compare to a working emulation (it never worked), and I cannot compare to the output without the disk controller, since there are two key presses (master title screen, then select "a") with a waiting loop which deliver a different output for every single run, depending how quick I press the key (in milliseconds). 

But there are some more and earlier issues, as I saw, which seem to have no visible effect at least, like read accesses to >9400 (which is wrong, since this is SPCHWT, not SPCHRD) that come from R1 having the value >1100, with PAD (>8300) being added, and so on. So there are some issues long before.

If I don't succeed I'll probably offer this dump (zipped) for the private investigators among you.

Michael

---

From: Jeffrey White <[email-masked]>
Date: Wed, 3 Nov 2010 23:28:02 -0700 (PDT)

It has been postulated that Myarc Extended BASIC II Level 4 v2.11 was based on 
Extended BASIC II of the 99/8.  Have you reviewed the Myarc source code?

If you let the cat out of the box, it does not die....until it tries to cross 
the street.  Even that is not certain.

Dirigibles are over my head.

I did find this edumakationable:

http://uncyclopedia.wikia.com/wiki/Uncertainty_Principle

Jeff

________________________________
From: Michael Zapf [email-masked]
To: [email-masked]
Sent: Wed, November 3, 2010 6:57:43 AM
Subject: [TI994A] Re: MESS: TI-99/8 problems with Exbasic II and floppy support

Hi Fred,

> If so what happens if you remove/rename that file?

good idea - I tried all options, but it seems to have no effect. Actually, I 
tested first without a disk in the (emulated) drive, so LOAD could not be found.

The "good" thing is that although the performance gets down to a crawl with the 
printf lines, the effect persists (would be really evil otherwise, with 
greetings from Heisenberg). The bad thing is that I need to record every single 
memory access, and this delivers about 3 million lines before the problem 
occurs, including GROM access. And also a problem is that I cannot compare to a 
working emulation (it never worked), and I cannot compare to the output without 
the disk controller, since there are two key presses (master title screen, then 
select "a") with a waiting loop which deliver a different output for every 
single run, depending how quick I press the key (in milliseconds). 

But there are some more and earlier issues, as I saw, which seem to have no 
visible effect at least, like read accesses to >9400 (which is wrong, since this 
is SPCHWT, not SPCHRD) that come from R1 having the value >1100, with PAD 
(>8300) being added, and so on. So there are some issues long before.

If I don't succeed I'll probably offer this dump (zipped) for the private 
investigators among you.

Michael

---

From: "Stuart" <[email-masked]>
Date: Thu, 04 Nov 2010 18:46:25 -0000

Excuse my ignorance but - if the Myarc Extended BASIC II Level 4 v2.11 for the 4A or the Geneve? Does it use any GPL? And is the source code available (on WHTech)?

Thanks,

Stuart.

--- In [email-masked], Jeffrey White <ti994a@...> wrote:
> From: Michael Zapf newsmail09@...

---

From: Jeffrey White <[email-masked]>
Date: Thu, 4 Nov 2010 16:34:57 -0700 (PDT)

Originally for the 99/4A with the Myarc 512K and 128K OS.  Refitted for the 
Geneve before Advanced BASIC for MDOS became available.  It is all assembly.

The ABASIC for MDOS source code is available at the WHT ftp site 
(ftp.whtech.com), but I could not locate the XBII Level 4 source code there.  

There is 99/8 source code on the ftp site, but I am not sure it is complete.

Jeff

________________________________
From: Stuart <[email-masked]>
To: [email-masked]
Sent: Thu, November 4, 2010 2:46:25 PM
Subject: [TI994A] Myarc Extended BASIC II Level 4 v2.11

Excuse my ignorance but - if the Myarc Extended BASIC II Level 4 v2.11 for the 
4A or the Geneve? Does it use any GPL? And is the source code available (on 
WHTech)?

Thanks,

Stuart.

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 05 Nov 2010 00:26:00 -0000

Hi all,

I got a bit closer to the problem: When Exbas II is entered, the system tries to load DSK1.LOAD. However, I noticed that only SBO 0 and SBZ 0 are sent to the floppy controller, not even a start of the motor, or any access to >5ffx. After digging through the dump I found that the controller DSR is indeed accessed, and the DSK1 entry was found, but shortly after starting, it exits with a "file error", raised within the file name check/copy. It fails because it reads a 00 from VDP where the PAB is supposed to be. I searched through the dump for accesses to 8c00 and could not find any lines which state that the byte sequence "DSK1.LOAD" was ever written to VDP! This filename error as return seems to cause trouble in Exbas II.

I will check that during the weekend, but I now know better where to look at. Without the PAB in VDP RAM, disk loading cannot work, since the DSR is not replaced as within MDOS. But some of you said they were successful with loading from disk, at least Exbas II does not crash, so there must be a way. 

Michael

---

From: mark wills <[email-masked]>
Date: Fri, 5 Nov 2010 10:42:03 +0000 (GMT)

Are you able to press a key to defeat the auto loading? I seem to remember to 
you could do that on the 4a in XB, or am I inventing memories?

A workaround may be to patch the system to simply prevent it from attempting to 
auto-load...?

Mark

----- Original Message ----
> From: Michael Zapf <[email-masked]>
> Sent: Fri, 5 November, 2010 0:26:00
> I got a bit closer to the problem: When Exbas II is entered, the  system tries 
>to load DSK1.LOAD. However, I noticed that only SBO 0 and SBZ 0 are  sent to the 
>floppy controller, not even a start of the motor, or any access to  >5ffx. After 
>digging through the dump I found that the controller DSR is  indeed accessed, 
>and the DSK1 entry was found, but shortly after starting, it  exits with a "file 
>error", raised within the file name check/copy. It fails  because it reads a 00 
>from VDP where the PAB is supposed to be. I searched  through the dump for 
>accesses to 8c00 and could not find any lines which state  that the byte 
>sequence "DSK1.LOAD" was ever written to VDP! This filename error  as return 
>seems to cause trouble in Exbas II.
> 
> I will check that during  the weekend, but I now know better where to look at. 
>Without the PAB in VDP RAM,  disk loading cannot work, since the DSR is not 
>replaced as within MDOS. But some  of you said they were successful with loading 
>from disk, at least Exbas II does  not crash, so there must be a way. 
>
> 
> Michael
> 
> 
> 
> ------------------------------------
> 
> Yahoo!  Groups Links
> 
> 
> 
>

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 05 Nov 2010 13:27:51 -0000

Does anyone know a file-file GPL disassembler (i.e. disassemble the contents of a given file and store it in another, like Diskassembler)?

It would make bugtracking much easier if the GROM contents of the 99/8 were disassembled. I know that there are sources, but they are only useful in a limited way: The source code does not contain absolute addresses, so it is quite tedious to compare the memory accesses in a dump with the source code. I did it for a small part - you basically have to assemble the lines in mind to find out the opcode and how many bytes they use so that you can countercheck with the dump. Disassembled code is much more useful in that respect.

I found two GPL disassemblers, but they seem to read from GROMs only, not from a dump file. 

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 05 Nov 2010 13:34:53 -0000

Hello Mark,

> A workaround may be to patch the system to simply prevent it from attempting to 

you mean pressing Shift to avoid autoexec.bat and config.sys to be loaded? Wrong film, sorry. :-) 

There is indeed a flag byte which can be set to avoid loading, but I do not know how to set it or which component sets it - before XB II starts up.

Anyway, the problem would still be there. I would expect that in this case, no OLD or RUN would work. Because the autoload, as it turned out, is nothing else but a pre-scanned RUN "DSK1.LOAD" which is executed before the prompt is displayed.

Michael

Michael

---

From: Gregory McGill <[email-masked]>
Date: Fri, 5 Nov 2010 11:06:44 -0700

not stock 99/4a XB..  not sure about xbII   my GK XB and newer vers you hold
space and it doesn't auto-load.

Greg

---

From: "morpheusinindy" <[email-masked]>
Date: Sat, 06 Nov 2010 09:30:09 -0000

FWIW - The only peripherals I have ever seen for the 99/8, where all HEXBUS. Maybe the ROM's we have only know how to talk HEXBUS, or within MESS the support structure for HEXBUS is not there, or the HEXBUS DSR's are not binaryly correct?

Dan

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 06 Nov 2010 12:23:45 -0000

Hi Dan,

> FWIW - The only peripherals I have ever seen for the 99/8, where all 
> HEXBUS. Maybe the ROM's we have only know how to talk HEXBUS, or 
> within MESS the support structure for HEXBUS is not there, or the 
> HEXBUS DSR's are not binaryly correct?

IIRC the Hexbus DSRs are not part of the dump. The actual question is how far the TI-99/8 is compatible to the peripheral system of the TI-99/4A. For instance, can the disk controller cards still be used or not?

I just did one more test, outputting VDP access for the TI-99/4A + Extended Basic on startup, and comparing to the output of the TI-99/8. Indeed, Extended Basic (1) does write a PAB into VDP RAM containing the string "DSK1.LOAD", while Extended Basic II does not. Or the writes were lost at some point, due to a mapping error. 

Two cases: (1) Something caused the GPL code in Extended Basic II to be skipped when the PAB should be copied to VDP RAM. I'll check this today. (2) The DSRLNK in the TI-99/8 would rely on PABs in CPU RAM. Option (2) would clearly add yet another score to the list of BAD ideas for the 99/8, essentially breaking all DSRs of classic disk controller cards.

Michael

---

From: "James W." <[email-masked]>
Date: Sat, 06 Nov 2010 13:46:10 -0000

Two points:

1.) Has anyone looked at the PEB interface schematics between the 99/8 and the PEB? 

2.) The 9995 used in the 99/8 is modified-no internal CPU ram. (As per Mike Bunyard)

James

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 06 Nov 2010 21:31:24 -0000

Hello James,

> 1.) Has anyone looked at the PEB interface schematics between the 99/8 and the PEB? 

This is not important for the emulation, since we assume that all necessary wires are connected to the box in the proper order (e.g. the databus lines D0-D7 match those from the processor (behind the mapper) and the callback lines like READY or INTA are also correctly connected). 
 
> 2.) The 9995 used in the 99/8 is modified-no internal CPU ram. (As per Mike Bunyard)

Right, this is considered in the emulation.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 06 Nov 2010 22:30:07 -0000

So, by now I have come to some more conclusions. And actually, I hope that I am wrong. 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. 

** My conclusion is that the TI-99/8 does not work with any peripheral card of the TI-99/4A which uses DSRs. It is likely that only hexbus devices are supported with the existing prototype consoles. **

I'm not talking about Extended Basic II crashing on startup - if I am right this will lead to an exceptional situation which can have some unforeseen effects. So it can happen that the real machines allow XB II to start up, but no disk operations are possible.

Why is that? Please have a look at 998SourceDisk6.dsk, file "FMEX". I'll post the important file to the repository of this group as well.

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.

****

One consequence is that as there are no emulations of hexbus devices yet, this means that I have to remove all disk controller support for the 99/8 in MESS. Only the cassette recorder and the cartridge slot will remain.

Michael

---

From: mark wills <[email-masked]>
Date: Sat, 6 Nov 2010 23:04:22 +0000 (GMT)

This is sad news.

One can only assume that, if the 99/8 had lived, it would have had its own suite 
of PEB cards. Same PEB box, but its own cards?

Mark

----- Original Message ----
> Sent: Sat, 6 November, 2010 22:30:07
> So, by now I have come to some more conclusions. And actually, I hope that I am 
>wrong. 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. 
>
> 
> ** My conclusion is that the TI-99/8 does not work with any peripheral card of 
>the TI-99/4A which uses DSRs. It is likely that only hexbus devices are 
>supported with the existing prototype consoles. **
> 
> I'm not talking about Extended Basic II crashing on startup - if I am right 
>this will lead to an exceptional situation which can have some unforeseen 
>effects. So it can happen that the real machines allow XB II to start up, but no 
>disk operations are possible.
> 
> 
> Why is that? Please have a look at 998SourceDisk6.dsk, file "FMEX". I'll post 
>the important file to the repository of this group as well.
> 
> 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. 
>
> 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.
> 
> ****
> 
> One consequence is that as there are no emulations of hexbus devices yet, this 
>means that I have to remove all disk controller support for the 99/8 in MESS. 
>Only the cassette recorder and the cartridge slot will remain.
> 
> Michael
> 
> 
>

---

From: Insane Multitasker <[email-masked]>
Date: Sat, 6 Nov 2010 22:48:56 -0600

Maybe someone with the working system(s) like Jim F. could affirm prior to your removing the support.

> From: [email-masked]
> Date: Sat, 6 Nov 2010 23:04:22 +0000
> Subject: Re: [TI994A] Re: MESS: TI-99/8 problems with Exbasic II and floppy support
> 
> This is sad news.
>

---

From: Bryan Roppolo Boulder <[email-masked]>
Date: Sun, 7 Nov 2010 00:01:32 -0400

I know Jim Fetzner said there was an adapter to allow the 99/8 use the PEB
and a few 99/8 cards were made.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Insane Multitasker
Sent: Sunday, November 07, 2010 12:49 AM
To: [email-masked]
Subject: RE: [TI994A] Re: MESS: TI-99/8 problems with Exbasic II and floppy
support

Maybe someone with the working system(s) like Jim F. could affirm prior to
your removing the support.

> >>00000906), before these lines are reached, then copied from there to
>8712 by 
> >the MOVE command.
> > 
> > ****
> >

---

From: Insane Multitasker <[email-masked]>
Date: Sat, 6 Nov 2010 23:43:07 -0600

Your comment spurred me into reviewing past messages again where I found an unread one from Jim dated 11/2.  An excerpt:
[In any case, I have used TI
DSSD controllers, TI DSDD controllers, and MYARC FDC (but not the HFDC)
controllers with it.  All boot to XB II.  If I have a 128K or 512K
card in the box (I have both), it also recognizes the additional memory in XB
II. ]

Given the Myarc FDC and the two TI controllers contain DSRs, it would appear that Michael's 
comment regarding different 99/8 system ROMs may be true and/or that the source
on WHT is an earlier revision than what was ultimately released in the 99/8.  

To: [email-masked]
From: [email-masked]
Date: Sun, 7 Nov 2010 00:01:32 -0400
Subject: RE: [TI994A] Re: MESS: TI-99/8 problems with Exbasic II and floppy support

I know Jim Fetzner said there was an adapter to allow the 99/8
use the PEB and a few 99/8 cards were made.

From:
[email-masked] [mailto:[email-masked]] On Behalf Of Insane
Multitasker

Subject: RE: [TI994A] Re: MESS: TI-99/8 problems with Exbasic II and
floppy support

Maybe someone with the working system(s) like Jim F. could affirm prior to your
removing the support.

> > Subject: [TI994A] Re: MESS: TI-99/8 problems with Exbasic II and
floppy 

> >     BS  RUN2           
    YES

> http://groups.yahoo.com/group/TI994A/

> Individual Email | Traditional

> http://groups.yahoo.com/group/TI994A/join

> (Yahoo! ID required)

> [email-masked] 

> [email-masked]

> [email-masked]

> http://docs.yahoo.com/info/terms/

---

From: "Michael Zapf" <[email-masked]>
Date: Sun, 07 Nov 2010 10:41:33 -0000

The explanations that I gave refer to Extended Basic II exclusively; it is actually XB II that introduces this incompatibility.

That is, Editor/Assembler works fine. I can load and run files from a TI FDC, BWG, and HFDC. The same is true for assembler language programs. 

Unfortunately, Extended Basic (1) fails to run in the TI-99/8 (which is a known issue, according to the Bugs document).

That is, I can keep the disk support, but I have to put this in the known limitations for the emulation that disk support is not available for XB II and that the disk support must be deactivated before entering XB II. 

(The good thing is that I could now write a tool to get a ROM dump from a real console and save that to disk. Hope to get the missing libraries (like P-code).)

MIchael