As posted on the proboard forum and at some stages on this blog…
There is a “problem” when using the shiftregister and doing bi-direction raster output using it.
Thomas had the idea that this problem is due to the fact, that VIA was manufactured by a couple of different companies, VIA had bugfixes along the way and was also produced in different “generations”.
See also: emulation deficiencies
The last few days I was trying to enhance emulation of that specific “problem” and I did not come to any result using the shiftreg and its timings.
Over the last couple of month – since I new the day was coming that I wanted to examine closer – I searched ebay and manufacturers and collected quite a few different VIAs (see images below).
What I/We were thinking was happening:
…the result being that even though it is always the VIA 6522 which was put into vectrex, the chip might behave slightly differently. One difference is the delay the actual shifting starts after accessing the shift register.
Experiments with different vectrex (over the world) show that there are at least these “shift delay” versions:
– delay of 0 cycles
– delay of 1 cycles
– delay of 2 cycles
– delay of 3 cycles
While one does not see the difference “often”, there is one particular area where you CAN see that difference.
If you write optimized routines for bi-directional raster graphics (of text output using a raster font).
I just tried putting all of the below VIA into one of my vectrex. The result looks like this:
(using Thomas calibration routine for Robot Arena as a test)
All (all!) eight of the below shown VIA produce exactly the same image!
Either I have really damn luck buying VIAs and get all “ONE”s – or the fault isn’t the SHIFTREG delay of VIA after all.
If anyone has any enlightning thoughts on that – please comment below. Especially I am interested in people who do have different output – and might have had a peek at their VIA. A similar test program can be found on the proboard forum. (DISASM.BIN by Thomas, Thread: vectrex revisions again)
While trying to emulate the above mentioned behaviour I tried different things. As it turns out – at least emulation wise – the exact “correct” behaviour (the calibration routines work for all cases) can be achieved if I delay the “RAMP” signal for the given delay cycles.
The RAMP signal has per se nothing to do with the shiftregister. The shiftregister in these circumstance controls the BLANK signal – the RAMP – doing raster output – is set manually!
This might just be emulation fault… any thoughts on that – someone?