Raster (2) and Tempest

05.02.2020

I was annoyed, that Lunar Lander was not working correctly (it crashed after a couple of seconds).

Long story short – it is working now.
As it turned out there were two problems within VecSim:

Some m6502 instructions did not have the correct cycle count (namely all instructions with an * or **). Meaning additional cycles for crossing page boundaries were not respected.
The DVG internal timings could go totally out of whack. That resulted in a “halt” at some point.

This has been taken care of:

07.02.2020

Had time for a „BurstMode” test…(AKA: void vectrexwrite_short(unsigned int address, unsigned char data))
The functions I wrote some weeks ago….

I don’t think it will make a big difference.

But anyways – I am glad it works, it has been more an experiment…
But now we have proof, that Kevins claim is true – PiTrex IS capable of „pumping” stuff into the vectrex every two cycles.
We know we CAN do proper raster graphics if at some stage we want to.
The little image of mine is 80×72 pixels – so ONLY setting of the pixels takes 11520 Vectrex cycles.
No positioning, nulling… etc. The image displayed on the Vectrex all in all takes in best cases about 22000 cycles.
The „miss” ratio of “2 cycles” I would have estimated to be around 1%-2% … so there is no „general” speed gain.
…
But we could do cool stuff with the piTrex memory in the background… little raster films with 80×80 resolution.
(and really 80×80, not 80×80 + VIA is faulty – every 8bit one additional duplicate pixel)

13.02.2020

Damn!

That was a debug session!
For 3 days – I tried to get Tempest to work.

In regards to the underlying VecSim:

IRQ handling within the emulator was not correctly implemented. Most games use NMI – but Tempest uses IRQ. The cycle count was not correct. So interrupts happened more or less “indefenetly” one after another.
AVG did not support “Tempest” style programming. Tempest – in opposition to other AVG programs does not “quit” the AVG loop. Other programs quit AVG and then AVG is initialized with further “go” commands. Tempest gets one “go” and loops forever in an AVG loop. The CPU updates the vector RAM “under the nose” of the AVG processing.

This also means:

i) a new mechanic to invoke AVG via “time slices” instead of scanning for a “go” command.
ii) a new mechanic for “open page”, since before the “go” was our “open page”

After all that (1-2 days) Tempest started to work.
Although display was somewhat “off”.

The “tubes” were missing!
The complete gameplay was there – but the tubes were not displayed.

What the F*CK!

This cost me the better part of the last two days to figure out.

At first I thought… “hm missing vectors” – must be the AVG implementation.
Since there are not too many sources for successfull Tempest emulation (only MAME comes to mind…).

I looked deeper into MAME.
The AVG implementation is quite different from VecSim, although I am sure VecSim was first.
VecSim’s approach is an “instruction” approach, the AVG has only a couple of instructions, like:

“vctr”,
“halt”,
“svec”,
“stat”,
“cntr”,
“jsrl”,
“rtsl”,
“jmpl”,
“scal”

… in typical “emulation” manor, these are handles by a switch case… and emulated as they come.

MAME takes another approach – namely: to emulate the underlying hardware and its state machine.
(see: http://www.vectorlist.org/Documents/jmargolin/vgens.pdf)

So a “direct” comparisson of the two approaches is difficult.

Since MAME works and I have no other way of testing… I took the AVG implementation from MAME and ported it to VecSim. This was also not as easy as anticipated… But I got it to work…

And … drum roll:
it looked exactly the same!

Gee – it probably is not the AVG implementation.

Growing desperate I started implementing stuff VecSim did not yet have, as e.g. EAROM.
Which is only used for high score saving… but who knows for sure?

Meanwhile I fiddled with the MAME sources and VecSim… to output their doings. (every assembler instruction, all registers, all AVG commands etc).

But due to several differences – a simple “diff” yielded too many results.
(We have no PSG implementation, no EAROM (well to start with), different switch settings, different random implementation within the PSG…).

What freaked me out most, is that MAME perhaps (if I read the signs right) actually has the IRQ timing implemented wrong (but that might just be me not understanding everything).

The AVG is in “reality” running in parallel to the M6502. Within MAME AVG is called with timeslices of 10000 (which I think results in 10000/8 M6502 cycles at 1.5Mhz).
The timeslices spent in the AVG actually REDUCE the IRQ timer by the “slice” value (or so it seems to me).

Anyway – that was one of my diff-difficulties – the difference in “cycles”.

Needless to say – it wasn’t the EAROM, which I never really suspected – but at some stage me might need it anyway, so…

Next suspicious object was the Mathbox. But that was dealed with very fast. The Mathbox in MAME is a verbatim copy of VecSims mathbox. So that was very easily dismissed.

Actually I ran out of options – at what to look at!

I debugged the AVG again – and sorted out the vectors that mame output, and identified the “tube” vectors.

VecSim AVG never even “tries” to output these!
Now I started debugging the AVG RAM, which is filled by the CPU… and it turned out that the VectorRam was not “correctly” filled.

Debugging the Tempest ROM
(Rom Listing – not too well documented though… :
https://github.com/smdjeff/tempest)
at exactly undocumented points… turned out… following to lines:

(getting close!!)

VecSim
c11d: e563   sbc 63         PC=c11d, A=00, X=00, Y=02, SP=01f5, nvdiZC, Cyc: 1005422
c11f: 8563   sta 63         PC=c11f, A=f1, X=00, Y=02, SP=01f5, Nvdizc, Cyc: 1005425

MAME
c11d: e563   sbc 63         PC=c11d, A=00, X=00, Y=02, SP=01f5, nvdiZC, Cyc: 1009582
c11f: 8563   sta 63         PC=c11f, A=f1, X=00, Y=02, SP=01f5, NVdizc, Cyc: 1009585

Very enhanced pattern recognition techniques were used (my eyes and my brain).

You see it – don’t you?

The OVERFLOW flag is not set correctly!

After seeing that I started google.
Emulating the flags of “SBC” within 6502 seems to be a science of its own.

Anyways – as it turned out, the implementation used in VecSim – did not set the overflow flag correctly!

The first time that actually changes something within the execution within Tempest is exactly at that above point, over a million cycles within the game.
If the Overflow is not set at this point – the tubes are not displayed.

WHAM!