PiStorm Chat

[Badwolf]

This one's for @Steve. :?

IMG_5973.jpeg

IMG_5974.jpeg

BW

(bonus photobomb to keep @exxos and @Icky on side after I've used hi-res pics... but I think they're justified ;) )

[Icky]

Nice mug @Badwolf, so how are you getting that resolution then :)

[Steve]

Wowwwwwwwww!!!!!

[Badwolf]

Nice mug @Badwolf, so how are you getting that resolution then :)

Thanks for the compliment, but why are you calling me a mug? ;)

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.

Trying to set up that image reminded me of doing desktop publishing on Pentium-class early Windows 2000 machines. You'd try desperately not to move the scroll bars because each window's redraw took three or four seconds!

BW

[DarkN3mo]

I NEED the pi4 support !!

:shock: :shock: :shock:

[Badwolf]

Bit of a development today.

For the first time ever, someone else, with a different Raspberry Pi, Pistorm board and ST was able to boot to desktop.

Over the last few weeks @dad664npc and I have been doing a bit of a reassessment of the PiStorm work I'd done initially.

With help from Lucasz over on the PiStorm Discord server we were able to slowly, by trying each others' ideas and seeing where things got better and where they got worse, spot mistakes I'd made that were either relying on my particular machine, relying on software timing, relying on acts of god or were simply wrong.

Today was one of those 'that's simply wrong, how did that ever work before' moments. Acknowledging all interrupts rather just the vectored ones(!)

Anyway, with that breakthrough I now believe there are four STs (three STEs) able to boot using at least four different RasPis and four different PiStorms. Half of which have latches, half of which have flip-flops (another issue I was initially unaware of).

IMG_6181.jpeg

Speed is back down again. Pretty much exactly half ST-RAM access rates, but we're trading that for repeatability at the moment.

If anyone has a socketed 68K or an STE adapter, a PiStorm board, a compatible Pi and fancies giving a it a go, this particular commit is the place to start:

https://github.com/dh219/pistorm/tree/0 ... 5e164b75c9


Here are the current stats. Don't expect miracles!

IMG_6182.jpeg

IMG_6183.jpeg

BW

[stephen_usher]

Stability is the key isn't it? Once you have a stable, if slow, system then you can at least look at optimisations.

[alexh]

Thanks for all your hard work. Looking forward to trying it soon. Bus arbitration is something I am watching closely as it is needed for PiStorm compatibility with CDTV

[Steve]

I still haven't got my head around the process of PiStorm, so 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?

[Badwolf]

I still haven't got my head around the process of PiStorm, so in order to use the Atari, you need to SSH into the Pi and start the emulator every time?

Yes, at the present time. Given its developmental status and you also to be able to interrupt the emulator for a reset (as we've used the reset line for bus error & have yet to provide a work around), this is not surprising.

Or can that be automatic.

PiStorm comprises a board+firmware and a piece of software.

The board and firmware allow the piece of software, running on a separate computer (the RasPi) to send and receive signals to the 68K socket on your ST permitting it to pretend to be a processor.

How you choose to run that software on the small computer is entirely up to you. Same as how you choose to configure that software. You may log in and run it every time (like the developers) or you may script it to run automatically on start up.

Also if it is automatic, is it fast enough turning on for when the machine is expecting a CPU to be present?

What does fast enough mean? The ST will happily wait all day until a user logs in and runs the emulator software if necessary. It's not dissimilar to powering on and holding reset. There's no requirement for the CPU to be ready in a certain number of seconds or anything.

BW