exxos's Atari, Amiga & retro forum

Badwolf wrote: 11 Apr 2024 10:13

mrbombermillzy wrote: 10 Apr 2024 20:45

Hang on. Just to clarify, Im sure I asked @Badwolf about using a Pi3B for this (using a riser because of the double stacked USB ports on the 3B) and Im sure I was warned by him not to use a GPIO riser because of signal degradation issues.

You want the Pi to PiStorm connector to be as short and robust as possibe. Flappy wires aren't going to cut it, but if you're just trying to get a couple of of mm clearance, longer headers should be fine. Not ideal, but then short of soldering the boards directly to each other, nothing is.

Thank you @Badwolf . I think I'll take my chances with a Pi3B and a riser then. :)

So how many people currently have one of these things or is planning to try it out ?

How it sort of looks to me currently (by what others have posted) , it's like a 100MHz 020 kinda speeds. But it's hard to tell.

exxos wrote: 11 Apr 2024 19:23 So how many people currently have one of these things or is planning to try it out ?

How it sort of looks to me currently (by what others have posted) , it's like a 100MHz 020 kinda speeds. But it's hard to tell.

Sysinfo reports 192MHz for the 020

dad664npc wrote: 11 Apr 2024 19:39 Sysinfo reports 192MHz for the 020

Yeah I saw that but I think it's always been a bit questionable on how it's working it out.

I mean the ST536 847% TTram speed at 50mhz. It's about 1000% at 60mhz. But I think there's wait states because the ram can't keep up. If SRAM was used I assume it would be double that. The pistorm is almost 2000. So the TTram is basically twice as fast as a ST536 anyway. But I'm not sure the ST536 RAM runs at the full CPU speed. So it would basically work out the pistorm would either be 60mhz or 120mhz, based on my mathematical guesswork. 60mhz doesn't seem right by other results. So id probably say 120mhz 020 CPU easily.

I thought @dad664npc did a GB6 run with cache off ? Can't find it. I think that's why the ROM speed ends up crazy high as it can't be doing bus accesses to get to like 3000% speeds.

exxos wrote: 11 Apr 2024 20:15 I thought @dad664npc did a GB6 run with cache off ? Can't find it. I think that's why the ROM speed ends up crazy high as it can't be doing bus accesses to get to like 3000% speeds.

All this sort of chat is going on in the AF forums ATM, with Gunnar Von B and the different HW/clones being discussed, including speeds.

My personal opinion, having coded 68000 and 68030, is to do any tests running straight 68000 code to keep it clean and rid the tests of any 'puzzles' regarding caches being off/more/less optimised by different programs, or even individual tests in the same programs.

Rather than trying to compare apples<>oranges. e.g. 68030; caches off, 68040 caches on, 68060...etc, etc. :dizzy:

Or as we want to use TT/32bit RAM/addressing, maybe stick to a '030', caches off?

It just takes away one headache from the whole comparison process.

Just sayin'... :lol: :hide:

exxos wrote: 11 Apr 2024 18:46 I guess it can be configured with altram in 68k space or TTram space. For most stuff, I think altram be easier in 68k space as it won't screw up the blitter access. Then anyone who needs more ram can, just won't be blitter friendly.

Blitter will have no access no matter where you map it.

The map will only ever apply to your emulated CPU.

Better to use TT-RAM space unless you’re emulating a 68k as then there is no confusion: it acts like TT-RAM.

Of course as it’s software there is nothing stopping someone writing a blitter emulator that can address 32 bit memory locations within the code, but it will have little advantage other than for compatibility. Speed isn’t really going to be an issue.

BW

mrbombermillzy wrote: 11 Apr 2024 20:25 All this sort of chat is going on in the AF forums ATM, with Gunnar Von B and the different HW/clones being discussed, including speeds.

Bet that's going well.

My personal opinion, having coded 68000 and 68030, is to do any tests running straight 68000 code to keep it clean and rid the tests of any 'puzzles' regarding caches being off/more/less optimised by different programs, or even individual tests in the same programs.

Yeah 68000 should be used as that's where the legacy software is at. Who's going to optimise all the games to run on a optimised 060 cpu or whatever. Not that the 060 would need anymore speed to run ST games :lol: but not my point :P

Also NVDI in the mix is enough to confuse things. Simply to much software all doing different things.

Rather than trying to compare apples<>oranges. e.g. 68030; caches off, 68040 caches on, 68060...etc, etc.

The barrel roll stuff gets faster per CPU gen. Nothing wrong with that kind of stuff. Caches while good and all that, it just adds a whole layer of chaos into the mix. We know they are generally good , so best to leave them off when comparing to a 68k IMHO.

Or as we want to use TT/32bit RAM/addressing, maybe stick to a '030', caches off?

For me I'm not to fussed currently about CPU type, be it 020 or 030. But yes the caches need to be off. The 020 is more TOS friendly so IMO, to rule out some headaches , the 020 is just easier to deal with.

It just takes away one headache from the whole comparison process.

Totally agree. My 32mhz booster access ROM at *almost* full speed. So it scales nicely to almost 400%. It makes sense and it's easy to add up. Now jump to the pistorm with 3,000% ROM speeds.. That be like 240mhz CPU. How much of that score is tainted by the CPU caches...The result is meaningless really.

But I think it can get more confusing because of the shifter accesses. I mean if we wanted to run 2 instructions , we would have a delay between the 2 instructions because of the shifter access. Now if we could run twice as fast, not only do we run 2 instructions at twice the speed but we didn't have to wait because of the shifter. So doesn't that it make it 4x as fast while only running at twice the normal clock speed, 16mhz.. :stars:

Of course it depends on the instructions. But as I tested years back, you can have 2 instructions running from ROM without needing any bus cycles. I think you basically got deminishing returns after 32mhz. But that's down to ST RAM bottlenecks then.

Badwolf wrote: 11 Apr 2024 20:57 Blitter will have no access no matter where you map it.

So the pi can't dump its own ram to the system ? Seems a bit odd :shrug:

exxos wrote: 11 Apr 2024 21:02 Now jump to the pistorm with 3,000% ROM speeds.. That be like 240mhz CPU. How much of that score is tainted by the CPU caches...

Remember you're measuring (completely Pi-side) memory speeds there. Like testing ROM speeds after running MAPROM -- you're testing TT-RAM in that case.

ROM speeds without availing yourself of a mapped ROM image will be close to stock. 102-110%. Something of that ilk.

exxos wrote: 11 Apr 2024 21:23

Badwolf wrote: 11 Apr 2024 20:57 Blitter will have no access no matter where you map it.

So the pi can't dump its own ram to the system ? Seems a bit odd :shrug:

I'm not sure what this means.

PiStorm is a bus master, or it's quiescent (after arbitration). It doesn't act as a bus slave so nothing (eg. blitter) can obtain data from it with DMA reads or write data to it with DMA writes.

It's a CPU replacement that has tricks *internal to the CPU*. If you magically grafted a load of memory onto a 68K's die, it wouldn't magically be DMA accessible.

BW