CyberStormPPC/BlizzardPPC register information reversing

[Toni Wilen]

I am still stuck with undocumented register bits..

PPC code first does something (reads and writes to FFF0xxxx memory which appears to work correctly), then it does following CyberstormPPC/BlizzardPPC register writes:

Write 0x85 to F60030 (IPL EMU)
Write 0x85 to F60030
Write 0x85 to F60030
Write 0x85 to F60030
Write 0x01 to F60020 (LOCK)

Above PPC code looks very boring, all written values are hardcoded: (Yes, PPC disassembler has been added. Unfortunately.)

FFF04964  38000085  li          r0, 133
FFF04968  98040030  stb         r0, 48 (r4)
FFF0496C  7C0004AC  sync
FFF04970  98040030  stb         r0, 48 (r4)
FFF04974  7C0004AC  sync
FFF04978  98040030  stb         r0, 48 (r4)
FFF0497C  7C0004AC  sync
FFF04980  98040030  stb         r0, 48 (r4)
FFF04984  7C0004AC  sync
FFF04988  38000001  li          r0, 1
FFF0498C  98040020  stb         r0, 32 (r4)
FFF04990  4C00012C  isync
FFF04994  7C0004AC  sync
FFF04998  4E800020  blr

Write to IPL EMU makes no sense, bit 7 is set so it is "set" mode, but IPL EMU already has all 3 low bits set by earlier boot code. There has to be some unknown side-effect.

LOCK bit 0 is totally undocumented. I assume it is some kind of strobe bit for triggering interrupt. But what kind of interrupt? I tried to trigger m68k level 2 interrupt (m68k has PPC related interrupt added), setting correct bits in F60008 so that interrupt handler accepts it but unfortunately interrupt handler only gets confused and accesses uninitialized memory. So apparently it isn't expecting interrupt, at least not yet.

BPPC boot PPC code and ppctest.dms PowerUP test run identical code sequence.

[phx]

Originally Posted by Toni Wilen

/* IPL_EMU 0x30 */
#define P5_DISABLE_INT 0x40 // if set: all CPU interrupts disabled
#define P5_M68K_IPL2 0x20
#define P5_M68K_IPL1 0x10
#define P5_M68K_IPL0 0x08
#define P5_PPC_IPL2 0x04
#define P5_PPC_IPL1 0x02
#define P5_PPC_IPL0 0x01
#define P5_IPL_MASK 0x07
/* INT_LVL 0x38 */
#define P5_LVL7 0x40
#define P5_LVL6 0x20
#define P5_LVL5 0x10
#define P5_LVL4 0x08
#define P5_LVL3 0x04
#define P5_LVL2 0x02
#define P5_LVL1 0x01

Something to do with interrupts but are they input or output or both?

Both.

As you know, unfortunately nothing is official. This is reverse engineered information, which I have found in AmigaOS4, Linux and NetBSD. I even wrote most of the NetBSD code for the CSPPC-port myself, but it is not working very well...

Mainboard inputs?

The P5_cpu_IPLn bits reflect the status of the 68k interrupt mask from the SR register. As you know the PPC has no SR register and no interrupt mask. The 603/604 chips only support a single external interrupt line, which can be masked by the EE bit in MSR, so Phase5 had to find a way to simulate the IPL0..IPL2 lines for the PPC.

On CSPPC/BPPC Amigas there can be only one interrupt master CPU. Either the M68k is interrupted or the PPC. It can be controlled by the P5_INT_MASTER bit (when clearing the bit, the master is PPC). In PowerUp/WarpOS mode the interrupt master is still the M68k, while in a PPC-OS (OS4, NetBSD, Linux) the interrupt master is the PPC.

As I understand, depending on the master-bit, you use either the P5_M68k_IPLn or P5_PPC_IPLn mask. A PPC interrupt master will use these lines to directly set the IPLn lines on the mainboard, which the disabled M68k no longer can do. This means when the PPC receives a serial level 6 interrupt it has to set P5_PPC_IPLn to 6, exactly like a M68k would do.

I can only guess about the M68k-master mode. I think the P5_M68K_IPLn bits only reflects the status of the M68k SR register, in case the PPC needs it.

Does writing cause interrupts?

Writing to IPL_EMU? No. See above.

Writing to IPL_LVL...? Hmm. No.
My guess is that you can use it to enable which individual interrupt levels are allowed to trigger the PPC's external interrupt line. In NetBSD I'm enabling all levels on startup. May be only relevant for PPC interrupt master mode.

[Toni Wilen]

Originally Posted by phx

As you know, unfortunately nothing is official. This is reverse engineered information, which I have found in AmigaOS4, Linux and NetBSD. I even wrote most of the NetBSD code for the CSPPC-port myself, but it is not working very well...

Yeah, something very important is missing, for example F60020 bit 0 is totally unknown and it has to do something with interrupts.

F60008 bits 2 and 3 are most likely PPC to M68K interrupt output enable and active bit (just like bits 0 and 1 are enable/active bits for SCSI interrupt), causing m68k int level 2 when both are active.

A PPC interrupt master will use these lines to directly set the IPLn lines on the mainboard, which the disabled M68k no longer can do.

But m68k IPL lines are input only (they are physically input only). Paula is the only IPL output. There is no way this register is used to set IPL lines as output. Even if it affects only onboard m68k (so it is not conflicting with Paula's IPL outputs), KS interrupt routine would still ignore them as spurious interrupts because Paula INTREQR/INTENAR bits are checked.

My guess is that you can use it to enable which individual interrupt levels are allowed to trigger the PPC's external interrupt line

I agree. Early boot code uses this register as a 7 bit storage for keyboard keys (esc, s, etc..) which means it has to be normal read/write register and it can't affect m68k side.

[phx]

Originally Posted by Toni Wilen

F60008 bits 2 and 3 are most likely PPC to M68K interrupt output enable and active bit (just like bits 0 and 1 are enable/active bits for SCSI interrupt), causing m68k int level 2 when both are active.

That's interresting. I hope that some more details will be revealed during this project.

But m68k IPL lines are input only (they are physically input only).

Yes, sorry. I wrote nonsense. I just wanted to fix my last posting.

By using P5_PPC_IPL the PPC just emulates the missing M68k SR register. So writing to it masks out lower interrupt levels in the same way as the M68k could do by writing SR.

P5_INTLVL: Early boot code uses this register as a 7 bit storage for keyboard keys (esc, s, etc..) which means it has to be normal read/write register and it can't affect m68k side.

Right, you can store 7 bits there, when the M68k is master. But it has a SET_CLEAR bit, like the other registers.

[Toni Wilen]

ppctest.dms WarpOS test now passes!

It seems INT_LVL isn't for allowing/not allowing interrupts, I think it is used to activate PPC interrupt: If any bit 0 to 6 is active in INT_LVL AND IPL_EMU is less than any active INT_LVL interrupt number AND P5_ENABLE_IPL is active: PPC CPU interrupt line becomes active. (active as in bit is cleared, active low).

This allows WarpOS test to work. It sets INT_LVL to 0x7f (all inactive), enables P5_ENABLE_IPL, sets IPL_EMU to 7 (IPL level 0). Later when 68k code wants to wake up PPC code, it clears INT_LVL bit 0. PPC interrupt code runs which sets it back to one.

PowerUP does it totally differently..

btw, I guess this method only works when 68K is interrupt master. (68k gets "real" Paula interrupts)

[phx]

Originally Posted by Toni Wilen

F60008 bits 2 and 3 are most likely PPC to M68K interrupt output enable and active bit (just like bits 0 and 1 are enable/active bits for SCSI interrupt), causing m68k int level 2 when both are active.

Just realized that I have no information about the bits P5_REG_ENABLE at all. Is this correct?

Bit 7 set/clear
Bit 3 PPC to M68k interrupt request? (active low?)
Bit 2 PPC to M68k interrupt enable (active low?)
Bit 1 SCSI interrupt request (active low?)
Bit 0 SCSI interrupt enable (active low?)

Both interrupts are mapped to the level 2 interrupt line?

Originally Posted by Toni Wilen

It seems INT_LVL isn't for allowing/not allowing interrupts, I think it is used to activate PPC interrupt: If any bit 0 to 6 is active in INT_LVL AND IPL_EMU is less than any active INT_LVL interrupt number AND P5_ENABLE_IPL is active: PPC CPU interrupt line becomes active. (active as in bit is cleared, active low).

Ok, great! That could make sense.
So P5_ENABLE_IPL=0 enables the function of IPL_EMU and INT_LVL. But which part of IPL_EMU are you talking about? M68K_IPL or PPC_IPL?

This allows WarpOS test to work. It sets INT_LVL to 0x7f (all inactive), enables P5_ENABLE_IPL, sets IPL_EMU to 7 (IPL level 0). Later when 68k code wants to wake up PPC code, it clears INT_LVL bit 0. PPC interrupt code runs which sets it back to one.

So this is probably the only kind of interrupt the PPC has to handle under WarpOS?

btw, I guess this method only works when 68K is interrupt master. (68k gets "real" Paula interrupts)

So P5_INT_MASTER is 1 under WarpOS, as expected?
The INT_LVL bits are always set to 0x7f under OS4 and NetBSD. No idea what happens when you manipulate them there with a PPC interrupt master. I guess that P5_ENABLE_IPL was inactive, when INT_LVL was used to store keycodes?

[Toni Wilen]

I think this topic should be separate. Moved from beta thread. (EDIT: I'll reply to your question later)

[Toni Wilen]

Originally Posted by phx

Just realized that I have no information about the bits P5_REG_ENABLE at all. Is this correct?

Bit 7 set/clear
Bit 3 PPC to M68k interrupt request? (active low?)
Bit 2 PPC to M68k interrupt enable (active low?)
Bit 1 SCSI interrupt request (active low?)
Bit 0 SCSI interrupt enable (active low?)

Both interrupts are mapped to the level 2 interrupt line?

I think so. Only proof I have so far is powerup interrupt handler code (level 2) that exists immediately if bit 2 or bit 3 is not cleared. (Same test method as SCSI river does, only different bits). If both are cleared, request bit is set and interrupt is handed.

Ok, great! That could make sense.
So P5_ENABLE_IPL=0 enables the function of IPL_EMU and INT_LVL. But which part of IPL_EMU are you talking about? M68K_IPL or PPC_IPL?

PPC_IPL (low 3 bits). I think M68K_IPL is always mirror of m68k physical line state.

So this is probably the only kind of interrupt the PPC has to handle under WarpOS?

Probably. It sets level 1 interrupt (SOFT, INTENA bit 2) and PPC code simply writes 0x8004 to INTREQ when it wants to interrupt m68k. Very simple and basic stuff here.

So P5_INT_MASTER is 1 under WarpOS, as expected?

Yes. m68k is always master, warpos or powerup. (at least so far it seems to be true)

The INT_LVL bits are always set to 0x7f under OS4 and NetBSD. No idea what happens when you manipulate them there with a PPC interrupt master.

Thats a good question but should be easy to test, write something to INT_LVL and see if kernel complains about spurious interrupts?

I guess that P5_ENABLE_IPL was inactive, when INT_LVL was used to store keycodes?

Yes and PPC CPU is also in stopped state (reset line active) until first PPC program gets executed so it shouldn't matter even if ENABLE_IPL is active.

[Toni Wilen]

Did some real CSPPC tests.

REG_LOCK: Bit 0 is the only one that can be changed. (Write 0x81 -> gets set to 1 and 0x01 -> cleared). Other bits won't change. This register is normally used to unlock flash chip write mode by writing "magic" values in sequence. (0x60, 0x50, 0x30)

IPL_EMU m68k IPL bits seems to be stuck at 7, writing won't change them, reading them in interrupt routine (I used level 3) still returned 7.. Even when ENABLE_IPL was active. DISABLE_INT bit is also stuck at 1. So apparently it is read-only too and perhaps DISABLE_INT and m68k IPL bits only work when PPC is active? (Or maybe even when PPC is interrupt master?)

REG_IRQ: Clearing both bits 3 and 4 (not 2 and 3) are confirmed causing an interrupt. System froze when I cleared both Bits 2 and 5 can be also set or cleared. Bit 6 is stuck at zero.

Speculation mode: PowerUP does something more if I trigger PPC interrupt when bit 0 is active (zero). PPC interrupt code sets it back to one which probably means it really should cause PPC interrupt. But the problem is that it is PPC code that clears this bit, PPC interrupting itself, why? (And after some interrupt it logs unexpected external interrupt crash information to serial port. Nothing appears on screen)

BlizzardPPC flash unlock is totally different. REG_LOCK most likely only has single function, bit 0 + bit 3 is always set as a "I am BPPC" identification bit that for example flash updater checks. Write $42 to $f60092: write-enable flash, write to $f60093: read-only flash. Also maprom works differently, write $f60012: maprom on, write to $f60013: maprom off.

[phx]

Some more information I got from various sources:

Reset sequence CSPPC (from NetBSD, OS4):

P5_REG_LOCK = P5_MAGIC1|P5_MAGIC2;
P5_REG_LOCK = P5_MAGIC1|P5_MAGIC3;
P5_REG_LOCK = P5_MAGIC2|P5_MAGIC3;
P5_REG_SHADOW = P5_SELF_RESET;
P5_REG_RESET = P5_AMIGA_RESET;

The magic sequence unlocks P5_REG_SHADOW. I verified that you can write to it only after that sequence. Any other write access to the P5_MAGICx bits locks P5_REG_SHADOW again.

I'm not sure why this sequence is required and what SELF_RESET is for. Tests show that clearing P5_AMIGA_RESET is sufficient to reset the system.

There seems to be no set/clear bit 7 in P5_REG_LOCK (?).

The other known bit in REG_SHADOW is P5_SHADOW (Bit 0). It may be for mirroring the last 512K of Fast-RAM at 0xfff00000. But after booting in 68k mode the register is 0x4f here, which means SHADOW is inactive? But the mirror at 0xfff00000 is present. So my guess may be wrong.

Edit: Tests show that clearing P5_SHADOW makes the system crash hard. It stays dead even after a normal keyboard reset. You need to press CTRL-Amiga-Amiga 10 seconds to wake it up again. Probably it is a ROM-shadow to copy the ROM somewhere into Fast RAM?

Difference in BPPC reset routine:
Before the unlocking the BPPC needs P5_BPPC_MAGIC = 0.

Code sequence to take over the PPC, after initializing the PPC's reset vector (I used it in my NetBSD bootloader, taken from Linux APUS):

P5_REG_RESET = P5_PPC_RESET;
P5_REG_INT = P5_ENABLE_IPL;
P5_REG_ENABLE = 0xa8;
P5_REG_ENABLE = 0x10;
P5_IPL_EMU = P5_SET_CLEAR | P5_DISABLE_INT;
P5_REG_RESET = P5_SET_CLEAR | P5_REG_RESET;

The sequence written to P5_REG_ENABLE is a mystery. Looks like:
1. Set bits 3 and 5.
2. Clear bit 4.
Bit 3 would be a PPC to M68k interrupt request? Makes no sense here.

Another interesting fact is that P5_DISABLE_INT seems to be active high, in contrast to most other bits.

[Toni Wilen]

Originally Posted by phx

I'm not sure why this sequence is required and what SELF_RESET is for. Tests show that clearing P5_AMIGA_RESET is sufficient to reset the system.

Nothing seemed to happen when SELF_RESET was set or cleared.. Lock was unlocked, reading REG_SHADOW shows bit 6 being cleared.

There seems to be no set/clear bit 7 in P5_REG_LOCK (?).

That mysterious bit 0 of REG_LOCK can be set normally (0x81 -> set, 0x01 -> clear). Only bit 0. The one that seems to be very critical.

The other known bit in REG_SHADOW is P5_SHADOW (Bit 0). It may be for mirroring the last 512K of Fast-RAM at 0xfff00000. But after booting in 68k mode the register is 0x4f here, which means SHADOW is inactive? But the mirror at 0xfff00000 is present. So my guess may be wrong.

Bit 0 enables map rom feature. But FFF00000 is always reserved for PPC reset and exception vectors.

Map rom not enabled: FFF00000 is last 512k of fast ram. You can copy KS ROM here and then enable map rom, if you want. Or to last 512k. (BlizKick writes to FFF00000)

Map rom enabled: FFF00000 is second to last 512k of fast ram. last 512k of fast ram is used for kickstart mirror. This is not mirrored in FFFxxxxx anymore.

(I have read all publicly available sources many times already)

[phx]

Oh... missed your new posting, while writing mine.

Originally Posted by Toni Wilen

REG_LOCK: Bit 0 is the only one that can be changed. (Write 0x81 -> gets set to 1 and 0x01 -> cleared).

Ok, and clearing bit 0 causes a strange PPC->M68k level 2 interrupt?

Other bits won't change. This register is normally used to unlock flash chip write mode by writing "magic" values in sequence. (0x60, 0x50, 0x30)

But it also unlocks REG_SHADOW. I verified that. Otherwise I don't understand why you unlock the flash for rebooting the system.
Do you know at which address the flash is written after that.

IPL_EMU m68k IPL bits seems to be stuck at 7, writing won't change them, reading them in interrupt routine (I used level 3) still returned 7.. Even when ENABLE_IPL was active. DISABLE_INT bit is also stuck at 1. So apparently it is read-only too and perhaps DISABLE_INT and m68k IPL bits only work when PPC is active? (Or maybe even when PPC is interrupt master?)

I would guess it starts working with PPC interrupt master. I'm definitely using DISABLE_INT with PPC interrupt master while setting the new PPC_IPL, which is usually done in two steps: set PPC_IPL bits, with DISABLE_INT set, then clear PPC_IPL bits and DISABLE_INT. So no interrupt can occur while PPC_IPL doesn't have the final value.

REG_IRQ: Clearing both bits 3 and 4 (not 2 and 3) are confirmed causing an interrupt. System froze when I cleared both Bits 2 and 5 can be also set or cleared. Bit 6 is stuck at zero.

About which register are you talking here? REG_IRQ = REG_INT ?

Speculation mode: PowerUP does something more if I trigger PPC interrupt when bit 0 is active (zero).

Can't follow here. Bit 0 of which register?

BlizzardPPC flash unlock is totally different. REG_LOCK most likely only has single function, bit 0 + bit 3 is always set as a "I am BPPC" identification bit that for example flash updater checks.

Bit 0 and 3? Wasn't bit 0 your mystery cause-interrupt strobe? Then that wouldn't work on BPPC? And writing has no effect at all?

Write $42 to $f60092: write-enable flash, write to $f60093: read-only flash.

Wow! Never heard of these registers. Write any value to $f60093? And writing a value != $42 to $f60092 doesn't write-protect the flash again?

Also maprom works differently, write $f60012: maprom on, write to $f60013: maprom off.

Ah! I only knew the maprom-off register as BPPC_MAGIC. So this is not required to unlock something, as I first suspected, but just to turn MapROM off, before a reboot.

Very good progress in reengineering here.

[Toni Wilen]

Originally Posted by phx

Ok, and clearing bit 0 causes a strange PPC->M68k level 2 interrupt?

No. Nothing happens, it probably causes PPC interrupt but that can't be fully correct either because it still won't fix PowerUP.

I am quite sure this bit only does something when PPC is active.

But it also unlocks REG_SHADOW. I verified that. Otherwise I don't understand why you unlock the flash for rebooting the system.
Do you know at which address the flash is written after that.

Bad explanation, sorry. It unlocks REG_SHADOW and REG_SHADOW bit 2 is flash write-enable bit. (CSMK3/CSPPC only)

Remember that "write-enable" only means flash chip sees write accesses, flash chip still needs flash write or erase access sequence to actually write anything. Just check any compatible flash chip datasheet to see how programming works. (29F010 or 29F040 for example)

BPPC does not have flash enable bit here, it has separate registers (as I said above)

Also because BPPC has 512k flash (vs 128k in Cyberstorms), it has extra flash mapping, if SCSI is disabled (P5_SCSI_RESET is cleared), flash also appear at $f40000-$f5ffff, this space is mostly used, very tiny part at $f5c000 is used for config saving only. Apparently last 128k of flash is always unmapped. At least flash updater only writes first 384k of flash.

About which register are you talking here? REG_IRQ = REG_INT ?

I forgot I renamed some registers because they looked wrong
My REG_IRQ = f60008.

Can't follow here. Bit 0 of which register?

REG_LOCK, the register with only one settable/clearable bit.

Bit 0 and 3? Wasn't bit 0 your mystery cause-interrupt strobe? Then that wouldn't work on BPPC? And writing has no effect at all?

I meant bit 0 is the mystery one and then BPPC has extra bonus bit, bit 3 set to one as an BPPC identification bit. Flash updater says you don't have BPPC if this bit is not set. (This is always cleared on CSMK3/CSPPC)

Wow! Never heard of these registers. Write any value to $f60093? And writing a value != $42 to $f60092 doesn't write-protect the flash again?

Flasher utility (and flash rom boot menu settings flasher) uses $42 for both. Can't confirm, don't have hardware.

[phx]

As you know everything which was publically known, and more by reengineering, there is probably nothing left I could help you with. But nevertheless I'm very curious to find out about every detail of the register set to document it.

Originally Posted by Toni Wilen

Also because BPPC has 512k flash (vs 128k in Cyberstorms), it has extra flash mapping, if SCSI is disabled (P5_SCSI_RESET is cleared), flash also appear at $f40000-$f5ffff, this space is mostly used, very tiny part at $f5c000 is used for config saving only. Apparently last 128k of flash is always unmapped. At least flash updater only writes first 384k of flash.

This section reads quite confusing to me. Is the $f40000 address range you mentioned valid for BPPC, for CSPPC or only when SCSI is disabled? You wrote "also appear at": where does the flash primarily appear? I know that the CSPPC has some kind of ROM beginning at $f00000.

Can you give more details about the address ranges of the Flash?

I forgot I renamed some registers because they looked wrong
My REG_IRQ = f60008.

Although it is as wrong as REG_ENABLE, when the register contains interrupt request and interrupt enable bits.

For the purpose of documentation, can you please repeat which are the enable-bits and which are the request-bits?

[Toni Wilen]

Originally Posted by phx

As you know everything which was publically known, and more by reengineering, there is probably nothing left I could help you with. But nevertheless I'm very curious to find out about every detail of the register set to document it.

Only way to continue is to try random things while PPC is active. (But I don't do PPC code). For example checking if clearing LOCK bit 0 triggers random interrupt or some other side-effect, or if it really needs strange 4*0x85 to IPL_EMU to "unlock" something..

This section reads quite confusing to me. Is the $f40000 address range you mentioned valid for BPPC, for CSPPC or only when SCSI is disabled? You wrote "also appear at": where does the flash primarily appear? I know that the CSPPC has some kind of ROM beginning at $f00000.

$f40000-$f4ffff is SCSI space. (f41000 to f42fff is RAM [no idea where this RAM comes from] for NCR SCSI SCRIPTS code. Interestingly SCRIPTS are not put in normal fast ram like most other NCR53c7xx based SCSI controllers store it)

$f50000-$f5ffff (and apparently also $f70000-$f7ffff) is something unknown, possibly related to memory controller configuration because boot rom code writes to all kinds of addreses in this space and after each write it does memory check. I assume it configures memory (SIMM) layout and boot code searches for memory layout that creates best memory space layout (due to different size SIMMs). Or something like that. This does not need emulating.

Can you give more details about the address ranges of the Flash?

Flash is linearly mapped from $f00000 to $f1ffff (CyberStorm, 128k flash) or $f00000 to $f3ffff + $f40000-$f5ffff when SCSI is disabled (BPPC, 512k flash)

f6xxxx is always board register io.

For the purpose of documentation, can you please repeat which are the enable-bits and which are the request-bits?

I'll recheck this first.

[jbenam]

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

[phx]

Originally Posted by Toni Wilen

Only way to continue is to try random things while PPC is active. (But I don't do PPC code). For example checking if clearing LOCK bit 0 triggers random interrupt or some other side-effect, or if it really needs strange 4*0x85 to IPL_EMU to "unlock" something..

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?

Thanks for the details.

[phx]

Originally Posted by jbenam

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

Are you sure it is the recent one?
I knew him very good during his Amiga time (I wrote the WarpOS memory management and ppclibemu for him). 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.
Nevertheless, even if he could remember anything, which I doubt, he took the same reengineering approach as Toni does now. Only Ralph Schmidt and a few other Phase5 employees have the real information.

[thomas]

Originally Posted by jbenam

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

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

[jbenam]

Originally Posted by thomas

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

Cheers. Must've missed that. Nevermind, I'm sure Toni will be able to figure it out on his own