IntroJR demo modified to work properly on Tandy 1000s

[NewRisingSun]

... at least it should on the EX/SX/TX/HX/SL/TL/RL, but not the original Tandy 1000. (I have actually tried this only on a TX and an RL).

ZIP file

Maybe I'll record a video showing this running on my TX.

 

[Scali]

Could you explain exactly what you modified, and why this was necessary?

 

[NewRisingSun]

Palette (PCjr: index/data to 3DA, Tandy: index 3DA, data 3DE) and setting up the 160x100 mode (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).

 

[Great Hierophant]

Palette (PCjr: index/data to 3DA, Tandy: index 3DA, data 3DE) and setting up the 160x100 mode (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).

This explanation explains why it will not work on a Tandy 1000/A/HD. The video gate array chip found in these machines does not implement the register at 3DD. I do not know if these machines may implement the behavior at 3DF which allows this unpatched demo to display properly on a PCjr. There are other differences in the graphics implementation between IBM and Tandy's systems that could conceivably break a program designed solely for the PCjr.

 

[NewRisingSun]

I do not know if these machines [Tandy 1000/A/HD] may implement the behavior at 3DF which allows this unpatched demo to display properly on a PCjr.

They do not. 3DF bit 6, which on the PCjr determines whether video memory address bit 13 is substituted with row address bit 0, is ignored on the Tandy 1000(A). Instead, this behavior is controlled by bit 1 of I/O address 3D8, which on the CGA just enables the four color graphics mode. Tandy had to do this for register-level CGA compatibility. If they had implemented I/O address 3DF exactly as on the PCjr, Digger would fail, as it ignores BIOS and sets graphics mode entirely through register level writes and does not update 3DF since it does not exist on the CGA.

 

[Trixter]

I missed this thread, and I'm both flattered and flabbergasted! My reactions:

- Next time, ask me for the source code! (could have saved you a lot of relocation work)

- You're lucky I didn't use the hardware VINT, which would have made your patch impossible. I did at first, but then I wanted more CPU time for the middle area stuff so I set up IRQ0 to fire right when the visible area ended. Had I not included cpu-heavy content, the original idea was to use VINT (IRQ5) for the music and scroller, and IRQ0 for the raster bars. Because the raster bars are CPU waitloop-timed, they are "dirty" on one edge due to jitter, something we tried to hide at one point using static graphics.

Palette (PCjr: index/data to 3DA, Tandy: index 3DA, data 3DE) and setting up the 160x100 mode (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).

I don't seem to have the tech refs that explain what all of 3DD's bits do; anyone got a link?

 

[NewRisingSun]

Next time, ask me for the source code! (could have saved you a lot of relocation work)

But then I would have to install Turbo Pascal, which would have been more trouble than patching the relocation table.

You're lucky I didn't use the hardware VINT, which would have made your patch impossible

Why is that? Tandys have a VINT at IRQ5 as well. People just choose to disable it to run their cheesy little hard disk controllers at IRQ5.

 

[Trixter]

But then I would have to install Turbo Pascal, which would have been more trouble than patching the relocation table.

Touche! It's about 90% asm, but the other 10% would have proven annoying for you.

Why is that? Tandys have a VINT at IRQ5 as well. People just choose to disable it to run their cheesy little hard disk controllers at IRQ5.

Correct, but it's more than that: The Tandys that can emulate the 160x100 trick don't have a hardware VINT (it was removed fairly early on IIRC), and the Tandys that can do the hardware VINT can't emulate the 160x100 trick.

The loss of the 100-line hack isn't fatal; there's just a blank line between every other on-screen line when running on a Tandy.

If you're feeling adventurous/bored, ShakeJR could use a patch. I just checked the source and it doesn't use the hardware VINT either (although it used to at one point in its development; I don't recall why I switched it to a software VINT).

 

[NewRisingSun]

Correct, but it's more than that: The Tandys that can emulate the 160x100 trick don't have a hardware VINT (it was removed fairly early on IIRC), and the Tandys that can do the hardware VINT can't emulate the 160x100 trick.

My TX can do 160x100 and has the video IRQ; I'm using it for my split-screen 160x200 top, 320x200x4 bottom stuff right now. Based on tests, Cloudschatze's TL can do 160x100 and has the video IRQ as well, and the same applies to his RL (from 1990). I'm curious where people are getting this idea that the video IRQ was ever removed, as opposed to just disabled by jumper.

 

[Trixter]

I'm curious where people are getting this idea that the video IRQ was ever removed, as opposed to just disabled by jumper.

I always assumed that was the case! Now you've got me thinking about how I came under this impression, and I don't have an answer. I have confused myself.

To make sure I wasn't going crazy, I decided to look at my (incomplete) tech ref collection to verify for myself if a system had IRQ5 tied to vertical sync. Results:

• Tandy 1000 EX: Yes (looks like it cannot be disabled?)
• Tandy 1000 HX: Yes (looks like it cannot be disabled?)
• Tandy 1000 SL: Yes
• Tandy 1000 SX: Unknown. Ref manual states "Interrupts 5 - 7 are connected through a switch to the system board function listed, and are also connected to the expansion bus. To use interrupt 5, 6, or 7 on the bus, the system board function must be disconnected (set the appropriate switch to off)."
• Tandy 1000 TX: Yes (interestingly, denotes "off" as "external sync")
• Tandy 1000 TL: Yes

So, I consider myself corrected, although it would be interesting to know if the TL/RL models that came with hard drives also had IRQ5 routed to sync. I don't know how their hard drive interfaces are set up.

I guess if I wanted to make a truly unpatchable PCjr program, I'd have to get sneaky. For example, writing directly to the first 128KB of RAM to update video, as opposed to using b800h and the paging registers. That would be much more time-consuming to patch around, I think.

I'm using it for my split-screen 160x200 top, 320x200x4 bottom stuff right now.

You buried the lead! Making a game?

 

[Great Hierophant]

The Tandy 1000's Tech Notes & Jumper Manual Volume 1 gives a video IRQ disable jumper or dipswitch for every model of the 1000 series with Tandy Video, except for the 1000/A/HD/EX/HX. I would note that although the manual indicates that the IRQ assignment is switched from IRQ5 to IRQ2, if you look at the schematics in the available Technical References, you will find that is not the case. In these instances, the jumper merely disconnects the IRQ5 signal to the video chip.

Does anyone know of any software that uses IRQ5 with Tandy Graphics or even PCjr. Graphics? No software has ever given me difficulty on my Tandys which I could trace to the video IRQ. Tandy says that some software won't work correctly if the IRQ is not enabled, but did not identify specific software titles.

My SX can also do Trixter's 160x100 double scan mode as implemented by NRS's patch.

 

[Great Hierophant]

I always assumed that was the case! Now you've got me thinking about how I came under this impression, and I don't have an answer. I have confused myself.

To make sure I wasn't going crazy, I decided to look at my (incomplete) tech ref collection to verify for myself if a system had IRQ5 tied to vertical sync. Results:

• Tandy 1000 EX: Yes (looks like it cannot be disabled?)
• Tandy 1000 HX: Yes (looks like it cannot be disabled?)
• Tandy 1000 SL: Yes
• Tandy 1000 SX: Unknown. Ref manual states "Interrupts 5 - 7 are connected through a switch to the system board function listed, and are also connected to the expansion bus. To use interrupt 5, 6, or 7 on the bus, the system board function must be disconnected (set the appropriate switch to off)."
• Tandy 1000 TX: Yes (interestingly, denotes "off" as "external sync")
• Tandy 1000 TL: Yes

The SX's jumpers act very simply. Remove a jumper and you disconnect the IRQ line from the 8259 to the appropriate chip. The answer is Yes. HXs and EXs did not implement this feature because of their unique PLUS form factor, only IRQ2 hard disk controllers were anticipated.

I guess if I wanted to make a truly unpatchable PCjr program, I'd have to get sneaky. For example, writing directly to the first 128KB of RAM to update video, as opposed to using b800h and the paging registers. That would be much more time-consuming to patch around, I think.?[/COLOR]

That would narrow down the number of systems that could use your program quite a bit, but not completely. A Tandy 1000 with 128KB of RAM should behave in the same way as a PCjr. with 128KB of RAM in this regard. Better to time your program to the slower PCjr. 128KB standard than the Tandy 128KB standard and let things go nuts at the faster speed. Or if you wanted to be truly Evil, put your program on a cartridge with hard coded memory accesses.

 

[Trixter]

Or if you wanted to be truly Evil, put your program on a cartridge with hard coded memory accesses.

That could be patched around more easily than you think. (I could do it, which means NRS could do it faster. ) I think the only unpatchable, PCjr-only software would have to make use of the BIOS ROM contents *and* write to the first 128K for updating video memory *and* use all 128KB RAM to not make room for a copy of the PCjr BIOS data. And even writing that just now, I can see how it can be patched (although "patch" is overloaded in this case as you'd be relocating every segment, embedding a copy of the PCjr BIOS ROM, requiring a 256KB system, etc.).

I think your idea of making it speed-sensitive is the only way to make a PCjr-only program, although I can't immediately think of a way to get a speed difference to *crash* the program, only make it run oddly/slower.

This conversation is threatening to delve into copy-protection territory.

 

[NewRisingSun]

You buried the lead! Making a game?

No, just converting games that use composite artifacting to using 16 color RGBI graphics. By switching modes mid-screen, I can get sharp text and nice color without rewriting all graphics routines from 320x200x4 to 320x200x16 mode.

For example, writing directly to the first 128KB of RAM to update video, as opposed to using b800h and the paging registers. That would be much more time-consuming to patch around, I think.

I am experienced at patching that situation: Some Tandy games write directly to (total memory size minus 32K) instead of using B800h and the paging registers. These games fail to work on a 768K Tandy 1000, because that one only allows access to video memory at B800.

Starting with the TL, video memory can be arbitrarily moved around using just software, by writing to I/O addresses FFE8 and FFEA (plus FFEE in the RL). Even a temporary 128K configuration can be set up in software this way. But all pre-TL models require disabling the additional memory using jumpers --- just writing to the memory configuration register at I/O address A0h won't do the trick, as it merely moves around video RAM without disabling system RAM.

Does anyone know of any software that uses IRQ5 with Tandy Graphics or even PCjr. Graphics?

Tandy: Super Boulder Dash, Touchdown Football, Demon Attack, Ghostbusters. PCjr: All the previous ones plus Pitfall 2. (These are the ones I checked, there are likely others.)

This conversation is threatening to delve into copy-protection territory.

You're saying that like it's a bad thing.

 

[Trixter]

You should put all of your Tandy patches in a single place so that Tandy owners can benefit. I can grant you read/write access to the tvdog archive if you like.

You're saying that like it's a bad thing.

Oh, it's not I was just noting the similarity between both discussions (ie. trying to ensure a program will only run in specific conditions).

 

[NewRisingSun]

I don't seem to have the tech refs that explain what all of 3DD's bits do; anyone got a link?

Only bit 0 is of importance; it enables the "extended addressing mode". The other bits control an extended video memory size of 256K rather than 128K, which only the EX, SX and HX support and is useless anyway (who needs that many pages?). "Extended adressing mode" basically changes the meaning of bits 6 and 7 of 3DF.

• 3D8 bit 1=0, 3DD bit 0=0, 3DF bit 7=0, 3DF bit 6 ignored: fully linear video memory, used only in BIOS text modes.
• 3D8 bit 1=1, 3DD bit 0=0, 3DF bit 7=0, 3DF bit 6 ignored: Row Address bit 0 selects one of two 8K banks within video page. Used in 320x200x4, 640x200x2 and 160x200x2 modes. Reason: the original MC6845's vertical displayed register was only 7 bits wide and thus could not count to 200 rows. Hence, it is programmed to 100 rows with 2 scanlines per row.
• 3D8 bit 1=1, 3DD bit 0=0, 3DF bit 7=1, 3DF bit 6=1: Row Address bits 0 and 1 select one of four 8K banks within video page. Used in 320x200x16 and 640x200x4 modes. Reason: same as above, plus the original MC6845 only has 14 bits for the video memory address. Hence, it is programmed to 50 rows with 4 scanlines per row.
• 3D8 bit 1=1, 3DD bit 0=0, 3DF bit 7=1, 3DF bit 6=0: Row Address bit 1 selects 16K bank within video page. No practical use known.
• 3D8 bit 1=1, 3DD bit 0=1, 3DF bit 7 ignored, 3DF bit 6=0: fully linear video memory, not used by any BIOS mode. Can be used to create a fully linear 160x200x16 or 320x200x16 mode by setting the Maximum Scanline register to 0, the Vertical Displayed register to 200 and the rest accordingly. This is possible as the EX and later Tandys use a 6845 clone with an 8 bits wide row counter and 15 bits for video memory address. When not updating the Maximum Scanline register as described, a 160x100 or 320x50 mode is created.
• 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.

On the SL/TL/RL, 3DD does not exist at all; its function has moved to 3DA/3DE index 5 bit 0. So it's a good idea to update both registers for compatibility, and to reset them when finished, as the SL/TL BIOS does not reset them when changing video modes.

 

[Trixter]

The other bits control an extended video memory size of 256K rather than 128K, which only the EX, SX and HX support and is useless anyway (who needs that many pages?).

ho HO!! *I* can think of a use for 256K' worth of pages! (rubs hands in glee). Methinks there might be an EX/SX/HX-only demo at some point in the future.

This info has been copied and bookmarked, thanks for the info!

 

[Great Hierophant]

Only bit 0 is of importance; it enables the "extended addressing mode". The other bits control an extended video memory size of 256K rather than 128K, which only the EX, SX and HX support and is useless anyway (who needs that many pages?). "Extended adressing mode" basically changes the meaning of bits 6 and 7 of 3DF.

The TX should also be included, shouldn't it? It contains the "Big Blue" graphics chip and its Technical Reference indicates it supports "Extended addressing mode".

 

[NewRisingSun]

The TX has the Big Blue graphics chip, but only supports 128K of video RAM. The chip alone does not determine the video RAM size; it also has to be connected in the proper way. The Big Blue chip even has provisions for 512K of video RAM, but no system into which it is built connects it that way.

Re-reading the SX technical reference manual, I'm not even sure if the SX supports 256K video RAM. On the EX and HX, it's clear: the standard 256K on the system board are all video memory. All expansion RAM is separate and inaccessible to the video chip.

The TX on the other hand has fixed 128K video memory and 512K or 640K of system memory, for a total of 640K or 768K of memory. Enabling the various 256K video RAM bits does nothing on the TX. How the SX performs in this regard can only be found out from experimentation --- the TX Technical Reference manual reuses portions from the EX manual without noting that they don't apply, and I would suspect the same is the case for the SX. What makes me think that the SX can't do 256K video RAM either is that on page 22 of the Technical Reference, it says "The Tandy 1000 SX video interface circuitry controls 128K of memory.", just like the TX', while the EX' and HX' clearly state 256K on the respective page.

 

[Trixter]

On the EX and HX, it's clear: the standard 256K on the system board are all video memory. All expansion RAM is separate and inaccessible to the video chip.

Does that mean the video memory on an EX and HX is in a fixed location between segments 0000h-3FFFh?