Undocumented Amiga hardware stuff

[Toni Wilen]

Originally Posted by NorthWay

Thx. (I'm (still/again) trying to do a Gauntlet style split for a right hand side info panel and I think the numbers add up for it being possible.)

When you increase bplcon1 scroll delay values during active display, what is shown in the "gap" that you create? Is it DFF180, last pixel stretch, pixels repeated, or something else?
(Yeah, I can't wait to get my 4000 back so I can test stuff like this...)

Zero bits. Check also http://eab.abime.net/showthread.php?t=71437

Do the Amiga chips have any internal logic that behaves in a similar fashion to the Atari ST chips (see for example the talk here [ Show youtube player ]) so that they can be manipulated to do be "confused" and do things they weren't intended to?
(Basically using strict timing to force unintended internal states from my understanding.)

AFAIK only blitter can get confused. (by modifying BLTCON0 when blitter is active)

EDIT: and it is possible to force bitplane dma overrun, causing refresh cycle conflicts that messes up graphics.

[NorthWay]

On the topic of the hw logic; has anyone heard anything from the Visual6502 crew or anyone else working on de-capping the chips? Did Jens say he had done it?

Oh, and was there ever a summary list of registers that had to be updated every frame (i.e. best used in a copperlist) and which ones that would reuse last value written?

Bonus: 5.25" floppydrives - do they work differently from 3.5"? Can a gcr disk be read as an MFM image? Are there any alternative(/more effective) encodings to the official one that still adhere to the official MFM restrictions? I vaguely remember some old Psygnosis interview claiming 1.2M? 1.3M? 1.6M? format on a disk, but I don't know if they were breaking the rules. What makes 81/82 tracks (or more) work or not? Is there space for a full 11 sectors on 81+?

[Toni Wilen]

I don't think that is really undocumented enough for this thread.. (and floppy mechanism or size has nothing to do with encoding)

[Toni Wilen]

DMA mode sprite interesting side-effect if sprite's x-starting position is earlier than sprite's last or both DMA slots.

Sprite shift register is loaded immediately when x-coordinate matches and sprite is armed, DATA or DATB accesses or contents won't make any difference.

This means previous line's data is shown if new DATA or DATB has not been written. "Worst" case is when x matches between sprite's DMA slots, first sprite plane is correct, second plane has previous data. Final side-effect is last line appearing twice, first normally, then second time in next line.

Original report: http://eab.abime.net/showthread.php?t=85482

[Toni Wilen]

Blitter B channel "B old" value (see HRM blitter diagram) is only cleared at blitter startup if channel is enabled.

Normally this does not cause any unexpected side-effects and is totally harmless. Except if previous blit's (with B channel enabled) last B channel read was non-zero, following blit has B channel disabled, B channel shift is non zero (for example B channel shift was used in previous blit) and BDAT is CPU (or copper) loaded with some static value. Because B channel shift is done instantly, shift count number of bits from "B old" will be shifted in, changing the data you loaded and it is not necessarily zeros that get shifted in. After BDAT load modifying shift value makes no difference.

This kind of situation is really rare but it has happened at lest once: http://eab.abime.net/showpost.php?p=...9&postcount=31

So always clear B-shift before manually setting BDAT, not after

ADAT works differently, "A old" seems to be always zeroed at startup.

[Toni Wilen]

FMODE>0 and address not aligned to fetch size:

FMODE=1 and FMODE=2

Load 32-bit value (from address AND ~3)
If address is not divisible by 4: lower 16-bit is copied to upper 16-bit.
If FMODE=2 and address is divisible by 4: upper 16-bit is copied to lower 16-bit

FMODE=3:

Load 64-bit value (from address AND ~7)
If address is not divisible by 8: lower 32-bit is copied to upper 32-bit
If address is not divisible by 4: do the same to both 32-bit halves: copy lower 16-bit to upper 16-bit.

[Toni Wilen]

I think this is now completely solved. Undefined = BPLCON2 PF1 and/or PF2 is set to undocumented value 5, 6 or 7. OCS/ECS only.

Sprites and sprite priorities work identically to documented value 4 (all sprites have priority over both playfields) even if value is 5 or larger.

Normal plane mode and EHB:

If number of planes is 5 or 6 and BPLCON2 PF2 is >= 5 and if plane 5 (counting from 1) has bit set: other planes are ignored in palette selection = COLOR16 is selected. ("SWIV" score board feature). PF1 does nothing.

Dual playfield:

Any number of planes. No 5+ requirement here.

If playfield's matching BPLCON2 PFx value is >=5 and if playfield is not transparent, it is always drawn using COLOR0. PF2PRI still work normally, only color selection becomes strange. (Used in Running man / Scoopex intro's logo). If both PF1 and PF2 is >=5: both playfields disappear, only background color (and sprites) are visible.

HAM:

HAM works normally. EDIT: Most likely because "special" plane 5 is is not used in HAM to select palette indexes.

[Photon]

Originally Posted by Toni Wilen

Blitter B channel "B old" value (see HRM blitter diagram) is only cleared at blitter startup if channel is enabled.

Normally this does not cause any unexpected side-effects and is totally harmless. Except if previous blit's (with B channel enabled) last B channel read was non-zero, following blit has B channel disabled, B channel shift is non zero (for example B channel shift was used in previous blit) and BDAT is CPU (or copper) loaded with some static value. Because B channel shift is done instantly, shift count number of bits from "B old" will be shifted in, changing the data you loaded and it is not necessarily zeros that get shifted in. After BDAT load modifying shift value makes no difference.

This kind of situation is really rare but it has happened at lest once: http://eab.abime.net/showpost.php?p=...9&postcount=31

So always clear B-shift before manually setting BDAT, not after

ADAT works differently, "A old" seems to be always zeroed at startup.

I guess you've tested with A disabled and previous blit reading a non-zero value from A using A mask=-1. I reply because it hasn't come up for me; the order of operations in HRM seems to have always been followed.

[Toni Wilen]

Originally Posted by Photon

I guess you've tested with A disabled and previous blit reading a non-zero value from A using A mask=-1. I reply because it hasn't come up for me; the order of operations in HRM seems to have always been followed.

I think you misunderstood. I didn't mean xDAT contents which of course is not modified (if DMA is off). I meant "hidden secondary" xDAT that is used to store previous xDAT value, used internally for shifting in bits to "real" xDAT if shift value is non-zero. Hidden ADAT is always cleared when blit is started, hidden BDAT is not if channel DMA is off.

[Photon]

Originally Posted by Toni Wilen

I think you misunderstood. I didn't mean xDAT contents which of course is not modified (if DMA is off). I meant "hidden secondary" xDAT that is used to store previous xDAT value, used internally for shifting in bits to "real" xDAT if shift value is non-zero. Hidden ADAT is always cleared when blit is started, hidden BDAT is not if channel DMA is off.

Well, there were at least 3 separate issues in that thread, and I probably didn't understand the problem because the code for the font writer referenced wasn't there (or I couldn't find it, just had a quick look).

I'm not sure I have something to say on the subject until then except a general "BLTCONx is written, xDAT is shifted, this and the order of operations is documented." Which when followed probably doesn't provide any interesting side-effects

Edit: I have a candidate for a possibly undocumented feature. Writing any value to BPLCON0 will set BPLEN in DMACON. (And maybe more bits like SPREN, DMAEN?) You could wait until I can provide a test case like I should, just don't have the time right now. The test case would be something like a Copper list where either a move to DMACON or possibly a previous move to DIWSTOP turns off bitplane DMA, and a later move to BPLCON0 re-enables BPLEN.

[AwoLStill]

Originally Posted by Photon

The test case would be something like a Copper list where either a move to DMACON

I tried this:
move.b 1,DMACON

with a piece of code you may be familiar with ;-) called:
DDE3-Bobs!!3.a

and absolute nothing (Noticable) happened.

Have i implemented the test wrong?

The code was modifed to this:

Demo: ;a4=VBR, a6=Custom Registers Base addr
*--- init ---*
move.l #VBint,$6c(a4)
move.w #$c020,$9a(a6)
move.w #$87c0,$96(a6)
*--- clear old bob ptrs ---*
lea LastBobs,a0
lea LastBobs2,a1
moveq #MaxBobs-1,d0
.l0: clr.l (a0)+
clr.l (a1)+
dbf d0,.l0
*--- clear screens ---*
lea Screen,a1
bsr.w ClearScreen
lea Screen2,a1
bsr.w ClearScreen
WAITBLIT
*--- start copper ---*
lea Screen,a0
moveq #bpl,d0
lea BplPtrs+2,a1
moveq #bpls-1,d1
bsr.w PokePtrs
move.l #Copper,$80(a6)
move.b 1,DMACON ; only change here.

[Toni Wilen]

I don't think mostly random, not confirmed, test code (that does not even attempt to guarantee identical timing) should be in this thread. Only actual results of tests, with links to test thread. This is far too long already.

btw, check the last line more carefully. Also writing bytes to custom registers don't work like writing byte to memory.

[Don_Adan]

Originally Posted by AwoLStill

I tried this:
move.b 1,DMACON

with a piece of code you may be familiar with ;-) called:
DDE3-Bobs!!3.a

and absolute nothing (Noticable) happened.

Have i implemented the test wrong?

The code was modifed to this:

Demo: ;a4=VBR, a6=Custom Registers Base addr
*--- init ---*
move.l #VBint,$6c(a4)
move.w #$c020,$9a(a6)
move.w #$87c0,$96(a6)
*--- clear old bob ptrs ---*
lea LastBobs,a0
lea LastBobs2,a1
moveq #MaxBobs-1,d0
.l0: clr.l (a0)+
clr.l (a1)+
dbf d0,.l0
*--- clear screens ---*
lea Screen,a1
bsr.w ClearScreen
lea Screen2,a1
bsr.w ClearScreen
WAITBLIT
*--- start copper ---*
lea Screen,a0
moveq #bpl,d0
lea BplPtrs+2,a1
moveq #bpls-1,d1
bsr.w PokePtrs
move.l #Copper,$80(a6)
move.b 1,DMACON ; only change here.

You cant use "move.b 1,DMACON", this is buggy command here.

[Toni Wilen]

SPRxDATx accesses when sprite is 32 or 64-pixel wide are quite unexpected but I think I found out how it works.

32 pixel wide, FMODE = 32-bit access: Sprite's first and last 16 pixels get updated with duplicated written data. I didn't find any side-effects.

32 pixel mode, FMODE = double cas: First 16 pixels are filled with last chipset bus value. Last 16 pixels: if previous cycle was bitplane DMA: bitplane DMA data (which means whole 32-pixels of sprite shows bitplane data, AGA bitplane fetch is always internally 32-bit, even if bitplane FMODE=0), if previous cycle was not bitplane DMA: value written to SPRxDATx.

64 pixel mode: first 32 pixels work exactly like double cas 32 pixel wide mode, last 32 pixels always have SPRxDATx value duplicated. Very unexpected feature: if sprite FMODE is lowered when first 32 pixels of 64 pixel wide is being drawn, matching part in last 32 pixels gets blanked! (I assume 64 bit wide sprite is internally made from 2x32 bit shift registers and second shift register's output is connected to first's input only if sprite width is 64 pixels)

Common to all sprite widths: sprite width is decided when SPRxDATx is written to (via DMA or copper or cpu). It is possible to have different size sprites in same horizontal line.

Original discussion: http://eab.abime.net/showthread.php?t=94345

[Toni Wilen]

Very similar to sprites:

- FMODE=3: first 16 pixels are last bus data, remaining 48 pixels are duplicate of written data.
- FMODE=2: first 16 pixels bus data, last 16 pixels written data.
- FMODE=1: written data duplicated.

EDIT: if FMODE is lowered after writing to BPLxDAT, last 32 pixels of FMODE=3 mode disappears, just like with sprites. No effect on other FMODEs, not even when setting it to zero.

Last bus data is first word of copper MOVE (=address of of BPLxDAT) to BPLxDAT if blitter or bitplane DMA is active at the same time. Easy to see by setting (unused) high bits of register value, more pixels appear on screen.

[Toni Wilen]

If FMODE>0 and modulo and BPLxPT is "unaligned" (not integer divisible by 4 if FMODE=1/2 or not integer divisible by 8 if FMODE3):

When modulo is added to BPLxPT, adder ignores possible carry of bit 1 sum (if FMODE=1/2) or bit 2 and 1 sum (if FMODE=3). Most likely reason is that same bit is used to increment BPLxPT by fetch size. (and it would be useless anyway because result would be corrupted display due to unaligned BPLxPT)

For example: BPLxPT=$10002 MOD=$6 FMODE=1: BPLPT after modulo added: $100004. (Sum of 2 lowest bits: 2 + 2 = 4 but because carry was ignored -> 0. Sum of other bits: $100000 + 4 = $100004)

(http://eab.abime.net/showthread.php?t=94943)

[Toni Wilen]

More information about CPU write to COPJMP while blitter is running and copper is waiting.

I did many tests with logic analyzer and I found more required conditions that are needed to trigger the bug. All following conditions need to be true:

(already known)

- CPU write to COPJMP
- Blitter active
- Copper waiting

This causes COPJMP to do 2 cycle sequence, first cycle is dummy (and does not need to be free), second cycle apparently does internal pointer copy and bug happens if copper don't allocate the cycle and blitter uses it.

(new)

- CPU write to COPJMP uses odd cycle (=following cycle becomes first COPJMP cycle)
- Any cycle after COPJMP write and before second COPJMP cycle must not have been allocated by any higher priority DMA channel.

If CPU write uses even cycle, copper correctly allocates second cycle (can't be available for the blitter).

If there is one or more higher priority DMA channel access(es), for example bitplane, after CPU write to COPJMP and before second COPJMP cycle, copper also correctly allocates second cycle.

If any higher priority DMA channel access uses cycle that was supposed to be used for second COPJMP cycle, copper won't get the cycle, next free cycle is correctly allocated for the copper.

CPU odd cycle requirement makes this very timing sensitive.

[sonycman]

Originally Posted by Toni Wilen

Also writing bytes to custom registers don't work like writing byte to memory.

Dear Toni, would you, please, give more detailed information as to how byte write to custom registers works actually?

Recently I`ve found a code in some game that writes a byte to AUD0VOL register:

MOVE.B (A1,$0013) == $000108df [3a],(A5,$0008) == $00dff0a8

As you`re can see, address is A8, and not A9, and minimig has some problem with that.

But WinUAE is fine, as the real hardware, I think.

Should the byte write actually work as word write, with mirrored 8-bit data to both bytes of a word?

[Toni Wilen]

Chipset registers are always 16-bit wide and they always accept byte writes. How it works depends on hardware:

68000 mirrors same byte value in both upper and lower byte of 16-bit data bus when writing bytes. byte write xx becomes xxxx.W

AGA: byte write and odd address: 00xx.W gets written. Even address: xxxx.W gets written.

Some 68040+ accelerator boards don't support byte writes properly (as can be seen in many whdload slave changelogs)

[sonycman]

Thanks a lot, Toni.

Originally Posted by Toni Wilen

68000 mirrors same byte value in both upper and lower byte of 16-bit data bus when writing bytes. byte write xx becomes xxxx.W

That is definitely not the case with the TG68K soft processor.