With much help from @StephenHorn on Discord, and many thanks to @Frank van den Hoef for opening up VERA to all of us, I've created VERAduino: Upduino-based VERA being driven by an Arduino Uno!
VERAduino
VERAduino
On 3/26/2022 at 2:06 AM, Cyber said:
Great job indeed. This makes VERA look like ready to go multi purpose video device.
Which therefore looks like X16 is using VERA as kind of "off the shelf" component. )
It looks like he's hit a brick wall ?
Joke aside, it does show that with determination that the VERA design can be made to work outside the X16 platform by those with talent. Congrats!
VERAduino
On 3/26/2022 at 5:49 AM, Edmond D said:
It looks like he's hit a brick wall ?
Joke aside, it does show that with determination that the VERA design can be made to work outside the X16 platform by those with talent. Congrats!
From what I see, VERA was designed to work outside of the X16 with reasonable ease. I'm working on instructions that people comfortable with Arduino or RaspberryPi, a soldering iron, cutting a trace on a PCB, and spending $50 in parts can follow to have working VERA video for their project also.
Audio output on this solderless breadboard build could be a possibility if the Verilog for VERA's PCM audio is replaced with the X8's PWM audio. In my photo, I have the correct PCM DAC soldered onto a SMD->DIP adapter board just above the ferrite bead on the VGA cable, right side of the image. I plan to get normal VERA audio working, but far fewer people would be willing to go through that.
The SD card functionality might also be a possibility but needs some investigation. I have a breakout board in my build, but it is not connected yet. It requires a 3.3V quad-NAND gate that will respond to the 1.7V CDONE signal from the FPGA. In my limited testing so far, 1.7v wasn't seen as logic 1 so this hasn't worked. I might be able to coerce it to work with a couple of transistors.
VERAduino
On 3/26/2022 at 3:41 PM, Wavicle said:
I'm working on instructions that people comfortable
Thanks for documenting your work for others - I believe it will be a very useful set of instructions for some. Having the audio example and SD implementation would certainly aid others as well.
VERAduino
On 3/25/2022 at 9:46 PM, x16tial said:
Reported to the authorities. There's no way a law-abiding person could have acquired all those electronic components!
?
Great job!
Might just be a hoarder. I remember in the good old days, like 2019, when pretty much anybody with enough on their online payment balance could have all of that and more without breaking a single law.
VERAduino
I may have been a bit too optimistic in my claims of ease when working with VERA. VERA's first target is 6502 and I've spent all weekend trying to get my breadboard 6502 computer to work with it. I was ultimately successful but it was quite a mess getting here. Most of the time was spent staring at another unsuccessful run wondering how I might investigate further since the symptoms were always "VERA returned $00 when reading the register back." After lots of head-hitting-against-the-wall and some clever debug hacks inserted into the VERA design, I finally found the root cause. After a couple hours of failed workarounds, I finally hit on one that worked:
100pF capacitors added to the 3.3V level-shifted side of the A4-A0 signals to slow them down a few nanoseconds and give VERA time to sample their intended value. I feel dirty after doing that. I'm not sure how many showers that hack calls for. Regardless, communication appears to have become reliable after that, however the oscilloscope can barely see a difference between the two:
(No capacitor on the left, 100pF cap on the right; 10ns/5V per division; cyan line is the WE# signal, magenta line is A1)
The issue was the generation of CS#/WE# signals. One of them has to de-assert for VERA to sample the address and data busses. The normal way to do this is to combine one with the clock; e.g. WE# = ~(PHI2 & ~RWB) will drive the WE# signal low (asserted state) on the high phase of PHI2 during write cycles. When PHI2 goes low, the WE# signal will de-assert and we have 10ns to sample the address and data bus. That 10ns is a much harder deadline than I had thought. I couldn't get writes to VERA registers to go to the correct register because the propagation delay of a single gate plus the slew rate of the logic plus the setup time of VERA's IO pins was too long and the address bus started slewing to the address of the next instruction before it had been sampled. The data bus value appears to be retained much longer since the CPU is going to set its data lines to a high impedance state in preparation for the RAM or ROM to service the next instruction fetch, but the address bus is actively driven by the CPU and was changing almost immediately after the address hold time expired.
I know that at least some of the issues were caused by inductive and capacitive effects inherent to putting an entire computer on a breadboard. According the scope, the fall time of the clock was 23.8ns! I would hope that on a manufactured PCB, the signaling would be much cleaner.