Jump to content
Sign in to follow this  
Kchula-Rrit

Disabling TI's Wait-State Generator

Recommended Posts

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:

1457530593_TIWaitStateStarter.thumb.jpg.7fc19c8b7e1ae044a93edb2eb0fb8953.jpg

 

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":

 

1203441966_MyWaitStateStarter.thumb.jpg.4a09309df4a0957e4fcb8aee231dd537.jpg

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Kchula-Rrit

Share this post


Link to post
Share on other sites

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.

  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites

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?

 

console_32k_ram_circuit_diagram.gif

  • Like 2

Share this post


Link to post
Share on other sites
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.

 

 

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. :)

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...