Dual ANTIC

[dmlloyd]

So the next thing I want to do to my 600XL is introduce switchable ANTICs so I can test PAL and NTSC stuff. I was looking over the data sheet and I thought I'd run by some ideas here to see if any ANTIC experts want to chime in (I know that some folks had done various experiments with multiple ANTICs).

 

I plan to have only one ANTIC be active at a time (the other is held offline via /RESET). I was looking at each ANTIC signal and here are my thoughts on each (going down the list on the data sheet):

 

* /RNMI - Input, tie together

* D0-7 - *should* be configured as an input while /RESET is asserted?

* R/W - *should* be configured as an input while /RESET is asserted?

* AN0-2 - Normal output - these will have to be multiplexed e.g. 74157

* Φ0 - Normal output - this will be multiplexed

* /HALT - Normal output - this will be multiplexed

* /NMI - Normal output - this will be multiplexed

* /REF - Normal output - this will be multiplexed

* RDY - Open drain output - should be OK to tie together as long as /RESET doesn't pull it low

* A0-15 - *should* be configured as an input while /RESET is asserted?

* Φ2 - Input, tie together

* FΦ0 - Input, tie together

* /LP - Input, tie together

* /RES - Input - controlled by switch

 

So it looks to me that only 7 pins need to be multiplexed, which can be accomplished with a pair of 74LS157, assuming that I'm right that all the bidirectional pins are inputs while /RESET is held. The ANTIC data sheet from the Atari Historical Society is notoriously incomplete (pages 27 through 33 are missing) but according to the TOC, all the electrical parameters pages should be present. But in these pages there is no discussion about the state of things while RESET is active. But it seems to me that it would have to relinquish the bus to avoid clashing with the CPU.

 

What do you guys think? Experts chime in!

Edited June 5, 2010 by dmlloyd

[dmlloyd]

In particular, I'm wondering whether the internal chip-select logic will "kick in" even if /RESET is asserted. Maybe I should also clamp Φ2 to 0 to keep the data bus from possibly shorting out on read operations?

[Rybags]

I don't think it'll be that simple.

 

Don't worry about /RNMI, it's only used as the System Reset key input on 400/800 so should be wired the same for a second one in XL.

 

The problem I think you'll encounter:

 

RESET to Antic doesn't hold the chip in some suspended state. Why? Well, you'll notice on XL machines that you can hold the Reset key and the machine will be suspended until you release it.

If Antic was to go into suspend, the RAM Refresh would also suspend and your machine would lose it's memory.

Also, I believe Antic retains it's video timing, so it will still be sending commands to GTIA.

 

I don't know exactly what goes into suspend when you pull RESET on Antic, but I'd suspect that all it does is suspend Display List processing and maybe a few other minor things. Stuff like RAM Refresh would still have to take place otherwise the RESET key would always perform a coldstart.

 

Maybe a better option would be to just try tying all the inputs and Address/Data buses together but have the +5 Volts only supplied to a single Antic at a time.

But even then, who knows what might happen? It might be that the entire address/data bus of the inactive chip needs to be isolated completely.

 

Another consideration - you'd still have the GTIA of the original machine, and it holds the PAL Register which the OS and other software will use to determine what machine it thinks it's running on.

[dmlloyd]

The problem I think you'll encounter:

 

RESET to Antic doesn't hold the chip in some suspended state. Why? Well, you'll notice on XL machines that you can hold the Reset key and the machine will be suspended until you release it.

If Antic was to go into suspend, the RAM Refresh would also suspend and your machine would lose it's memory.

 

Good point. So maybe I should also plan on locking Φ2 and FΦ0 as well to keep the chip from "thinking".

 

Also, I believe Antic retains it's video timing, so it will still be sending commands to GTIA.

 

The multiplexing should take care of that, since only one of the two chips' control signals will be "visible" to GTIA.

 

Maybe a better option would be to just try tying all the inputs and Address/Data buses together but have the +5 Volts only supplied to a single Antic at a time.

But even then, who knows what might happen? It might be that the entire address/data bus of the inactive chip needs to be isolated completely.

 

Yeah I thought of that but like you said, who knows what might happen... I'm hoping that I don't have to isolate every signal of both chips because that's a lot of hardware.

 

Another consideration - you'd still have the GTIA of the original machine, and it holds the PAL Register which the OS and other software will use to determine what machine it thinks it's running on.

 

Yeah that's a software problem I plan on tackling separately. The PAL register would indicate NTSC (and rightly so) because after all it's really NTSC at 50Hz. As far as the OS goes though, I have a routine which correctly calculates 50/60Hz simply by using VCOUNT and WSYNC, so I'll replace the default copy-from-GTIA with that.

 

Apart from that, NIR-PAL has been known since the 90s so hopefully modern software (games, demos) will be using an intelligent determination of frame rate rather than relying on GTIA.

 

Worst case scenario would be to use a GAL to intercept a couple bits of the GTIA address & data bus and its /CS line and have it reflect the state of whichever ANTIC is selected.

[Rybags]

The GTIA intercept for PAL register is a good idea... it'd even be worth producing in it's own right for those of us who want to run the other machine's Antic in our computer.

 

Maybe for your first attempt, just (like you said) try holding the clock inputs to certain values, it might be enough to keep the inactive Antic from interfering with things. I guess in that case you'd just maintain power to both of them.

 

Advantage there could be that you could probably swap over on the fly... just hold Reset and switch over to the other one and resume whatever was running at the time.

[dmlloyd]

The GTIA intercept for PAL register is a good idea... it'd even be worth producing in it's own right for those of us who want to run the other machine's Antic in our computer.

 

Maybe for your first attempt, just (like you said) try holding the clock inputs to certain values, it might be enough to keep the inactive Antic from interfering with things. I guess in that case you'd just maintain power to both of them.

 

Advantage there could be that you could probably swap over on the fly... just hold Reset and switch over to the other one and resume whatever was running at the time.

 

Yeah that's a cool idea. Maybe I could even latch it so you can hit the switch any time then just hit Reset to activate, or something. Maybe even software control...

[dmlloyd]

Turns out I was using "Φ" for phase when I should have been using "ϕ". Guess I'm a Unicode noob.

[Bryan]

I messed with the same idea a while back. One thing I seem to remember is that the buses are only floating when reset is asserted and the input clock is held in one state (not sure which clock input it was...). Otherwise I got stuff on the bus during half the clock.

[dmlloyd]

I messed with the same idea a while back. One thing I seem to remember is that the buses are only floating when reset is asserted and the input clock is held in one state (not sure which clock input it was...). Otherwise I got stuff on the bus during half the clock.

 

Cool. Yeah my thoughts are that just holding ϕ2 still isn't enough because you might "freeze" the clock with an address on the bus, and /RESET isn't enough because as Rybags pointed out, the refresh logic (at the least) will keep ticking. I am, however, worried that an unfortunate circumstance may arise where /REF is asserted at the exact moment the clock is frozen and /RESET is poked. So I'm thinking that maybe I'll set it up so that the clock isn't frozen until /REF comes high just in case...