21.07.2020
I have not found the culprit in O3 yet – but someday I will :-).
I made myself an UART interface and added the inits to bare metal, so I have now at least a printf().
Also I made a Makefile and a compile environment, where I can compile tailgunner for baremetal and for „normal“ Pi from one structure. Not beautiful but working for me.
Nothing fancy though, I am not a huge fan of automated Makefiles – I like to control things myself.
22.07.2019
„DRIFT” calibration should not be used at the moment, everything else seems to work fine (finer on baremetal). (I am also not sure if drift calibration can work with the current setup)
I found the things that caused trouble and I can compile with -Ofast now.
Still the speed is only about 2/3 of that of a Multitasking version.
But right now I can’t really be bothered, since it plays perfectly without any flicker even when resized.
Later that might a be a thing to investigate.
There are two makefiles, one for a „Ubuntu 64″ linux, with a baremetal dev installment from:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
Put the ../bin in the path and you should be ready to go.
The other can compiler a „tailgunner” for the raspbian.
I used the „-S” version so assembler code can be seen, all files are first compiled to „*.S” and put into the build directory. Sometimes that was helpfull…
The baremetal version can „printf(…) to the UART mini – so one can print debug output to a Terminal (115200 8n1 no flow control).
I haven’t done any changes to tailgunner itself (speed/sound etc).
25.07.2019
I had a „personal” major breakthrough:
What this means is, I can access the filesystem of the SD card, I can read and write files!!! This doesn’t sound like much – but baremetal this is kind of cool!
The whole baremetal setup looks a bit different now, since I partly use a library(https://github.com/vanvught/rpidmx512)I also have a lose contact with Arjan (who also finds our project cool!).
As always the whole „just using a library business” wasn’t as easy as one would think (double function names, no debugging, compiler issues, missing defines etc etc).It cost me the better part of the last three days – but now its running.
My vision for the next steps would be:- Build some kind of bootup system, which only displays a „menu” on the vectrex.- From the menu one can load from the file system different „runnable” baremetal pi programs (different emulators).- Also for the emulators it would be possible to load the ROM images (which we most probably do not want to distribute with pitrex).
Would that be ok with you if I follow for now that route?(later I would come back to the direct vecx port and try to get that running a bit better)
Also I guess for the Asteroid emulator I propably have to implement a function like “v_drawDot(x,y, int ultrabright)” :-).
Also:
I have been pitrexing „nonstop” for quite some time now, my girlfriend is getting a bit squeezy – I might have to slow down a bit:-).