Raster and compatibility

04.02.2020
I was trying to output a raster image in the „normal” vectrex interface. As it is – it seems the pi can not write to the VIA with „2 cycles” length for more than a few cycles.
Per round I don’t think I lose more than 20 nano seconds for „calculations” – but somehow these seem to accumulate – rather than being compensated.

You see the start (left) is fairly stable – but at the end there is quite a grizzle… that grizzle are the accumulated „2 cycle” – misses.
The technique I used differs a little from the normal raster display (which probably still works). With this new technique it would have been possible to display images correctly (8 pixel with 16 cycles), rather than wrongly (8 pixels with 18 cycles, the last pixel doubled).
That would have been a PiTrex specialty – but … we are not fast enough… :-(.

There a a couple of more tests that I can do to get better results – but I did not take the time yet.

06.02.2020

haven’t done any exciting new stuff.
I have written a new „C” file called „osWrapper”, which includes baremetal functions that have the same signature as on raspbian, for now these are mostly filesystem stuff:

  • fopen()
  • fread()
  • fclose()
  • fseek()
  • ftell()
  • chdir()
  • getcwd()
  • opendir() // only one directory open at a time
  • readdir() // only one dirent open at a timeclosedir()

also prints:

  • fputs()
  • fputc()
  • fprintf()

They all should work as on raspbian. This means e.g.:

FILE *writeSometing =  fopen(„somename","w");
fprintf(stdout, „a file  was  created!");
fprintf(stderr, „... and there was no   error!");
fprintf(writeSometing, „and you can actually output data");   

Works as intended.
What I still intend to do is memory management…

  • malloc() // …

and its partners:

  • free()

Therefor I changed the cinematronics emulator to again use fopen (etc) instead of open – so that all sources are equal.
In order for that to work it is advisable to have the includes

#include <vectrex/vectrexInterface.h>
#include <vectrex/osWrapper.h>

(both in raspbian and baremetal)
in general as your last „standard” includes in the list of includes in your „*.c” files.
There are not many „#ifdef FREESTANDING” left in the code…


I made a „general” Makefile for raspbians in the main directory too – so there is no need to make them all one by one.


I changed the vector font to be also influenced by sizes and offsets. But this does not look to well for the calibration menu. I have to think about that further…


I left all settings as they were.I did a recompile of everything under raspbian and baremetal – there are no errors or warnings (for me).
Emulation of cinematronics is quite slow, since Graham left creation (and writing into) of a debug output file switched on.This now also is produced running under baremetal :-).
For show I added 5 additional cinematronics emulations to baremetal too…


I started implementing more debugging features… but the above „came in my way”. The only thing I did indeed was add „online” debugging for the „sims”, but I want to extend that further, since debugging will be really necessary, once we want 

  • a) more games to be playable well
  • b) enhance the current games with hints

Hello world…
For the Raster fonts brightness was missing. The other functions „carry” the birghtness with them – raster not.


A far away goal is also to make a SVGALIB or X11 version of vectrexInterface…So that one can actually develop on a system without a vectrex. Sure it will not look 100% perfect – but for the „groundwork” it would be nice.


I will also change the “loader” soon to have submenus. Like Atari and Cinematronics etc…
Also at some stage dipswitches must be set for the machines…



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.