3 ms·
I assume you refer to BeePi, which is a fantastic thing but it doesn't run FreeMiNT as the _only_ OS on a Raspberry Pi. It basically packages up a Raspbian OS w
by chris_j 4y ago
I assume you refer to BeePi, which is a fantastic thing but it doesn't run FreeMiNT as the _only_ OS on a Raspberry Pi. It basically packages up a Raspbian OS with the Hatari and Aranym emulators running on top of it, with EmuTOS/FreeMiNT running on top of that. I've got it running on one Raspberry Pi and it's quite nice; unlike Aranym on my Mac, I can actually get networking to work. But it's not running an Atari OS directly on the Raspberry Pi hardware, which is a shame.
- cmrdporcupine 4y agoOh I see, you want to baremetal it. That's tricky. My friend did this with the C64 (BMC64) by making VICE run basically as a unikernel on the Pi. It's a lot of work. There's payoff there for something like the C64 where latency is super important for video games etc. But on the ST, I dunno if I see the advantage esp if you're running MiNT etc. If you mean actually running the OS sans emulation, like a port of TOS/MiNT to ARM; I actually started down this road many years ago, trying to port as much of EmuTOS over to native ARM as I could... and others have fiddled with it, too. But it's a huge endeavour with little payoff. There's no binaries to run, so you'd end up hosting an emulator in it, and the endianness is entirely different so it's just... awkward. I found the transition to 32-bit and little endian and totally different graphics hardware made much of the EmuTOS sources useless. Take something like the AES. It uses 16 bit big-endian values throughout, hardwired into C-structs, basically. And this maps 1:1 with resource file contents. You either have to rewrite everything incompatible with ST-AES and resource files and use 32-bit little endian. Or you have to be constantly swizzling values back and forth. Or do both. Awkward. Or the VDI that's written there. I actually made "ok" progress writing a fresh VDI from scratch for the Pi framebuffer. But then... what's the value? The API is not really compatible because word sizes, framebuffer depth etc. It just starts to look really anachronistic. Better to just build something new.
- chris_j 4y agoApologies, I was assuming that lproven was talking about baremetalling it but apparently not. Re endianness, I confess I hadn't even thought of that aspect of it. (I understand that Cortex-A processors can run in big-endian mode but I bet it's not that easy.) And I bet there are a million other things that would be hard to make work. But I still wish EmuTOS/FreeMiNT could be made to run on a modern CPU. It makes me sad to think that the 680x0 architecture basically isn't going to go much further than the Apollo 68080 (or Coldfire...), whereas a modern ARM (or X86 or even RISC-V...) chip is stupendously more powerful and I'd love to be able to run those OSes on that. Oh well, I can dream I guess...
- cmrdporcupine 4y agoI tried booting an RPi in big-endian and I was unable to get it to work. Maybe there's a way. I'm not an ARM expert, so. It's probably more reasonable simply to boot directly to a bare metal 68k emulator -- one that doesn't emulate any hardware other than the CPU but passes through to the underlying video etc hardware -- and host a fork of EmuTOS there. There is also this project : https://github.com/kelihlodversson/pTOS https://github.com/kelihlodversson/pTOS Which appears similar to what I had attempted, myself. Looks abandoned though. You might also look at RISC-OS. It runs (single core) on a modern Pi. And it's kind of similar to GEM/TOS in terms of era and style. It is kind of a shame that ColdFire is dead. It held promise.