Undocumented Amiga hardware stuff

[mc6809e]

Originally Posted by Toni Wilen

There is no DMA fetch conflict because copper does not need the DMA word, it just fetches it for fun if there is no one else doing the fetch during this magic COPxJMP second cycle.

I guess this was some kind of optimization in Agnus design, perhaps existing MOVE circuitry was used for COPxJMP special case.

My next test will be to set blit, started by copper and position it exactly so that blit cycle "steals" the COPxJMP second special cycle and see what happens to blitter pointers.

(and I forgot about that patent again)

EDIT: (Not sure what I was thinking about..) Blitter can't use either cycles so unexpected pointer copy shouldn't be possible.. This is probably unrelated, perhaps it is WAIT that does weird things when it is "woken" by COPJMP. More tests to do..

Wait. Maybe they are connected.

Look at Figure 4. To get the COPxLC address in the backup registers to the copper's DMA pointer register the current copper DMA pointer register has to be selected by the register address select logic so that the register can receive the new value. The output of a selected pointer register always goes two places: the adder and the output address bus. This makes sense since nearly always when a pointer is used for DMA it is also updated with a new value for the next fetch or access.

While the copper is sequentially fetching instructions, the adder is adding two each time to the pointer's address. If a strobe is performed then one input to the adder is gated-off and COPxLC from the copper backup registers passes through the adder and into the copper's DMA address register. Because the copper's DMA address register is selected, the old value contained there is still output even while the new value is being delivered back into the register. That explains the dummy copper cycles you see and the write to 1FE. There is sort of a pipeline effect created as the new value (COPxLC) moves through the adder and back into the copper's DMA address register.

I think the bug can be partly explained by assuming a WAIT turns off the copper and stops the pipeline. It's possible that this leaves COPxLC as an input to the adder with the hardware ready to take the output of the adder and load it into one of the other DMA registers when some trigger occurs.

I wonder if the effect only occurs with the blitter. The even-only cycles nature of the copper might prevent it from affecting bitplane DMA registers for four or fewer bitplane displays.

[Toni Wilen]

Ok, writing to COPJMP2 while copper is waiting: cycle usage is different!

Copper waiting (normal wait instruction in copper list)
Write to COPJMP2 (using CPU) while copper is waiting.

- 1st copper cycle: idle (does not need to be free, available for CPU or blitter)
- 2nd copper cycle: copper reads next instruction word, destination address is 0x1FE! Normal first MOVE cycle is write to 0x8c. This cycle needs to be free and is always allocated for the copper.
- 3rd copper cycle: normal first cycle from COP2LC

It looks like copy to blitter pointer happen if blitter allocated 1st copper cycle ("idle cycle"). Blitter DMA channel does not seem to matter. If allocated by A-channel, A channel pointer changes to COP2LC and so on..

I guess this mystery is mostly solved now. Still need to check what happens if for example bitplane pointer uses this cycle.

EDIT: Bitplane DMA does not seem to cause any weird behavior.

[xxxxx]

I have a question about the linedraw hardware, an idea to optimize using blitter trick, and this seems like the perfect place to do it

I am in the middle of optimizing my filled vector routine (yes, keeping it old school :-). I have drawn some lines to a temp buffer (EOR'ing in the lines), performed a fill from the temp buffer to the back buffer, and I need to clear the temp buffer again. I used to clear the lines with EOR, and that takes 8 cycles per pixel as usual, and it does a read from C and a write to D. But I was thinking, I don't really need the blitter to read the screen, and perform an operation, I am fine if it just writes $0000 to the whole memory address for each pixel in the line, rather than just clear the one specific pixel, and it works great when i set the mintern bits to $00

I was wondering what happened if I disable the C src - does it still perform the bresenham calculation properly, and trace along the line, but just not read from memory?
or would the linedraw just fail?

I don't have actual hardware anymore, so I can't test it, I work only in WinUAE now.

[source]

This amazes me. The reverse engeneering that has gone into the WinUAE project. congradulations. I would not even know where to start let alone figure this stuff out.

[Toni Wilen]

Originally Posted by xxxxx

I was wondering what happened if I disable the C src

Post #6 in this thread

(I forgot to check what actually happens when C is disabled, for example if blitter stops doing all DMA accesses)

[xxxxx]

ah, you are right, I missed that. thanks.

[Toni Wilen]

Superhires has a side-effect. Normal horizontal bitplane DMA limits gets disabled in superhires mode.

DDFSTRT and DDFSTOP can be set to illegal values and display gets corrupted if values are "too illegal". (AGA confirmed)

This is actually documented in Alice data sheet (Alice-AGA.pdf, should be on EAB file server, unfortunately this appears to be only interesting bit of information on this document..), BPLCON0 register documentation says:

SHRES = superhires (640 by 400 non-interlaced) [yes, it really says 640 by 400!] sets the bit plane control for this mode - doubles the of the output of a given bit plane over HRES. (hi res chips only). Two bit planes maximum. If priority is less than 4, the 1 available sprite has priority. If >>= 4, the sprite and bit plane are XOR'ed. Disables hard stops in vertical and horizontal display windows

It looks like this text originally came from ECS chipset data sheet (mentions 2 plane maximum and other limits), apparently ECS Agnus also has same disable DMA limit feature. (No idea if other limits are true, 1 sprite only and XOR feature, ECS superhires is used very rarely)

Programmed modes also disable DMA limits, this is documented in BEAMCON0 documentation. (Amiga NetBSD console screen uses this feature to set DDFSTRT=$14, works but disables all sprites)

EDIT: Superhires disabling DDFSTRT/STOP limits confirmed. A500 with ECS Agnus + ECS Denise.

[Photon]

I for one thought the side effect of sprites getting XOR'd with bitplanes was way more interesting than the limits!

Likely to steal massive time from the CPU, so no real gain in demos. But maybe some use, who knows?

[Toni Wilen]

Originally Posted by Photon

I for one thought the side effect of sprites getting XOR'd with bitplanes was way more interesting than the limits!

Likely to steal massive time from the CPU, so no real gain in demos. But maybe some use, who knows?

It would have been interesting if it isn't ECS Denise only.
(I guess I need to do some A3000 ECS Denise tests)

[Mrs Beanbag]

What exactly do you get when you read BLTDDAT? My hardware book says it doesn't actually give you the blitter data when you read this with the CPU, so what actually do you get?

[Toni Wilen]

Originally Posted by Mrs Beanbag

What exactly do you get when you read BLTDDAT? My hardware book says it doesn't actually give you the blitter data when you read this with the CPU, so what actually do you get?

"Bus noise". Reading BLTDDAT does same as any other non-existing register address (*).

It depends on chipset, accelerator chip etc what you get.. Usually it is whatever data was last accessed in chip bus but not always. AFAIK it is side-effect of Agnus/Lisa internal bus buffers (and possibly also buffers between CPU and chip bus can make the difference). There appears to be some kind of hardware "OR" operation happening, the more you read the register in tight loop, the more bits gets set to one..

*) Except on OCS Agnus where reading BLTDDAT always seems to return last chip bus accessed word but reading any other non-existing register returns "bus noise".

[Mrs Beanbag]

Is that behaviour emulated at all? Only I think I just discovered why some of my code worked on a real Amiga but not in UAE. See also the thread about "code that only works by coincidence".

[Toni Wilen]

Originally Posted by Mrs Beanbag

Is that behaviour emulated at all? Only I think I just discovered why some of my code worked on a real Amiga but not in UAE. See also the thread about "code that only works by coincidence".

Only enough to handle one or two buggy A500 demos (Codertrash is one), in cycle-exact mode only.

[Toni Wilen]

Sprites can be horizontally visible 1 lores pixel earlier than first bitplane pixel.

I assume reason is quite simple: bitplane start has HRM documented 0.5 cycle extra delay (1 lores pixel) but sprite shift register starts shifting immediately probably because data register was pre-loaded by DMA during horizontal blanking and it also does not need bitplane delay shifting.

[PiCiJi]

Lately I am interested in amiga chipset.

Copper writes to custom registers happen 1 cycle later than CPU writes.

That means the copper move happens in a non Copper cycle (the next bus cycle after the second instruction read) ?

If so, what happens if this cycle is occupied by higher level dma? If it is a free cycle, I would assume blitter/cpu can not use it.

[Toni Wilen]

Originally Posted by PiCiJi

Lately I am interested in amiga chipset.



That means the copper move happens in a non Copper cycle (the next bus cycle after the second instruction read) ?

If so, what happens if this cycle is occupied by higher level dma? If it is a free cycle, I would assume blitter/cpu can not use it.

I think this has to do with some kind of internal pipelining or something similar (I don't even remember what needed this or if it is even valid anymore..). There is no way it can use complete following cycle.

[mc6809e]

Originally Posted by PiCiJi

That means the copper move happens in a non Copper cycle (the next bus cycle after the second instruction read) ?

If so, what happens if this cycle is occupied by higher level dma? If it is a free cycle, I would assume blitter/cpu can not use it.

My guess is that by the time the next DMA cycle begins, a valid memory address has already been computed and latched inside Agnus and RAM is ready to be read from or written to. Any copper writes to internal registers can occur at the same time.

[PiCiJi]

in winuae src there is a table with delays for some copper register writes. Can it be considered as hack for something to work?

[Toni Wilen]

Originally Posted by PiCiJi

in winuae src there is a table with delays for some copper register writes. Can it be considered as hack for something to work?

Yes and no. This delay does exist but exact reason is unknown, probably something to do with Denise's internals. It is also done this way because emulating few cycle delays many times/scanline is really CPU expensive.

Note that most copper comments are obsolete

[xArtx]

Everyone knows about the Pause control (physical pin) on the 68000 right?
Have you emulated that Toni??
I don't know that it could be if the Amiga doesn't connect to it.