Tandy graphics 320x200 16 colors programming

[Mills32]

The memory is not continuous in all modes. You can't assume 32K is present all the time. You're supposed to use the page registers to switch hidden and visible pages as I mentioned in http://www.vcfed.org/forum/showthre...200-16-colors-programming&p=658284#post658284 .

Sorry I was testing that but I forgot to post about it.

Changing page registers, I was not able to activate 32K in the mode 8 (160x200), there is always a 16K page that wraps around. That 3df register works as expected, it changes visible pages and maps different ones to b800, but I guess mode 8 is just a 16K mode.

I found register 3dd which is supposed to do something about pages and sizes:

	video		D0	D7	D6
	Descriptions 	3DDH	3DFH	3DFH

	8p 1 - 16K	0	0	0
	8p 2 - 8K	0	0	1
	4p 2 - 16K	0	1	0
	4p 4 - 8K	0	1	1
	4p 1 - 32K	1	0	0
	2p 2 - 32K	1	0	1

So I tested that, but it didn't work. Mode 8 was always showing one 16K wrapping page.

	union REGS regs;	
	byte CRT_Page = 0;		//16K visible page.
	byte Processor_Page = 0;	//16K area accessible at B800h address for write/read. 
	byte Video_Address = 1;		//00000001
	byte page = (Video_Address << 6) | (Processor_Page << 3) | CRT_Page;
	
	//Set mode 8 160x200
	regs.h.ah = 0x00;
	regs.h.al = 0x08;
	int86(0x10, &regs, &regs);

	//Set bit 0 of 3DDH to 1
	asm MOV	AH,0
	asm MOV	DX,03DDH
	asm MOV	AL,00000001b
	asm OUT	DX,AL
	
	//Set page
	asm MOV	DX,03DFH
	asm MOV	AL,page
	asm OUT	DX,AL

 

[Trixter]

Changing page registers, I was not able to activate 32K in the mode 8 (160x200), there is always a 16K page that wraps around. That 3df register works as expected, it changes visible pages and maps different ones to b800, but I guess mode 8 is just a 16K mode.

Correct. Sorry if it was implied otherwise.

You are probably just stuck doing scrolling the way we had to do it with CGA, which is to understand you only have a single page, and repaint the scroll width in rows, or height in columns, racing the beam. Good examples of this on real hardware are:

Bob Winner (horizontal)
Spy Hunter (vertical)
Prohibition (horizontal and vertical)
Super Zaxxon (both, "diagonal" scrolling, this is severe "racing the beam" stuff)

 

[Great Hierophant]

There is an undocumented feature of the Tandy 1000s with either the "Big Blue" chip or the TL/RL/SLs ( anything released after the 1000/A/HD) that allows for smooth vertical scrolling, as shown in the attached demo from NewRisingSun.

I have a video capture here using a special, private build of DOSBox, which matches what I have seen from original hardware

 

[Trixter]

Nice, I always assumed all Tandy mode handling was the same. Cool to learn something new after all these years.

If NRS could provide some details on how this works, it would help the OP. Or, I guess the OP could debug/disassemble the SCROLL.COM file and see what's going on, although I had a quick look and don't recognize some of the values and regs. Is this undocumented behavior, or is it something we can check one of the tech refs for?

 

[NewRisingSun]

http://www.vcfed.org/forum/showthre...k-properly-on-Tandy-1000s&p=398738#post398738

This post explains the bits of register 3DD and what combination of 3D8/3DD/3DF is necessary for scrolling, in particular the part

3D8 bit 1=1, 3DD bit 0=1, 3DF bit 7 ignored, 3DF bit 6=1: Row Address bit 0 selects one of two 32K banks within (two-screen) video page. Used in 160x200x16/320x200x16 mode when creating a virtual 160x400x16/320x400x16 screen for vertical scrolling using the CRT start address registers. The more likely application for this is 400 line interlace mode, which I managed to get working on the TX.

The CRT controller registers (3D4) are updated to account for two scanlines per row.

 

[Trixter]

Sweet. Added to my notes about how you found a way to extend my PCjr 160x100 mode to all Tandys.

(
and for those who are curious about that one:
PCjr: clear bits 6 and 7 on 3DF
Tandy SX/TX/EX/HX: as PCjr plus set bit 0 on 3DD
Tandy TL/SL/RL: as PCjr plus set bit 0 on array register 5
)

 

[Mills32]

http://www.vcfed.org/forum/showthre...k-properly-on-Tandy-1000s&p=398738#post398738

This post explains the bits of register 3DD and what combination of 3D8/3DD/3DF is necessary for scrolling, in particular the part The CRT controller registers (3D4) are updated to account for two scanlines per row.

Is there any source code to test?. I think I did what the post says, but I just got a black screen on both 8 and 9 mode (160x200, 320x200).

	union REGS regs;	
	byte CRT_Page = 0;		// page visible.
	byte Processor_Page = 0;	// areas accessible at B800h
	byte Video_Address = 1;
	byte page = (Video_Address << 6) | (Processor_Page << 3) | CRT_Page;
	

	regs.h.ah = 0x00;
	regs.h.al = 0x09; //Also tested 0x08
	int86(0x10, &regs, &regs);

	asm MOV	AH,0
	asm MOV	DX,03D8H
	asm MOV	AL,00000010b
	asm OUT	DX,AL
	
	asm MOV	DX,03DDH
	asm MOV	AL,00000001b
	asm OUT	DX,AL
	
	asm MOV	DX,03DFH
	asm MOV	AL,page
	asm OUT	DX,AL

I have been testing the cga graphic/text mode (160x100) in pcem. Tandy seems to work much faster than cga and I also get hardware scroll. Vertical scroll moves 1 line at a time, horizontal scroll moves 2 "pixels" (one text cell).

 

[carlos12]

When I ran the scroll.com demo on DOSBox (both 0.74 and DOSbox-X on Tandy mode), and on 86Box, emulating specifically a Tandy 1000 SL/2, the result wasn't what the video of the real hardware showed. It didn't display properly. The scroll was there, it was smooth but the image was distorted. With scroll2.com I got a black screen on DosBox.

I guess these so specialized procedures aren't still properly emulated, even by 86Box, which is arguably more accurate than PCem.

 

[Trixter]

The OP is delving into territory that was never explored by software when the hardware was current. Until software + video evidence is submitted to emulator authors, it is very unlikely any emulator will support these tricks correctly.

I have been testing the cga graphic/text mode (160x100) in pcem. Tandy seems to work much faster than cga and I also get hardware scroll. Vertical scroll moves 1 line at a time, horizontal scroll moves 2 "pixels" (one text cell).

I don't think tandy works "faster" than CGA in this mode as they both have roughly 160KB/s REP MOVSW speed to the video area, last I checked. I could be wrong. If you're targeting 160x100, keep in mind on real CGA cards it will produce a ton of snow.

 

[Mills32]

The OP is delving into territory that was never explored by software when the hardware was current. Until software + video evidence is submitted to emulator authors, it is very unlikely any emulator will support these tricks correctly.



I don't think tandy works "faster" than CGA in this mode as they both have roughly 160KB/s REP MOVSW speed to the video area, last I checked. I could be wrong. If you're targeting 160x100, keep in mind on real CGA cards it will produce a ton of snow.

In this case, dosbox, pcem and 86box seem to emulate the CGA snow. If it looks like here, I can live with it

 

[Trixter]

Is that program running in CGA mode or is it on a Tandy? Tandys didn't have snow.

If you're scrolling and only updating the sides, then that snow does appear to be representative of what it looks like on a real CGA card (the bursts are when, I'm assuming, you're updating the edges).

 

[Mills32]

Is that program running in CGA mode or is it on a Tandy? Tandys didn't have snow.

If you're scrolling and only updating the sides, then that snow does appear to be representative of what it looks like on a real CGA card (the bursts are when, I'm assuming, you're updating the edges).

It is working with CGA card (Dosbox), tandy did not show any snow. I'm updating a column and a row when a counter reaches 8, so the snow bursts represent the updates. Row updates are not visible because I reduced the Y resolution to 92 lines, I'll have to test how a real monitor handles that, but it should be ok, because the vertical sync and the update rate were still working at 60 fps.

There is also a bit of constant snow at the top part of the screen, because the sprite is always being drawn and erased.

I used this CGA mode instead of a tandy one, because it makes scrolling very easy, and that tandy mode with two pages is not emulated well, so it is difficult to test.

 

[Trixter]

I'd say that snow is representative of what you'd see on a real card, so you can keep doing what you're doing. Reducing rows to 92 is compatible with real hardware, you should be fine.

 

[Mills32]

I managed to solve the wrapping vram problem in tandy by just adding some "and" instructions in the tile drawing function. For "sprites" I had to add some checks every scanline, but it is fast enough for the slowest cpus. This seems to work well on every emulator I tested, it probably looks ok on real hardware, because there is nothing special in the code, just "movsw", "and" etc:




Testing other things, I wonder if you can change the vram start address every scanline with the tandy chip, to make weird effects like on cga demos (area 5150, 8088mph).

 

[GloriousCow]

Sorry for the somewhat-necropost, but I'm working on Tandy 1000 emulation in MartyPC and would love to test to see if this program works. Do you have an updated version you could share?

I managed to solve the wrapping vram problem in tandy by just adding some "and" instructions in the tile drawing function. For "sprites" I had to add some checks every scanline, but it is fast enough for the slowest cpus. This seems to work well on every emulator I tested, it probably looks ok on real hardware, because there is nothing special in the code, just "movsw", "and" etc:

View attachment 1255381


Testing other things, I wonder if you can change the vram start address every scanline with the tandy chip, to make weird effects like on cga demos (area 5150, 8088mph).