Using the Falcon's expansion connector

[Badwolf]

Ah great,so now you have at least own ram access and normal falcon ram+io access sorted out?

Current status:

• 50MHz CPU; no alt-ram: stable
• 16MHz CPU + 16MHz alt-ram: stable
• 20MHz CPU + 20MHz alt-ram: stable
• 25MHz CPU + 25MHz alt-ram: mostly stable
• 40MHz CPU + 40MHz alt-ram: not stable
• 50MHz CPU + 50MHz alt-ram: not working
• 50MHz CPU + 25MHz alt-ram async: not working

Because of all the debugging headers I've got on this card, the signal paths of the data lines are convoluted, branching and have quite a high capacitance. As the speeds go up I'm seeing more ringing on the lines. I need to either try to get asynchronous clocks working so I can run fast CPU and slower alt-ram, or work out some termination for the data lines to damp the oscillations.

Myself did a temporary fix on a ISA design of mine and almost forgot about it,just to later realize everything had been ok from the beginning..lol
It was really a software thing at the unlocking of the device that was wrong,,well that cost me several weeks later on,luckily had made notes of the temp revision fix

Ha!

BW.

[neanderthal]

[*]25MHz CPU + 25MHz alt-ram: mostly stable

So tt-ram start to swing out at 120nS cycles? Given if using DSACKx termination?
And yeap with many extra probe wires things tend to get a bit upset sometimes.
Came to think of it you use SDRAM?
I've never worked/read much of those but arent they much more tricky than things like old EDO?

Edit there on the cycles, 3 clocks if using full speed,tend to always think 4 as old 68k.

[Badwolf]

Quick update on progress with my SDRAM.

I managed to get 16 bit RAM working at 50MHz. Great news (although I was originally hoping the RAM would run at 100MHz), but could I extend it to 32 bit?

No. Not quite. Sometimes it'll run for ten minutes or more, other times won't even make it to the desktop. When I have managed to get programs running, this is the performance before any optimisation:

50MHz_32bit_Unstable_NB.jpeg

HOWEVER, things look a lot better at 40MHz. Admittedly testing with only 16MB of the 128MB onboard so far, but that proves the logic is sound, but maybe not up to a bit more speed.

I might try optimising at 40MHz and see where that gets me. That's still a very reasonable upgrade to 16MHz/16bit.

BW

[MegaSTEarian]

Nice!

[Cyprian]

Quick update on progress with my SDRAM.

I managed to get 16 bit RAM working at 50MHz. Great news (although I was originally hoping the RAM would run at 100MHz), but could I extend it to 32 bit?

No. Not quite. Sometimes it'll run for ten minutes or more, other times won't even make it to the desktop. When I have managed to get programs running, this is the performance before any optimisation:





HOWEVER, things look a lot better at 40MHz. Admittedly testing with only 16MB of the 128MB onboard so far, but that proves the logic is sound, but maybe not up to a bit more speed.

I might try optimising at 40MHz and see where that gets me. That's still a very reasonable upgrade to 16MHz/16bit.

BW

great!
Which screen resolution?

there you can find more NemBench results for different Falcon (and TT) configurations:
Falcon and NemBench

[viking272]

Quick update on progress with my SDRAM.

Those are really good figures, well done mate, getting there!
Whats the 68030 on the expansion board running at, is it 40 Mhz or also 50 Mhz?

there you can find more NemBench results for different Falcon (and TT) configurations:
Falcon and NemBench

There is a Magnum board on this link, with FastRAM but it's lacking the faster CPU with 32bit bus, so maybe not a good comparison.

[Cyprian]

There is a Magnum board on this link, with FastRAM but it's lacking the faster CPU with 32bit bus, so maybe not a good comparison.

there are stock 16MHz 030 Falcons and also boosted 100MHz 68060

[Badwolf]

Those are really good figures, well done mate, getting there!
Whats the 68030 on the expansion board running at, is it 40 Mhz or also 50 Mhz?

Many thanks. That's a 50MHz 030 sharing the clock with the AltRAM. I did a little experimenting with a faster CPU and slower memory, but I haven't gone down that road fully yet.

I don't think I'm going to be able to keep those figures with this board as I'll need a breakthrough to get 50MHz fully stable, but 40 is looking solid. The good news is at that speed the cheaper 33MHz plastic 030s can be used too.

I'm going to try to optimise at 40 for now and then do a round of Nembench in 2 colour mode. Those figures above were at 16 cols.

Cheers,

BW.

[viking272]

That's freaking awesome!

Some of the results are about 30-50% quicker than a TT (give or take and I know these are early results) which is really encouraging.

[shoggoth]

... but 40 is looking solid. The good news is at that speed the cheaper 33MHz plastic 030s can be used too.

The CT2 uses a 33MHz plastic QFP-type part, but the device is rock stable at 50MHz. These devices are known for good amount of headroom.

[Badwolf]

... but 40 is looking solid. The good news is at that speed the cheaper 33MHz plastic 030s can be used too.

The CT2 uses a 33MHz plastic QFP-type part, but the device is rock stable at 50MHz. These devices are known for good amount of headroom.

Neither of mine work at 48, but both stable at 40.

Mileage may vary, I suppose.

BW

[Badwolf]

A bit of an update.

After some hardware modifications I seem to have the board working very nicely indeed at 48MHz, but the target 50MHz is still elusive.

I know it's so close that you might think why worry, but it's annoying me now!

Here's the Nembench output at 48MHz 2 colour mode:

Code: Select all

root@spitfire:/f/working/nembench>cat nb48_2.txt 
NemBench v2.1 - precision CPU/FPU profiler.

Integer multiply (16bit)     -> 1.845 Mips (~300%)
Integer divide (16bit)       -> 1.089 Mips (~300%)
Linear (stalled) integer     -> 23.953 Mips (~300%)
Interleaved (piped) integer  -> 23.953 Mips (~300%)

16bit read (100% hit)        -> 23.668 MByte/sec (~301%)
16bit write (100% hit)       -> 10.706 MByte/sec (~177%)
32bit read (100% hit)        -> 47.281 MByte/sec (~301%)
32bit write (100% hit)       -> 21.459 MByte/sec (~321%)

Linear 32bit read (ST-Ram)   -> 5.144 MByte/sec (~96%)
Linear 32bit write (ST-Ram)  -> 6.475 MByte/sec (~100%)
Linear 32bit copy (ST-Ram)   -> 3.244 MByte/sec (~100%)

Linear 32bit read (FastRAM)  -> 16.879 MByte/sec (~317%)
Linear 32bit write (FastRAM) -> 20.592 MByte/sec (~319%)
Linear 32bit copy (FastRAM)  -> 10.296 MByte/sec (~318%)
root@spitfire:/f/working/nembench>

And, for shits and giggles (but mostly as a stability test), here's the same configuration under MiNT in 256 colour mode running a tcp/ip stack, sshd, bash in toswin2 and again remotely with ssh, clock, xcontrol and teradesk. Oh and Doom in a window, of course.

doom_window.JPG

Don't get your hopes up too high: that says 2.2 FPS. It's just a great test.

BW.

[Fletch]

BW,

Is the ultimate goal to have this as a purchasable product? If so, will the standard PSU fit or will that need to change?

Regardless, great work!

[Badwolf]

BW,

Is the ultimate goal to have this as a purchasable product? If so, will the standard PSU fit or will that need to change?

Regardless, great work!

Many thanks.

The aim is to have it fully open source so anyone can buy the parts and assemble it, flash it and use it. Alternatively any sellers can build some up and retail them if they wish. I shan't be selling completed units, I'm afraid.

Of course, they could also be taken up and improved by anyone who is better at it than me -- or has a particular requirement.

Having the original PSU in place is a stated project goal, but I don't know if it can actually handle the current draw yet.

https://github.com/dh219/DFB/blob/main/README.md

BW.

[MegaSTEarian]

A bit of an update.

After some hardware modifications I seem to have the board working very nicely indeed at 48MHz, but the target 50MHz is still elusive.

I know it's so close that you might think why worry, but it's annoying me now!

Here's the Nembench output at 48MHz 2 colour mode:

Code: Select all

root@spitfire:/f/working/nembench>cat nb48_2.txt 
NemBench v2.1 - precision CPU/FPU profiler.

Integer multiply (16bit)     -> 1.845 Mips (~300%)
Integer divide (16bit)       -> 1.089 Mips (~300%)
Linear (stalled) integer     -> 23.953 Mips (~300%)
Interleaved (piped) integer  -> 23.953 Mips (~300%)

16bit read (100% hit)        -> 23.668 MByte/sec (~301%)
16bit write (100% hit)       -> 10.706 MByte/sec (~177%)
32bit read (100% hit)        -> 47.281 MByte/sec (~301%)
32bit write (100% hit)       -> 21.459 MByte/sec (~321%)

Linear 32bit read (ST-Ram)   -> 5.144 MByte/sec (~96%)
Linear 32bit write (ST-Ram)  -> 6.475 MByte/sec (~100%)
Linear 32bit copy (ST-Ram)   -> 3.244 MByte/sec (~100%)

Linear 32bit read (FastRAM)  -> 16.879 MByte/sec (~317%)
Linear 32bit write (FastRAM) -> 20.592 MByte/sec (~319%)
Linear 32bit copy (FastRAM)  -> 10.296 MByte/sec (~318%)
root@spitfire:/f/working/nembench>

And, for shits and giggles (but mostly as a stability test), here's the same configuration under MiNT in 256 colour mode running a tcp/ip stack, sshd, bash in toswin2 and again remotely with ssh, clock, xcontrol and teradesk. Oh and Doom in a window, of course.


doom_window.JPG

Don't get your hopes up too high: that says 2.2 FPS. It's just a great test.

BW.

It rocks!

Dump question: The CPU bus is still 16bit or 32?

[Cyprian]

nice figures @Badwolf


@MegaSTEarian "Linear 32bit read/write" show figures for 16Mhz bus

[dhedberg]

This sure is starting to look very interesting! Thanks for all the time and effort you put into this!

[MegaSTEarian]

nice figures @Badwolf


@MegaSTEarian "Linear 32bit read/write" show figures for 16Mhz bus

Ah, this is what I thought. I bet this is the next milestone to accomplish past the 50MHz one?

[Badwolf]

Dump question: The CPU bus is still 16bit or 32?

Talking to the Falcon mainboard is still a maximum of 16 bit. Nothing we can do about that, that's the number of physical lines on the data bus.

https://github.com/dh219/DFB/wiki#the-p ... the-falcon

The AltRAM is full 32 bit.

The onboard ROM is also 16 bit, but could in theory be made 32. Not a lot of point, though, as you can map it into the AltRAM if you want.

BW

[dhedberg]

Dump question: The CPU bus is still 16bit or 32?

Talking to the Falcon mainboard is still a maximum of 16 bit. Nothing we can do about that, that's the number of physical lines on the data bus.
https://github.com/dh219/DFB/wiki#the-p ... the-falcon

Make your board also connect to the ST-RAM connectors of the motherboard and replace the ST-RAM with a dual-port RAM. That way you can give the 68030 CPU on your card a 32-bit bus to ST-RAM while the rest of the system still accesses ST-RAM using the 16-bit bus. Probably easier said than done, but should be possible, and would give the machine an awesome performance boost. The machine would finally be able to make good use of the 16-bit TrueColor video mode!

[Badwolf]

Make your board also connect to the ST-RAM connectors of the motherboard and replace the ST-RAM with a dual-port RAM. That way you can give the 68030 CPU on your card a 32-bit bus to ST-RAM while the rest of the system still accesses ST-RAM using the 16-bit bus. Probably easier said than done, but should be possible.

Haha. I had thought about some development around the memory headers -- not quite that idea, but there's scope for work to be done, that's for sure.

We'll see. There's quite a few daydreams to play with yet and when I've reached stability with this board I need to start looking for DSP experts to explain to me what's going on with it and why I've had to pretend it doesn't exist so far.

BW

[MegaSTEarian]

Dump question: The CPU bus is still 16bit or 32?

Talking to the Falcon mainboard is still a maximum of 16 bit. Nothing we can do about that, that's the number of physical lines on the data bus.

https://github.com/dh219/DFB/wiki#the-p ... the-falcon

The AltRAM is full 32 bit.

The onboard ROM is also 16 bit, but could in theory be made 32. Not a lot of point, though, as you can map it into the AltRAM if you want.

BW

I see, nice explanation there. Thanks

Please do buy a CT60! I'd buy one if I could justify it to the wife.

Same here, plus that production has stopped?

This gives us all the advantages of the full 32 bit data and address busses and allows us to control its speed.

This means that the bus speed is also increased?

Dump question: The CPU bus is still 16bit or 32?

Talking to the Falcon mainboard is still a maximum of 16 bit. Nothing we can do about that, that's the number of physical lines on the data bus.
https://github.com/dh219/DFB/wiki#the-p ... the-falcon

Make your board also connect to the ST-RAM connectors of the motherboard and replace the ST-RAM with a dual-port RAM. That way you can give the 68030 CPU on your card a 32-bit bus to ST-RAM while the rest of the system still accesses ST-RAM using the 16-bit bus. Probably easier said than done, but should be possible, and would give the machine an awesome performance boost. The machine would finally be able to make good use of the 16-bit TrueColor video mode!

Was also thinking about it but this breaks the "solder less" principle of the project I think.

I took it a bit further as well:
Could the two CPUs be set to work in some sort of parallel or as a co-processor? Like using the onboard CPU to offload tasks from the accelerated CPU? I believe TOS doesn't support that but what about EmuTOS (scarce thoughts here and there)?

[Cyprian]

I took it a bit further as well:
Could the two CPUs be set to work in some sort of parallel or as a co-processor? Like using the onboard CPU to offload tasks from the accelerated CPU? I believe TOS doesn't support that but what about EmuTOS (scarce thoughts here and there)?

really good question

Make your board also connect to the ST-RAM connectors of the motherboard and replace the ST-RAM with a dual-port RAM. That way you can give the 68030 CPU on your card a 32-bit bus to ST-RAM while the rest of the system still accesses ST-RAM using the 16-bit bus. Probably easier said than done, but should be possible, and would give the machine an awesome performance boost. The machine would finally be able to make good use of the 16-bit TrueColor video mode!

I second that idea, that would give a huge boost to for 32MHz CPU

[Badwolf]

This gives us all the advantages of the full 32 bit data and address busses and allows us to control its speed.

This means that the bus speed is also increased?

Not for the Falcon mainboard, but "our" local bus is fully under our control.

Also, normally when Videl is dragging the frame data out of memory it makes the CPU wait to use memory, which is why you see 256 colour mode is slower than 2 colour mode. Since we're using our own memory 'behind the back' of the mainboard, we get an additional boost as this wait doesn't apply when we're using our own bus.

Could the two CPUs be set to work in some sort of parallel or as a co-processor? Like using the onboard CPU to offload tasks from the accelerated CPU? I believe TOS doesn't support that but what about EmuTOS (scarce thoughts here and there)?

That mostly is an OS/software problem. Well beyond the scope of my project!

BW

[MegaSTEarian]

This gives us all the advantages of the full 32 bit data and address busses and allows us to control its speed.

This means that the bus speed is also increased?

Not for the Falcon mainboard, but "our" local bus is fully under our control.

Also, normally when Videl is dragging the frame data out of memory it makes the CPU wait to use memory, which is why you see 256 colour mode is slower than 2 colour mode. Since we're using our own memory 'behind the back' of the mainboard, we get an additional boost as this wait doesn't apply when we're using our own bus.

Nice. So you’ve noticed an improvement there as well, nice!

Could the two CPUs be set to work in some sort of parallel or as a co-processor? Like using the onboard CPU to offload tasks from the accelerated CPU? I believe TOS doesn't support that but what about EmuTOS (scarce thoughts here and there)?

That mostly is an OS/software problem. Well beyond the scope of my project!

BW

Yeah, you’re right. This why I brought up TOS/EmuTOS.