TI-99/2 questions

[+mizapf]

When I execute the code, the display stays, the cursor disappears during the execution and reappears after 1'07". No crash, no error.

 

I can't understand that ... I already checked the ROMs that you dumped, and there are clear indications that the screen blanking is done the same way - by setting CRU bit 0 at address E00E to 0. And you noticed that during cassette operations, the screen is blanked, so it should work in principle. Are you sure there are no typos?

 

The first bytes represent the commands

 

 

  LI  R12,>E00E
  SBZ  0
  ...

 

I can only imagine that the program is trashed by some system activities. Maybe you can try to peek the values again. Also, I assumed that in your case, the interrupt is off, as I saw in the MAME debugger. We could try to add a LIMI 0 to the beginning: 3,0,0,0.

[kl99]

I'm also pretty curious whether you will be successful with tape loading/saving.

 

Did you miss my post that contains the stored audio file?

I am already done with that part.

[+mizapf]

You said you were not able to load the program again and suspected cable issues. I was not able to load it either in MAME, and since there cannot be a cable problem, I'd like to find out whether there is a bug in the 99/2. In that case it would not make sense to try to get it running.

[fabrice montupet]

I'm sure to have correctly input the program, I have read it two times before run it.
This morning, I made an other try just after a reset of the computer and the result is better: The screen is blanked an the program terminates after 59 seconds and displays ** DONE** :-)

[fabrice montupet]

Reading the results, my prototype of 99/2 is faster than the latest version. It is the one shown at the january 83 CES.

 

In the article writen by Charles Good, the little program:

100 FOR N=1 TO 10000 
110 PRINT N 
120 NEXT N 

is executed in 30 minutes 20 seconds in TI BASIC with the 99/4A. Charles wrote that it takes only 3 minutes and 3 seconds on the 99/2 (which is already very fast). My 99/2 takes 2 minutes and 36 seconds.

[kl99]

Testing twice the 32kb speed test program

 

Testing once the 24kb speed test program

 

Testing CALL CLEAR behavior. It shows that CALL CLEAR blanks the screen and CALL GCHAR returns that value 32 (blank) is at every screen location. Instead of the value 255, that mizapf expected.

[+mizapf]

That's a nasty little Ground Squirrel! It is starting to test my patience...

 

I need to check how that internal error message could have been caused.

 

 

Testing CALL CLEAR behavior. It shows that CALL CLEAR blanks the screen and CALL GCHAR returns that value 32 (blank) is at every screen location. Instead of the value 255, that mizapf expected.

 

Well, this is the proof that "Fake news" have already been around in the early 80s. GCHAR is a complete liar. So sad.

 

Actually, it finds >FF and tells you there is >20. I mean, what answer would you have preferred? You can only use the characters below >7F, and until now it was clear that CALL CLEAR filled the screen with spaces, so why confuse people?

 

I certainly have to find the respective locations in the ROM code to proof my claim, but the attached screenshot from the MAME debugger shows the screen buffer, and it is mainly filled with >FF, except for the bottom lines. I got the value from line 2, column 20.

[+mizapf]

Found a problem: You should have entered the lines in command mode, not write a BASIC program from it. The point is that the space I wanted to use may have been modified by the BASIC interpreter. There may be a difference between single command execution and running the program.

 

I will write another test program soon to rule out any similar issues. Thanks so far.

[fabrice montupet]

I have done again the test (for 24K ROM version) : I obtain 58 seconds... and an Internal Error. Yes, this Ground Squirrel is crazy :-)

That said, we work on prototypes computers, not finalized.

 

I have verified all the components that I could verify (all but the two TAL004) and the SAVE command still no works. I think about a bug in the ROM or a non finalized implementation of the command.

Edited May 13, 2018 by fabrice montupet

[fabrice montupet]

I'm trying to understand the differences in computer behavior while doing the same test. So, I redid the test and I still had a surprise (but the same time lapse) : At the end of the test, the screen started a (nice and smooth) scrolling ASCII characters for a few seconds and then displayed an internal error. Perhaps it would be necessary to completely empty the memory before doing anything. Unless these differences in behavior are due to an instability of the computer.

[+mizapf]

I'm preparing another test program that is loaded into E000 memory (or some free space), then copies a part from the F000 area, moves the test program into that area, runs, and then restores the F000 area so that everything is the same when returning to BASIC.

[+mizapf]

I hope this one works as expected. Since I don't have a way to save programs on the 99/2 yet, I had to type it in repeatedly until it worked. So when you type it in, remember that I already did the same about 6 times (also for testing the 24K version).

 

 

10 CALL POKE(-7712,6,1,22,254,6,2,22,252,4,91)
20 CALL POKE(-7680,3,0,0,0,2,0,225,240,2,1,240,0,2,3,225,224)
30 CALL POKE(-7664,2,2,0,5,204,17,204,115,6,2,22,252,194,139,4,193)
40 CALL POKE(-7648,2,2,1,144,2,12,224,14,30,0,6,160,240,0,29,0)
50 CALL POKE(-7632,2,0,225,240,2,1,240,0,2,2,0,5,204,112,6,2)
60 CALL POKE(-7616,22,253,3,0,0,4,4,90)
70 CALL MCHL(-7680)

 

Expected behavior: The screen should blank, then after some time, the screen appears again, and the cursor blinks in a new line. The program stops without DONE, which makes me a bit uneasy, but I don't like to go through it again right now.

 

This is the source code:

 

       AORG >E1E0 
       DEC  R1
       JNE  $-2
       DEC  R2
       JNE  $-6
       RT
   
       AORG >E200    
       LIMI 0
       LI   R0,>E1F0
       LI   R1,>F000
       LI   R3,>E1E0
       LI   R2,5
       MOV  *R1,*R0+
       MOV  *R3+,*R1+
       DEC  R2
       JNE  $-6
       MOV  R11,R10
       CLR  R1
       LI   R2,400
       LI   R12,>E00E
       SBZ  0
       BL   @>F000
       SBO  0
       LI   R0,>E1F0
       LI   R1,>F000
       LI   R2,5
       MOV  *R0+,*R1+
       DEC  R2
       JNE  $-4
       LIMI 4
       B    *R10       

[+mizapf]

By the way, quite interesting: They implemented a MID handler in the 99/2 (both 24K and 32K).

 

When you do this

 

 

CALL POKE(-8000,0,0)
CALL MCHL(-8000)

 

the CPU hits the invalid opcode >0000, which raises a "Macro Instruction Detect" interrupt, and issues "INTERNAL ERROR" on the console, then resets on key press.

 

I used that MID on the Geneve for my "Guru meditation" tool, showing a black screen with a red text that indicates the current WP, PC, and ST, and waits for a left mouse button click. And it had a blinking red frame. I guess I picked it up from somewhere...

[fabrice montupet]

Test done :-)
The screen becomes blank, then after 59 seconds, the screen appears again. No blinking cursor. The program stops without displaying "**DONE**", it freezes.

When I do a CALL POKE(-8000,0,0) and a CALL MCHL(-8000), the computer displays "INTERNAL ERR: PRESS ENTER". When I press ENTER, the 99/2 returns to the start menu.

[fabrice montupet]

Michael, could you make a screenshot of the ASCII table you get with your emulator using my 24K ROM set? By advance, thank you!

[+mizapf]

Well, at least it finishes the test. It seems as if it crashes on returning to BASIC, which I somewhat expected already, since the return in MAME was not clean either. But it served its purpose.

 

Yesterday evening I tried to find out how to determine the "safe" space in BASIC. The address F00A is obviously not the pointer. I did not yet succeed, however. On the other hand, there must be such a pointer to free space, since this is where it places the next BASIC lines. I compared the contents of the on-chip RAM after adding lines, checked the normal RAM, and went through the disassembled lines. It will take some more time, as it seems.

 

Klaus, did you try the above test program as well? (#187)

[+mizapf]

Michael, could you make a screenshot of the ASCII table you get with your emulator using my 24K ROM set? By advance, thank you!

 

See below, both versions. (I need to postprocess the screenshots with GIMP to add some shadow to the white background.)

[fabrice montupet]

Thank you :-)

There are many differences between the two versions, the second is closer the TI-99/4A ASCII table than the first.

[kl99]

Klaus, did you try the above test program as well? (#187)

 

I have my 99/2 stored away again. I am little bit low of space currently due to the huge DS990 machine opened and spreaded across two tables. On Friday I fly away. Did you verify that the program works in the emulated 99/2?

 

Regarding character definitions, didn't you see the little man I once posted:

 

Character Definitions start at >1C00 and go up to >1FFF.

It includes small caps letters as the 99/4a.

The very last character "1C3E6B7F633E1436" is some leavebehind message of the engineers it seems.

 

character-definitions.png

You can see that the characters before Ascii 32 (space) are used for Block Art Drawings.

[+mizapf]

@Fabrice: I tried my program in the 24K version, and it ran exactly 59 seconds in MAME! Sounds good ... we're getting closer to a proper emulation. Also, this is the ultimate proof that the CPU clock is 10.7 MHz.

 

The next thing to verify is whether we have auto-wait states. (The last program ran in the on-chip RAM which is immune to wait states.) Finally, when this is clear, I can find out whether the HOLD time is correct (when the line is drawn).

 

The point why I'm doing these tests (and bother you all with these programs) is that Hexbus and cassette handling will never work when the CPU clock (and wait states) are not correct.

[fabrice montupet]

Good news :-)

I am available for any other tests you'll need.

[+mizapf]

Here is one more test that checks whether we have auto-wait states or not. It runs almost the same loop as above, but it does not try to return. It copies the loop into on-chip RAM, blanks the screen, loads a byte from E000 in each loop iteration, activates the screen again, and locks up.

 

Please take the time. I expect a difference of 10 seconds between 1 WS and 0 WS. Note that you can run this test only once, then you have to reset your computer.

 

 

10 CALL POKE(-7712,208,32,224,0,6,1,22,252,6,2,22,250,4,91)
20 CALL POKE(-7680,3,0,0,0,2,0,225,224)
30 CALL POKE(-7672,2,1,240,0,2,2,0,7)
40 CALL POKE(-7664,204,112,6,2,22,253,4,193)
50 CALL POKE(-7656,2,2,1,144,2,12,224,14)
60 CALL POKE(-7648,30,0,6,160,240,0,29,0,16,255)
70 CALL MCHL(-7680)

 

The 9995 can be configured to insert a wait state into each external memory access by pulling down READY on power-up. With READY high, no wait state is inserted. The 99/8 is configured for auto-wait state, but the 99/2 already diverts in so many details from the specs that I would not be surprised about anything.

[fabrice montupet]

I ran the test: The time is 1 minute 47 seconds.

Edited May 16, 2018 by fabrice montupet

[+mizapf]

I got 108 seconds for 1 WS, 98 seconds for 0 WS. I suppose this really means we have auto-wait states. Good. Thanks!

 

@Klaus: If you find some time, please check on your 32K machine.

[+mizapf]

Meanwhile, some numbers.

 

CPU clock 10738635 Hz internally divided by 4 is 2684658.75 Hz. This yields a cycle time of 372.487 ns (a bit longer than the 99/4A with 333 ns).

 

The outer loop is 400, the inner loop is 65536 iterations, which is a total of 26214400 iterations, each with one memory access.

 

If there is a wait state of one cycle for each memory access, this means 9.76 seconds, which is roughly that what I found as the time difference on the MAME emulation.