• Please review our updated Terms and Rules here

Anyone using ANSITerm with the Tandy M4 graphics card?

pjhacnau

Experienced Member
Joined
Apr 5, 2015
Messages
270
Location
Morisset, NSW Australia
Dear all,

I recently became the proud owner of a reverse-engineered Tandy M4 graphics board (26-1126 - Pascal's board via Ian). Works nicely. Except for one thing. Running ANSITerm, I get two types of what can be best described as "snow". There are two different (regular) patterns; one for text going to screen, one when it's scrolling.

I see the following reasons:

I'm ruling out the first two; "if hash filled" sort-of matches up with the "snow". Given ANSITerm uses the hardware scrolling feature of the board, I wouldn't be surprised if it also uses the "disable wait states" option; can anyone confirm/deny that?

Is there anyone out there using ANSITerm with a genuine 26-1126? Seen this?

Thanks,

PJH


PS: I have a video of the "snow" - if anyone wants to look PM me and I'll point you to a dropbox folder.
 
I have a similar setup, though both are gate-array variants. Did you apply the ANSITerm patches per Ian's guidance?

The patches are only necessary for proper operation with the Grafyx clone boards with 32 KB of memory (which get mistakenly detected as Tandy cards).

Digging in to ANSITerm a bit I see it does not set bit 1 of port $83 to enable wait states. So there will be snow when data is written to the graphics board. Setting the scrolling register doesn't cause snow, but when ANSITerm scrolls it will need to erase the new line at the bottom of the screen so there are data writes associated with scrolling.

I imagine they did this to avoid dropping characters at higher baud rates. In theory the 240-ish cycle worst-case wait state delay wouldn't be a problem at even 19200 baud, but it may have caused issues nonetheless.
 
Digging in to ANSITerm a bit I see it does not set bit 1 of port $83 to enable wait states. So there will be snow when data is written to the graphics board.

I'm slightly confused here; I thought for the NGA M4 the wait states were enabled by default; wouldn't ANSITerm need to explicitly disable them (rather than just not enable them)?
 
I'm slightly confused here; I thought for the NGA M4 the wait states were enabled by default; wouldn't ANSITerm need to explicitly disable them (rather than just not enable them)?

Graphics software has to explicitly make a choice as all of the (write-only) register at port $83 must be written to enable graphics. And also to control a number of other handy functions such as automatic update of the X,Y position. Here's how the port is mapped (high bit on the left, lowest bit on the right):

Code:
        +-------+-------+-------+-------+-------+-------+-------+-------+
Write 83|Move Y	|Move X	|Move Y	|Move X	| Y DIR	| X DIR	|Enable |Enable	|
        | Write	| Write	| Read	| Read	| 0=++	| 0=++	|  I/O	|Graphic|
	| if 0	| if 0	| if 0	| if 0	| 1=--	| 1=--	| Wait	|	|
	+-------+-------+-------+-------+-------+-------+-------+-------+
						Grafyx:	|Disable|
							|Text   |
							+-------+

Notice that Grafyx boards have a different function controlled by bit 1. Programs will typically put something like $F3 into the register to enable graphics and I/O wait states.
 
Dear all,

I recently became the proud owner of a reverse-engineered Tandy M4 graphics board (26-1126 - Pascal's board via Ian). Works nicely. Except for one thing. Running ANSITerm, I get two types of what can be best described as "snow". There are two different (regular) patterns; one for text going to screen, one when it's scrolling....

As far as I recall, when I ran ANSITerm4 in testing for Richard back in 89-90 timeframe on my 4D with a 26-1126 card there was snow; that was required to keep up with higher baud rates as I recall. I do recall that it was a conscious choice by Richard to allow this; ANSITerm just barely keeps up with higher baud rates without I/O waits. It would be easy enough to patch the various OUT's to the graphics registers to enable I/O waits to see the effect.

(My relationship to ANSITerm4: I took an older Model III mode hi-res terminal program, cleaned it up, rewrote some sections, and released a model III ANSITerm, and Guy Omer of 8/N/1 loved it so much that he put out a public call (via the 8/N/1 BBS itself) for a Model 4 version, and Richard Van Houten, of ARC3 and ARC4 fame, among other things, took up the challenge. I have the source for the Model III older version, but Richard didn't share the source for the current ANSITerm 4. I remember how tight things had to be for the Model III ANSITerm, and even with hardware scrolling ANSITerm 4 has a great deal of work to do to keep up (Model III ANSITerm doesn't scroll, as far as I recall, because doing that on the Model III 26-1125, the card for which it was written, was way too expensive for anything past 110 baud or so)).

The I/O-mapped hi-res was not built for speed.
 
As far as I recall, when I ran ANSITerm4 in testing for Richard back in 89-90 timeframe on my 4D with a 26-1126 card there was snow; that was required to keep up with higher baud rates as I recall. I do recall that it was a conscious choice by Richard to allow this; ANSITerm just barely keeps up with higher baud rates without I/O waits.

That's the confirmation I was hoping for. In the short term I'll try to ignore it.

It would be easy enough to patch the various OUT's to the graphics registers to enable I/O waits to see the effect.

Yes. I'm adding that to my (long) list of "things to do on my retro-computing machines". Given my primary use-case is only at 9600 baud I'm hopeful that it will cope with the states.

(My relationship to ANSITerm4: I took an older Model III mode hi-res terminal program, cleaned it up, rewrote some sections, and released a model III ANSITerm, and Guy Omer of 8/N/1 loved it so much that he put out a public call (via the 8/N/1 BBS itself) for a Model 4 version, and Richard Van Houten, of ARC3 and ARC4 fame, among other things, took up the challenge. I have the source for the Model III older version, but Richard didn't share the source for the current ANSITerm 4. I remember how tight things had to be for the Model III ANSITerm, and even with hardware scrolling ANSITerm 4 has a great deal of work to do to keep up (Model III ANSITerm doesn't scroll, as far as I recall, because doing that on the Model III 26-1125, the card for which it was written, was way too expensive for anything past 110 baud or so)).

Thanks for that; It's always nice to have more context.

The I/O-mapped hi-res was not built for speed.

I've already noticed that :)
 
Back
Top