Using the Falcon's expansion connector

[Rustynutt]

I had some terrible trouble getting the DSP to work reliably with my board: it was all down to how the Falcon's expansion port doesn't have A0 and derives it from UDS which I was terminating at the 'normal' time. Things work better when it's delayed so A0 is properly asserted when AS goes high.

Congratulations on finding this, by the way! This is one of these things that seem crystal-clear in hindsight; but I would not have thought of this. Makes you wonder what Atari was thinking when they gave the expansion connector a "68000-style" bus interface...

You think the DSP issue with the Eagle Sonic is due to this?

[Rustynutt]

Excellent progress. Dammitall, bought a 50MHz PGA 882 for this assuming you'd of went that direction Still have plenty of PLCC 40MHz units.

Haha, sorry. Most of the 40MHz PLCCs overclock nicely so 50MHz isn't a stretch. Bloody thing is *half* working at the moment, though. Draws lovely fractals. Fails all the tests. I think it's bad connections on this shitty socket. I need to reflow it all then rip it off and replace if that doesn't work.

BW

Early on in the thread, you discussed a similar issue accessing the onboard FPU.

I'm sure unrelated due to hardware differences, found with a 24MHz bus, and Afterburner installed, but drivers disabled (020 "mode"), had FPU access failures.
Ended up clocking it with a separate oscillator, and for whatever drove me (I'm clueless), stepped up the clock to 64MHz, when the FPU began to function.

As in your test, it will fail the accuracy test, but complete FPU bench, and renders with Scape882 (Planet Scene Generator), and all the Chronos software. AIRC, Grapher also worked fine. Wondering if FPU Bench is the culprit?

[Badwolf]

Congratulations on finding this, by the way! This is one of these things that seem crystal-clear in hindsight; but I would not have thought of this.

Thanks, Christian. Your input, whilst not directly related to the problem, sent me down a different path that eventually made me think about it!

Makes you wonder what Atari was thinking when they gave the expansion connector a "68000-style" bus interface...

I've asked this question about 500 times during the life of this project. Why wouldn't they just connect the upper 8 address bits, even? Imagine how many more capable add ons we could have had. Infuriating.

BW

[Badwolf]

Early on in the thread, you discussed a similar issue accessing the onboard FPU.

I traced that to bad contacts.

I'm sure unrelated due to hardware differences, found with a 24MHz bus, and Afterburner installed, but drivers disabled (020 "mode"), had FPU access failures.
Ended up clocking it with a separate oscillator, and for whatever drove me (I'm clueless), stepped up the clock to 64MHz, when the FPU began to function.

I think there is a genuine advantage (from a bus interface point of view) to having the FPU clocked faster than the CPU, but...

As in your test, it will fail the accuracy test, but complete FPU bench, and renders with Scape882 (Planet Scene Generator), and all the Chronos software. AIRC, Grapher also worked fine. Wondering if FPU Bench is the culprit?

I'm actually starting to think that perhaps these FPU chips aren't as overclockable as people suspect. The 030 if you overclock it too far simply stops working. Is it possible the FPU, when excessively clocked begins to partially function?

I could draw fractals happily, run the speed tests but fail the dedicated test programs. QuakeFPU would also fail, however.

Reducing my clock to 40MHz (the rated speed of the FPU) allows all the tests to pass, but also Quake to run. Co-incidence? Possibly -- my interface logic perhaps breaks down at 50MHz -- but is it feasible it is not accurate when overclocked?

To be investigated further.

BW

[czietz]

I'm actually starting to think that perhaps these FPU chips aren't as overclockable as people suspect. The 030 if you overclock it too far simply stops working. Is it possible the FPU, when excessively clocked begins to partially function?

It's not only possible, but plausible! Different units within the FPU have different timing margins and therefore start to fail at different clock speeds.

As a matter of fact, I have a CPU that has been relabeled (eBay purchase) with a higher clock speed. It generally runs fine at the overclocked speed, except very few instructions reproducibly fail, i.e., give wrong results. Took me a while to figure that out.

EDIT:

I could draw fractals happily, run the speed tests but fail the dedicated test programs. QuakeFPU would also fail, however.

I know of someone whose FPU ran the (GB6) speed tests without issues but generated bogus results when running Linpack: https://github.com/czietz/linpack-atari/. Particularly, the FORTRAN version LINPACKD.TOS prints some numbers that quantify the accuracy of the calculations.

[Badwolf]

It's not only possible, but plausible! Different units within the FPU have different timing margins and therefore start to fail at different clock speeds.

As a matter of fact, I have a CPU that has been relabeled (eBay purchase) with a higher clock speed. It generally runs fine at the overclocked speed, except very few instructions reproducibly fail, i.e., give wrong results. Took me a while to figure that out.

That's really great insight, thanks, Christian. I think I'm going to add a dedicated oscillator socket for the FPU and do some more rigorous testing.

I know of someone whose FPU ran the (GB6) speed tests without issues but generated bogus results when running Linpack: https://github.com/czietz/linpack-atari/. Particularly, the FORTRAN version LINPACKD.TOS prints some numbers that quantify the accuracy of the calculations.

Aha! I'd forgotten about Linpack. I do have that on my hard disc already -- I'll add that to my armoury.

119 for 16MHz but 32bit data bus, by the way!

BW

[czietz]

Aha! I'd forgotten about Linpack. I do have that on my hard disc already -- I'll add that to my armoury.
119 for 16MHz but 32bit data bus, by the way!

That's surprisingly close to the Falcon (111 kFlops), which only has a 16 bit data bus. Then again, FPU commands and responses are 16 bit transfers, anyway; mainly the operand register benefits from 32 bit transfers.

As for testing the correct operation of the FPU, for sure dml's FPUTEST is the "gold standard" as it tests for bit-exactness. But you can also see wrong numerical results in the output of the FORTRAN version of Linpack (LINPACKD.TOS):

The norm. resid is a measure of the accuracy of the computation. The value should be O(1). If the value is much greater than O(100) it suggest that the results are not correct.
[...]
The values of x(1) and x(n) are the first and last component of the solution. The problem is constructed so that the values of solution should be all ones.

[Badwolf]

Aha! I'd forgotten about Linpack. I do have that on my hard disc already -- I'll add that to my armoury.
119 for 16MHz but 32bit data bus, by the way!

That's surprisingly close to the Falcon (111 kFlops), which only has a 16 bit data bus. Then again, FPU commands and responses are 16 bit transfers, anyway; mainly the operand register benefits from 32 bit transfers.

Yes, and at 40MHz CPU and 40MHz FPU I only got 270-something. Nothing close to the CT2 result on your GitHub page!

As for testing the correct operation of the FPU, for sure dml's FPUTEST is the "gold standard" as it tests for bit-exactness. But you can also see wrong numerical results in the output of the FORTRAN version of Linpack (LINPACKD.TOS):

That's great, thanks. I hadn't gone into the manual of that yet.

I get about 1.44 in that headline resid figure with an FPU configuration that passes FPUTEST and, amusingly, when running at 50MHz (with a 16MHz CPU, for more assured stability), 7.4e13!!

That's quite some error.

I'm doing some experiments now, but it does look very strongly like this particular chip doesn't go much beyond its rated speed. I think this partial failure mechanism is enough to throw people.

Thanks again,

BW.

[Rustynutt]

With a change in powersupply....

[czietz]

Yes, and at 40MHz CPU and 40MHz FPU I only got 270-something. Nothing close to the CT2 result on your GitHub page!

I haven't specifically checked it, but LINPACK performance is also impacted by memory speed. The 100x100 linear equation system that is being solved is is too big to be kept in the FPU registers, i.e., it resides in memory.
Iirc, you have Fast-RAM on your card. Which speed does MEMSPEED (http://atariftp.czietz.de/pub/atari/Uti ... mspeed.lzh) measure? (Apologies if you had already answered that in the thread in Exxos's forum. I didn't follow the discussion there.)

I get about 1.44 in that headline resid figure with an FPU configuration that passes FPUTEST and, amusingly, when running at 50MHz (with a 16MHz CPU, for more assured stability), 7.4e13!!
That's quite some error.

Yep, there's certainly something wrong.

I'm doing some experiments now, but it does look very strongly like this particular chip doesn't go much beyond its rated speed. I think this partial failure mechanism is enough to throw people.

FWIW, my TT has its original CPU and FPU (rated 33 MHz) but happily runs overclocked at 48 MHz; passing both FPUTEST and LINPACK.

[Badwolf]

Yes, and at 40MHz CPU and 40MHz FPU I only got 270-something. Nothing close to the CT2 result on your GitHub page!

I haven't specifically checked it, but LINPACK performance is also impacted by memory speed. The 100x100 linear equation system that is being solved is is too big to be kept in the FPU registers, i.e., it resides in memory.
Iirc, you have Fast-RAM on your card. Which speed does MEMSPEED (http://atariftp.czietz.de/pub/atari/Uti ... mspeed.lzh) measure? (Apologies if you had already answered that in the thread in Exxos's forum. I didn't follow the discussion there.)

EDIT: I just realised I was inverting some of the clock logic and running a proportion of the FPU timings mentioned above at 16MHz! What a wally.

I have at some point I suspect -- but it's always out of date as I'm constantly fiddling with things.

At 40/40 (known good configuration) the headline figures are:-

Memspeed: read 27, write 28 MB/s
Nembench: read 14, write 17 MB/s; float multiply 0.677 MFlops
Gembench6 AltRAM: 11.69s; Float 2.94s
Linpack @200x200: ~307 kflops

Everything bar the float figures speeds up with the CPU, but I've run into a parallel problem at the moment: I can't speak reliably to the FPU (whatever its clock frequency) with the CPU at 50MHz. Its likely my AS, DS and DSACKx connections are strained at that speed.

FWIW, my TT has its original CPU and FPU (rated 33 MHz) but happily runs overclocked at 48 MHz; passing both FPUTEST and LINPACK.

Wow. Fair enough! I know there's something else going wrong here (as above), but even with the CPU stably at 16MHz, I can't get to 48MHz on the FPU. I do have another couple of chips I can try, but for now I'm going to try to get a dual-clock system working with the CPU at 50MHz, then the preferred combination can be set.

I'm going to try dropping my pull-ups to 1k2 for starters.

Cheers,

BW.

[czietz]

Memspeed: read 27, write 28 MB/s
Nembench: read 14, write 17 MB/s; float multiply 0.677 MFlops
Gembench6 AltRAM: 11.69s; Float 2.94s
Linpack @200x200: ~307 kflops

Okay, most of it is within the expected range. My TT @ 48 MHz has:
MEMSPEED: read 29.4, write 36.7 MB/s (for TT-RAM)
NEMBENCH: read 30.1, write 31.2 MB/s (for TT-RAM, I wonder why it so much slower for you), float multiply 0.811 MFLOP/s
LINPACK: 286 kFLOPS/s

The LINPACK results highlights a difference between the TT and your board. While CPU, FPU and TT-RAM access run at 48 MHz, the communication (i.e. /AS, /DS, /DSACKx) between CPU and FPU go through additional circuitry. As you can see, this makes it slower than you board.

EDIT: The results for the PAK68/3 (though with a 68020 CPU) at 40 MHz and the CT2A at 50 MHz give roughly 8.5 kFLOP/s per MHz.

FWIW, my TT has its original CPU and FPU (rated 33 MHz) but happily runs overclocked at 48 MHz; passing both FPUTEST and LINPACK.

Wow. Fair enough! I know there's something else going wrong here (as above), but even with the CPU stably at 16MHz, I can't get to 48MHz on the FPU. I do have another couple of chips I can try

Note that the FPU (and CPU) in my TT are original, i.e., genuine. If I bought, e.g., a MC68882FN40 today on eBay, I'm nearly certain that it has been relabeled. So you never know whether it's actually a 16 MHz version.

[Cyprian]

Nembench: read 14, write 17 MB/s; float multiply 0.677 MFlops

Okay, most of it is within the expected range. My TT @ 48 MHz has:
...
NEMBENCH: read 30.1, write 31.2 MB/s (for TT-RAM, I wonder why it so much slower for you)
...

Impressive figures @czietz . It seems you have a special TT-RAM card (a new one?)

Mine figures for 32MHz TT:
Linear 32bit read (FastRAM) -> 14.835 MByte/sec (~279%)
Linear 32bit write (FastRAM) -> 12.615 MByte/sec (~195%)

[czietz]

Impressive figures @czietz . It seems you have a special TT-RAM card (a new one?)

A Storm TT - which I run at 48 MHz, yes. A regular Storm TT (i.e., at 32 MHz) has about 17 - 20 MB/s:
https://wiki.newtosworld.de/index.php?t ... chmark.jpg

(But let's not hijack this thread too much )

[Badwolf]

Okay, most of it is within the expected range. My TT @ 48 MHz has:
...
NEMBENCH: read 30.1, write 31.2 MB/s (for TT-RAM, I wonder why it so much slower for you), float multiply 0.811 MFLOP/s

Thanks for these, very interesting.

Yes, I don't know why such a difference between Nembench and Memspeed there. Of course none of the AltRAM code is optimised at all yet and the firmware is in a massive state of flux, but whilst that might explain poor results, it wouldn't really explain a discrepancy.

The LINPACK results highlights a difference between the TT and your board. While CPU, FPU and TT-RAM access run at 48 MHz, the communication (i.e. /AS, /DS, /DSACKx) between CPU and FPU go through additional circuitry. As you can see, this makes it slower than you board.

I was thinking to add in extra circuitary to improve reliabiltiy.

Note that the FPU (and CPU) in my TT are original, i.e., genuine. If I bought, e.g., a MC68882FN40 today on eBay, I'm nearly certain that it has been relabeled. So you never know whether it's actually a 16 MHz version.

Mmm. I've two from Exxos, one off ebay and one that I've not yet dug out and tested. Exxos does test the FPUs he sells, but I don't think guarantees the number on the front.

I've rigged up an entirely separate oscillator and will do some more testing with a variable clock and the CPU at 16MHz, I think.

I really think I need to gate the AS, DS and DSACKx lines between the two chips, though, as I'll wager my faster CPU, slower FPU + clock switching on one end is causing grief.

Cheers,

BW

[czietz]

I'm wondering: Does caching work properly in your setup?

The reason why I'm wondering: MEMSPEED differentiates between L1 cache (internal to the 68030), L2 (not present in the TT, so this column in meaningless there) and cache misses that go to main memory. When I disable the cache (via the menu in EmuDesk), obviously the L1 figure drops, since effectively there is no L1 cache. But the main memory figures stay almost the same.

In contrast, the NEMBENCH figures for TT-RAM take a huge hit when cache is disabled: 18 MB/s read, 22 MB/s write. When I scale this to your clock speed (i.e., by 40 MHz / 48 MHz) I end up with 15 MB/s read, 18 MB/s write; suspiciously close to your results.

[1st1]

I follow this project silently since almost the beginning, Badwolf you did impressive work and I hope that you get a stable reliable solution for the masses...

But how about for the classes? I have checked, it seems still to be compareable easy as getting a 68030 to have a 68040... Would it be possible and make sense to have a 040 version of your turbo card?

[Badwolf]

I'm wondering: Does caching work properly in your setup?

You know, I think it may have been turned off -- I wasn't paying attention to memspeed in full but I don't remember seeing the 43MB/s odd L1 hit reported.

I don't interfere with the caching at board level at all, but perhaps something I'd run before had disabled it.

I've gone back to working on getting a solid FPU testbench ATM so don't have the 'usual' firmware in place to retest so we probably ought to take those results with a pinch of salt.

Thanks,

BW

[Badwolf]

But how about for the classes? I have checked, it seems still to be compareable easy as getting a 68030 to have a 68040... Would it be possible and make sense to have a 040 version of your turbo card?

Haha. I know nothing about 040s. My next big project -- if this ever gets to release -- would likely be for the STE, but I'd like to look into a PiStorm-like Arm CPU emulator drop-in in the future.

BW

[1st1]

I know nothing about 040s.

Maybe it's not that different from 030?

[czietz]

Maybe it's not that different from 030?

It is. The 68040 bus interface is massively different from the 68030. Of course, everything can be adapted, as the existing 68040 accelerators prove. But it would mean a complete HW redesign.

[mrbombermillzy]

Would it be possible and make sense to have a 040 version of your turbo card?

I asked TerribleFire about the 040 a while ago. He told me he hated the 040 and apparently has engineered his cards so they dont accept one.

Personally, I believe an 030 @50mhz can give a 25Mhz 040 a good run and the 040 doesnt seem to overclock well enough either to give it a vast speed difference over the 030@50, so months of trying to get it to eventually work is barely worth the pain IMHO.

If thats not enough, from a coding perspective, despite that Move16 looking nice to use, once you start using 040 code, you are then cutting yourself off from all the lower 68k machines compatability wise, so you may as well go for an 060 or something even better. Either way, Falcon apps/OS will need patching up.

[mpattonm]

Not to mention that while 060s are (becoming) rare, 040s are virtually non-existent on the market.

[1st1]

Not to mention that while 060s are (becoming) rare, 040s are virtually non-existent on the market.

I checked yesterday on eBay, and I found more than 68030.

[Badwolf]

I'm wondering: Does caching work properly in your setup?

I went back to look at this because the more I thought about it, the less sense the results made.

I think I must have had a bad firmware there, or I'd run something prior that was goofing up the stats.

Here are the equivalent stats from my last 40/40 run:

Memspeed: read 18.9, write 28.7. (L1 read hit is 37.8 so cache must be on this time)
Nembench: read 20, write 24.5 MB/s; 0.67 MFlops
Linpack: 323KFlops

I have no idea where the figures above came from. The memspeed read figure I quoted is beyond my 50MHz performance!

Anyway, I've been doing quite a few tests with different combinations of oscillator and firmware and the conclusion is that FPU clock faster than CPU clock is fine (only one of my chips makes it to the 40MHz spec doing this!), but you can't run with faster CPU than FPU clock reliably.

I'm going to theorise this is because DSACKx are taking too long to deassert, so I'm going to start cutting tracks and try gating their signals through the CPLD.

I think the final version will have to let the user choose to use the CPU clock or to provide a separate crystal, so I'd like to be able to support, eg. 50 CPU and 33 FPU.

BW