TI-99/2 questions

[+mizapf]

Plain machine language, no GROMs, and the 9995. If I understood correctly from the descriptions, it is clocked by 5.35 MHz (10.7 divided by 2).

[+acadiel]

Plain machine language, no GROMs, and the 9995. If I understood correctly from the descriptions, it is clocked by 5.35 MHz (10.7 divided by 2).

One of the IUG newsletters had a section with a key combination one could press to make it run full speed. Unfortunately, it’s not one of the newsletters I have.

[fabrice montupet]

Hi Fabrice, we may find a way to dump the ROMs without desoldering, and it will certainly be interesting to get a dump from yours.

 

Desoldering and dumping the ROM chips is easy and fun, it's just take some time to accomplish. So, this week end I will take a half an hour to do and I'll send to you the binaries :-)

[+acadiel]

The prototype of Fabrice is an earlier version, not the 32k version.

Here are the 4 eproms on mine:

http://www.ti99.eu/?attachment_id=3149

Gotcha. I remember the early tech specs on the 99/2 mentioned 24K of ROM. I’m guessing they went to 32K and never updated the specs sheets for the Ground Squirrel?

[kl99]

OK, looks pretty simple. Klaus, could you please check the first available machine code location by doing a CALL PEEK(-4086,A,B) and report it here? (see personal message)

 

I need to know this to find out how much buffer we can use for copying the second bank. The longer we can get it, the less passes we need for saving the contents.

 

The machine code itself is only 26 bytes.

 

-4086, right? not -4096!

 

result:

A: 209

B: 33

[kl99]

Gotcha. I remember the early tech specs on the 99/2 mentioned 24K of ROM. I’m guessing they went to 32K and never updated the specs sheets for the Ground Squirrel?

 

Another user scanned a high resolution about a very detailed article on the 99/2 from the Byte Magazine with the project leaders:

http://atariage.com/forums/topic/258370-ti-992-general-system-rom-dump/?p=3730639

The change of the rom size is mentioned.

[+mizapf]

 

-4086, right? not -4096!

 

result:

A: 209

B: 33

 

Yes, this is what they specify in the docs (BASIC reference guide, CALL MCHL). So your result is D121. To make sure, does it change when you add BASIC lines? (in which direction?)

 

The description on that page is again a bit confusing. They say that a machine language program should be poked into an area which is immediately below the memory for the BASIC program; so I would expect that this address is the bottom of the BASIC program area. However, the sample program suggests to add the requested buffer size, which would mean to go upward, and the address is the one "that was previously the bottom of memory".

 

I guess we can easily find out when you just add some more lines.

[kl99]

added 3 lines and executed the program once.
now its

A: 236

B: 22

[kl99]

Hm, I can not reproduce the values. When entering a program now it is always 209;33

[fabrice montupet]

I had a little free time this evening so I have desoldered the ROM chips of my 99/2 prototype and made a dump.

You can download them (named ROM0, ROM2 and ROM4) on my website, at the bottom of this page: http://www.ti99.com/ti/index.php?article7/basic-computer-99-2

 

Have fun :-)

Edited April 17, 2018 by fabrice montupet

[+mizapf]

Je les ai déjà téléchargé... merci!

 

As I saw, the contents of your dumps are not identical to the existing dump in MAME, which seems to be a 32K dump with a missing last 8K.

 

(I hope there are less versions of ROMs than consoles...)

[+mizapf]

This is interesting. Here is the beginning of Klaus' ROM, with some comments from me:

 

 

0000:     DATA >EB72,>0014   RESET
0004:     DATA >EB72,>01C6   INT1
0008:     DATA >EB72,>00FA   MID
000C:     DATA >F00C,>01BC   Decrementer
0010:     DATA >EB66,>01C8   INT4
 
Reset
0014:     LI   R3,>E000
0018:     BLWP @>39D4        Set CRU@>E000 to 1
001C:     LI   R1,>0400     
0020:     S    @>4000,R1     4000 = 0000 (bank 0), 0100 (bank 1)
0024:     SLA  R1,5          R1 = 8000 / 6000
0026:     BLWP @>39DC        Set CRU@>E000 to 0
002A:     MOVB *R3,R2        Get current value of E000
002C:     INV  *R3           Invert the value at E000
002E:     CB   R2,*R3        Check for change
0030:     JEQ  >0080         No? Then we don't have RAM at that location
0032:     MOV  R3,@>F000     Yes, there seems to be RAM. Save that address as the lower end.
0036:     C    R3,R1        
0038:     JEQ  >0080                                      1323           : 0038
003A:     AI   R3,>F000      Go back by 4K
003E:     JMP  >002A         Check for more RAM

 

 

while this is Fabrice's ROM:

 

 

0000:     DATA >EB74,>0014
0004:     DATA >EB74,>00A2
0008:     DATA >EB74,>00D2
000C:     DATA >EBB4,>56B2
0010:     DATA >EB68,>5D1C
 
Reset
0014:     LI   R2,>AA00                                   0202 AA00      : 0014
0018:     LI   R1,>6000     Check 6000
001C:     CB   *R1,R2       for AA
001E:     JNE  >002A        No, then search
0020:     INCT R1                                         05C1           : 0020
0022:     MOV  *R1,R1                                     C051           : 0022
0024:     INCT R1                                         05C1           : 0024
0026:     MOV  *R1,R1                                     C051           : 0026
0028:     B    *R1                                        0451           : 0028
002A:     MOVB R2,*R1       Is that RAM?
002C:     CB   R2,*R1                                     9442           : 002C
002E:     JEQ  >0084                                      132A           : 002E
0030:     AI   R1,>4000     Next 16K (A000)
0034:     CI   R1,>E000     So we only check 6000 and A000
0038:     JEQ  >0084                                      1325           : 0038
003A:     JMP  >002A                                      10F7           : 003A

[+mizapf]

Hm, I can not reproduce the values. When entering a program now it is always 209;33

 

I tend to believe that the "-4086" as given in the reference manual is wrong, could be -4096 after all. I found references to F000 in the ROM, but F00A does not occur.

 

Could you please try the above with -4096?

[kl99]

224;0

it is like this after reset

it stays like this after entering lines of basic code and executes.

[+mizapf]

Thanks. Let's just try and see what happens.

 

The value E000 means that you have 4K RAM (E000-EFFF), which is more than originally designed (2K). This seems to be correct, looking at your photograph from the previous page. There are two 6116 chips, each one a 2Kx8 RAM. With 2K only, this would have become pretty ugly.

 

4K is not very much, in particular when you consider that 768 bytes are used for the screen, so effectively, you have 3328 bytes plus the 256 bytes from the CPU-internal RAM. The RAM in your system is from E000 to EFFF plus F000 to F0F9, plus FFFA to FFFF, minus the screen RAM at EC00 - EEFF. The byte at EF00 is a control byte for display.

 

First we test to see whether the concept is working, later we can dump the bank completely.

 

I'm not sure whether DATA lines take more or less space, so I take a direct poke instruction. I hope that the area from EF01 to EFFF is free to use; if not, something with crash, either the machine routine, or the BASIC program. Then we need to move to another location.

 

Please add the following lines to your program at the beginning. They will place the routine at address EF40 and use a buffer at EF80.

 

 

1 CALL POKE(-4288, 2, 12, 224,   0,  29,   1,  2,   0)
2 CALL POKE(-4280, 64,  0,   2,   1, 239, 128,  2,   2)
3 CALL POKE(-4272, 0, 16, 204, 112,   6,  66, 22, 253, 4, 91)
4 CALL MCHL(-4288)
... your dump program ...

 

This is intended to turn on the second bank, and to copy the contents of 4000-400F to EF80-EF8F (-4224 to -4209). You should then dump this address range.

 

If it crashes, you can relocate that program to another location in E000-EBFF (-8192 to -5121). For that purpose, replace the target address in the POKE subprogram with another address, and also the address in MCHL. The buffer address is in the second line (239,128 = EF80 = -4224). You should also point that to another location and accordingly dump that new address.

 

I am not sure whether the CALL MCHL is a BL which can be returned by RT (as done here). If it is a BLWP, we have to replace that with RTWP. Also, we could need to use SBZ instead of SBO.

[kl99]

will try once I reach home (~4 hours left).

99/2 is still setup and will keep it like this until we are satisfied.

[kl99]

@mizapf: best is to read the BYTE article that was pointed to before. it goes into all the details since it was not done by some press guy but the Project leaders.

http://atariage.com/forums/topic/258370-ti-992-general-system-rom-dump/?p=3730639

 

The Ram was enlarged to 4096+256 byte. 256 byte are the CPU onboard Ram. 4096 Byte are from the one Ram chip. They increased the RAM by 2K to carry the overhead of the system BASIC.

[kl99]

for some reason i always get i/o error 02 when trying to save any program to disk.

i had the problem with the inner floopy in the hx-5102 from the beginning. i replaced the inner drive.

now loading from internal hex-bus drive and external drive works but not storing anything, on both it doesn't work.

i am currently sweating from switching out all kinds of configurations.

i will not be able to do something tonight. maybe tomorrow morning before work.

[+mizapf]

Hmm, too bad. I hope it has nothing to do with our test (i.e. switching the bank).

[fabrice montupet]

for some reason i always get i/o error 02 when trying to save any program to disk.

It's already a good start :-) From my part, my TI-99/2 doesn't recognizes hexbus device with OLD and SAVE commands. If I use "HEXBUS.10x" or "DSKx" devices with my HX5102, it always returns to tape device... Yes, this computer is really an very early version! One day, I will install a more recent ROM set on this prototype to see it 100% function.

 

On the other side, my HX5102 controller (with 5.25" & 3.5" disk drives) works fine on my 99/5 and 99/8 prototypes computers.

[kl99]

if it really keeps failing even when reinstalling the original shugart drive into the HX-5102, I can still stick to the HexBus-RS232 and transmit the data over that port to my PC.

It has worked the last time i dumped the first three banks with an external drive. maybe I did the termination wrong.

In the end we have to succeed.

So wish me luck tonight

And another teaser: We might be able to see how a real 99/2 cartridge looks like.

[fabrice montupet]

And another teaser: We might be able to see how a real 99/2 cartridge looks like.

Oh! At last, we will see other thing than pictures? Good news :-)

[+mizapf]

99/2 cartridges? Can't wait to see...

 

Klaus, before trying to save the contents, you could probably first check whether this method is working as intended by simply printing the values on the screen.

[fabrice montupet]

... or connect the RS232 Hexbus device to send datas to a XMODEM communication program on a PC with a serial port. It is what I did when I hadn't yet the Hexbus floppy disk controller.

[+acadiel]

... or connect the RS232 Hexbus device to send datas to a XMODEM communication program on a PC with a serial port. It is what I did when I hadn't yet the Hexbus floppy disk controller.

 

 

 

The RS232 is one versatile piece of equipment. It's how I dumped all the CC-40 ROMs