I have been looking at m68k emulation, there is command line which executes gcc for 68000 sucessfully, I have the pieces to update it to the latest Musashi core, and I was going to add a 68040 version (to run 020-060 binaries, which also run of Vampire).
On RPi 2/3/4 there are 4 cores available, so instead of adding (traditional) binary execution (executed in single threaded pTOS core), I thought to use at least 2 of those extra cores to execute m68k code only. Thinking the final core could be used for "Atari specific hardware emulation", if there is a need for such things (eg. AY-3-8910, YM2149F, YM3439, RTC), or system emulators (Steem, Hatari, AranyM), or development specific tools - however this has implications for single core systems.
I am also looking to build 64bit versions, knowing 32bit build on RPi3 already works, (hopefully) allowing RPi4 builds (both 32 & 64 bit). It is possible that RPi4 wont boot off less than FAT32 partition (yet to be confirmed). I have seen a pTOS toolchain by mikro (on github).
If the above mentioned toolchain works natively on ARM, then I will look to compile a developers image, specifically for Olivier Landemarre to build MyAES for pTOS (there is a new version due out soon, around christmas 2021).
(If all the above goes well) To support usage and further pTOS developemnt across future (incompatible) platforms and architectures, I am looking to compile a "source only" package manager, to help users (as opposed to just developer tools).
I am woundering if 192K ROMs are enough to support a "pTOS platform OS", thinking about UTF and the 512K ROMS, but the UTF libraries are HUGE, and weather or not adding uClib, Diet, or NewLib should be tacked on to the end of a 512K image, along with LDG to simplify developement and reduce binary size (ie. non-static binaries without shared libraries), or weather to jump straight to stripped down MiNT (built with an above mentioned lib).
It seems that, besides an emutos.inf
, a ptos.inf
might be useful, to help control and configure the boot process. Specifically (for me) the default resolutions, which vary depending on HDMI displays, all of which support 640x480, but not all support resolutions upto 4k (CEA), and there are various native monitor resolutions (DMT), again, usually only a selection are supported (sometimes none) - there is new NatFeat funtionality in EmuTOS to deal with this in Hatari (and other emulators, when implimented).
Without a proper working USB, and possibly a drive & partition format setup, further hands on development will be differcult, but not impossible, as the mouse works, and you can prepare the post-TOS side of the boot process before hand, even without in-TOS write access to the FAT16 boot partition (currently disabled by default).
On RPi the current build system uses the standard kernel.img
load process, which means all DTD and (standard RPi) config files (nomally in the partition root) can be moved out of the root, into their own subfolder, while still retaining the ability to use any RPi hardware (with their paired kernel blobs). on x86 Chromebooks there is uboot to do the same, and examples of uboot on RPi (OpenElec).
A uboot layer (a pre-kernel boot layer) can be used to set up or contain filesystem drivers, which the TOS side would then not have to provide (they would work natively per platform and architechture), and could be used to impliment other NatFeat's. Gparted now contains many formats by default, including AtariST and Amiga. FAT32 is native on most systems, and FATeX is a common format for large drives shared across various OS's.
There is now working Vulkan driver for RPi3. RPi can (in hardware) auto scale graphics modes (I have a locked 640x480 RPi2B+ that will boot the default 1280x720 pTOS, down-scaling without any modifications, and all my monitors work at 1360x768 natively, even tho they all support 1080p)
In theory it is possible to boot multiple pTOS partitions from a single installtion (on RPi), and therefore (with multiple cores) possible to run per-core instances (with only some minor pre-setup for either locked memory per core, or shared memory manged by core-0)