exxos's Atari, Amiga & retro forum

:bravo:

GB6 next ;)

exxos wrote: 26 Nov 2021 23:06 :bravo:

GB6 next ;)

It's been run many times, don't worry!

The problem is posting like-for-like results. Basically I have to run NVDI because of TOS4 and it's damned lack of soft-blitter, so any TOS4 comparisons are massively out of whack.

I'll have to do a comparison versus stock+NVDI, maybe.

BW

This is really great progress.

It looks like theres work to do, but you've past the absolute worst of it.

Personally, Im keeping a very close eye on this, as it ticks pretty much all all the boxes for me (i.e. absolutely no soldering, better 'baseline' 68k code compatibility, more RAM, a bit faster CPU boost). May even be able to recycle some of my code from the TT.

So, @exxos , have you got any available in your store yet? ;)

OK, Monday morning update-o'clock.

I replaced the bacofoil FPU's PLCC socket with a decent quality one from Exxos & immediately things were better.

I was getting reasonably reliable FPU accesses at 50MHz. It would benchmark well, it would draw the little Mandelbrot set in Frac perfectly, it would happily run programs targeted to 020-060 (which always demand an FPU). My little DSACK0 indicator light was flickering away happily (this was not happening with the old socket).

But it would fail a number of tests:


And PM-Quake/FPU would run for a bit but trip up after a couple of minutes.

Dropping the oscillator down to 40MHz improves things greatly. The tests now all pass and Quake seems stable in single tasking TOS (although it also seems to trip up under MiNT).

So there are two options I can see:

1) The communication between CPU and FPU is not reliable at 50MHz -- this is possible, I have to go high Z when the FPU is accessed and then drive the lines again when it stops. Timing could be a little out at high speed and there are non-synchronised clocks involved.

I have a test I'd like to try where I'll route the DSACKs from the FPU via the CPLD. It could cause a performance hit, but it'll mean I don't have to switch to and from a high-Z mode. Needs a bit of trace cutting and bodging, so that's probably a couple of days away (I could also join the CPU and FPU clocks together, but I'm worried about powering it without a clock during CPLD programming).

2) The ability for these FPU chips to be overclocked has been overstated.

This is a 40MHz chip. Is it purely co-incidence it runs well at 40MHz, but fails at 50? I wonder if, because a lot of normal use programs work happily in the overclocked configuration, it's been concluded overclocking works well. When the 030 is overclocked too far it just stops, but perhaps the FPU fails incrementally?

Not sure which way it is yet. The fact Quake works in single TOS but not MiNT, even at 40MHz could suggest it's my communication between the two that's ultimately to blame as when there's more going on it breaks down, but I've got a configuration where I run the 030 at 16MHz whilst leaving the FPU at 40 and 50. The same effects are seen in this configuration (tests fail at 50, pass at 40) despite there now being a significant tolerance margin.

So there are decent arguments both ways.

More investigation required!

BW

Very odd.

In GB6 I think the instructions used were done so to be compatible across all the variations. So it somewhat limits the instructions used. I'm not sure offhand what instructions it uses.

It does give me a thought though. With most tests GB6 is visual so you know when something is wrong. BUT things like FPU tests are not checking the results. So if you know enough to edit a bit of asm code, we could update GB6 to check the results as well. Similar int-div isn't checked, but normally the CPU would be overheating and crash anyway. But checking results could be a really useful feature .

Would be more work still, but built in RAM test tools would be useful as well. My asm skills are near zero so nothing I could do on my own. Pretty much anything could be added in fact.

exxos wrote: 01 Dec 2021 02:43 So if you know enough to edit a bit of asm code, we could update GB6 to check the results as well. Similar int-div isn't checked, but normally the CPU would be overheating and crash anyway. But checking results could be a really useful feature .

I can't claim to be any great shakes with assembly. I've only been really playing with it for the last *mumble* months, but if it's amending something that's already there I could have a go.

I doubt it would pick up many problems though, as I've found some interesting results. Suprisingly many of the different tests pass well above the failure rate for others.

That pattern I showed above is quite often repeated as the first sign of trouble. That ftrig:brand (no idea what that means!) is normally the first indicator that you've passed the point of no return. As you go faster and faster progressively more fail. You'd have to test the highest common failing factor to be reliable, I suppose.


What I've tried is to run my CPU at motherboard frequency (16MHz), the FPU at oscilaltor frequency and repeat that test. I've one that works at 40MHz, but then starts to fail on that test at 48 (my next step), one that works at 16 but not 25 and one that works at 25 but not 36! I think I have one more FPU somewhere, but haven't go around to that yet.

Christian's reported having a PLCC 33MHz FPU that runs happily and passes all the tests at 48MHz, so I think there may be a second issue going on here. Having two different 40MHz FPUs that cant' get to 40MHz, plus one that can't get to 48? I may have something wrong with my interface, perhaps.

What I have now is AS, DS, DSACK0, DSACK1 connected directly CPU-FPU with 1k pull ups. The CPLD is eavesdropping on AS and DS lines, but the DSACK0 and DSACK1 lines it's having to drive open drain. I wonder if there's an issue at all with the latter?

Although it's odd that the results are entirely repeatable across chips. Perhaps Occam's Razor should apply and the chips really can't go that fast!

I left it working in a 50/25MHz configuration last night. Which is good enough for me, but I think I'll try fitting a second oscillator and see if I cna't get 50/40 to work.

BW

I did these tests a while ago https://www.exxosforum.co.uk/atari/last/FPU/index.htm but I'm not sure at what point dml wrote his fpu test program and what point I started using it. I used to sell my fpu tested at 50mhz, but they might have failed with dml fpu tests. 64mhz seemed the max back then.

I guess if you repeat my tests you would get a more concrete answer ...

exxos wrote: 01 Dec 2021 17:40 I guess if you repeat my tests you would get a more concrete answer ...

I'll give it a go. Downloaded the fractal program last night. Was gluing an oscillator daughterboard onto the side of mine yesterday! :lol:

I still think there's something a bit off about my communications between the two. Possibly when I'm going high Z, possibly just the clock switching on the CPU.

It does seem that things work better with a faster FPU and slower CPU rather than the other way around. Perhaps that's in the datasheet and I missed it.

BW

Badwolf wrote: 02 Dec 2021 12:57 It does seem that things work better with a faster FPU and slower CPU rather than the other way around.

Yeah, that's the "slight problem" with my test as they are running a stock CPU. So I don't know if this would affect the top speed of the FPU or not. I'm just assuming at this point it wouldn't.

exxos wrote: 02 Dec 2021 13:08

Badwolf wrote: 02 Dec 2021 12:57 It does seem that things work better with a faster FPU and slower CPU rather than the other way around.

Yeah, that's the "slight problem" with my test as they are running a stock CPU. So I don't know if this would affect the top speed of the FPU or not. I'm just assuming at this point it wouldn't.

Mmm. I suppose it would answer whether the fabric can work at the clock frequency, but not necessarily if the chip can handle the stress of being selected more often.

I've had some really funky results with different programs and different combinations. I think I need to gate AS, DS and the DSACKx lines -- even if it costs some cycles -- as I don't want to be introducing artefacts with my CPU clock switching nor my HIGHZ switching.

I'm very pleased it's got this far, though, to be honest! The new PLCC sockets you sent me are *far* more reliable than whatever I got off RS.

BW