PiStorm Chat

[Badwolf]

Cool, my falcon ones won't fit then, I will order one off amazon or somewhere then. Shame rapid don't seem to sell them.

Falcon is also 2.54, but the expansion headers are 30 and 50 pin, IIRC. Pi4 is 40 pin.

Same as a (full size) IDE connector.

BW

[Badwolf]

What was the reason for that over 373 ?

Timings - some ATARI's work, some don't - you know all about that :)

373s (latches) latch on falling edge, 374s (flipflops) latch on rising edge, so there's a [minimum of] a half clock cycle difference if using the same firmware.

All the work's been done on 374-based boards.

BW

[Badwolf]

Remember to get that GPIO riser package I mentioned in PM too.

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.

Here's how I initially brought it up. have alook at the height of the PiStorm socket!



BW

[stephen_usher]

I'm not sure that the tower is quite tall enough.

[exxos]

@Badwolf Does the thing copy ROM to the pi's own RAM and fake the address with the MMU like MAPROM does ? That would be amazing not having to go to the MB slower ROM all the time.

[agranlund]

I'm not sure that the tower is quite tall enough.

:lol:

[Badwolf]

@Badwolf Does the thing copy ROM to the pi's own RAM and fake the address with the MMU like MAPROM does ? That would be amazing not having to go to the MB slower ROM all the time.

MMU is not emulated, so no.

At its base level it simply uses all motherboard resources.

You can then map in extra bits of Pi RAM to the 68k's memory map, should you so choose. The obvious one is a ROM image at 0xE00000 and the same image at 0x0-0x7.

It then behaves like a DFB1 does with private to the CPU (ie. non-blitterable) ROM.

You can also map in AltRAM, TT-RAM, graphics card RAM etc.

BW

[dad664npc]

@Badwolf Does the thing copy ROM to the pi's own RAM and fake the address with the MMU like MAPROM does ? That would be amazing not having to go to the MB slower ROM all the time.

ROM images can be loaded at emulation start - if not supplied, on board ROM is used
All ATARI hardware remains as is. PiStorm simply emulates the CPU - hence 68000, 68010, 68020, 68030, 68040
PiStorm can map regions of memory to enhance performance, such as mapping in ROMs, and as BW said, AltRAM etc.

[exxos]

373s (latches) latch on falling edge, 374s (flipflops) latch on rising edge, so there's a [minimum of] a half clock cycle difference if using the same firmware.

All the work's been done on 374-based boards.

OK thanks. @go0se seems to be the guy to get the boards from. I am waiting for him to reply on that currently.

[exxos]

MMU is not emulated, so no.

Ah bugger. But no big deal I guess.

You can then map in extra bits of Pi RAM to the 68k's memory map, should you so choose. The obvious one is a ROM image at 0xE00000 and the same image at 0x0-0x7.

It then behaves like a DFB1 does with private to the CPU (ie. non-blitterable) ROM.

That be cool. I mean if the CPU can access a copy of ROM in the pi ram, that be a huge speed bump right there.

You can also map in AltRAM, TT-RAM, graphics card RAM etc.

Exxos approves. :lol:
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.