99/2 peculiarities ....

[Retrospect]

I've just tried to make a couple of games for the 99/2 in MAME emulation, as the cassette recording and playing works fine.

 

The first attempt was a "bomber" game using the 99/2's internal graphics subset, (32K rom 99/2, not the 24K)

This failed because HCHAR/VCHAR doesn't act like it does on the 99/4A ... take a look at this code and you'll know what it does.... 

32000 FOR Q=5 TO 28

32005 BH=INT(8*RND)+3

32010 GH=24-BH

32015 CALL VCHAR(GH,Q,144,BH)

32020 NEXT Q

This was meant to build a city using character 144 which is a nice clear block ... however when it went from left to right it wiped out the buildings on it's way towards the right.

This is unexpected behaviour.  I worked around it by making the line 32000 say "FOR Q=28 TO 5 STEP-1" and basically making the city the other way round, however, when the plane dropped a bomb, the bomb would blank out all buildings to the left of it at the same time as the one it was hitting.  How strange!

 

The second attempt was a "dopewars" game using just text.  This was going nicely, using the 32KB expansion, until about the 6th SAVE when all of a sudden I had a screen full of random characters and a message "Internal Error" or something to that effect!

 

The ROM is / was bugged all along?  

Edited May 22, 2022 by Retrospect

[+acadiel]

I’ll have to try this the next time I get my 99/2 out.  Thanks for the example code.  That will rule out if it’s a system issue or a MAME issue.   

 

[+mizapf]

The 99/2 defines all characters from 70 to FF als "BEOL" (Blank to End Of Line). If you write such a character into a line, the rendering process stops at that point and leaves the remainder blank.

 

The background is that the 99/2 does not have a proper VDP; also, the video memory is mapped into the CPU address space. So when it is supposed to draw a screen line, the CPU is halted to avoid concurrent accesses. When the line is done, the CPU is released.

 

This also means that the 99/2 becomes slower when the screen is filled.

 

See Section 3.3 in the attached document. This refers to the 24K console where 70-FF are BEOL, while in the 32K version, 80-FF are BEOL.

TI992_Product_Specification.pdf

[+acadiel]

The 99/2 defines all characters from 70 to FF als "BEOL" (Blank to End Of Line). If you write such a character into a line, the rendering process stops at that point and leaves the remainder blank.
 
The background is that the 99/2 does not have a proper VDP; also, the video memory is mapped into the CPU address space. So when it is supposed to draw a screen line, the CPU is halted to avoid concurrent accesses. When the line is done, the CPU is released.
 
This also means that the 99/2 becomes slower when the screen is filled.
 
See Section 3.3 in the attached document. This refers to the 24K console where 70-FF are BEOL, while in the 32K version, 80-FF are BEOL.
TI992_Product_Specification.pdf

Fascinating. I’m guessing that overriding this might mean that we have to find the test in rom that says >70 = BEOL and just increase it or something. Kind of interesting how they cut it off at 112.


Sent from my iPad using Tapatalk

[+mizapf]

9 hours ago, acadiel said:

Fascinating. I’m guessing that overriding this might mean that we have to find the test in rom that says >70 = BEOL and just increase it or something. Kind of interesting how they cut it off at 112.

This is surely done inside the TAL-004 custom video chip, so I guess there is no way to change it. The document below mentions a "bitmap mode", but there is no indication that the memory layout inside the 99/2 allows for a bitmap mode; maybe this was a possible future extension.

TI992_Video_Chip.pdf

[Retrospect]

On 5/22/2022 at 12:59 PM, mizapf said:

This also means that the 99/2 becomes slower when the screen is filled.

Yes, I encountered this.  When I got my "city" to draw (from right to left!) and the plane was travelling across the screen, it was slower if the city was taking up more screen space.