kelihlodversson / ptos Goto Github PK

(I think this should be asked (demanded?) sooner rather than later.)

Is it possible to (quickly?) rework the new RPi additions to EmuTOS, seperating RPi and ARM v6 and v7 stuff as well. So it can easily be modified for another device, specifically (but not limited too) other arm devices like Banana, Orange, etc (or the Gemini Palmtop PDA: http://www.planetcom.co.uk/) where usually only the video initialization need to be different for different platforms .. and other non-arm SBC's could use it too, also allowing pTOS to be safely integraded back into EmuTOS (in the future) if need be.it would also mean Iyonix (armv5) owners could (theoretically) use it as well (not that I have one to test on mind you).

.. thereby making pTOS into portableTOS instead of just piTOS

ok, almost there, now I am getting:
obj/emutospp.ld:127: undefined symbol '__mulsi3' referenced in expression

In emutos.ld, is the following RPi specific or cross-GCC specific:

ELF_LIB_REF(__mulsi3)
ELF_LIB_REF(__divsi3)
ELF_LIB_REF(__modsi3)
ELF_LIB_REF(__udivsi3)
ELF_LIB_REF(__umodsi3)
ELF_LIB_REF(__aeabi_idiv)
ELF_LIB_REF(__aeabi_idivmod)
ELF_LIB_REF(__aeabi_udiv)
ELF_LIB_REF(__aeabi_uidiv)
ELF_LIB_REF(__aeabi_udivmod)
ELF_LIB_REF(__aeabi_uidivmod)

why are they hard coded? how can these symbols be present in assembled code if they are NOT present in the libs they reference (libgcc.a in this case).

when I do arm-none-eabi-nm /usr/lib/gcc/arm-none-eabi/4.8/libgcc.a | grep "__mul" I get:

00000000 T __muldf3
00000000 T __mulsf3
00000000 T __muldi3
00000000 T __mulvsi3
00000000 T __mulvdi3
00000000 T __mulsc3
00000000 T __muldc3

and when I do arm-none-eabi-nm /usr/lib/gcc/arm-none-eabi/4.8/libgcc.a | grep "_muls" I get:

00000000 T __mulsf3
_mulsc3.o:
00000000 T __mulsc3
00000000 T __gnu_mulsq3
00000000 T __gnu_mulsa3

same with fpu/libgcc.a. by the way on RPi this usually indicates the need for -lm and a specific -L directory. but I also notice there are no "i" references there either, except __mulvsi3 & __mulvdi3.
however all the "aeabi"+"idiv" references seem to be present

I will try non-cross with gcc-6.1.0 tomorrow, as I read in a baremetal tut that you dont need arm-none-eabi when compiling on the actual hardware (just static linking).

actually I just checked 6.1.0 with /usr/local/gcc-6.1.0/bin/gcc-nm-6.1.0 /usr/local/gcc-6.1.0/lib/gcc/arm-linux-gnueabihf/6.1.0/libgcc.a | grep muls and I get the exact same as above, also with GCC 4.9, so it looks like some of those symbols are not present on actual Raspbian/Debian for Pi.

edit: I just checked a arm-none-eabi/4.8.3 not from the repo, and it is also the same.

I could probably #if defined(RPI) & !defined(QEMU) the actual values in, presuming this is the right thing to do (I dont have a m68k-atari-mint on any Raspbian distro to triple check)

I am getting the following on with make rpi2 as well as make rpi1:
/tmp/cc5c6vLp.s: Assembler messages:
/tmp/cc5c6vLp.s:436: Error: alignment too large: 15 assumed
Makefile:1169: recipe for target 'obj/raspi_memory.o' failed
make[1]: *** [obj/raspi_memory.o] Error 1
Makefile:702: recipe for target 'rpi1' failed
make: *** [rpi1] Error 2

seems like these are the offending lines:
// Todo figure out a less wasteful way to allocate these:
UBYTE mailbox_buffer[MEGABYTE] __attribute__ ((aligned (MEGABYTE)));
struct TARMV6MMU_LEVEL1_SECTION_DESCRIPTOR raspi_page_table0[PAGE_TABLE0_ENTRIES] __attribute__ ((aligned (4*1024)));
struct TARMV6MMU_LEVEL1_SECTION_DESCRIPTOR raspi_page_table1[PAGE_TABLE1_ENTRIES] __attribute__ ((aligned (4*1024)));

there must be another way to do this, even if its after boot. How does EmuTOS place items on page (or Mb) boundaries?

if not directly related to the issue #5 (chunky raster ops) ...

then it is possible the pre-built RSC files are not TOS compaible or not being accessed in a TOS compatible way (ie mk8k Big Endian). For true portability, all RSC resource files in pTOS should use the m68k-atari Big Endian format.

AFAIK armv6 is Big Endian by default (armv5 is too), and armv7/8 is Little Endian by default.

IE. you dont get render issues with the ARAnyM build of EmuTOS when using 24bit screen.

How are you pulling updates from the EmuTOS repo? I will be dropping and re-forking pTOS again tomorrow and the next lot of "issues" will be available as fixes via pull requests.

with the github interface, Merge request and Squashed commits both only add 1 commit, while committing all the changes made to the master. the Rebase option commits everything but then shows that amount of commits ahead AND behind.

How should I update my repo from urs? Should I only work on a new branch and make pull request with changes from there (not updates from master, but the stuff I will fix/add).

Also atm, sometimes I have to boogie a compare to Otto Thorstons repo just so I get the pull request going in the right direction. Doing pull request from a fork is not the same as being part of a project (master) repo.

How can I work this without having to drop the repo and re-fork to keep things clean? (Plus I have to re-clone across a phone every time, not low bandwidth diffs like normal repo updates)

After adding usb mouse support, the mouse pointer can now be moved around on screen.
Even though it looks like the correct mouse movement and button handlers are being invoked, the AES does not seem to update the screen based on the mouse events.

FYI: The builds I did at the time of the other issues posted confirm boot on RPi B, and RP2B+.

I now have RPi 3B+ and RPi 4B+ (v1.1 4Gb) and a v1.3/1.4 (or 1.5?) 8Gb version coming in October. Hopefully builds to come before christmas (2021), even without further USB support.

I am also going to try a build for Teensy 4.0 (600Mhz dual core ARM M2 with 2Mb eeprom and 1Mb ram), but I dont have any expansion board for input or output at the moment, so it would be just proof of concept.

Also note, I see a repo by Mikro with a pTOS toolchain.

If you add another make qemu-rpi2 option to make, then it can preset some things (sw mouse cursor) before also parsing the rpi2 settings. Unless you just add a QEMU def to make and set it to rpi2. there may be other things needed later on too.

I'm thinking as every day goes by the QEMU RPi2 will get closer and closer to the real thing, so unless they support a EMU detection like most AtariST/Amiga emu's do, you wont ever be able to "autodetect" especially if building wit cross-tools.

Note I said qemu-rpi2 and QEMU=rpi2 as it allows for non-RPi 2 build options later on.

when building "make rpi1" it aborts with unsupported architecture extension. I #IF'd out the "virt" but I can not yet figure out how to replace:

msr ELR_hyp, lr ;@ Set the address to ELR_hyp
eret ;@ Elevated return which will exit at NotInHypMode in SVC_MODE

the code is in startup_rpi.c, but the comments came from a raspberrypi.org post. I could only get 2 search results for msr ELR_hyp, lr, so I am unsure how to proceed atm. Ideas?

are these correct, they are 2Mb less than before, and the numbers in the final make output dont add up any more either:

### Warning: The DATA segment is not empty.
### Please examine emutos.map and use "const" where appropriate.
# TEXT=0x00008000 STKBOT=0x00083900 LOWSTRAM=0x00000800 BSS=0x0004b200 MEMBOT=0x0008b900
arm-none-eabi-objcopy emutos.elf -O binary kernel7.img
# RAM used: 571648 bytes (528590 bytes more than TOS 1.62)

sysop@pipaos:~/build/emu/pTOS$ expr 571648 - 528590
43058

-rwxr-xr-x  1 sysop sysop 274820 Aug 18 11:00 kernel7.img
-rwxr-xr-x  1 sysop sysop 274188 Aug 18 10:59 kernel.img

are these similar to what you are getting?

Well it looks like I wont have to buy a Gemini PDA after all, as according to the following link, some work is being done right now on the Asus C201 Chromebook, and RK3288 based arm7l processor, so it is able to alternate boot without the possibility of bricking the unit.

Miouyouyou/RockMyy#3

I will look into this as soon as I have BOTH the armv6 RPi B and armv7 RPi 2B+ booting to the pTOS desktop, like this:

#3 (comment)

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)

according to what I saw in the main RPi repo, it is possible to get the following..

.. for Raspberry Pi native HDMI resolution or set in config.txt:

default: read mailbox first to get native resolution, then set it again, including virtual

.. for non-standard:

closest: query mailbox with X by Y and "closest" set, returns the closest supported rez.
best: query mailbox with X by Y and "best" set, returns best supported rez
then: set mailbox to that rez with custom virtual rez (ie add borders)

.. for Falcon:

640x480 VGA: this is the smallest rez HDMI can set, even down to 2 bits per plane
640x400 RGB: this can be set by choosing 640x480 and setting virtual to 640x400 with 40 top + bottom borders

.. ST (a bit more tricky):

320x200: this can be set by choosing 640x480 and setting virtual to 640x400 with 40 top + bottom borders, and using pixel doubling
640x200: this can be set by choosing 640x480 and setting virtual to 640x400 with 40 top + bottom borders, and using pixel doubling on the Y axis
720x400: this can be set by choosing 720x480 and setting virtual to 720x400 with 40 top + bottom borders,
1280x960: this should be closest to 1280x1024. (with SDL, Y axis "spliced" for 1360x768)

NOTES:

640x480 is both CEA (HDMI mode 1) & DMT (DVI), this is minimum for ANY monitor HDMI or DVI
720x480 is CEA (480p/480i), all HDMI have this, standrad (4:3) and letterbox (16:9)
1280x1024 is DMT (DVI) and may not be available unless 1080 is also available.

the 1280x960 Viking mono mode can be modified to either 1280x720 or 1280x1024, which is exactly how minimig does it. I have had the same success with PCE-ST emu (1280x768 on 1360x768 monito). Note here that they also moved the base video address to ALSO allow FULL 14Mb of RAM when Viking mode is active (normally this is only 10-12Mb on real hardware). I dont know if EmuTOS supports 1280x960 mono yet?

I have 2x HDMI monitor from tha same manufacturer (Uniden), one is 19" the other 17". They both support exactly the same rez (incl. native 1360x768), except that on the 17" the1080 modes are squashed in hardware down to 1360x768 (native) physical rez, where as the 19" LCD panel is 1900x1080, and hardware expanded to 1360x768 (native). Our main TV (Sony) however is 1280x720 with (8-16-24-32 pixels) hidden borders

Also note that there is currently are a couple of discusions on the EmuTOS mail list about "extra rez" and storing them for across boots. The way SuperVidel XBIOS does it is unsuitable for HDMI/DVI monitors.

howsit, I am watching you progress on this project almost daily, as I would like to "fix" the boot rez (chose native or nearest "choice") and add reasonably useful rez including 320x200, 640x400, 640x480 and 1900x1080 (plus native rez).

I'm building on RPi 2 and with a fresh clone I am getting the following build error (RPI=2 make rpi2):
bios/startup_rpi.S: Assembler messages:
bios/startup_rpi.S:269: Error: bad expression -- 'ldr r0,=#0xfff000f0'
bios/startup_rpi.S:270: Error: bad expression -- 'ldr r1,=#0xe7f000f0'
Makefile:1172: recipe for target 'obj/startup_rpi.o' failed
make[1]: *** [obj/startup_rpi.o] Error 1
Makefile:714: recipe for target 'rpi2' failed
make: *** [rpi2] Error 2

this is what make says its doing:
make RPI=2 WITH_CLI=0 DEF='-DTARGET_RPI2 ' OPTFLAGS=-O2 UNIQUE=us IMG_RPI=kernel7.img kernel7.img
arm-none-eabi-gcc -march=armv7-a -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -fsigned-char -g -fleading-underscore -fno-reorder-functions -DELF_TOOLCHAIN -O2 -fomit-frame-pointer -fno-common -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -Iinclude -DWITH_AES=1 -DWITH_CLI=0 -DTARGET_RPI2 -c bios/startup_rpi.S -o obj/startup_rpi.o

I am using Raspbian jessie-stable-old (PipaOS v5):
gcc-arm-none-eabi (4.8.4-1+11-1)
binutils-arm-none-eabi (2.24.51.20140604-3+5)

FYI: the forced RPI=2 stops a "/bin/sh: 1: m68k-atari-mint-gcc: not found"

This seems pretty basic (fundamental), so any ideas would be welcome.

In the README.md for pTOS, can you explicitly state the GCC & BinTools versions you are using and on what platform (and its version), and whether or not you have a "m68k-atari-mint" cross-toos install (and is it in your path.

Can you also state explicitly what hardware you are testing on (incl. QEMU version)

Using Jessie-Stable-Old distros, I can get pTOS to build without error for both armv6 and armv7, have not tried armv8 (aarch64 or aarch32) yet, with "arm-non-eabi-4.8" (a known good version for compiling for arm targets incl. RPi) as long as I "fix" the __attribute__ ((aligned (4*1024)) in line 94 and 95 of pTOS/bios/raspi_memory.c to something more respectable (ie <16), I chose 8.

However I can not get pTOS to boot on either RPi B (armv6) or RPi 2B+ (armv7). If these are CPU cache related alignments, the 8 is enough for one instruction, but not enough to move it to a page boundry (4*1024). This may be the cause of "cant boot".

Alternatively, the initial compilation Error warning I get (1st line) before make drops in to the target, is not finding "m68k-atari-mint-gcc" which is used to pre-build tools and the resource file that gets included in the target build.

Without early boot console output, I can not see why pTOS is not booting, and the FAT16 write code is not usable yet to enable a dump or trace file.

The simplest immediate solution is to test (at least) the armv7 binary last considered stable by your development environment. If I can not get that to boot I know there is a code issue, not a compiler or configuration issue. So making your binaries available would increase initial build fault finding.

a emudeskt.inf and the RPi boot files would also help speed things up, as would a pre-built sdcard image (1 FAT16 partition). I have tested with a hand built FAT16 boot partition and a pre-build FAT16 boot partition (Linux Wheezy, that I know works), both have failed.

If you were to add 3 sections to the README.md, one for known OS success (or failures), one for GCC version successes (or failures), and one for known target success (or untested - RPi 0, RPi 0w, etc) that would be useful (especially in years to come). Or a new pTOS-BUILD.md file if that makes more sense.

Because I can not use QEMU (I am not on a PC/x86), and I dont have a USB serial (UART) cable, to simplify debugging, I have to go back to basics of bare-metal building ans develop an early console output.

Technically that would eventually be more useful if the ROM image being built was one with EmuCON built in to it and modified for pTOS debugging.

The only major VDI feature missing still is rendering of raster blocks.
In bitplane modes this is handled by complicated and optimized 68k assembly.

vro_cpyfm and vrt_cpyfm:

For our purposes the 8bpp packed pixel implementation can be implemented in straightforward C.
We need to support the following situations:

• blit 1bpp source to 8bpp packed pixel with fg color.
• blit 8bpp to 8bpp

And we may need one or both of these (FVDI seems to not support these.)

• 4bpp (packed pixel - two pixels in a byte) to 8bpp.
• 2bpp (packed pixel - 4 pixels per byte) to 8bpp.

vr_trnfm:

For converting MFDBs from standard to device specific format (and vice versa), we need to support:

• 8 planes to/from 8bpp packed pixel
• 1bpp is the same in both packed and standard format, so it's a no-op/pure memcpy

In case we implement the 4 and 2bpp blits above, vr_trnfm needs to additionally support these:

• 4 planes to/from 4bpp packed pixel
• 2 planes to/from 2bpp packed pixel

https://github.com/rsta2/uspi
this project was ported from Circle USB so it may be worth comparing since you are using parts of Circle

also this comment may assist immediately with better usb hub related detection or lack of it:
Chadderz121/csud#10

specifically:

... if you want to connect a USB keyboard, for example, directly to the USB port of RPi model A/A+/Zero/Zero W because they have no on-board USB hub (LAN9512) and their USB port is the port of the root hub.