Wait state generator inhibit

[matthew180]

I was thinking (dangerous, I know)... Without looking at the schematics yet, does anyone know what would be required to prevent the wait-state generator from being active during VDP access? I know Thierry has details about turning it off all together, but that mod is pretty serious. I was thinking that it would be nice to have an *easy* modification that would disable the wait-states only during VDP access. A solderless solution would be ideal. Possible?

[marc.hull]

I was thinking (dangerous, I know)... Without looking at the schematics yet, does anyone know what would be required to prevent the wait-state generator from being active during VDP access? I know Thierry has details about turning it off all together, but that mod is pretty serious. I was thinking that it would be nice to have an *easy* modification that would disable the wait-states only during VDP access. A solderless solution would be ideal. Possible?

 

I think it's cast in hardware. But perhaps a serious conversation between you and your console might do the trick .

[matthew180]

Heh. Yeah, well, I've spent 28 years in a conversation with my computer... Tired of that. I would prefer to collaborate with a real person (or persons) on something.

[marc.hull]

Heh. Yeah, well, I've spent 28 years in a conversation with my computer... Tired of that. I would prefer to collaborate with a real person (or persons) on something.

 

Well all right.....

 

The truth be told the memory access itself triggers the wait state generator in hardware. I don't think you could defeat this in software but if it could be done then the guy to ask is Jeff Brown. He is active on the new Yahoo group and knows the the silly beast inside and out. Barring him some of the Geneve guys (Tim) may have a clue. Personally I think it will take a knife and a threatening posture to convince the TI to ignore a basic instinct such as this but if your not into that then......

[Tursi]

It's not solderless, for sure. I spent a lot of time studying Thierry's notes on the wait state generator when I wrote my documentation on how the 16-bit 32k mod did its work. At any rate in that document I describe how the mod rewrites the wait state generator logic, that shows us with pin we need to set to inhibit it. Probably we could mask in the VDP access enable pin (since it's already decoded) to that circuit, though I think we will need an additional logic gate and a cut trace (in the same way that the 32k mod needs a cut trace to change the wait states).

 

Let me know if Jeff can't help you.

[matthew180]

What I was thinking was something like a small circuit board with a CPLD on it that would watch for the proper decode signals from the existing decode logic, and then pull a pin or two high or low as necessary to prevent the wait state from triggering. Logic levels can be over-ridden easy enough with pull up/down resistors, coupled with a FET or a tri-state buffer to isolate the circuit when no VDP access is going on.

 

If the required signals to watch / over-ride is small enough (2 to 4), then maybe some sort of "clip" could be used to tie to the pins on the necessary chips... Just some thoughts.

[marc.hull]

What I was thinking was something like a small circuit board with a CPLD on it that would watch for the proper decode signals from the existing decode logic, and then pull a pin or two high or low as necessary to prevent the wait state from triggering. Logic levels can be over-ridden easy enough with pull up/down resistors, coupled with a FET or a tri-state buffer to isolate the circuit when no VDP access is going on.

 

If the required signals to watch / over-ride is small enough (2 to 4), then maybe some sort of "clip" could be used to tie to the pins on the necessary chips... Just some thoughts.

 

And that's easier than busting out your hot iron ????

 

 

BTW those little clip on deals.... They really suck after a period of time ! Your better off with an x-acto knife and my Radio Shack soldering iron. Seriously Matthew............

[+OLD CS1]

BTW those little clip on deals.... They really suck after a period of time ! Your better off with an x-acto knife and my Radio Shack soldering iron. Seriously Matthew............

 

Might depend on the clip and quality. I have had the clips on an Amiga Kickstart switcher break. They were awkward to start, anyway, not wanting to hold onto the chip pin at a usable angle, shifting, etc. On my two MegAChips, however, the clips are just fine.

[marc.hull]

BTW those little clip on deals.... They really suck after a period of time ! Your better off with an x-acto knife and my Radio Shack soldering iron. Seriously Matthew............

 

Might depend on the clip and quality. I have had the clips on an Amiga Kickstart switcher break. They were awkward to start, anyway, not wanting to hold onto the chip pin at a usable angle, shifting, etc. On my two MegAChips, however, the clips are just fine.

 

So really what's better, those "operation" clips or soldered connections?

[+OLD CS1]

Might depend on the clip and quality. I have had the clips on an Amiga Kickstart switcher break. They were awkward to start, anyway, not wanting to hold onto the chip pin at a usable angle, shifting, etc. On my two MegAChips, however, the clips are just fine.

 

So really what's better, those "operation" clips or soldered connections?

 

Depends upon who is doing the installation. I would suspect that most of us can sling a soldering iron with some level of competence. I find myself too lazy at times. My opinion on the matter is to include the clip, and anyone who might not want to use it can remove the wire and solder it, so long as it does not increase cost significantly.

 

BTW, just to make sure we are talking about the same thing, I mean these kinds of clips and not the regular alligator clips.

[matthew180]

Yes, something like those clips, but maybe with some *bite*. Personally I don't have any problem with a soldering iron, but I also know that if you want a lot of people to use your stuff, it needs to be user friendly enough that most people could install it. I think installing the F18A might be the first time some 99/4A users will see the inside of their computer, and simply pulling the VDP from its socket might scare the hell out of some. Maybe not, I really don't know.

 

I'm also looking for ways to improve the system without making it potentially incompatible, and squeezing a little more speed out of the VDP interface seems like a good place to get some benefit without really many adverse side affects.

[Tursi]

What I was thinking was something like a small circuit board with a CPLD on it that would watch for the proper decode signals from the existing decode logic, and then pull a pin or two high or low as necessary to prevent the wait state from triggering. Logic levels can be over-ridden easy enough with pull up/down resistors, coupled with a FET or a tri-state buffer to isolate the circuit when no VDP access is going on.

 

If the required signals to watch / over-ride is small enough (2 to 4), then maybe some sort of "clip" could be used to tie to the pins on the necessary chips... Just some thoughts.

 

It's only possible to override the signal on the board if your new signal has a stronger drive. For instance, if a pre-existing signal uses a pull-up resistor, you can use a smaller resistor or none at all to force the signal the other way.

 

However the signals between the 74-series chips that control when the when state generator is invoked are direct connect, full current. If you pull the line the other way then you will have two full-on drivers on that line and likely will burn something out.

 

A CPLD is overkill for this either way. All you're going to be doing is a single AND or an OR operation (I don't have time to check the notes or I'd have given you the circuit already). One cut trace and one 74LSxx chip, and likely 3 wires, will do it.

 

I think it's a neat idea, too. A nice place to change performance of the system. Of course the code will suddenly have to be more careful about overruns, since it will definately be possible without the wait states in place.

[+OLD CS1]

I think it's a neat idea, too. A nice place to change performance of the system. Of course the code will suddenly have to be more careful about overruns, since it will definately be possible without the wait states in place.

 

I thought part of his original problem with the F18A was that it ran faster than the system. Given that, would there really be a worry about the CPU without wait states over-running the F18A, since the F18A could easily graph the rise and fall times of the signals coming from the 9900?

[matthew180]

A CPLD is overkill for this either way. All you're going to be doing is a single AND or an OR operation (I don't have time to check the notes or I'd have given you the circuit already). One cut trace and one 74LSxx chip, and likely 3 wires, will do it.

 

Yeah, a CPLD probably is overkill, I was just tossing around thoughts. If a logic gate or two is all that is required, then this would be a nice little mod kit.

 

I think it's a neat idea, too. A nice place to change performance of the system. Of course the code will suddenly have to be more careful about overruns, since it will definately be possible without the wait states in place.

 

Well, the built in routines, which most software uses, are already slow enough because they assumed the system could *already* overrun the VDP, so they have NOP or SWBP instructions in the proper places. I think we could sneak in such a mod and not cause any adverse side affects. It would be fun to try anyway. Access to the VDP is one place where more speed is always welcome, and I can't imagine anyone used VDP access in timing loops.

[matthew180]

I think it's a neat idea, too. A nice place to change performance of the system. Of course the code will suddenly have to be more careful about overruns, since it will definately be possible without the wait states in place.

 

I thought part of his original problem with the F18A was that it ran faster than the system. Given that, would there really be a worry about the CPU without wait states over-running the F18A, since the F18A could easily graph the rise and fall times of the signals coming from the 9900?

 

The F18A can't be overrun until you hit between a 25MHz and 50MHz system clock for your CPU. Tursi was talking about overruns on a real 9918A.

[+OLD CS1]

Well, the built in routines, which most software uses, are already slow enough because they assumed the system could *already* overrun the VDP, so they have NOP or SWBP instructions in the proper places.

 

The more I read about how the 99/4A was crippled, the more aggravated I get about it. I never understood why my 1MHz 8-bit machine could run rings around my 3MHz 16-bit machine. It just seemed to defy logic.

 

he F18A can't be overrun until you hit between a 25MHz and 50MHz system clock for your CPU. Tursi was talking about overruns on a real 9918A.

 

Ah. I must have misread the start of this line of thought, then. I thought you were talking about including wait-state defeating functionality in the F18A.

[matthew180]

Well, I would like to have included it with the F18A, but there is nothing you can do from the VDP socket to inhibit the wait states. It will require picking up a few signals on the motherboard in strategic places, and preventing the wait-state circuitry from triggering when the VDP is being addressed.

[Tursi]

Well, the built in routines, which most software uses, are already slow enough because they assumed the system could *already* overrun the VDP, so they have NOP or SWBP instructions in the proper places. I think we could sneak in such a mod and not cause any adverse side affects. It would be fun to try anyway. Access to the VDP is one place where more speed is always welcome, and I can't imagine anyone used VDP access in timing loops.

 

Yeah, I can't see it having a serious impact on any existing software (except that even that software should run slightly faster, depending on how often it accessed VDP).

 

It's not that I needed another project, but I'm curious to try this.

 

In taking a very quick look at things... the 9918 seems to have two chip selects, separate ones for read and write - !CSR (15) and !CSW (14). So we'd need both of those, and they are active LOW.

 

The trace we need to cut is the pin between U606 (74LS00) and U605 (74LS32) - this is the same pin that you need to cut for the 32Kx16bit speedup mod. (Have a look at Mainbyte's page (http://www.mainbyte.com/ti99/16bit32k/32kconsole.html) as he describes the cut with pictures. When this trace was low, the multiplexer and wait state generator would respond. When high, it would ignore that cycle. U606 provides the source of the signal, while U605 receives it.

 

It seems like this is correct understanding. Theirry notes: "This might seem strange since all these devices have 8-bit ports and could thus be hooked to half the 16-bit bus, upstream of the multiplexer. This is indeed the case for the VDP, yet multiplexing still occurs when accessing the VDP: a special circuit prevents the multiplexer from answering when data is read from the VDP." I think we can safely ignore that extra circuit.

 

We can simplify the truth table a bit. We know that anytime CSW or CSR are low, that the U606 should be outputting low to enable the multiplexer and wait states. We also know that only CSW or CSR can be low at any given time. It's kind of a pain dealing with separate CSW and CSR pins, though. Looking at the schematic, though, we're a little bit out of luck. These signals are generated by U505, a 74LS138 that decodes the >8000 block of memory. Pin 13 is low for >8800 (VDP read) and pin 12 is low for >8C00, later combined with the write line for VDP Write. So the truth table looks like:

 

U606 !CSR !CSW OUTPUT

1 1 1 1 (no vdp access, pass through U606 state)

0 1 1 0 (no vdp access, pass through U606 state)

0 0 1 1 (vdp access, disable multiplexer)

0 1 0 1 (vdp access, disable multiplexer)

 

So we want high except for the specific pattern 0/1/1 (too bad for that darn inversion). The 32k mod uses a clever trick to solve this sort of issue -- it uses a multiplexer (74LS153) with the inputs wired for the desired result. But the LS153 only has two bits for input, so it's not the one here.

 

Seems to me OUT = NOT ((NOT U606) AND CSR AND CSW) -- we need to simplify that logic a bit or it will take two chips.

 

Disclaimer: nothing above proven, this is just my first pass through it.

[+OLD CS1]

Well, I would like to have included it with the F18A, but there is nothing you can do from the VDP socket to inhibit the wait states. It will require picking up a few signals on the motherboard in strategic places, and preventing the wait-state circuitry from triggering when the VDP is being addressed.

 

It would require a little more space on the board, but those signals you have to pick up from the board could be taken by clip, wire to the board then processed there as needed. I might be thinking too much.

[matthew180]

It's not that I needed another project, but I'm curious to try this.

 

I need another project like I need a hole in the head. I usually keep my random thoughts in check, but this time the idea slipped out of my fingers before I could stop it.

 

In taking a very quick look at things... the 9918 seems to have two chip selects, separate ones for read and write - !CSR (15) and !CSW (14). So we'd need both of those, and they are active LOW.

 

Yup. !CSW, !CSR, and MODE. Those drive the CPU I/O state machine in the VDP. One one can be low at a time. Having both of them low is an illegal state.

 

Disclaimer: nothing above proven, this is just my first pass through it.

 

That's a good first pass! I'm going to try and give it some serious attention today and maybe even modify a real console.

[marc.hull]

That's a good first pass! I'm going to try and give it some serious attention today and maybe even modify a real console.

 

Do you mean drop the f18 into a console or...... do the wait state defeat mod using (gasp) wires and a cut trace or both ??? Come to the dark side Matt. Come to the dark side

 

If you need me to send you some spaghetti wire a rusty pocket knife then just say the word.

 

 

How about a video when you get it installed with the DSUB.... please