Undocumented Amiga hardware stuff

[Toni Wilen]

Originally Posted by meynaf

Why ?

It simply isn't something I am interested. CPU is a boring black box, no fun side-effects. There is much more interesting things to do. (and this is chipset thread..)

[Photon]

Undefined means that the CPU developers accept no responsibility for the predictability of the contents of the register, or whether register contents changes in the next CPU model. Now it's way after the fact and no more CPU models will be made, so possibly if some program relied on undefined data it could be hard to make it work on any Amiga or Amiga emulator or 68xxx emulator.

But for the chipset, a lot of vital behavior is still unmapped, and that's what needs to be documented if any Amiga remade in modern components is supposed to be an Amiga replacement, ie. if Amiga is to survive.

[Asman]

I have question about CHIP memory. Lets consider A500 with 0.5 MB CHIP ( $00000 - $07ffff ). What happens when I'm trying to read from $80000 or higher ? Is there kind of mirroring of the CHIP memory in such case ?

[Toni Wilen]

Originally Posted by Asman

I have question about CHIP memory. Lets consider A500 with 0.5 MB CHIP ( $00000 - $07ffff ). What happens when I'm trying to read from $80000 or higher ? Is there kind of mirroring of the CHIP memory in such case ?

Chip RAM mirrors up to 2M. That is not exactly undocumented because it is "documented" in schematics (It gets a bit more complex with A500+ in 1.5M chip configuration)

Fun part: 1M Agnus in 512k+512k configuration still sees 1M of Chip RAM internally. First 512k at normal Chip RAM region, second 512k is at normal slow ram region ($c00000-$c7ffff). For example bitplane DMA pointer $090000 is actually CPU address $c10000.

Quite useless information unless you want to write demo that requires 1M chip but also works in 512k+512k ECS Agnus A500s

[Asman]

Thank you Toni for answer ( fun part is awesome ). Its mean that is possible to make production ( game / demo ) which should works only for machines with 0.5MB CHIP and doesn't work on 1MB CHIP machines.

[Toni Wilen]

Originally Posted by Asman

Thank you Toni for answer ( fun part is awesome ). Its mean that is possible to make production ( game / demo ) which should works only for machines with 0.5MB CHIP and doesn't work on 1MB CHIP machines.

Already done!

http://eab.abime.net/showpost.php?p=417774

[TheDarkCoder]

Originally Posted by Toni Wilen

Chip RAM mirrors up to 2M. That is not exactly undocumented because it is "documented" in schematics (It gets a bit more complex with A500+ in 1.5M chip configuration)

Fun part: 1M Agnus in 512k+512k configuration still sees 1M of Chip RAM internally. First 512k at normal Chip RAM region, second 512k is at normal slow ram region ($c00000-$c7ffff). For example bitplane DMA pointer $090000 is actually CPU address $c10000.

Quite useless information unless you want to write demo that requires 1M chip but also works in 512k+512k ECS Agnus A500s

Excuse me Toni, I am not sure to exactly understand. Are you saying that that the second 512k bank can be accessed by the cpu at $c00000 and by the custom chips at $090000 ? Can the custom chips use it like usual chip ram? I.e. can I setup a bitplane in that memory bank (writing with the cpu at $cxxxxxxx and setting the corresponding adress in BPLxPT? And is the bitplane actually visualized?

This would mean that this 512k ram is, from an hardware perspective, a chip ram area, even if the cpu sees it allocated at uncommon adresses and that is seen as fast only from the OS.

Which Amiga models can have such configurations?

[hitchhikr]

Excuse me Toni, I am not sure to exactly understand. Are you saying that that the second 512k bank can be accessed by the cpu at $c00000 and by the custom chips at $090000 ? Can the custom chips use it like usual chip ram? I.e. can I setup a bitplane in that memory bank (writing with the cpu at $cxxxxxxx and setting the corresponding adress in BPLxPT? And is the bitplane actually visualized?

This would mean that this 512k ram is, from an hardware perspective, a chip ram area, even if the cpu sees it allocated at uncommon adresses and that is seen as fast only from the OS.

Exact.

Which Amiga models can have such configurations?

All A500 with ECS Agnus (probably all those with v1.3 kickstart) and maybe some more models.

Unfortunately it doesn't seem to be automatically activated when using some $c00000 fake fast + at least ECS Agnus in Winuae configuration (as it should be).

[Toni Wilen]

Unfortunately it doesn't seem to be automatically activated when using some $c00000 fake fast + at least ECS Agnus in Winuae configuration (as it should be).

It is enabled only in A500 compatible modes and config must be exactly ECS Agnus + 0.5M chip 0.5M slow.

[hitchhikr]

Unless i missed something this doesn't seem to work in WinUAE (but works perfectly on my A500):

http://franck.charlet.pagesperso-ora.../fake_chip.zip

[Toni Wilen]

Originally Posted by hitchhikr

Unless i missed something this doesn't seem to work in WinUAE (but works perfectly on my A500):

http://franck.charlet.pagesperso-ora.../fake_chip.zip

I don't see anything in the exe that moves the copper list to c50000 (yes, there is org in assembly but nothing interesting in exe..), did you really test the exe after powering off and then back on your a500

[hitchhikr]

Oki, i assumed you would assemble it directly, second try:

http://franck.charlet.pagesperso-ora...p/fakechip.zip

Edit: now it looks like you modified the way to enable that feature so it's automatic (there was some tricky manipulation to do before).

[Toni Wilen]

Originally Posted by hitchhikr

Oki, i assumed you would assemble it directly, second try:

http://franck.charlet.pagesperso-ora...p/fakechip.zip

I always take the easiest route and ready-made exe is much faster than recompilation

Works fine as expected, black screen and background color changes if I modify the background color move in copperlist.

[hitchhikr]

The manipulation is still here apparently (something like setting the chip ram to 1mb, reset, set it to 512k, reset).

[Toni Wilen]

Originally Posted by hitchhikr

The manipulation is still here apparently (something like setting the chip ram to 1mb, reset, set it to 512k, reset).

A500. "1.3 ROM, ECS Agnus, 512 KB Chip RAM + 512 KB Slow RAM" quickstart works fine. Any other way is unsupported and this is never going to be supported on the fly.

[hitchhikr]

I agree that the $c00000 memory trick was only available for A500 with newer Agnus (probably the most widespread Amiga model) but why isn't it activated automatically with the config you described ? (also i think it also worked when fast ram was plugged into the side expansion port (usually starting at $200000)).

[Toni Wilen]

Originally Posted by hitchhikr

I agree that the $c00000 memory trick was only available for A500 with newer Agnus (probably the most widespread Amiga model) but why isn't it activated automatically with the config you described ? (also i think it also worked when fast ram was plugged into the side expansion port (usually starting at $200000)).

Huh? It works automatically using above quickstart setting which is currently the only supported way to enable this hack. (other methods may or may not work)

You are out of luck if you want to use it in any other configuration (that might work on real thing) Chipset/CPU emulation really isn't made for this kind of aliasing and I don't want to make things even more messier just for improving emulation of this trick.

What are you exactly trying to do? "Not working" is not a bug report or any kind of report

(I guess these posts should be moved to separate thread or something)

Resurrecting this thread in search of information.

What I'm looking for is the workings of the blitter in line mode, for emulation purposes.

The problem is, in line mode, the blitter reads/writes the same words multiple times, for each pixel, and is supposed to take 4 blitter cycles per pixel. The 'normal mode' A-CD blit takes 3 per word.

Existing emulators, plus the minimig, just "make it take" 4 cycles per pixel for lines, but I'm looking for how it really works, pipelining and all.

I consider the normal-mode A-CD cycle sequence something like this:

A-CD:
A0R C0R --- A1R C1R D0W A2R C2R D1W A3R C3R D2W --- D3W
    A0S D0M --- A1S D1M --- A2S D2M --- A3S D3M

R = read, W = write, S = shift, M = minterm

(I'm assuming here that there's an upper and a lower part of the pipeline, and every blitter cycle can execute one of each. DMA (R/W) is upper, and shift/minterm (S/M) is lower, I may be wrong)

This doesn't cut it for line drawing, since C is read before D is written, so the last pixel written does not appear in the newly read C (plus, spec says 4 cycles per pixel).

The B channel is still shifted in line mode, so an extra "lower" blitter cycle can be inserted (and upper have to get an empty cycle to follow), but it still does not provide for enough room to write D before C is read.

Is there any deeper knowledge of line-drawing cycle sequence?

[Toni Wilen]

In my opinion this has not been so undocumented for some time now (http://eab.abime.net/showpost.php?p=416779)

Standard line draw cycle sequence is simple -C-D-C-D (confirmed on logic analyzer. It is NOT more logical pipelined -C-C-D-C-D-D) It is always 4 cycles.

Note that BLTCON0 channel selection bits don't work normally in line mode either. A needs to be enabled (or line will be drawn incorrectly) but it is never used for DMA transfers. BLTCON0 D bit can be disabled and linedraw still works correctly! (at least C is required or nothing gets drawn)

EDIT: -> it should be perfectly emulated in WinUAE and most likely in Minimig too.

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

Ah, right - channel A is used but no DMA - I know this, but somehow I forgot
That makes it all fit better, thank you. I was too busy staring at the A-CD normal mode cycles.

That could make my cycles come out like this (predictions):

--- C0R --- D0W --- C1R --- D1W ---
A0S --- D0M --- A1S --- D1M --- A2S

, or more likely, since C channel data should travel directly to D:

--- C0R --- D0W --- C1R --- D1W ---
A0S D0M --- --- A1S D1M --- --- A2S

which looks strange with an empty cycle. I'm missing a logic operation - Could be a C logic (but non-pipelined) step that's absent in normal-mode (SUD,SUL,AUL logic?).

Then to fit in the fact that first pixel is written to D pointer, the rest to C pointer...
Ah, the worries, but I have a fascination for the blitter and am trying to find a mechanism in which the cycles turn out 'right' as a matter of consequence, not design

Emulation is aiming to have no cycle-controlling via tables or states.
Two pipelining stages per channel, dma and logic. Value travels from dma to logic, except for D which is opposite. So for one word, B can be read while A is shifted, etc.