PiStorm Chat

[Steve]

Thanks BW, that clears it up. So technically once it's stable to be used in a system on a day-to-day basis, you could have the PiStorm start at the same time as the system automatically and the Atari will spring to life as soon as the emulator loads itself.

I just wasn't sure thx

[alexh]

in order to use the Atari, you need to SSH into the Pi and start the emulator every time? Or can that be automatic. Also if it is automatic, is it fast enough turning on for when the machine is expecting a CPU to be present?

It is only after a cold boot. I believe it can be made automatic. It is not fast enough to avoid making the first cold boot slower than a real 68k. Warm boots are unaffected.

[Badwolf]

It is only after a cold boot. I believe it can be made automatic. It is not fast enough to avoid making the first cold boot slower than a real 68k.

I've had it set up to auto-run in the past (crucially I forgot to do this before the Cyberlegends show which then
necessitated HDMI cables and USB keyboards being broken out ). Using my completely non-optimised Raspbian installation it takes about 15-20 seconds to come up on power on.

Warm boots are unaffected.

They would be if such a thing worked at the moment.

BW

[ctirad]

Raspberry Pi as virtual graphics card byte-swapping and dumping a 4 meg block of memory to the screen in Falcon 565 format. fVDI tweaked to provide the framebuffer in the right bit of altram space.

There is already existing open source implementation of the fvdi driver as part of the Aranym VM. The 68k part of the driver is just a wrapper, that pushes VDI calls to the main VDI driver that runs on the host CPU with all its resources available. There are in fact multiple NatFeats drivers. Network, audio, XHDI, SCSI, etc.. Porting it to the Pistorm should be easily possible.

[Badwolf]

@Steve



BW

[Steve]

@Badwolf Very nice!!

[Steve]

@Badwolf Do you think it may be possible to use emu68 instead of musashi to solve the speed issues?

[alexh]

The speed issues are down to the communication protocol between the Pi and the CPLD.

Which emulator you use is (I believe) irrelevant when it comes to ST-RAM access speed.

To solve the ST-RAM speed issues you'll have to change the Pi<->CPLD protocol. Perhaps compress it?

[Badwolf]

Sorry, I've not been active in PiStorm development since my new family addition.

THIS INFORMATION COULD HAVE BEEN SUPERSEDED:

AIUI the protocol itself isn't realy a problem. The GPIO pin reading times are the biggest factor in that but are still only of the order one half an 8MHz clock cycle -- not enough to cause a problem if they read correctly the first time. I think we actually poll them twice, so one clock cycle. Still not too bad if a bus cycle is 4 full cyles.

The issue I encountered was that having completed the data read, the emulator was not ready to request the *next* bus operation quickly enough. Writes, which don't require any futher emulator logic, can be made full speed as the next write is available instantly. Reads, however, are a little late and miss their bus transfer slot, having to wait again for the next one.

So a bare metal emulator, emu68-style, would likely solve that, yes.

I suspect it's not likely to be emu68, however, as that's extremely highly speed optimised and therefore probably doesn't have bus error, bus arb, FC lines and all the other things our STs need. Also bare metal is hard.

But I've not been following of late and @dad664npc nearly got Muashi to to 100% read speed, last I saw.

BW

[peters]

I'm not a hardware expert but when I read about the half speed RAM it made me wonder if it was missing the time slot and having to wait for the next.