Some good news – quite a few “bad” news.
Let’s start with the good news – so I can tear you down later on.
Good Thing – Overlays!
The overlays are finished! I have them here and they are beautiful!
IMHO – the most beautiful overlays I have seen for the Vectrex yet (and I think I have seen them all!). Many thanks go again to Jacek Selanski (for his artwork) and VectrexMad! (for having them printed).
Here the “full” thing:
And some close in “partials”:
And the corner with the box:
Crystal-clear!
Ok.
Bad thing 1 CRASH!
Stopping the sweet talk – down to business.
I don’t know who followed the beta-tester forum. But some serious trouble has been encountered in Vectorblade.
It crashes! Not often – and the “average” player might not even notice it. But amongst the beta testers some “hardcore” playing has been going on – and Vectorblade can crash sometimes. It might take between 20h-100h of gameplay. But it CAN happen. I have spent already many, many hours (a 3 digit hour number) hunting the “bug”.
I build numerous versions of Vectorblade, which “play” by itself. Found little things… but never THE cause.
It seems no emulator can reproduce the bug (I let Vide play literally for hundreds of hours). So by now I tend towards a “non programmer” bug.
Simple buggy code IMHO would have to be found by now – either from staring dozens of hours at the code, or by getting debug messages from my tryouts.
I added debug code to Vectorblade – and even quite “exotic” means to track what is happening.
e.g.: NMI
What you see in the image is a Vectorblade setup, which has a NMI button attached – and upon a button press I can jump into a debugging display routine. Dumping registers etc.
But even that has so far not been able to clarify anything. The only crash that occured while that thing being hooked to the Vectres didn’t react on NMI.
Which is strange to begin with. The only thing that “overwrites” an NMI is RESET and HALT.
There seem to be some undocumented instructions (HCF – Hold & Catch Fire) – which might be the reason, or some other glitches, which destroy the NMI interrupt vector.
Anyway, this was just a straw for me to cling to. If I had read that the NMI occurred at location XXXX and the register dump showed YY values – I dunno if I had been the wiser – since I would only have seeen where the PC was, AFTER the crash, not what happened during the crash.
All those tests and reprogramming are quite tedious – since I have literally NO single byte in RAM left and in some banks only a couple of bytes.
So each time I added special additional code – I had to change VB in order for it to fit… Which made it:
a) tedious
b) it wasn’t the same programm anymore that I wanted to test
My latest straw to cling to is best described in an old blog entry of mine:
1st of June – “Faulty” VIA vs “INC”
See… during my experiments I tested VB on one of my “other” vectrex – and it seems, that this Vectrex at some stage became “special” meaning, the VIA is now as “faulty” as described in the above blog entry. So Vectorblade crashed right from the start.
Somehow this crash reminded me of the current situation… and I thought…
“Hmmm… what if the other crash situations are somehow related? What if there are
– good VIA
– bad VIA
– VIA which are bad one in a million?”
I don’t know if that is “a thing” – but like I said – I am looking for straws to cling to.
Sooo at least I have a very easy test scenario – I have a completely faulty Vectrex. I reprogrammed all of Vectorblade (took only about 15hours) to be faulty insensitive (Vectorblade lost again in average a couple of hundred cycles speedwise – ARRRGHH – I am hating it).
I have to test the new version (meaning I have to play 100-200 hours… and see if a crash occurs) – if it doesn’t I won’t be much happier – but a tiny little bit more content.
If the crash occurs – I am back to square one.
Bad thing 2 Overlay!
The overlay is fantastic. But it also makes me scream in frustration. See – the opaque part of overlay seems to be a little “big” around the edges. Some of the game area can not be seen anymore.
Usually I look a little but “top down” on my Vectrex when I play:
You see what I mean?
While I could relocate the “EXTRA” (btw in the above screen it read XTRA” – hard to see – isn’t it?) – and also the score…
The play area doesn’t really fit well (imagine the UFO – which appears above the upmost enemy in the above setting).
You might say… “So what – just move everything down a bit, do a simple calibration with an Y-Offset”.
SMARTASS!
It is not that I can’t think of that on my own. Thing is – the only possible way to that kind of calibration is by adding an additional MOVE to every vectorlist that is displayed.
Yes – I can do that – but my first guess is, that would “cost” me another 1000 cycles at LEAST per vectrex round.
And I am really getting (I actually already am, with everything that has been necesssary of late) to a state, where I cannot afford to lose more cycles.
Vectorblade will soon start “to wobble” and be “flickery”.
I do not want that!
I don’t know yet, what I will do about this thing. One problem after another, first the crash, than the overlay.
But let me just say… Vectorblade stopped being fun quite some time ago. Nowadays it is just something, that I wish I had finished already.
Cheers
Malban
PS
If you look straight at it (or even a little “up”) it is not TOO bad :-(.
Those overlays do look beautiful, both quality and design.
I don’t think this is the only overlay that obscures play area if you look down on it, it’s why I always try to position a stool chair so I am sat face on… that is needed also for when the overlay has box outlines for things like gauges/air/score/other stuff…. your straight on photo shows it is workable.
The score is unobscured; could just the EXTRA be relocated? Slightly left… smaller font…. down the bottom if room under the player ship?
Yep – sure I can just relocate the EXTRA…
Well… not “just” … of course… but if anyone can do it… 🙂
Glad the overlays arrived safely.
The issues you describe are what put me off doing a fancy overlay for the non-screen calibratable games that people often ask for. For YASI, I took 8 different Vectrex consoles and got varying vertical height positions of graphics. I made the horizontal coloured bars with heights as large as possible to accommodate the different Vectrex graphic positionings. Even so, a couple of persons still reported to me that the top UFO was obscured by the overlay graphics. Chris P’s suggestion of moving the “EXTRA” text is fine for the particular Vectrex you showed, but there are many Vectrex consoles out there each with differing screen offsets, unfortunately. Still, you are following in the footsteps of the original GCE/MB game programmers who reportedly really didn’t like overlays and the fact that they only saw them in the later stage of their game development – making them to have to reposition their graphics. Failing a calibratable vertical positioning, maybe simply solved by positioning the score and “EXTRA” text at the bottom and taking into account an average tolerance for screen positioning?
great overlays quality! i agree with Chris’s idea, if u can just do something with the EXTRA (eg. move it), honestly i think the rest is ok, not a problem at all
ps. personally i dont like to look down at vectrex screen like your ‘top down’ picture, i either look face on, or have the vectrex a little higher even…
Hello,
I don’t know if you read my previous comment, but “Bad VIA” are definitively physically damaged one.
As most devices from this era, there is no esd protections in the vectrex.
Before being destroyed these chip surely start to latch-up.
Is someone be able to reproduce the bug with a new W65C22N fitted in place of the original VIA ?
Hi,
yes I read you previous comment- sure did :-).
Thx for the information.
Like I said – I tend to agree with your assessment, that this VIA is damaged. One interesting question is – how many broken VIAs are out there? If this little damage does not show until played with bankswitching – nobody might notice.
And if I have a way “around” it – and at the moment I do have one (programmatically) I’ll probably leave it in. Not many people will like changing their VIA just because of Vectorblade.
Other interesting thing that perhaps you as “knowledgeable” might answer… Is there such a thing that it can be “half” damaged – that sometimes the latch works and sometimes not?
The I/O dance on pb6 without ESD protection or externally forced state expose the chip to damages.
In I mode, the chip input is very vulnerable as the O circuitry which could absorb transients to GND or to VCC is disconnected.
The latch-up phenomena could be outright and definitive: broken VIA or in progress: half damaged VIA. (search for ESD & latchup defects)
On the later case it would be interesting to see if a simple high value pulldown on pb6 near the VIA chip (to minimize path inductance and capacitance) fix things (and as well as we are put there an ESDALC5-1BT2Y too).
All is pure guessing as I don’t know any publications about the transistor level I/O structure of this chip.
The good thing is that W65C22N is still in production and widely available (Mouser) and should be a drop in replacement with less know bugs.
If it fix the problem, it would be a better route than by default software workaround as it would be an “aging” defect and not a from day 1 defect. But yes, as PB6 line is badly protected and only used by bankswitching, workaround should be available/desirable as my theory is pure speculation and noting is proven for now.
Some things like ESDALC5-1BT2Y (or their array variants) should be placed everywhere to preserve these old things: controller ports, cartridge port.
Thx for your insights!
PS
I ordered a couple of W65C22N – to test out, if they work as replacements out of the box…
Reading the WDC version datasheet is very interesting :http://www.westerndesigncenter.com/wdc/documentation/w65c22.pdf
It contain the general electronic structure of the port A and port B of the present and historic versions of the 6522.
And the logic description of the port B (all version) explicitly state that the observed Peers faulty VIA in output mode behavior is totally impossible.
On port B, in output mode, pin read return the programed state and not the observed state as on port A.
Is it a baseline logic property of the 6522 family which must be followed by all 6522 variants/clones/evolutions of the 6522.
So Peers VIA (a Synertek sourced one, so an original MOS) is definitively faulty.
Confirmed in this old Synertek datasheet: http://archive.6502.org/datasheets/synertek_sy6522_via_1978_jan.pdf
All know bugs of the original MOS version are corrected on the WDC version (external CB1 clocking and non 6502 bus arbitration) but are not relevant for the Vectrex.
The WDC version is a fast (14Mhz) CMOS version of the chip (less consumption too) and is minimally ESD protected witch is not the case of the MOS one (NMOS process).
Your work on this game is amazing, keep you motivation up and it will hopefully pay out at the end!!!
The last 20% takes 80% of the time! The overlays look great. Personally, if I were producing an overlay for a game, I’d first calibrate my monitor. Then I’d assume that everyone’s Vectrex monitor was calibrated. Lastly, I’d base the overlay on the dimensions of the monitor calibration card. You can’t know how everyone’s monitor will be performing, so I’d just assume best case, else you’d have to make too many compromises. Regarding your particular circumstance, if you can fix it such that looking straight on at the monitor gives unobstructed text, I’d be happy with that. I’m sure, though, that in your head, you already know what your acceptable solution will be :-). Good luck!