Disabling TI's Wait-State Generator

[Kchula-Rrit]

I was looking over my TI Tech manual for the past few weeks because I was thinking about building a 16-bit RAM for my console.  I've been staring at the wait-state timer, trying to figure it out.  Anyone figured out how that thing work?  I know its a shift register, but I cannot decipher everything else around it.

 

Anyway, this is what TI uses to start the wait-state timer:

 

The 74138 is on Sheet 4, and the two other gates are on Sheet 2, with the CPU and the wait-state timer.  It appears to disable the timer on accesses to memory addresses 0-FFF and >8000-9FFF.  I assume this means that the VDP and sound chips are also on the 16-bit bus.

 

I came up with this modification to disable the timer for some other addresses I'm interested in making "16-bits":

 

 

I could use this to add Low- and High-RAM on the 16-bit bus.  The only cartridge I use is the Editor/AssemIt, so I could put 16-bit RAM there, too.  Also, it would be awesome to put a DSR on the 16-bit bus, for my own evil experiments.

 

Thoughts?

 

K-R.

[+mizapf]

You need to get three states (for the cycle plus two wait states). It seems to me that this 74ls194 is a shift register that shifts a bit at QA, QB, and when it reaches QC, it is fed back to the first position, inverted.

[Tursi]

Thierry Nouspikel has a detailed teardown of the wait state generator on his page - http://www.unige.ch/medecine/nouspikel/ti99/wait.htm

 

[Kchula-Rrit]

I didn't notice that in all my wanderings through my copy of the Web-site.  After looking it over, it still seems pretty complex; have to read it again.

 

My idea above was to just generate the "start-inhibit" signal for Low and High RAM accesses, along with Cartridge RAM at >6000-7FFF.  I would leave 0-FFF and >8000-9FFF to not mess up Boot-ROM, VDP, sound, and GROM accesses.  That way, I could add 16-bit RAM to the 16-bit bus.

 

K-R.

Edited November 20, 2020 by Kchula-Rrit

[apersson850]

When I installed 64 K RAM in my console, I noticed that the warning in the E/A manual, that you need an additonal instruction, a NOP or something useful, between some VDP accesses, finally came true. For programs running from a normal memory expansion it doesn't matter. But now it did.

Only one single program I have run so far can't handle the faster memory expansion, and that's the game Tennis.

I added an LS123 timer, enabled by a CRU bit, decoded to trigger on VDP access. If I enable that, I can run Tennis in fast RAM. The computer becomes unbeatable, but the program works. Without the timer, the players, consisting of two sprites, disintegrate. The legs run in one direction and the body in another.

[Stuart]

Looks similar to what I done, but just for the low and high memory areas.

 

With your solution, might want to add a DIP switch and pullup resistors on your new U2A/B inputs so you can simply switch blocks in and out as you experiment?

 

[+FarmerPotato]

8 hours ago, apersson850 said:

When I installed 64 K RAM in my console, I noticed that the warning in the E/A manual, that you need an additonal instruction, a NOP or something useful, between some VDP accesses, finally came true. For programs running from a normal memory expansion it doesn't matter. But now it did.

Only one single program I have run so far can't handle the faster memory expansion, and that's the game Tennis.

I added an LS123 timer, enabled by a CRU bit, decoded to trigger on VDP access. If I enable that, I can run Tennis in fast RAM. The computer becomes unbeatable, but the program works. Without the timer, the players, consisting of two sprites, disintegrate. The legs run in one direction and the body in another.

I too had added the NOPs (or a SWPB for VDPWA) just like it says. Until I learned from here, that unrolled loops run ok without NOP.

 

Yamaha finally added a WAIT output on the V9958, which helps solve this in hardware. Over there, it's well documented that available write slots come up with various cycles in between.

 

 

 

 

 

[apersson850]

15 hours ago, FarmerPotato said:

I too had added the NOPs (or a SWPB for VDPWA) just like it says. Until I learned from here, that unrolled loops run ok without NOP.

Yes, usually. It's only certain sequences of accesses to the VDP, when both the code and the workspace are in 16-bit no wait state RAM that fails.

[Tursi]

Reading immediately after setting the VDP address will do it for sure. Other sequences depend on the instructions used, but are less likely. The read-before-write of the 9900 means that most write sequences are a long ways from overrun.