Missiles DMA

[MaPa]

HI, I have a question... what will happen if I'll set up PMG (both players and missiles) but will enable DMA only for players by "poking" value 42 ($2a) into 559 ($22f). It should set standard playfield, enable dlist DMA and enable player DMA but no missiles. In atari800win emulator it just reads missiles data regardless of missile DMA enabled/disabled and I have screenshot from real HW (I assume the setting of 559 register was not altered) where the missiles are shown correctly too (in this case visible only missiles 0&1 with data $1f in whole missile pmg area). I can't test it on real HW but I just heard rumor that GTIA does something like that it uses default value of $0f in some cases... is it true? What will happen with that setting? Jesus I hope you understand

[Rybags]

According to the official Atari Hardware Manual, you can enable missile DMA only but if you enable Player DMA, Antic will also fetch the missile data.

 

Also, Antic reads the 1 or 5 bytes per scanline regardless of if it's doing 1 or 2-line resolution.

 

All VDELAY does (inside GTIA) is tell it not to reload the graphics registers on even scanlines.

 

The player and missile data registers are stuffed with zeros by the OS during warm/coldstart. I think that they might contain random data in some cases on powerup. You sometimes see a stripe or two when powering up an XL machine (there is some lag on startup since it does the full "quick" memory test/POST).

 

When you enable GTIA to have it's DMA via GRACTL, all that is doing is telling GTIA that it should listen to the data bus on the relevant cycles when Antic normally fetches the PMG data.

 

That's why you can get the random looking checker patterns - it's not random, but is whatever data happens to be sitting on the data bus at that cycle.

There's a seperate thread somewhere - I tested all this (as have many others). IIRC, Antic will fetch the Display List instruction during the cycle it normally does the Missiles if PMG DMA isn't enabled.

[analmux]

...That's why you can get the random looking checker patterns - it's not random, but is whatever data happens to be sitting on the data bus at that cycle....

 

Indeed. I always wondered though, what causes this checker-pattern to have the same vertical resolution as the display-list-setup, i.e. ...when you have gr.0 then the pattern is 8 scanlines high. Thus it stays constant for 8 scanlines. In gr.8 the pattern is 1 scanline high.

 

especially the case of gr.0: the data on the bus should change every scanline, but PM DMA is off, thus Antic does not fetch any bytes, but GTIA does read the bus, but what causes the GTIA to do this only once every 8 scanlines, and not every scanline. How does the GTIA know that a new graphics line starts?

 

...or does the secret lie in internal bus commands from antic to gtia (AN0-2)??

Edited May 28, 2008 by Analogue Multiplexer

[Rybags]

I think some synchronisation logic must be in place (?) It also applies to Blank line instructions.

 

Probably GTIA sees Antic doing it's Missile DMA cycle, so it knows to snoop the data bus. You can kinda prove that too by setting VDELAY.

 

You can see proof that Antic takes the opportunity to use that cycle for the Display List if PMG DMA isn't enabled ($D400) - the Missiles will assume the bitmap defined by the DList instruction. And Player 3 will contain one of the bytes of the operand if it's a 3-byte instruction.

 

I worked some of that stuff out when playing with forced multiple loads of the graphics registers. With the right timing you can just execute a dummy LDA $abcd type instruction and it will load a couple of the data registers.

[Rybags]

Just saw your edit.

 

I think you could probably further prove my theory with a DLI that turns off Display List Instruction fetch.

In that case, Antic would just repeat the same graphics mode.

 

If the checker pattern disappears then it would be evidence of the theory.

 

I don't think the AN0-AN2 commands are any different for the first line of a graphics mode. All it has is Vertical Sync, 2 Horizontal Blank commands (set 40 chr/clear 40 chr) then 5 devoted to BG and PFn colours.

[Rybags]

Just looking at the GTIA.PDF schematics/tech description.

 

Pin 26- HALT output. Could that be from Antic? No reason I know of for GTIA to supply that signal, but perfectly feasible for it to have it as an input.

[MaPa]

Btw. the higher bits in 559 register are unused and does not matter what is set there? So putting i.e. 34 (for standard setting) in 559 is the same as 98 (34+64) or 226 (34+64+128) or 162 (34+128) ?

[Rybags]

DMACTL

 

Bits 7,6 unused.

Bit 5 1=enable Display List Instruction Fetch

Bit 4 1=enable single line PMG resolution

Bit 3 1=enable all PMG DMA

bit 2 1=enable Missile DMA

bits 1,0 Playfield DMA type 00=none 01=narrow 10=standard 11=wide

 

 

Screenshot with PMGs enabled and placed P0-P3, Missiles M3,M2,M1,M0. Display List Interrupt running (part of the listing in screenshot).

 

PMG DMA is disabled on Antic, GRACTL set to 3 in GTIA (allow PMG graphics register loading).

The DLI disables Antic's DList instruction fetches for a period (which is visible in the PMGs where the data remains static in the bottom half of screen)

 

As you can see, that then means that the data in the PMG graphics registers remains static. Seems to prove that GTIA relies on the DMA occuring in the cycle allocated to the missiles to know when it should reload the graphics registers.

 

Also proves that a WSYNC allows the next instruction to start to execute. The Players are loaded with graphics data value = $8C, which is the STY instruction.

All 4 players have the same data since the RDY is asserted on the 6502, so the instruction code remains on the data bus.

 

Observe the missiles - they reflect the Display List instructions: $42 for the first text line, $02 for most of the rest, $82 where the DLI is, and $41 for the JVB at the bottom.

 

Also, Antic uses the DMA slot normally reserved for doing Player 3 for fetching the low address operand of the DList instruction when PMG DMA isn't enabled ($40 in the first text line, and $20 in the JVB in the bottom border).

[analmux]

So, to summarize:

 

If GTIA register 'GRACTL' (53277) is 3 (player&missile bus access enable), then GTIA will check if _HALT is low. If true, then GTIA will read the bus. This happens to be the case when Antic does no PM DMA but a DList instruction fetch, so GTIA is fooled?

 

Sounds like a quite good explanation to me

[Rybags]

Sounds reasonable to me also. Explains why you get the checker pattern which always coincides with Display List fetches.

 

I checked the schematics in the Hardware Manual - GTIA does receive the Halt input from Antic.

 

Kinda strange though - you'd reckon that GTIA would have the logic anyway to remain in sync with Antic and "know" when certain events are supposed to happen.

 

Probably explains too why you can have Antic doing Missiles for you and nothing else, but not Players and nothing else. It has to use that cycle as a "notification" that things will be updated.

 

No idea though why they use those 2 cycles to get the DList data early. Especially the address part of DL instructions - why not just fetch it on Player 0 and 1's DMA cycle rather than have the 3 cycles beforehand free?

 

I'm thinking that they probably had seperate teams engineering each chip, so maybe things were engineered that way to be doubly safe that they'd interface correctly.

 

But, maybe GTIA isn't as "smart" as we'd give it credit for. You can mix and match PAL/NTSC Antics and GTIAs in a system, can't you?

There must also be some sort of logic inside GTIA for handling the time before/after VBlank - the display is always black, not background, which doesn't really seem to correspond to any specific input from AN0-AN2 (unless Antic holds it at the "Vertical Blank" value for that entire period).

[Rybags]

<dbl post>

Edited May 30, 2008 by Rybags

[analmux]

Kinda strange though - you'd reckon that GTIA would have the logic anyway to remain in sync with Antic and "know" when certain events are supposed to happen.

 

Then maybe we could say that it's some kind of hardware 'bug'.

 

All that happens is that, even when Antic's PM DMA is off, and GTIA has GRACTL enabled, GTIA ignores the bus when HALT not low on the critical cycle. It sounds even quite reasonable to block GTIA from reading the bus. I suppose it could be a mismanagement of Antic design. Why should a displaylist command read be done some cycles earlier when PM DMA is off??

[1050]

I just wanted to add that in my 1985 Rockwell Data Book the HALT signal does not exist for any 65xx microprocessor offered so it must be an Atari "Sally" exclusive input signal? Although DMA is mentioned in passing it is not really discussed at all.

 

The RDY (Ready) input signal is used to "allow the user to halt or single cycle the microprocessor on all cycles except write cycles. A negative transition to the low state during or coincident with phase one will halt the microprocessor with the output address lines reflecting the current address being fetched. If Ready is low during a write cycle, it is ignored until the following read operation. This condition will remain through a subsequent phase two in which the Ready signal is low. This feature allows microprocessor interfacing with the low speed PROMs as well as Direct Memory Access (DMA)."

 

And that is the first and last time DMA is mentioned at all...

 

However, the 6512 and only the 6512 also has a low active DBE line which is the Data Bus Enable line.

 

I've heard that Sally has some sort of logic gates in addition to what must be the HALT/DBE and/or RDY line(s), perhaps that is the reason you two find the odd, one off "wait state"?

 

In my mind, the DBE feature is not really as useful as an Address Bus Enable line would be, perhaps a Sally 6502c additionally has ABE instead of DBE? I'm thinking it MUST in order for ANTIC to be able do RAS only memory refresh with Antic suppling the addesses during refresh.

 

But in the book there is no 65xx micro like that...

 

Rybags, I wanted to make sure you had seen warerat's photos in post #73 in this thread...

XL/XE compatible Atari 800?

just interesting and generic FYI, I can draw no conclusions as yet from any of it.

[Rybags]

IIRC, Sally came about because they wanted to decrease the chip count in the XL. Previously, a couple of extra ICs were needed to decouple the bus.

 

The RDY technique (which I think the C-64 uses for all it's DMA which needs the CPU stopped) as you said potentially more cycles since it doesn't stop writes, and has to be asserted early to ensure it works.

 

I don't know if Sally has any additional logic tied into RDY - I'm pretty sure it should function exactly the same as the 6502 used in the 400/800. In any case, RDY is only used if a program writes to the WSYNC register on Antic.

[Bryan]

1050, you can look at the schematic for the CPU board in the 400/800 and see the logic that was incorporated into Sally. Basically, it can be stopped on any cycle (basically extending the first half of the cycle since writes occur in the 2nd half), and doing this also decouples the bus.

[dmlloyd]

I just wanted to add that in my 1985 Rockwell Data Book the HALT signal does not exist for any 65xx microprocessor offered so it must be an Atari "Sally" exclusive input signal? Although DMA is mentioned in passing it is not really discussed at all.

 

The RDY (Ready) input signal is used to "allow the user to halt or single cycle the microprocessor on all cycles except write cycles. A negative transition to the low state during or coincident with phase one will halt the microprocessor with the output address lines reflecting the current address being fetched. If Ready is low during a write cycle, it is ignored until the following read operation. This condition will remain through a subsequent phase two in which the Ready signal is low. This feature allows microprocessor interfacing with the low speed PROMs as well as Direct Memory Access (DMA)."

 

Right, the SALLY is an Atari custom IC with the additional /HALT line. In addition, one or two other pins are moved around a bit as well. The semantics of HALT are simply to gate the incoming clock signal (like RDY) and release the address and data busses (but not the R/W line as far as I've been able to determine).

 

However, the 6512 and only the 6512 also has a low active DBE line which is the Data Bus Enable line.

 

Also, all of the current line of 65C02/65C816/etc from WDC include a BE (bus enable) line which can be used to release the address and data busses as well as the R/W line (but not stop the clock - you have to do that separately via the clock input or RDY).

 

(Edited: typo)

Edited June 5, 2008 by dmlloyd