27.12.2019
Last act before the holiday.
Update to vecx.direct. The original games are nearly perfect now – my own games not yet. (perhaps the emulation can be a tiny slightly bit faster though)
During the vecx execution I already implemented a „reset detection“ – so while you are in the emulator you can return to the main menu via „reset“ (on your vectrex). (I plan to implement that to the other „things“ as well … but it is no so easy as it may sound).
Also after the „Vecx direct“ select you jump to a submenu, where you can chose what rom to play. Listed are all roms that are on your piTrex in the directory „vectrex“.
“Up/down” chose the selection, „button” – run the selection,
„left/right” load the next four titles from the directory.
The archive contains now a directory „to_baremetal“ – you can copy the contents directly to your baremetal „game“ pi….
11.01.2020
Graham opened up a whole new world of „timing” measurement for me, by telling me, that there is a way to access a CPU cycle counter of the ARM. With this it is possible to measure exactly up to one processor cycle which is 1 nano second!
Ok… due to Heisenberg… we can never measure that exact… put in the range of +- 10 nano seconds is GREAT.
Anyway, due to experiments done today, I think the emulator is „good” enough, its the VIA access the pitrex does, which might be causing the trouble…
Reasoning:
I am measuring within the VECX emulator how long (write) access to the VIA need:
... // reset the cycle counter PMNC(CYCLE_COUNTER_ENABLE|CYCLE_COUNTER_RESET|COUNTER_ZERO); // set data to VIA SET(viaRegister, data);
// get the cycles, that passed unsigned int waited = get_cyclecount();
// print them printf("VIA ACCESS: %i \r\n", waited);...
The PMNC … is a macro to actually a single assembler line.
The get_cycle_count() is inlined and are actually 2 assembler instruction… nothing which should really influence the result in a great deal.
Following is the result of one VECTREX „round”:
low: about 1200high: about 1900
Reminder: 1 vectrex cycle = 666 nano seconds
So it seems:
a) to write a value to via takes about 2 „vectrex” cycles
b) we can lose up to 1 cycle, when we „start” the via access at exactly the wrong time (when one cycle so to say just finished, and we have to wait for the next)
->
– While printing raster data you CAN see a difference, if something is 1 vectrex cycle of.- There are quite a couple of VIA accesses
– the „faults” accumulate with each „line” of the String.
See (animated GIF):
