24.02.2020
I created a GitHub repository under:
https://github.com/malbanGit/pitrex
Checked in is the PiTrex13.zip, and the last changes mentioned by Graham.
A very short intro to Git:
https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners
In order for us to collaborate you need to create a github account and tell me your account names, than I can implement you as “collaborators” and you can push/pull to your likings.
25.02.2020
Optimization idea?
For now baremetal only.
I have been thinking about a more “multitasking” approach to our vectrex library.
There is still “much” time idling away while drawing vectors.
Mainly when drawing “large” vectors or moving “wide” distances… than much time is being wasted with just waiting for the beam to arrive at its destination.
If possible I would like to use that time.
Therefore I have been thinking about interrupts again, an easy method to allow “parallel” execution.
Pi – timer interrupts that is – resolution about 1 microsecond.
We know that vectrex VIA accesses must happen uninterrupted.
What if ALL DRAWING is done within the interrupt “handling” – and thus cannot be interrupted?
When the drawing routine discovers that a “long” wait is immanent – than a new interrupt timer is set – and and rti issued.
Large draws/moves can easily last for about 50-100 microseconds – many calculations (emulations) can be done in that time!
Since the drawing already is double buffered – the uninterrupted “game loop” will always alter the next (vector-)buffer.
While the interrupt loop keeps drawing the last completed buffer.
Sync-point would be the waitRecal – as always.
Sound and Vectrex IO
It must be assured though, that all Vectrex IO and Sound IO (basically all VIA accesses) must not be done while interrupts are enabled.
But that should be no problem if one:
- a) places the IO routines (joystick) directly after the WaitRecal
- b) use doubleBuffering with sound – and also place the sound update routines directly after the WaitRecal
Thoughts?
26.02.2020
Cinematronix speed up.
A „dumb” one :-)…
The „main” function now looks like: (ends with)
...
cineInit (ProgData, OptKeyMap); // setup segment pointer, reset breakpoints
cineReset (); // called after ini file has been read.
cineExec (); // either run one instruction or a lot ending in a vsync
exit(0); // probably never reached.
}
...
In cineops.c:
...
opWAI_BB_A:
/* wait for a tick on the watchdog */
bNewFrame = 1;
parity ^= 1;
if (parity) startFrame();
RCregister_PC++;
goto cineExit;
opWAI_B_BB:
bNewFrame = 1;
parity ^= 1;
if (parity) startFrame();
RCregister_PC++;
goto cineExit;
...
… and cineops „looping” in itself…
Before … after EVERY instruction it was tested whether a frame was finished… and cineops (different object file) was called as a subroutine every round.
The result is… where cinemu before took 45-55% of the overall time it now takes between 15-20%…
27.02.2020
Some more Git:
Ok….
I gather you have git installed. If not – do an “apt-get install git-core” or something similar.
In general:
This is the first time I actually use git – so I am no pro either 🙂
Git seems to be used in two stages:
- building a revision control system on your own computer (you do not have to use github at all!)
With git you can build an own repository add/checkin/checkout build branches etc on your computer without anything remote happening. - Making your own repository “public” by “releasing” it to github.
If you are working with a team on a project, than each member has its own repository on their computers. They can make changes to their own repository. (also build branches etc…)
If/when you want to make the changes “public” you PUSH your own repository to github, either with a new branch or to the “master”. (or do a pull request – but we will not do that (yet))
First step
In our case the first step is to have the current public repository on github
your “own” repository on your computer.
In a “clean” environment, you just do:
> git clone https://github.com/malbanGit/pitrex.git
This will setup in your current directory a “clone” of the repository master from github.
The new directoy “pitrex” will appear – with all pitrex stuff inside.
(I made a single subdirectory “software” in anticipation, that perhaps someday a “hardware” directory, or a “documentation” might be a thing to do…)
> cd pitrex/pitrex/software
This is our “usual” directory, from here you can execute e.g.:
> make -f Makefile.raspbian
etc.
Than you can work “normally” with the project.
STATUS
If you want to know your current changes, you can type
> git status
This lists all deleted/changed/added files within the current project.
ADD
If you created new files withing the repository you must add them manually with (you can also add directories/structures)
> git add newfile
COMMIT
To commit (all) your changes locally – type:
(you can also commit files/directories etc)
> git commit -a -m "comment of what changed"
(First time you commit, you might have to tell git your credentials… don’t worry, git will tell you how. It is very helpfull!)
PUSH
To make your changes visible to other users – you also have to update our
“public” github repository. Above changes were all made locally.
To do that you use the push command – which updates the github repository with your changes.
You must have a github user with the rights to update our repository.
(Make a user – and tell me – I’ll give you the rights)
> git push origin master
(git will ask for your user name/passwd)
Your changes will be committed!
CONFLICT / PULL
If someone else “pushed” already some changes to github (which concern the same files) you might encounter a conflict message and the push will not be executed.
In this case you must “update” your local respository with the changes first:
> git pull
Will update your local repository with the current version held on github.
If possible git will merge changes. If the automatic merge fails, you have to
solve the conflicts manually. (git will tell you which files, you can also do a “git status”)
The files with the merge conflict have the conflicts “marked” with:
<<<<<<< HEAD ... some lines ======== ... some lines >>>>>>> e5f71728add78ac94cff0665d234474ab9a13e19
Decide what to use and save the file.
UNDO
UNDO all changes (locally from last commit)
> git reset --hard
28.02.2020
int versus long (long long)
Doing the tailgunner static binary translation wielded different results with a raspbian compile / and a baremetal (cross) compile.
…
I am pretty sure, that the error with translate has to do with integer sizes.
If I print out the sizes:
(Ubuntu)
char size = 1
short size = 2
int size = 4
long size = 8
long long size = 8
You see, that long is the same size as long long.
And I guess the “long” (s) in the program are ment to be 32 bit, not 64 bit.
If you don’t mind – test the sizes on the pi with:
printf ("char size = %i\n", sizeof(char));
printf ("short size = %i\n", sizeof(short));
printf ("int size = %i\n", sizeof(int));
printf ("long size = %i\n", sizeof(long int));
printf ("long long size = %i\n", sizeof(long long int));
Anyways… if I replace all “long” definitions within the code with “int”…
#ifdef UBUNTU #define U_LONG unsigned int #define S_LONG signed int #else #define U_LONG unsigned long #define S_LONG signed long #endif
The programs runs ok – no errors – and the “tailgunr-ops.c” is generated like it should.
–
Nonetheless – its a strange error behaviour…