A small update on “things”.
Tempest
I started collecting information about tempest (see also: Tempest), added in game information and callbacks. Added two “sounds” as proof of concept.
Many more things left todo – as implementing the spinner – I just need to find the time (and the mood).
VTerm (Vectrex Terminal)
This thing drives (drove) me crazy. I tackled this for a few days but some things were always awry.
The mentioned “packing” works – but I am trying to make the serial transport more reliable. I added a send/acknowledge routine – but for some reason each back/forth (send<->recieve) takes at least 15ms. I tried this every 128 bytes – depending on the ack/nack, I wanted to resend the chunk.
But 12ms is way, WAY to slow. I need to transfer one “frame” in about 20ms if one ack alone take 12ms -> go figure. I did some digging and it MAY be in relation to the chosen usb/serial chip FTDI – buffering…
I ordered different usb/serial converters – but I still need to try them out. This is so time consuming – for just that one simple task, transfer some bytes – I invested literally days already!
Additional note:
Debugging this is a living hell. Usually I debug with “printf” statements to terminal output.
But hey! Terminal output is serial output, and serial output is directed towards MAME.
Thus I can not “live” debug and see whats going on. I redirected the stdio to file system – and I can only read AFTER I run the program. ARGH!
Also – writing to SD card in baremetal is slow – damn slow, I mean – REALLY slow.
Here Heisenberg strikes again – if I output debugging information I actually disturb the serial communication – because timing problems. ARG!
Vide
In between I got a request for a Vide enhancement – something done in 5 minutes, but I am glad it helped. Mainly this was to make Vide more accessable on devices with small monitors. The desktop now can have scrollbars – so you can access all parts of opened windows – even if the appear out of bounds.
PiTrex – general
I also am still thinking (and sometimes implementing) things to improve the output in general. In the back of my mind I was thinking (and playing) battle zone.
As it is – especially if not set up correctly – lines and figures are sometimes drawn wrong.
I know my general line routines are not the best – and I will at some stage tackle those too – but I was trying to implement a more general – higher layer – thing first.
Cluster
I implemented routines to “cluster” vectors, keep near vectors close to each other (also while actually drawing them) – and also sorting them.
Overlapping
I implemented routines to check whether vectors “overlap” – and these regions are drawn twice (and be able to reduce overdrawing).
Angle optimization
Just for the fun of it – because I wanted to try it out – I also implemented a set of routines that check if two adjacent vectors have very small angle differences – and if a threshold is reached (a very small angle) – skip the middle point.
All these routines are implemented – and I think they are more or less working. But I ran out of time – and I have more checking and finetuning to do before these are actually usable.
So -> also half finished on this end also.
Serial
As mentioned under “VTerm” I had some difficulties with a reliable serial connection to Mame. In my course of actions I tried different things.
This is also something I tried – but again ran out of time and my last actions are again a couple of days ago.
UART. The Pi Zero has two UART interfaces, a so called “miniUART” (UART1) and a “real” UART (PL011 -> UART0).
Up untill recently I only used the miniUART – which has some restrictions – of which I thought were not relevant. I now can chose between both UART with a “define-switch”.
Actually if I had been smarter this would only have taken about an hour – as it was it took me 3 days. Damn.
The thing that completly through me off balance was that UART1 (mini UART) – is speed wise configured regarding the ARM system clock frequence (you have to calculate the settings using the clock speed, in general 250Mhz).
UART0 (PL011) has an OWN dedicated clock, which runs per default at 48Mhz. Somehow – I either overread that in every documentation, or they just failed to mention it.
Thing is I kept calculating the BAUD rate with 250Mhz instead of 48Mhz – thus all output was garbled and drove me crazy!
Funny thing is – UART0 and UART1 use exactly the same Pins/GPIO on the Pi. You don’t have to rewire anything. UART0 and UART1 are two different alternative usage settings for those pins (ALT0 and ALT5).
In one way this makes it easy… on the other hand… you can not have two different serial interfaces at the same time.