I changed the baremetal code now to run with 1000Mhz as in the normal Pi setup.
I encountered difficulties – after switching to 1000Mhz I had disturbences on the vectrex.
After many trials on „my“ side – I sort of grew desperate.
I tried more different things and the one that did the „trick“ was to switch off „USE_EDR“.
I don’t know why – but with USE_EDR switched on running 1000Mhz I get jitters even on bare metal – without USE_EDR everything looks fine again.
I didn’t go further into detail – I was just glad it worked as it is supposed to, and it doesn’t seem to be related to „my“ vectrex timings.
While experimenting I also „inserted“ the new GPIO code V 2.1 into my source tree.
In the future I will probably make it „default“ but for now I have a compile Define -DMHZ1000 for well – 1000MHZ.
Note:
This is not „good“ but for the time being there are two include files called „bcm2835.h“
The GPIO references are in the same directory so include with
#include „bcm2835.h“
The bare metal library I additionally use has the include in the standard include path (see makefiles) so the include used goes like:
#include <bcm2835.h>
I will do something about that in the future.
Tailgunner… and asteroids…
…
Behave differently when I compile them on the raspbian (for Linux) or baremetal on linux.
I can’t think straigth right now…
The „correct“ Raspbian out put of „line 17“…:
COUNT :17 1 - FromX:166 FromY:870 ToX:166 ToY:882 COUNT :18 1 - FromX:166 FromY:882 ToX:150 ToY:882 COUNT :19 1 - FromX:150 FromY:882 ToX:150 ToY:894
On bare metal the output of the same location is:
COUNT :17 1 - FromX:666 FromY:65486 ToX:666 ToY:65498 COUNT :18 1 - FromX:666 FromY:65498 ToX:650 ToY:65498 COUNT :19 1 - FromX:650 FromY:65498 ToX:650 ToY:65510
(output done with:
int count =0;
void CinemaVectorData (CINESWORD FromX, CINESWORD FromY, CINESWORD ToX, CINESWORD ToY, int vgColour)
{
printf("COUNT :%i \n\r",count++);// if (v_debug >0)
printf("1 - FromX:%i FromY:%i ToX:%i ToY:%i \n\r",FromX, FromY, ToX, ToY);
ToX = ToX << 16; ToX = ToX >> 16;
FromX = FromX << 16;
…)
It probably is some kind of internal compiler option … doing something to signed unsigned int length or whatever.
But I have been looking at different kinds of code today and as said – can’t think straight right now.
(Asteroids behaves also a little bit differently….)
🙁
Nah – This is something more nasty.
Somehow the current baremetal setup seems to implement some „std” function differently – or something like that.
I compiled an old version and it works ok, with same compiler settings.
This baremetal stiff drives me crazy, it never just works, to do the simplest things you have to explore and eliminate.
Now (again) things that just used to work don’t – without apparent reason.
I have to sift thru all functions and look whats happening… well … until I scream hurray – you know what I am doing…
🙁
6 hours later.
I got it.
I am glad I hunted this one down – but it was again a pain todo.
Many many small steps.
The first version of the baremetal worked fine – the last ones all – NOT.
I finally – after removing every single „new! function by hand… the very last function remained and that was it!
Setup of the MMU. The „old setup” did enable „unaligned memory access” – the new function doesn’t.
I am VERY surprised that the game runs at all, and that nearly all data accesses were right.
But it turns out if I insert following lines to my boot up:
// enable unaligned memory access
mrc p15, 0, r0, c1, c0, 0 @ read SCTLR
bic r0, r0, #2 @ A (no unaligned access fault)
orr r0, r0, #1 << 22 @ U (v6 unaligned access model)
mcr p15, 0, r0, c1, c0, 0 @ write SCTLR Than Tailgunner and Asteroids both work correctly again.
I will finish a new „version” of my setup and upload it later. For today I am done again – and didn’t do anything new :-).
But I guess stabelizing and getting to know the ARM better is also a thing.