exxos's DFB1 trials

[Badwolf]

As the AB patches a TOS image in fast ram, and successfully boots from there (on a warm reboot) displaying the Atari logo (thus utilizing the blitter), the blitter can be accessed from fast ram using a TOS image in fast ram.

I doubt it. It (physically) can't address RAM in the TT-RAM space. It's loading the image from the ROM that still exists on your motherboard.

so I'm understanding it's a hardware utilization difference on the DFB, and not that the blitter can't be accessed from fast ram? Some difference there, and my mistake for not getting that point.

No difference. Blitter physically cannot access ranges beyond 16MB from zero. Ie. it can access ST-RAM, onboard ROM and the registers.

If you built an AltRAM board that reduces ST-RAM to 4MB and uses that space, then you can have the blitter accessing fast RAM, but that's still in the first 16MB. Blitter cannot access the TT-RAM address space. Full stop. Not possible. It has only 24 (23 really -- A0 isn't used) address lines.

The 1/2 CPU blitter setting is just to get around running the COMBEL blitter speed to a point it fails.

DFB1 does not accelerate the bus. This isn't an issue.

BW

[Badwolf]

What benefit does the FPU have in normal (games etc.) software have?

Most applications would have been written for the ST which doesn't have one anyway.

Theoretically zero, in reality it's useful.

Having it running at 50MHz instead of 16MHz? Basically no reason other than benchmarks.

To explain, virtuall all 'old' software is built for the 68000 and so no FPU calls are ever made.

Modern software is a bit different. The most popular modern compiler for our system, Vincent and Thorsten's ports of gcc 4 have only two target settings: 68000 and 020-060.

Compilations with the 68000 target will not use the FPU. When you see mint-000.prg, that's what that is.

However all compilations with 020-060 optimisations require an FPU to even start up. This was a design decision taken years ago which is perhaps regrettable now, but it's where we are.

So, anything optimially compiled (with gcc) for the 030 will require an FPU to run even if it uses zero FPU calls. By way of example if you try to run bash from the mint-020-60 package on a mint-000 installation that doesn't have an FPU, it can't work.

So having an FPU used to be extremely useful, just to run half the modern software out there.

BUT since then, @agranlund has very kindly written an FPU emulator program. It's very slow for real floating point work, but it will get around these programs that simply require an FPU to start up, without ever really needing it. Or for programs that perhaps use the FPU extremely occasionally. This is virtually everything.

Now, say you do want to run Quake (I use it as a soak test). You do need a real FPU for that. You may get 0.5 FPS with a 50MHz FPU versus 0.3 FPS with a 16MHz one. You won't notice the difference between 40 and 50.

So, in my opinion, the FPU is of far less importance now than it was a year ago, but if you need one it's nice to have it there as an option. If you can get it to run at 50MHz, it's a nice treat, but it has no real value to do so. I run mine at 25.

If the 50MHz FPU doesn't work on a board you buy, I genuinely wouldn't be upset about it.

BW

[exxos]

Been doing some more testing and I think 40MHz is just going to become the "norm" currently. Though I don't think this is the bottom line of it all.

If I remember rightly the TTRam is effectively access that 25MHz @Badwolf ? Either way I don't think it would be necessarily running at the full 50MHz speeds effectively. So the CPU is waiting around a little bit for that access. In accessing anything on the main Falcon bus is running at slower speeds anyway (16MHz). Flash is limited because of the speed of the flash itself.

I can run TTRam test for hours and the CPU does get incredibly hot but it does not flag up any errors on testing at all. It can run GB6 fine also. Though likely that is switching down to slower speeds anyway.

I don't believe the FPU is a speed problem because it can run at 50MHz fine on different boards. Though I am constantly hitting the same issue that something starts tripping up that 50MHz, but only when accessing the FPU. Which coincidentally the CPU is being run at full speed. So you would think it would be some sort of thermal problem, but I'm not really convinced now that is the case. Basically I need to narrow things down somehow. By the looks of it FPU tests will work for approximately an hour with no heatsink or cooling on the CPU whatsoever. Then it will intermittently start throwing up areas. I have a little fun blowing on it when that starts to happen and the problem goes away.

Occasionally I see even a 40MHz board trip up on FPU test. Though this tends to be when it has been running for a long time. So I think definitely these things will need a heatsink and a fan to keep them cool. I'm still not ruling out there isn't some odd issue yet to solve. But trying to locate intermittent bugs will likely be incredibly time-consuming. I don't think anything is ever going to be 100% perfect on a first batch. Though I think the majority of the problems are going to be solvable in future firmware revisions.

Anyway, I wonder if anyone can write me a routine in assembly to do something like a bucketload of integer division for like 60 seconds (or more). Basically to run the CPU at 50MHz and also check the results. So if the CPU can do internal stuff at 50MHz, I would be inclined to think that the CPU is actually capable of that speed, At least for internal operations.

[Badwolf]

If I remember rightly the TTRam is effectively access that 25MHz @Badwolf ? Either way I don't think it would be necessarily running at the full 50MHz speeds effectively.

I'm never quite comfortable quoting memory access speeds as MHz-equivalents, I'm afraid. The memory is clocked at CPU frequency. So 40 or 50MHz.

For single, non-burstable access it takes 5(*) clock cycles before data is latched. So that's around 100ns-125ns SRAM equivalent access time for 50-40MHz , I think.

Slowing the processor slows the memory as it's synchrnous RAM.

BW


(*) There are half-cycles in there. I think I used to have it around 4.5, but ran out of space on the CPLD. Let's call it 5.

[sunaiac]

Modern software is a bit different. The most popular modern compiler for our system, Vincent and Thorsten's ports of gcc 4 have only two target settings: 68000 and 020-060.

Compilations with the 68000 target will not use the FPU. When you see mint-000.prg, that's what that is.

However all compilations with 020-060 optimisations require an FPU to even start up. This was a design decision taken years ago which is perhaps regrettable now, but it's where we are.

So, anything optimially compiled (with gcc) for the 030 will require an FPU to run even if it uses zero FPU calls. By way of example if you try to run bash from the mint-020-60 package on a mint-000 installation that doesn't have an FPU, it can't work.

I have been using Thorsten's 9.3.1 lately for my project (with those options: m68k-atari-mint-gcc-9.3.1.exe -Iincludes -Wall -Wextra -pedantic -Ofast -fomit-frame-pointer -m68030 -fno-common -std=c99) and it does not require an FPU apparently.

[Rustynutt]

There's a lot of 882 apps out there.
Personal favorites are the Zenomorph package (Chronos, Key Frame Animator, Phoenix) and Neon.
A 40-50MHz 882 renders faster than the emulation on the 040.

[exxos]

I have found that I need another delay on FPU_CS :roll: Currently there is 3xCPU clocks, basically 60ns.

I scoped out CS vs all other signals did not really find that much.


This one is DSACK (blue) and CS (yellow) presumably this is the FPU setting DSACK After CS goes low.

IMG_0768.JPG

The only other point is that all the data lines do not exactly reach a logic high before CS goes low. I would assume that data is latched on the rising edge of CS, the datasheet (from what I can tell currently) does not seem to specify when the latch happens. If it happens on the falling edge of CS then it could explain why the CS delays needed because logic high has not yet reached a high before CS goes low.

IMG_0767.JPG

EDIT:

I did a quick experiment of placing a X1 probe on one of the upper data lines and it pretty much immediately crashed. This was running at 40MHz, (it's unstable that 50MHz) but had been running for about half an hour before-hand.

[exxos]

This is the scope of the data line with X1 probe. Clearly it is more of a "arc" as expected. This makes things probably about 25% more unstable.

IMG_0769.JPG

This one with 50MHz and fails pretty much every few tests.

IMG_0770.JPG

The rise time according to my scope is 46ns. Which isn't exactly too shabby start with...

[Badwolf]

This one is DSACK (blue) and CS (yellow) presumably this is the FPU setting DSACK After CS goes low.

WTF is going on there?

DSACK asserting immediately FPUCS does? That doesn't sound at all right to me. I think we need to actively add the FPUCS line to the DSACK high-Z switch to make sure that's not us asserting that.

I'll get the datasheet out.

BW

[exxos]

I think we need to actively add the FPUCS line to the DSACK high-Z switch to make sure that's not us asserting that.

That is what I did in my original firmware before I started basing it on FPUX instead. There wasn't any difference which signal was used IIRC.. This is going back to "day 1" stuff again now..