30.07.2019
After a 2 days pause, today I hacked a little bit concerning PiTrex.
I started programming a bootloader. It is not fully developed yet (doesn’t generate the menu from items on disk etc).
But it lets you select 1 of the four „runnable“ PiTrex programs and starts running them.
(baremetal)
The current memory layout I am using when doing baremetal:
/* Memory Map: 0x8000 start of baremetal kernel.img all of the bootcode programs Stacks moving "down" 0x308000 - 0x300000 - undefined stack 0x310000 - 0x308000 - abort stack 0x318000 - 0x310000 - FIQ stack 0x320000 - 0x318000 - IRQ stack 0x340000 - 0x320000 - supervisor stack * 0x500000 - 0x0ffffff user prog loaded (fixed) (only 1!!! at a time!) 0x10000000 - 0x1fffffff heap space of user progs */
In general this means, the bootloader is able to load one program (it doesn’t use malloc or anything).
The loaded program must be compiled to load to address 0x500000 (I do not generate or handle relocation tables, so since the programs have fixed memory addresses I must use a „defined“ address).
I created new makefiles which generate „pit“ files:
tailgunner.pit
vecxemult.pit
asteroids.pit
Once loaded I jump to the address 0x50000 and execute the programs. The programs itself are „normal“ „C“ programs from the user point of view – they can do file accesses and even use malloc() to get memory (see above heap definition).
To my surprise this worked nearly out of the box – hurray!
Pressing all four buttons returns to the menu (AKA does a jump to address 0x8000 and so resets to the boot state).
I tried „capturing“ the reset button of the vectrex but with the current implementation it is total coincidence whether it works or not
probably works 1 out of 100 times.
Thing is if VIA is reseted, than all registers are set to zero (and all interrupt disabled etc etc etc).
While Vector drawing – we wait for the interrupt T1flag to be set – that is than obviously NEVER the case – so we stay in an endless loop
I might find a way around that, but not tonight :-).
31.07.2019
Suggested strategie:
- bootStrap (kernel.img) this is the “program” the Pi always starts with. The bootstrap loads a “loader.pit” to address 0x1f000000 – which is nice far away – and starts it.
- loader.pit (position dependend code) displays a menu, the menu entries are actual “img” files. The selected img file is than loaded to 0x8000 and acts (MUST act) as a “normal” kernel. Which means it also must set things like stack/vectors/alignment access/speed/mmu etc
That way – any menu entry can be loaded – and if it is a “raspian.img” menu entry… it would work.
Will try that tonight.
01.08.2019
This stupid Pi!
It doesn’t behave like I want it to!
image1 boots fine using below strategy
image2 boots fine using below strategy
image3 hangs while booting
All three images use the same start code!
And image3 hangs before it even executes any code that is different from the other two!
I look at the sources for 2 days now. There is nothing wrong… I am frustrated and will take a day or two off now.
Gee that bare metal stuff is crap – and the documentation also. According to all my sources – I am doing everything right…
and it works on 2/3 of my images…
Grrrmmmllll!
https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=247562&p=1512126#p1512126
(The problem went somehow – away and was not seen again…)
update…
All bare metal „only“
- First I concentrated on the boot loader.
- Than I tried to make some very precise timing functions.
- Than I tried to improve Vectrex direct emulation.
- I did not change anything with the SBT variants. I slightly changed some timing parameters, these are not
calibrated with the SBT – so some vectors might be off. I think sooner or later we anyway need a
different configuration file for each SBT. - I have for a long time not compiled any raspbian version – there might be some changes necessary
- I changed the “vectorDraw” files to “vectrexInterface”.
- pi is switched to 1000Mhz on start
The “kernel.img” file is built from the files in directory “pitrex/piTrexBoot/…”.
This file “starts” the pi bare metal.
As the second stage the binary: “loader.pit” is loaded (built in the same directory).
This displays as of yet 5 hardcoded entries on the Vextrex:
VECX DIRECT
VECX EMUL
TAILGUNNER
ASTEROIDS
BATTLE ZONE (not working yet)
You can select the entry and press a button. Reset on vectrex brings you back to the bootloader.
The corresponding “img” files are loaded from the SD and started.
These img files could also be taken as a “normal” boot kernel…
VECTREX DIRECT
Has become MUCH better. All strings are still “dancing” a little bit – but are well discernable.
Given the fact how precise the timing must be for the strings to be correct I think the accuracy is nothing short of astounding.
One Vectrex cycle is 666 nanoseconds = 0.666 usecond.
The most accurate timer on the pi has a resolution of 1 useconds – the slight “dancing” of the strings is timing wise exactly in that region I guess in about 0.3 useconds. I really don’t think we can be better than what we have now.
If we want “direct” emulation to look better I have to program a “hook” to PrintStr and do it directly on the pi.
vectrexInterface
In the “h” file you can now switch between :
#define BEAM_LIGHT_BY_SHIFT 1
#define BEAM_LIGHT_BY_CNTL
In FREESTANDING mode (bare metal) RAMP is still set/unset using the T1 timer – but the waitloop for “vectorstart” / “vectorend” is not a busy loop checking the timer all the time, but using the pi system timer. That way I can detect the reset button on the vectrex without execution halting.
I think I might pause a little the “pi” development… I have to catch up on my vectorblade.
Next things on my todo list are still more experimental:
- program a file lister – to be able to load files from the SD
(like specific vectrex roms) - write a YM player, that plays YM files thru the vectrex
- write a sample player, that plays WAV files on the vectrex
- write a “movie” player that plays files like “Bad apple”
The last three points should not take much longer than a couple of hours each – but would be cool “demos”
- than next step would be to build a configuration file setup for different emulation needs
The current SBT would need special settings to be really “beautifull” – like some
hints regarding vector drawing optimization. - Perhaps afterwards a little “demo” of what own “C” programs could do with the speed
of a pi in the background (probably some 3d stuff)