CyberStormPPC/BlizzardPPC register information reversing

[Toni Wilen]

Originally Posted by phx

Ok, this is something I can try, when I have some more time. Maybe over the weekend.
Is it sufficient to run PPC code with M68k interrupt master?

Yes, m68k as interrupt master is better choice to mimic PowerUP (and WarpOS) environment. I think all code that sets PPC as interrupt master also stop the m68k.

I think at least following tests should be done:

- Does clearing bit 0 of REG_LOCK do anything at all? What if exact same sequence is done (write 0x85 to IPL_EMU four times, then clear REG_LOCK).
- Can P5_DISABLE_INT be modified when PPC is active. Nothing happens when I try to change it, bit always stays set. And does it really stop interrupts?
- Can M68K_IPLx values be modified. Don't seem to be possible at least under M68K CPU. (I assume they are always read-only)
- Does SELF_RESET actually do anything at all?

I also assume only phase5 and "official" p5 developers knew about that mysterious bit. For example WarpOS does not modify it. (At least I haven't noticed any accesses)

[amilo3438]

Originally Posted by jbenam

Maybe Sam Jordan (the author of WarpOS) could help you, Toni? I've found his email address...

Originally Posted by phx

I knew him very good during his Amiga time (I wrote the WarpOS memory management and ppclibemu for him).

Frank(ly), is really ?! (I just wanted to ask if the author of ppclibemu and BPPCfix might be of help)

Btw. also thanks for helping Toni on this problem.

Originally Posted by phx

I talked last to Sam more than four years ago. He left the Amiga more than a decade ago. He even left software development and earned a degree in Physics at a dutch University, where he probably is still working.

Yes, but theoretical physics at the University of Zurich, right? -> http://www.sam-jordan.ch/software.htm

Originally Posted by phx

Nevertheless, even if he could remember anything, which I doubt, he took the same reengineering approach as Toni does now.

I am not sure about reengineering approach ?

Because, according to above link (check under "PowerASM)" he got access to prototype hardware, which allowed him to play with the PowerPC CPU's much time before endusers could buy the final hardware products. (and probably got some more infos about from board developer, I guess)

Originally Posted by phx

Only Ralph Schmidt and a few other Phase5 employees have the real information.

Perhaps, but according the above project list, Sam might be also of help specially with his good knowledge about PowerPC (didnt he wrote PowerASM & WarpOS) and thus we will newer know if he is interested to project while it does not check, right ? (now we can only guess)

[jbenam]

Originally Posted by phx

Are you sure it is the recent one?

Not really sure of that - he posted it on a Wikipedia Talk page around 4 years ago.

Originally Posted by phx

He left the Amiga more than a decade ago.

Looks like he was back for a while in 2012 to work on UltimatePPC (which looks to be dead in the water) http://www.amiga.org/forums/showpost...&postcount=139

Now enough off-topic or Toni will punish us

[phx]

Originally Posted by amilo3438

Yes, but theoretical physics at the University of Zurich, right? -> http://www.sam-jordan.ch/software.htm

He moved to Utrecht for being promoted (how is it called in english?) after that. From his home page:

At March 1st in 2009 I moved to Utrecht in the Netherlands to start working as a doctoral student in the Quantum Gravity group at the Utrecht University.

So it must have been in 2009 when I last talked to him. He wanted to give me his old Amigas.

I am not sure about reengineering approach ?

Because, according to above link (check under "PowerASM)" he got access to prototype hardware

Yes, but you can be very sure that Phase5 didn't include any hardware description. An alpha version of PowerUp was included. That's all.

[amilo3438]

Originally Posted by phx

He moved to Utrecht for being promoted (how is it called in english?) after that. From his home page:

Oh yes, it is mentioned on his home (main) page. (somehow I missed that info)

Originally Posted by phx

Yes, but you can be very sure that Phase5 didn't include any hardware description. An alpha version of PowerUp was included. That's all.

Perhaps you re right. Anyway, as Toni just mentioned, WarpUP seems working fine! (great)

[phx]

Originally Posted by Toni Wilen

Yes, m68k as interrupt master is better choice to mimic PowerUP (and WarpOS) environment.

I chose PowerUp for my first tests. WarpOS does not work, because it sets up the MMU to protect the $f60000 page.

- Can P5_DISABLE_INT be modified when PPC is active. Nothing happens when I try to change it, bit always stays set. And does it really stop interrupts?

Yes. It can be modified. From both CPUs, as soon as the PowerUp kernel is active. I wonder what makes it changeable. When PowerUp starts, it clears bit 1 of REG_INT, activating P5_ENABLE_IPL. P5_DISABLE_INT becomes 0. But when I clear P5_ENABLE_IPL after a reboot, without the PPC running, then P5_DISABLE_INT is still stuck at 1.

When I bring P5_DISABLE_INT back to 1, when PowerUp is running, then all PPC processes are frozen. So it definitely has an effect on the PPC. The M68k interrupts are still working.

[Toni Wilen]

I debugged some more and noticed that 68K code also modifies f60020 bit 0. And sometimes BPPC boot code and ppctest.dms powerup tests succeed, even if I ignore bit 0. It seems to be timing sensitive.

Not very optimal code..

68EB54CE 48e7 000e                MOVEM.L A4-A6,-(A7)
68EB54D2 2a4e                     MOVEA.L A6,A5
68EB54D4 7001                     MOVE.L #$00000001,D0
68EB54D6 b0ad 015c                CMP.L (A5, $015c) == $6803555e,D0
68EB54DA 6610                     BNE.B #$00000010 == $68eb54ec
68EB54DC 287c fff1 0082           MOVEA.L #$fff10082,A4
68EB54E2 4e71                     NOP
68EB54E4 18bc 0040                MOVE.B #$40,(A4)
68EB54E8 4e71                     NOP
68EB54EA 6026                     BT .B #$00000026 == $68eb5512
68EB54EC 7002                     MOVE.L #$00000002,D0
68EB54EE b0ad 015c                CMP.L (A5, $015c) == $6803555e,D0
68EB54F2 6610                     BNE.B #$00000010 == $68eb5504
68EB54F4 287c 00f6 0020           MOVEA.L #$00f60020,A4
68EB54FA 4e71                     NOP
68EB54FC 18bc 0001                MOVE.B #$01,(A4)
68EB5500 4e71                     NOP
68EB5502 600e                     BT .B #$0000000e == $68eb5512
68EB5504 287c 00f6 0020           MOVEA.L #$00f60020,A4
68EB550A 4e71                     NOP
68EB550C 18bc 0001                MOVE.B #$01,(A4)
68EB5510 4e71                     NOP
68EB5512 4cdf 7000                MOVEM.L (A7)+,A4-A6
68EB5516 4e75                     RTS

68EB5518 48e7 000e                MOVEM.L A4-A6,-(A7)
68EB551C 2a4e                     MOVEA.L A6,A5
68EB551E 7001                     MOVE.L #$00000001,D0
68EB5520 b0ad 015c                CMP.L (A5, $015c) == $6803555e,D0
68EB5524 6610                     BNE.B #$00000010 == $68eb5536
68EB5526 287c fff1 0082           MOVEA.L #$fff10082,A4
68EB552C 4e71                     NOP
68EB552E 18bc 00c0                MOVE.B #$c0,(A4)
68EB5532 4e71                     NOP
68EB5534 6026                     BT .B #$00000026 == $68eb555c
68EB5536 7002                     MOVE.L #$00000002,D0
68EB5538 b0ad 015c                CMP.L (A5, $015c) == $6803555e,D0
68EB553C 6610                     BNE.B #$00000010 == $68eb554e
68EB553E 287c 00f6 0020           MOVEA.L #$00f60020,A4
68EB5544 4e71                     NOP
68EB5546 18bc 0081                MOVE.B #$81,(A4)
68EB554A 4e71                     NOP
68EB554C 600e                     BT .B #$0000000e == $68eb555c
68EB554E 287c 00f6 0020           MOVEA.L #$00f60020,A4
68EB5554 4e71                     NOP
68EB5556 18bc 0081                MOVE.B #$81,(A4)
68EB555A 4e71                     NOP
68EB555C 4cdf 7000                MOVEM.L (A7)+,A4-A6
68EB5560 4e75                     RTS

Especially these two functions..:

68EB54B6 48e7 0006                MOVEM.L A5-A6,-(A7)
68EB54BA 2a4e                     MOVEA.L A6,A5
68EB54BC 4cdf 6000                MOVEM.L (A7)+,A5-A6
68EB54C0 4e75                     RTS

68EB54C2 48e7 0006                MOVEM.L A5-A6,-(A7)
68EB54C6 2a4e                     MOVEA.L A6,A5
68EB54C8 4cdf 6000                MOVEM.L (A7)+,A5-A6
68EB54CC 4e75                     RTS

[Toni Wilen]

Those two functions are in ppc.library but they are marked private between PPCSetAttrs and PPCCacheTrashE. Bah.

...
#pragma libcall PPCLibBase PPCSetAttrs 19e 801
/* Private entries
* 1a4
* 1aa
*/
#pragma libcall PPCLibBase PPCCacheTrashE 1b0 10803
...

EDIT: It may be some kind of semaphore feature (CPU that clears the bit prevents other CPU from doing any memory accesses?). There is code sequence like this:

ppc.library/1a4
exec.library/Remove
ppc.library/1aa

EDIT2: It has to be hardware semaphore. I think this problem is now solved.

It would be interesting to see if you can lock yourself out by clearing the bit twice (Probably not)

[Toni Wilen]

P5_SELF_RESET function found: It is protected bit (need unlock sequence to set/reset it) and it needs to be cleared or P5_AMIGA_RESET bit does nothing.

For some reason display blanks for few seconds if I try to clear P5_AMIGA_RESET without P5_SELF_RESET, without reseting anything at all. Possibly something to do with Indivision AGA MK2. If P5_SELF_RESET is cleared, P5_AMIGA_RESET does reset whole system.

P5_M68K_RESET does nothing, P5_SELF_RESET cleared or set. Perhaps it only works when P5_M68K_RESET is cleared by PPC CPU? I am not sure if it also needs P5_SELF_RESET.

P5_AUX_RESET and P5_SCSI_RESET does not require P5_SELF_RESET bit.

[phx]

Originally Posted by Toni Wilen

ppc.library/1a4
exec.library/Remove
ppc.library/1aa

EDIT2: It has to be hardware semaphore. I think this problem is now solved.

Confirmed! When I clear bit 0 of REG_LOCK on the 68k, then the PPC stops and continues working as soon as I set the bit. It also works from the PPC side. When setting it the 68k is stopped (which results in a system freeze, as PowerUp is controlled by 68k), but I verified that the PPC continues working after that.

It would be interesting to see if you can lock yourself out by clearing the bit twice (Probably not)

Twice on the same CPU? No, that makes no difference. On different CPUs? No, that's not possible as the other CPU is stopped.

[phx]

Originally Posted by Toni Wilen

P5_SELF_RESET function found: It is protected bit (need unlock sequence to set/reset it) and it needs to be cleared or P5_AMIGA_RESET bit does nothing.

That would make sense, but unfortunately this is not what happens here.
I reassured myself that P5_SELF_RESET is set. Then I cleared P5_AMIGA_RESET, and my A3000 resets.

For some reason display blanks for few seconds if I try to clear P5_AMIGA_RESET without P5_SELF_RESET, without reseting anything at all. Possibly something to do with Indivision AGA MK2. If P5_SELF_RESET is cleared, P5_AMIGA_RESET does reset whole system.

Hmm. This is an A4000? Maybe there is a difference in the reset logic between the models.

P5_M68K_RESET does nothing, P5_SELF_RESET cleared or set. Perhaps it only works when P5_M68K_RESET is cleared by PPC CPU? I am not sure if it also needs P5_SELF_RESET.

P5_M68K_RESET and P5_PPC_RESET do not depend on P5_SELF_RESET (although this is hard to tell on my system, see above .
I'm using P5_M68K_RESET to stop the M68k when the NetBSD/amigappc kernel starts. As far as I can see this works fine. Otherwise the 68k would continue flashing the background colours, which it doesn't. This is how I launch the PPC kernel from the 68k:

        ; reset PPC, which runs into our bootstrap routine at the Reset vector
        lea     P5_BASE,a5
        move.b  #P5_CLR|P5_PPC_RESET,P5_REG_RESET(a5)
        nop
        move.b  #P5_CLR|P5_ENABLE_IPL,P5_REG_INT(a5)
        nop
        move.b  #$a8,P5_REG_ENABLE(a5)
        nop
        move.b  #$10,P5_REG_ENABLE(a5)
        nop
        move.b  #P5_SET|P5_DISABLE_INT,P5_IPL_EMU(a5)
        nop
        move.b  #P5_SET|P5_PPC_RESET,P5_REG_RESET(a5)
        nop

        ; wait for the PowerPC to kill us...
        stop    #$271f
err:    move.w  #$888,$180(a6)
        move.w  #$f00,$180(a6)
        bra     err

[phx]

Concerning P5_M68K_IPL:
These three bits are read-only and reflect the current IPL state on the mainboard. When an interrupt occurs, the PPC can read these bits to know which interrupt level it was.
P5_PPC_IPL is for masking interrupt levels on the PPC.

[Toni Wilen]

Originally Posted by phx

Concerning P5_M68K_IPL:
These three bits are read-only and reflect the current IPL state on the mainboard. When an interrupt occurs, the PPC can read these bits to know which interrupt level it was.
P5_PPC_IPL is for masking interrupt levels on the PPC.

Can you confirm M68K_IPL bits only change when PPC CPU reads them? They seem to be stuck at all ones when M68K reads them, even inside interrupt routine.

Emulation does this and it seems to work.

Originally Posted by phx

Confirmed! When I clear bit 0 of REG_LOCK on the 68k, then the PPC stops and continues working as soon as I set the bit. It also works from the PPC side. When setting it the 68k is stopped (which results in a system freeze, as PowerUp is controlled by 68k), but I verified that the PPC continues working after that.

Stops immediately or when it tries to do next memory access? (Maybe difficult to test, maybe by making sure test code is in instruction cache?)

Hmm. This is an A4000? Maybe there is a difference in the reset logic between the models.

Yes, desktop A4000. It just does that weird display blanking, nothing else.. (if P5_SELF_RESET is set to one)

I can try to do A3000 test but I am not sure if I am bothered to set correct jumpers..

P5_M68K_RESET and P5_PPC_RESET do not depend on P5_SELF_RESET

BPPC boot code also changes PPC_RESET without clearing P5_SELF_RESET.

[phx]

Originally Posted by Toni Wilen

Can you confirm M68K_IPL bits only change when PPC CPU reads them? They seem to be stuck at all ones when M68K reads them, even inside interrupt routine.

I can confirm that M68k_IPL bits change. But the PPC has to be interrupt master to make it work. Reading these bits by a PowerUp or WarpOS process shows no change.
I inserted a printf in amiga_get_irq() in the NetBSD/amigappc kernel. It definitely prints the current interrupt level.

Emulation does this and it seems to work.

Yes. WarpOS or PowerUp don't need these bits.

Stops immediately or when it tries to do next memory access? (Maybe difficult to test, maybe by making sure test code is in instruction cache?)

Yes. That's really difficult. And even if I make it execute in the cache, how do I determine and remember my result?

[Toni Wilen]

Originally Posted by phx

Yes. That's really difficult. And even if I make it execute in the cache, how do I determine and remember my result?

What about something like this:

Run PPC code that has as small loop as possible that takes at least 5+ seconds to finish, it must only modify CPU registers. After loop ends, save some status value ("loop done") to memory, exit.

After PPC code has been started, m68k CPU should near immediately clear REG_LOCK bit 0. Wait 10 seconds, set REG_LOCK bit 0. If PPC code finishes immediately, CPU was still executing, CPU was stopped if it does not finish immediately.

I expect it to be memory accesses blocking only, memory controller already needs to prevent simultaneous memory accesses from both CPUs.

[phx]

Ok, I did that. Unfortunately the result is not what you expected. Seems that the PPC is halted, and the rest of the loop continues after I have set bit 0 of REG_LOCK again (with the M68k).

Usually the code must run in the cache. I made the following PowerUp program:

        .text
        .globl  start
start:
        nop
        lis     r3,0x1f0000@h
        li      r0,0
        stw     r0,0(r3)
        li      r0,-1
        lis     r4,0x80000000@h
loop:   subic.  r4,r4,1
        bne     loop
        stw     r0,0(r3)
        sync
        li      r3,0
        blr

The loop executes for nearly 10 seconds on a 200MHz 604e. After 1 second I cleared bit 0 of REG_LOCK. Then, after 30 seconds, I have set the bit again - and had to wait for another 9 seconds before the PPC program returned...

I made another interesting observation: when clearing bit 0 of REG_LOCK then it also locks out something else. I guess that Cyberstorm-SCSI is locked, because nothing happens anymore, when I access the disk.

[Ratte]

Originally Posted by Toni Wilen

For some reason display blanks for few seconds if I try to clear P5_AMIGA_RESET without P5_SELF_RESET, without reseting anything at all. Possibly something to do with Indivision AGA MK2. If P5_SELF_RESET is cleared, P5_AMIGA_RESET does reset whole system.

You are right, its MKII(cr) related. Same phaenomen with WhichAmiga running on AGA - MKII.
I think it has something to do with the LACE, during WhichAmiga-tests the LACE is interruppted for a short moment, but enough to start the MKII-screenmode scanning (blank).

[Ratte]

Regarding unaccessible pci-roms on grex-pci-bridges.

I found out that there might be some kind of mmu-protection around pci-devices used in a grex-board.
Is not easy to get in touch with a rom from a installed pci-device (graphiccards).

Following the pci-specs its easy to point the xrombar to somewhere in the (unused) memorymap and perform a read on it (to build a shadowrom).
After reading the rom, the xrombar must be disabled and the normal bar must be reactivated for normal memoryaccess (graphicsmem).
The grex-problem .... its possible to act normal with the xrombar and bar registers, but the rom is INVISIBLE.

Now pci-specs told us, that you can read a rom or access the memory, but not both at the same time.
So i decided to check what will happen, if i set the xrombar to the memarea where the (deactivated) bar is pointing to ... and voilà ... finally the pci-rom is visible!
Pointing with xrombar to the same area like the deactivated bar (graphicsmem).

Next steps are daily business ... copying the rom to somewhere in the ram .. disable xrombar, activated (mem)bar and so on ...

I just send a message to Radoslaw (strim?) for the netbsd-grex-port.
Maybe on day, the os4-team is able to handle a grex-pci-bridge.

[Toni Wilen]

Unknown bits that MorphOS for classic sets very early in boot process (before hanging):

REG_IRQ (0xf60008) bit 5 is set. (Sets bit 3 and 5, clears 4)
REG_INT (0xf60028) bit 2 is set.

Must be some unknown interrupt "mode" or something..

[DarrenHD]

Originally Posted by Ratte

Regarding unaccessible pci-roms on grex-pci-bridges.

I found out that there might be some kind of mmu-protection around pci-devices used in a grex-board.
Is not easy to get in touch with a rom from a installed pci-device (graphiccards).

Following the pci-specs its easy to point the xrombar to somewhere in the (unused) memorymap and perform a read on it (to build a shadowrom).
After reading the rom, the xrombar must be disabled and the normal bar must be reactivated for normal memoryaccess (graphicsmem).
The grex-problem .... its possible to act normal with the xrombar and bar registers, but the rom is INVISIBLE.

Now pci-specs told us, that you can read a rom or access the memory, but not both at the same time.
So i decided to check what will happen, if i set the xrombar to the memarea where the (deactivated) bar is pointing to ... and voilà ... finally the pci-rom is visible!
Pointing with xrombar to the same area like the deactivated bar (graphicsmem).

Next steps are daily business ... copying the rom to somewhere in the ram .. disable xrombar, activated (mem)bar and so on ...

I just send a message to Radoslaw (strim?) for the netbsd-grex-port.
Maybe on day, the os4-team is able to handle a grex-pci-bridge.

Hi Ratte, further to the NetBSD documentation in setting up the GREX here is some of the code:

1/
move.l #$FFFE0000,a0
move.l (a0),d1
nop
andi.l #$80000020,d1

2/
move.l #$FFFE0000,a0
moveq #2,d0
move.l d0,(a0)
nop
move.l #$FFFE0010,a0
moveq #1,d0
move.l d0,(a0)
nop
move.l #$FFFE0020,a0
moveq #1,d0
move.l d0,(a0)
nop

3/
move.l #$FFFE0000,a0
move.l (a0),d7
nop
clr.w d7
swap d7
lsr.l #8,d7
moveq #$F,d1
and.l d1,d7
moveq #2,d0
cmp.l d0,d7
bcs.b JL_0_31C
move.l #$FFFE0040,a0
move.l d0,(a0)
nop

4/
lea $FFFE0000,a1
nop
move.l (a1),d2
nop
swap d2
andi.l #$000000FF,d2
bne.b JL_0_20E4
nop
clr.l $30(a1)
nop
move.l (a1),d2
nop
andi.l #$00000003,d2
bne.b JL_0_20E4
nop
move.l #$00000003,$30(a1)
nop
move.l (a1),d2
nop
andi.l #$00000003,d2
cmpi.w #$0003,d2
bne.b JL_0_20E4
moveq #1,d0
JL_0_20DA
move.l d1,8(a0)
movem.l (sp)+,d2/a5-a6
rts
JL_0_20E4
moveq #0,d0

5/

We are trying to preserve the information for the Amiga community so it is not lost as source code is lost or knowledge lost by people passing away, etc. I know it is a long shot, We suspect there are additional registers 020, 030, 040:

0xFFFE0000 = 2 (Endian swapper, write 0x02 to switch bridge into big endian mode)
0xFFFE0010 = 1 (Interrupt Enable - write 0x01 to enable Interrupts (INT2 on Amiga side)
0xFFFE0020 = 1 ?
0xFFFE0030 = 3 ?
0xFFFE0040 = 2 ?

Any help you could give would be most appreciated....