I'm debugging an ECS demo (SushiBoyz by Ghostown) on minimig.

In the part with the face and '3D' light, the demo sets no. of bitplanes = 7, and the HAM bit is enabled in BPLCON0 (BPLCON0 = $7A00).

From what I gathered, this should mean the following:
- Agnus 'thinks' this is a four-bitplane mode
- Denise 'thinks' this is a 6-bitplane mode (EHB)
- since HAM bit is enabled, this overrides EHB mode

So this is a HAM mode with 6 bitplanes, but Agnus only does fetches for 4, is my thinking correct?

Yes. From Denise point of view it is normal HAM6 but because Agnus does not update BPLDAT5 and 6, they can be modified with CPU or copper, without Agnus overwriting it.

Annoyingly Denise ignores any BPLDATx registers that are disabled in BPLCON0. This trick makes it sort of possible. (Same works without HAM bit and is also used in few demos)

Great, thanks!

Seems to fix at least the SushiBoyz and Sliced&Diced demos.

(BTW: the SushiBoyz demo only works correctly with ECS chipset - with OCS, the logo in the dancefloor part is offset to the left, and with AGA, the 'dancers' on the dancefloor have an interesting color cycling, instead of real colors (because of the PF2OF offset). It actually looks kinda good ;))

Does it make any difference if the number of bitplanes is set to 6 instead of 7 in this case?

Similar OCS/ECS differences are not that rare (lots of listed in WinUAE demo test thread).

I have never bothered to try OCS/ECS demos in AGA mode, they rarely work anyway.

6 planes vs 4 planes makes a quite big DMA bandwidth difference if you only need (semi) static BPLDAT5/6 contents.

Having separate bitplane mask value (not count) for both Agnus and Denise would allowed lots of interesting effects vs current single bitplane count value.

AGA BPLCON0 BYPASS bit:

As documented, it bypasses palette selection but it also ignores "special" bits.

- if HAM: HAM control bits (planes 5 and 6 if HAM6, planes 0 and 1 if HAM 8) do not appear in output. In other words, HAM6: value range is 0 to 15. HAM8: low 2 bits are always zero.
- if EHB: EHB plane 5 does not appear in output. (Range is 0 to 31)
- Output is grayscale, output value is copied to all color component bits, not just red.
- Sprites seem to work exactly like bitplanes, palette is bypassed and sprite's palette index value appears in output.

Ahh.. I missed the bit where 7 causes agnus to do dma for 4 planes, whereas 6 causes it to do dma for all 6 planes.

Just to confirm... I can't tell so easily from the youbue video ,but are the hardware sprites going behind the score? or does swiv actually not use hardware sprites for the player "bullets" (i read that it was some funky multiplexing routine for HW sprites, but as the game is running at 25fps, it seems pointless to use sprites :D )

Ok, the bullets are HW sprites, and they go in front of the panel... but for the life of me, I don't know why they used HW sprites for these :D

Some CD32 undocumented features after few days of poking around with mon and asmone :). Was already posted in cd32load thread.

- It seems unmapped addresses don't "float", all invalid reads seem to always return zeros.
- CIA chip select, address bits 12 and 13 are CIA selects. Gary: 0=none,1=A,2=B,3=A+B, Gayle: 0=none,1=A,2=B,3=none, Akiko: 0=A,1=A,2=B,3=B
- CIA address space: Gary: $A00000-$BFFFFF, Gayle: $BFDxxx and $BFExxx, Akiko: $BFE000-$BFFFFF.
- Custom register mirror at $B90000-$B9FFFF! (This is really weird..)
- Akiko addresses are mapped from $B80000 to $B87FFF and has 64 byte mirroring.
- Full Akiko ID at $B80000.l is $C0CACAFE (KS only checks for $CAFE)
- All write-only registers seem to read same data as nearby read-only register. (not random data/bus noise like other write-only registers)
- Interrupt registers only have bits 24 to 31 writable, other bits always read as zeros.
- Config ($B80024) register has bits 23 to 31 writable, other bits always read as zeros.
- Subchannel arrived interrupt bit is set at boot for some unknown reason, subchannel index register ($B80018) works strangely and has unexpected value at boot ($C2).
- Akiko internal CIAs don't have external TOD input pins. CIA-A TOD which normally counts vsyncs or power supply ticks count rate is selected with $B80020 bit 23 (0=50Hz, 1=60Hz). CIA-B (hsync) timing logic is not known yet but it is also internally generated.

Does this old news posting touch upon something undocumented? https://groups.google.com/forum/#!to...er/dG6E_95Hq9U

No. COPJMP blitter bug is known and is really annoying in some situations (listed in this thread). Of course everyone who replied didn't get it..

ERSY stuff (and others) in that post was just OP's misunderstanding.

Glitch free AGA bitplane overrun
 

Enough testing done, time to post here too.. (from http://eab.abime.net/showthread.php?t=83771 and http://eab.abime.net/showthread.php?t=83704)

Normally when bitplane DMA overruns to next scanline, it will always conflict with refresh DMA slots causing corruption and/or even system crash/hang in some situations.

But if mode is AGA 64-bit lores and DDFSTRT/STOP pair "aligns" it nicely (maybe also possible in 32-bit fetch mode), only idle cycles will "conflict" with refresh slots (=nothing happens) and final bitplane fetch block starts after refresh cycles, only conflicting with disk DMA (which does nothing if disk DMA is not active) and first audio channel (which causes conflict and corrupted graphics if first channel is active). I guess game coder never noticed it because at this point of development game didn't have any sound..

Most interesting visible side-effect in this "mode" is that part of bitplane graphics will be visible in left overscan, without killing any sprites. (if horizontal diwstrt is wide enough)

Surprising chipset bug (Which yet again proves that AGA was just hacked on top of ECS). Also quite useless bug, unfortunately.

Came back to this now.

Does the copper use one bus cycle that it hasn't allocated? That was kinda how I vaguely understood this thread.
Are there any programs that need this to work correctly?

http://eab.abime.net/showpost.php?p=...&postcount=122

None known but thats not the point. This condition is too easy to trigger and can be extremely annoying and time consuming to debug using real hardware.

I ran across an old usenet post that claims that it is possible to reload the line pattern (BLTBDAT) in blitter line mode (without cpu or copper), albeit in a very limited fashion (BLTBMOD has to equal 2, restricts angle to multiples of 45°). Source B has to be enabled in BLTCON0.
https://groups.google.com/forum/#!ms...8/eti4ztDD87kJ (Post by Morten Leikvoll)

I do not have a real amiga here, can anyone comfirm or disprove this claim? And what happens if BPLBMOD doesn't equal 2? Does it stop working at all, or is it fetching the pattern with the respective modulo?

EDIT: and while I'm at it, what happens in line mode if BLTADAT has a different value than 0x8000? I guess the line is drawn with that horizontal "pattern" (per word), right-shifted and truncated at 16 bit?

(A rotten memory and not enough search-fu withstanding:)
Is it documented the relation between bitplane memory fetch and how much later the pixels are shown on screen?

When testing in UAE it seems to me that in 8bpl 64-bit lores mode the first pixel will display 5 pixels offset from end of last fetch:
I simply made a long copperlist that ping-pongs between two colours and looked at how many pixels I could see between the delay the fetch imposed and where the bitplane pixels started showing.
I found a comment that copper writes happen later than expected - is that what I'm seeing?

(I'm trying to see if I can make a vertical split fit in between the fetches; reseting bplcon1 values plus pointer changes.)

--

Do bitplane modulos update all bitplane pointers or only those that are in use according to bplcon0?

I guess it can do. I did some linemode tests with B enabled but results didn't make any sense. I don't think this can be solved without some internal low level blitter diagrams.

I think so. I don't remember if I ever tested it..

(Not very useful answers..)

There should be 1 lores pixel delay between BPLDAT1 write and pixel appearing on screen (assuming no bitplane delay)

I am not sure if I understood. CPU write using cycle x vs copper using same cycle x: copper write happens later (I think it was 1 cycle later)

Did you mean horizontal? There should not be any problems doing the split in AGA 64-bit lores, lots of idle cycles. Just make sure you don't accidentally hit the chipset feature of updating any DMA pointer when next cycle is used by same DMA channel. Your write goes nowhere in this situation (this annoyingly limits OCS split to 3 planes)


Only active planes.

did you ever investigated the Pangolin Lasershow software?
i once made a request in their forum, but never got a reply, 4 yrs ago ... :)

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

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 https://www.youtube.com/watch?v=F4WJYyoF1Lk) 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.)