26.01.2020
Finalizing for now…
Short notes – unsorted…
Starting on Raspbian
On Raspbian without „sudo“ the timer is not accessable – therefor some things do not work as intended. Most notably, gyrocks doesn’t shoot (shots are timed things…).
Make
I changed/“redid“ all raspbian makefiles.
a) they use a different „build“ directory
b) pitrex/vectrex/sim – common stuff is only build once
c) the „single“ makefiles call makefiles in the appropriate directories
The makefiles for baremetal were not changed (yet).
Sims (VSim 0.8)
I have been quite „dumb“…I added „theoretically“ joystick and buttons – but they absolutely refuse to do anything I want them to. Perhaps Graham might look at that.
BattleZone
… still crashes after a view minutes. (The current input settings prevent that – I think – since the game sort of starts „in game“, joystick even does basic movement…)
Asteroids*
Refuses to run. I cannot compile it under Raspbian (cc1 out of memory)
Asteroids deluxe*
I cannot compile it under Raspbian (cc1 out of memory)
Tempest
not supported by VSim 0.8
Lunar lander*
I cannot compile it under Raspbian (cc1 out of memory).
Seems to miss some collision detection with the ground – the lander falls through and than crashes.
Space Duel
The intro screen doesn’t seem right – the „letters“ should show SPACE DUEL – not randomly distributed over the screen.
Black Widow
Looks nice – but well – as said above – the game does not start (no coin? no start?)
Gravitar
Some joystick mappings here actually work – although they might need changing… But with some good will one can play a game. From the SBC code a message „STATIC CODE ACTIVE!“ is displayed as debug output fairly often – I have not examined that further.
*
You can still produce runnable programs, if you use the „xxx_sim.o“ file created for baremetal, rename them to „sim.o“ and put them in the „build.raspbian“ directory. There is a „warning“ message of the linker, but the produced binary still seems to run ok.Using different compiler settings may also work – I haven’t tried that.
——
vecx.direct
I have not yet done the „bin“ file selection for raspbian. Basically it is the exchange of the file accesses. Basically the same as in the „memory.c“ file. But I am not overly confident that vectrex emulation makes sense at all – so I saved my time…
Menu Handling (changed)
– Enter configuration Menu: Button 1+2 simultaniously
– Chose an entry: Button 4
– Exit an entry: Button 3
– Navigate: Joystick
– Return to main menu: all four button at together (vecx.direct – reset button)
VectrexInterface
More documentation is pending. Once we get an emulator going so that it really is „runnable“ – we must investigate in what patterns the drawings are done – than we can supply hints to speed things further up.
At the moment this is still rather „under developed“.
Using the display pipeline – it as of now has 4 draw modes:
- 0 (default)
display the generated vectorlist each round after it was „generated“ - 1 double buffered
this displays each frame twice – without doing any „emulation“ between the two.
This works e.g. for tailgunner, which is originally a 38Hz game.
You can run tailgunner in 76Hz with double buffer on.
Than the display is 76Hz – but the game is at the speed of 38Hz. (Only way to do that is changing the code or via the UART terminal) - 2 Smart buffer
If the game does not produce ANY output in a „round“ – than the last round is redisplayed Battle Zone uses this, as BZ only generated a frame every 3 rounds.
With this active the display is nice and smooth. - 3 no display
This actually switches off the complete display and the game just runs (fullspeed! – without any sync) without displaying.
(Battle zone crashes really fast than!)
Clipping
I took out any clipping done by the emulators (SIM). You can add a „user clipping“ to the display. The user clipping is done BEFORE any other „enhancement“ is done to the vectors. (like scaling/positioning/rotation).
With BZ I use this.
Battle Zone display is a bit „pumping” – this is due to the blinking letters in the upper left corner. I must examine when they appear and compensate the offsets. That is doable – but for that I haveto engage in the „opimization“ path – and as it doesn’t run properly anyway yet – I did not do anything further.
As before you should do all drawings with:
void v_directDraw32(int32_t xStart, int32_t yStart, int32_t xEnd, int32_t yEnd, uint8_t brightness)
During debugging we will use:
void v_directDraw32Hinted(int32_t xStart, int32_t yStart, int32_t xEnd, int32_t yEnd, uint8_t brightness, int forced, char* debugInfo)
You can already switch global hints with the variable „commonHints“ – but I would not advise it.
The Vector String routines also use the pipeline now.
The Raster Strings do not.
During the Configuration menu, I open a „window“ and everything „game“ related in the window is „clipped out“ (inverse clipping).Also during the opened window all input is exclusively for the window, the running game does not recieve any input data.
It would also be possible to „halt“ the game completely – perhaps that is an option.
Most things in baremetal can be controlled over the UART console („H“ for help). On the raspbian side there is (as of now) no console.
In case the pipeline produces problems – everything pipeline related can be switched of by the variable: usePipeline (0=no, 1=yes).
If switched off the interface will react like before… (more or less).
Other
The saving of the properties changed a bid, but this is not final. I have to divide the properties better, which are „global“ and which are game dependend…
Compiling on the Pi Zero is quite slow. Frankly its „easier“ and faster to compile on my computer and swap the sd cards – doing it that way saves 80% time (at least). Might be more manual handling – but the resulting time save makes up for it, I would say.
Files
In the directory „to_baremetal“ are precompiled all things you need to run baremetal.
In the directory „to_raspbian“ are all precompiled things you need to run in raspbian.
Configuration
While running.
- drift is the „Kristof Tuts“ calibration.
Output is a tiny bit slower when different than „0“. Personaly I don’t use it at the moment. The tiny little drift correction on my vectrex – seems not worth it. - size same as before self explanatory
- position same as before self explanatory
- SMS Set Maximum Strength
The higher (max 127) the faster the display. Some „cranky“ vectrex need lesser speeds (my cranky is ok with 100) - STO Set T1-Timer Offset
How much cycles must pass after T1 reaches zero (ramp off), till the BEAM actually has to be switched off probably somewhere around „20“.
To low – Vectors will not be closed, to high, bright dots at the end of vectors. (The lower the faster, the higher the slower) - SSS
Set correction value to scale/strength conversion. This has to do with the calculation of the „scale“ and strength used. Values somewhat between 1-4. This does not influence speed.
As mentioned before – I will probably take a little time off now, in the hopes I can pull myself together and finish Vectorblade.
My hope would be that the „started“ emulations can somehow be made to run well. And I can continue to do optimizations.
If there are any questions – or things that need implementation – please don’t hesitate to ask.
Demo: