Denial

I just sent the Gerber files for the Victor Alpha board to JLCPCB and received DigiKey's surprisingly big box of components—the march to a functional Alpha board is on!

However, some of you may be asking, "Who the heck is Victor?". Victor is a project attempting to implement the VIC 6560/6561 as an FPGA. We're a couple of years down the line from when I started, and I'm now happy that it is good enough to move from an FPGA development board plus an interface board to a single PCB.

I was working with a friend who is a professional PCB layout and board stuffing chap with pick & place and reflow equipment. Unfortunately, he has been unavailable to help for an extended period, so I've done my less-than-perfect layout and will be stuffing components by hand. Many of those components are surface mount, and many are 0402 series resistors and capacitors that are remarkably hard to see, let alone manipulate, so unfortunately, these boards will take forever to make.

While I was waiting for my friend to be available again, I played around with the FPGA firmware, adding questionable features that are fun but not particularly practical, such as graphics primitives and multiply/divide/sine/cosine/sqrt functions (16.16 fixed point arithmetic). These are fun to play with, and you can see videos of some of the results at https://youtube.com/@Vicenary if you are interested - ray tracing, spinning cubes, that sort of stuff.

I'm going to make a minimal number of Alpha boards—probably just 5—and send 3 of those out to people I think will be able to test them in exciting scenarios, particularly unusual VICs (there's a guy I know who has several highly unusual VIC-20s, such as the prototype 16KB VIC-20) and people with exciting software that uses the VIC in distinctive ways, such as weird graphics and demo programs, and someone that has access to some pretty odd monitors that can be hard to keep happy.

I have had to invest in many expensive tools for this final step, so I am committed to productizing this - not that I'll ever make my money back, but because it would be embarrassing to fail after investing so much in it!

More frequent updates and discussions can be found on my Discord server, https://discord.gg/YDxnFgVucf

JonBrawn wrote: ↑Sun Aug 04, 2024 11:59 pm Many of those components are surface mount, and many are 0402 series resistors and capacitors that are remarkably hard to see, let alone manipulate, so unfortunately, these boards will take forever to make.

Good luck, I swear enough trying to place 0805 resistors the right way up.

Exciting progress!
A 100% compatible drop in-replacement VIC would be an absolute dream come true. :')

This will be such a great help to those of us trying to keep the VIC-20's working for others to enjoy.

Joe

Good luck with the Alpha board builds!

Thank you for the update. I think this project is very exciting and such a boon to the VIC-20 community.

This is very cool and much appreciated. Looking forward to developments....and eventually owning one!

That alpha board works, but at two weeks per board to build, there won't ever be more than one—especially given the mistakes I made and the amount of bodge wire on the back of the PCB. Now, I'm laying out the Beta board. This uses a BGA256 version of the FPGA as it is smaller than the Alpha's QFP. I'm also cutting out most non-essential components, like extra config jumpers and the push buttons. I will leave the RGB LED, as you can display a lot of status info with different colour flash sequences. The Beta board will not fit within the outline of just the DIP-40 socket, as I want to make sure that the final Beta design component choices are good before I go crazy with miniaturizing every single component and doing a packed placement, and I'll need to be able to drop a test probe onto many of the signals, and that becomes harder when you move to more layers, and to get the tight packing I shall need for the final board, which will have more layers than the four I'm currently using.

NOTE: If you have ideas of features that it should have, excluding HDMI, which isn't viable for this design, now would be a good time to mention it. I'm trying to work out what to do about S-Video, if anything, but adding S-Video adds quite the handful of components, plus a connector of some sort, plus a configuration jumper, so I'm not keen.

JonBrawn wrote:I'm trying to work out what to do about S-Video, [...]

IMO, Victor should just output Y/C as does the original. That way, if someone wants S-Video, she or he can apply any preferred variant of the S-Video mod in the video circuitry around the video chip.

Otherwise, regarding features in the production release, I'd take the minimalist approach here, especially if it helps to keep down the footprint. Most important is the support of all original features, and these include paddle and lightpen functionality. Thus far, for example, I have seen no confirmation that Victor works fine with MINISKETCH. Could you enlighten us about that?

About the only thing that should be included in that minimalist version here is a hardware jumper to switch between NTSC and PAL. No register based switch. Programs are inevitably going to 'probe' a non-standard register setup even if just by dumb mistake, and then you have <100 % compatibility.

I have to agree with Mike here, beware of feature-creep! Ideally this should just be a drop-in replacement for a defective VIC-chip (PAL or NTSC) and behave exactly the same. Anything else is just asking for trouble with regards to compatibility, especially an "extra-register". See al the trouble the C128 had with it's 2 MHz-register in C64 mode that got inadvertently set by some older games making them crash.

A way down the road may be to use a "magic-sequence" like Ultimem did to enable an extra register. This would highly minimize the risk of accidentally writing to it.

+1 to Mike and Tokra's points
I'm okay with jumper-enabled features (I guess, they aren't really of interest to me), but a 100% compatible mode (no extras) is essential.

Good stuff as usual!

Extra features can be enabled by writing 'V' to the first paddle register and 'C' to the second paddle register. It would be unlikely for anything to write those two specific values to the game paddles, which are read-only and have no side effects if written to.

Powering on, resetting the VIC-20, or hitting the Run-Stop+Restore sequence all write 255 to those locations, which turns off all extra features.

I am currently planning to have just one three-pin jumper, which can be used to select PAL (A+B shorted), NTSC (B+C shorted), NTSC50 (all open) or PAL60 (all shorted), plus the programming connector.

It would be unlikely for anything to write those two specific values to the game paddles

If i learned one thing in the past years dealing with emulation it is: whatever you think is unlikely - some program(s) will do it and misbehave

groepaz wrote: ↑Fri Oct 11, 2024 10:08 am If i learned one thing in the past years dealing with emulation it is: whatever you think is unlikely - some program(s) will do it and misbehave

I have a backup plan; it is as cunning as a fox.

JonBrawn wrote:I have a backup plan; it is as cunning as a fox.

PM sent.