Undocumented Amiga hardware stuff

[Photon]

Originally Posted by Toni Wilen

Of course internal operation is not known, not really needed except when trying to emulate fully programs that change blitter registers while blitter is active, lots of very strange things can happen in this situation...

Möhöhö, sounds like a diabolical demo plan (rubs hands).

btw, how did you solve this demo?? Mr. Gurk says he changes line mask very fast in one of the parts...

[Toni Wilen]

Originally Posted by Photon

Möhöhö, sounds like a diabolical demo plan (rubs hands).

btw, how did you solve this demo?? Mr. Gurk says he changes line mask very fast in one of the parts...

No lines or line masks used. Normal blits only.

[yaqube]

Originally Posted by Toni Wilen

A needs to be enabled (or line will be drawn incorrectly) but it is never used for DMA transfers.

The A channel timeslot mustn't be taken by another higher priority DMA transfer. Otherwise the blitter waits for a free timeslot. That's because the A channel pointer register is used as the error accumulator in Bresenham's line drawing algorithm and needs the address ALU to perform required calculations. During the A channel access the DBR is never asserted and the CPU is not slowed down.

[Toni Wilen]

Originally Posted by yaqube

The A channel timeslot mustn't be taken by another higher priority DMA transfer. Otherwise the blitter waits for a free timeslot. That's because the A channel pointer register is used as the error accumulator in Brehenham's line drawing algorithm and needs the address ALU to perform required calculations. During the A channel access the DBR is never asserted and the CPU is not slowed down.

What do you mean by "A channel timeslot"?

Perhaps I misunderstood your post but both "idle" cycles in line draw mode needs free DMA time slot and both are usable by the CPU. (or my logic analyzer is lying)

This also includes BLTDDAT write if it gets skipped in onedot mode.

[yaqube]

Originally Posted by Toni Wilen

What do you mean by "A channel timeslot"?

I mean the first empty cycle in -C-D DMA access sequence. Actually it modifies the A channel pointer register and needs an access to the DMA address ALU.

Perhaps I misunderstood your post but both "idle" cycles in line draw mode needs free DMA time slot and both are usable by the CPU. (or my logic analyzer is lying)

You are right. Although there is no reason for the second idle cycle to need an access to the DMA address ALU it also needs empty DMA cycle not taken by any other DMA channel. Of course the CPU can use both these idle cycles as the blitter has the lowest priority and cannot block any other DMA channel.

This also includes BLTDDAT write if it gets skipped in onedot mode.

Yes, but it's another story.

[Toni Wilen]

Originally Posted by yaqube

You are right. Although there is no reason for the second idle cycle to need an access to the DMA address ALU it also needs empty DMA cycle not taken by any other DMA channel. Of course the CPU can use both these idle cycles as the blitter has the lowest priority and cannot block any other DMA channel.

Ok, I thought you meant "non-A" idle cycle is "real" idle cycle. That was the only confusing part

[pandy71]

Hi guys, looks like KILLEHB in BPLCON2 is implemented in MOS 8373 (Hi Res ECS Denise) - any idea for what KILLEHB can be used in ECS?

btw IMO this is documented "undocumented" feature

[Toni Wilen]

Originally Posted by pandy71

Hi guys, looks like KILLEHB in BPLCON2 is implemented in MOS 8373 (Hi Res ECS Denise) - any idea for what KILLEHB can be used in ECS?

btw IMO this is documented "undocumented" feature

AFAIK it is documented in 3rd edition HRM ECS chapter, will check later today (which for some reason is missing in PDF versions).

KILLEHB was originally meant for Genlock stuff (can use plane 6 as a genlock transparency mask), ECS Denise introduced lots of genlock features (that no one used?)

EDIT: KILLEHB is listed in 3rd edition HRM (black covers), genlock features list.

[pandy71]

So in theory... there is alpha 2 bits in color registers and additionally whole bitplane? weird... logical OR? I can imagine that all genlock features was very easy to implement in hardware (not many resources used for all that functionality almost for free)

[Toni Wilen]

CIAs have internal delays.

Timer startup by setting control register start bit: 1 E-clock delay.
Timer startup by writing to high timer register (and oneshot mode set as documented): 2 E-clocks delay.

delay = cycles needed before timer actually starts counting. (start bit gets set instantly, it does not have any delays)

When timer finishes, start bit is immediately cleared but interrupt request bit gets set slightly later.

(on a 68000 Amiga this can be duplicated by starting timer and then reading control register continuously and then doing the same by reading interrupt request register, if timed correctly, control register start bit clears earlier than interrupt request gets set)

[Toni Wilen]

Quite useless undocumented Paula feature (not sure why they even bothered to waste some gates for this)

SERDAT is full 16-bit register (not 10 as documented)

For example if you set bit 15, Paula will transmit full 15 bits (+stop bit), if you only set bit 0, Paula will only transmit start and stops bits only

Of course receiving strange bit lengths may be difficult with standard hardware..

[meynaf]

Originally Posted by Toni Wilen

Quite useless undocumented Paula feature (not sure why they even bothered to waste some gates for this)

Perhaps it was just simpler to do things like that, who knows. They might have some ready-to-use 16-bit shift registers, or something like that.

[Toni Wilen]

Undocumented side-effect that I have noticed long time ago but I always thought it was something more complex than it actually is..

Starting disk WRITE DMA with ADKCON WORDSYNC bit set.

Paula starts internally reading the disk (just like it does when read DMA is started with WORDSYNC) until internal buffer matches WORDSYNC register. Only then actual write DMA starts.

Which means if some program accidentally forgets to clear WORDSYNC (There are few), writing never starts or finishes if track does not already have correct wordsync marker.

EDIT: Example game (Viaje Al Centro De La Tierra) that does it wrong accidentally:

00011364 33fc 7f00 00df f09e      MOVE.W #$7f00,$00dff09e
0001136C 33fc 9500 00df f09e      MOVE.W #$9500,$00dff09e ; set MFMPREC, FAST and WORDSYNC
00011374 33fc 4489 00df f07e      MOVE.W #$4489,$00dff07e
0001137C 4a79 0001 133a           TST.W $0001133a ; nonzero = write
00011382 6700 0014                BEQ.W #$0014 == $00011398 ; -> read
00011386 33fc 9100 00df f09e      MOVE.W #$9100,$00dff09e ; write, so only set FAST and MFMPREC (but previous write to ADKCON already set WORDSYNC..)

[Photon]

Originally Posted by Toni Wilen

if some program accidentally forgets

That would be hw track-loading games, as demos almost never write to disk and anything using trackdisk.device (including DOS) works with the sector paradigm; read, replace sector, write.

What's interesting is that quickformatted disks factory-formatted for PC can work only if 1 of these three is used:

1. The read is skipped if a bit in the disk bitmap is set (to "unformatted _track_"), clearing WORDSYNC if so
2. If the track read fails, WORDSYNC is cleared
3. WORDSYNC is always cleared, like by all good trackloaders (most likely).

[Toni Wilen]

I was implementing AROS m68k card.resource and noticed something interesting..

There are two methods to reset the card (activate CC_RESET line)

Method 1:

Activate: write to address 0x00A40000.B
Deactivate: read address 0x00A40000.B

Method 2:

Activate: set address 0x00DA9000.B bits 0 and 1.
Deactivate: clear bits 0 and 1.

Normally bits 0 and 1 do following:

Bit 0 = if set, hardware reset Amiga if PCMCIA card removed
Bit 1 = if set, cause bus error exception if PCMCIA card removed
(=does not make sense to have both set)

Interestingly A600 Gayle supports both methods, A1200 Gayle (I have AA-Gayle-R5) supports only second method. (I have heard rumors that some older AA-Gayle revisions support this method too? Can anyone confirm?)

Kickstart ROM code only uses method 1 = this explains A1200 PCMCIA reset problems (without using software or hardware fix)

I guess OS developers were never told about this hardware design change..

Final interesting feature: A600 Gayle reset features are completely separate, activating reset with method 1 and then clearing it with method 2 won't clear the reset state. (Or vice versa)

[Toni Wilen]

Paula volume implementation: http://eab.abime.net/showthread.php?t=63227

[FrenchShark]

Originally Posted by yaqube

For the short line (227 CCKs) it should be from 0 to 226*2+1 (= 453) but as it's advanced by 2 it is in range from 2 to 455.



I tested this indirectly by changing sprite trigger position (the sprite trigerred on any hpos value between 2 and 455). The same test may be conducted on ECS Denise horizontal display window: if diwstop <= 455 (and >= 2) and diwstrt < 2 the display is blanked. Alternatively if diwstart is in 2 to 455 range and diwstop out of this range the display is never blanked horizontally.

Did you test the sprite trigger position in NTSC ?
I am expecting Denise's HPOS to be delayed by half a CCK cycle (one lores pixel) when STRLONG is present. (IMHO, this is the simplest way of implementing the delay in Denise) This should occur when HPOS = 5.
So, sprites with 2 <= horizontal pos < 6 must show a sawtooth effect in NTSC.

Regards,

Frederic

[Toni Wilen]

COPJMP1 or COPJMP2 writes have one strange cycle.

Write to COPJMP:
Next copper cycle fetches next instruction word normally (just like another MOVE)
Second copper cycle is the strange one.
- if cycle is free, it gets allocated for copper (CPU or Blitter can't anymore use it) and it fetches following word and writes it to 0x1FE. It looks like normal copper MOVE to 0x1FE in logic analyzer.
- if cycle is not free (was used by BPL DMA for example), it still is usable by copper.

Third cycle is normal fetch from new pointer.

Previously I thought second cycle needs to be free because I assumed it is same as any other copper cycle.

My crystall ball (above is logic analyzer confirmed, this one isn't yet) says that this cycle is the one where copper pointer is copied and which also explains this http://eab.abime.net/showpost.php?p=488782&postcount=47 bug.

I guess COPxLC to internal copper pointer copy uses some shared Agnus circuitry which is also used by blitter and maybe also other DMA channels.

Did you test the sprite trigger position

How to do this? How I am supposed to see sprite position inside hblank?

[mc6809e]

Originally Posted by Toni Wilen

I guess COPxLC to internal copper pointer copy uses some shared Agnus circuitry which is also used by blitter and maybe also other DMA channels.

I think the Amiga patents confirm this. Taking a look at Figure 4 of any of the Amiga patents, I see that all the DMA channel pointers share a single internal bus and a single adder is used to update the pointers. Not only is Agnus responsible for prioritizing access to memory, it is also responsible for prioritizing access to the single adder and to any of the address registers involved when DMA pointers are updated through the adder.

This explains why during line draw, for example, channel A takes up a DMA slot even though there is no actual DMA to perform. Line draw logic must use the adder to update the error held in APTR. If the adder is currently being used by some other DMA channel (incrementing BPL1PT, for example), then the error in APTR can't be updated until Agnus' adder is free.

Now there is also a gate that allows backup registers (audio buffer start pointers and copper list start addresses) to be transfered through the adder without change and into the appropriate (we hope) DMA pointer register. When COPJMPx is touched, the value in the backup register, COPxLC, should go through the adder and back into the copper list pointer register. As coyote pointed out, sometimes COPxLC is transfered to the wrong register (BLTDPT for instance) if the copper is executing a wait and COPJMPx is strobed.

You write that the copper can use the second cycle even if it's unavailable. I wonder: what address then is on the bus? Just one of the 25 DMA address pointers can be on the bus at a time. Which one is used to get the next word? Is some other pointer corrupted as a result or does the copper fetch its word from the address pointed to by the conflicting DMA channel?

[Toni Wilen]

Originally Posted by mc6809e

You write that the copper can use the second cycle even if it's unavailable. I wonder: what address then is on the bus? Just one of the 25 DMA address pointers can be on the bus at a time. Which one is used to get the next word? Is some other pointer corrupted as a result or does the copper fetch its word from the address pointed to by the conflicting DMA channel?

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