Cinematronics arcade clones repair. Pt.2: "Vectorbeam eliminator"

[@minombredepila1580]

Amazing work Frank !!!!. Impressive 🙂

[@jandjrandr]

Making mistakes is all part of the learning curve when you are working these older systems and seeing that even the original designers made some serious errors makes us all feel a little better. Great job finding the solution and getting that system back on its feet!

[@iz8dwf]

Thanks for the comment! It's indeed a great satisfaction to get these old games back in working condition!

[@GadgetUK164]

Incredible work =D

[@petesapwell]

Hi Frank, that’s great work and you are happy to display your small error, this is great for others learning, we all make mistakes :) Great to hear from you again :) and complements of the season 🎄

[@iz8dwf]

Hi Pete, most of my projects have issues on the first prototype :) The good news is that I'm stubborn enough to fix them. Season's greetings, take care!

[@senilyDeluxe]

Awesome! I once "designed" (more cobbled together with lots of trial&error - I suck at analog engineering, it's not my main goal in life either) a replacement board for Atari Asteroids DACs. These are rare, ancient and expensive, so I checked what modern(ish) component you could still buy that does the job (just as you did). I settled on the AD7533JNZ, which I couldn't get to work in any bipolar mode, so I used another TL082 (or rather half a TL084 as I didn't have 082s on hand) to re-center and amplify the picture. The results are... not excellent. They can probably be improved to be unnoticeable in test mode, but as it is right now, you need to look really hard in game mode to see any artifacts, good enough for me. Pretty much unnoticeable in game mode.

[@iz8dwf]

Good job! I luckily have quite a few spares for those DACs, they don't seem too unreliable also.

[@dmuntz]

Wow, that looks amazing! Not too surprisingly, it looks better than the original Cinematronics D2A board. I came across this video while looking for a way to use a vectrex monitor with the cinematronics CCPU board. I found Jürgen Müller's page where he build a board to connect an Asteroids PCB to a Vectrex. However, knowing that the original cinematronics D2A board is a bit of a mess, I then went looking for a better D2A solution and found your project, which looks perfect. Would you be willing to sell these, or alternatively, provide files I could use to order PCBs from JLCPCB or PCBWay? Another project I've had on my mind (one that sets some people off...) is taking the digital output from the CCPU and sending it to a PI so the vector drawing can be done on whatever video device is available to the PI. This gets a little weird due to the CCPU not sending an actual coordinate for the end point of a vector, but instead sending a point that _might_ be a linearly-extended end point to deal with drawing "straight" vectors on a curve dictated by capacitor discharge (as described in the cinematronics vector theory section of their manuals). I've worked out all the math needed to deal with this (involves timing the BRIGHT/INTENSITY signals--don't recall which one) and doing some math to calculate the actual end point. From bus traces of the video connector on the CCPU, I can recreate the displayed images, but I still need to figure out how to get the parallel bus data into the PI for processing. That's a todo for later :-).

[@iz8dwf]

As I said as reply on your previous comment, I haven't updated the PCB design to use the new offset circuitry. I can upload the design to a github repository later and send you the updated schematics via email too. I'm not sure the original vectrex deflection circuit can cope with arcade vector drawing speed. Of course the Jurgen Muller deflection board instead can do that. Using the digital output and have another CPU re-calculate the vectors is a bigger problem than doing an analog adapter, at least for my analog mind LOL.

[@dmuntz]

@@iz8dwf I'm more of a software person than a hardware person, so I've solved most of the software pieces. Just need to get those parallel bits serialized and stuffed into a USB interface so I can run the calculation and drawing software on them. :-) One thing I've been considering is I might be able to simplify it greatly by changing the E8 PROM so the CCPU doesn't modify the vector endpoints, so the data from the CCPU would be the exact start and end coordinates for all vectors. I built a little adapter to use a modern flash chip in place of the 32-byte PROM, but haven't gotten around to doing this yet. At one point, I had walked through the state machine used by the CCPU to determine the multiplier for the endpoint, and it looked like this would be possible, but at the time I wanted to avoid any CCPU modifications.

[@iz8dwf]

@@dmuntz LOL good, I'm more a hardware person instead. I can handle assembler and C, but higher level languages start to lose sense to me. I wouldn't change the E8 prom anyway. RC charging is just an exponential function and you have all the parameters of it (C and R values are known from the schematics) so you could simply make a lookup table in software for this exact function. Look at how MAME implemented it, should be straightforward to port to your setup. You should simply unblank the trace according to /INTENSIFY (and make it brighter if /BRIGHT goes low). I'll upload the project on my github repository anyway, even if I won't re-route the PCB for now.

[@dmuntz]

@@iz8dwf MAME implemented it by having the NRM/NV (normalize vector) CCPU op not modify the endpoint, so you get actual start and end points for the vectors which are passed to the drawing routine. I was thinking E8 could be changed to accomplish the same thing, but this wouldn't be my first (or second) choice :-). I can calculate the actual end point as a function of start point, munged end point, and time that the vector is being drawn. This makes things a bit more complicated circuit-wise, because now there's a timer in the circuit, and the value of that timer becomes more bits I have to capture for each vector. However, this method does give very good results based on the images I've drawn from the logic analyzer (using a "cheap" Hantek 32-bit analyzer, with PulseView/sigrok). The code for all of this is in C, along with a very basic assembler for the CCPU assembly language, and a disassembler based on Zonn's disassembler. I wrote a bunch of test code to figure this stuff out and ran the assembled code in MAME and on the CCPU board.

[@iz8dwf]

@@dmuntz Wow, great job! I've had to learn quite a few opcodes of the CCPU too in order to repair the most stubborn boards. I didn't think MAME cheated that much... How about reversing the table inside the E8 PROM and "undo" the start/end modification in software? I hope it doesn't sound silly, but I never had to actually look too closely at that part of the CCPU (luckily I'd say).

[@danielepatane3841]

Ciao Francesco ;-)

[@douro20]

Microhard is still very much in business, producing vending machines and automated payment systems.

[@iz8dwf]

Yes, indeed I've found a company with the same name. I think the 1970's and the 1980's were a very particular period for electronics, I'm sure the engineers of those old days are retired by now.