Jump to content

Wavicle

Members
  • Posts

    147
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Wavicle

  1. I'm most curious about how viral the license is intended to be. There are X16 Enthusiasts here making tools and game engines for others to use. Some of those could end up in the form binary library object files. Linking against a vbcc-compiled library will implicitly include binary data produced by vbcc into that project without the library user ever touching vbcc. Will the non-commercial licensing restriction then infect that project, or stop at the library? Well-intentioned library authors need to know if there is an implicitly viral license that library users will need to be aware of.
  2. Yep! Thank you clarifying that. I believe that I've fixed the Verilog causing this and sent a PR to Frank for consideration. (https://github.com/fvdhoef/vera-module/pull/11) For all those not on Discord here are before (current VERA design) and after (VERA design w/ my sprite priority fix) photos rendered on real hardware (with hand-drawn red circled areas where sprites were hidden because the scoreboard background sprite was rendered on top of them):
  3. I have another quick update for this thread on progress with the SD card issue: The short version is: I've never seen my "Breadboard16" fail to recognize an SD card as seen in the update video from last August. VERA will usually not come out of reset if an SD card is plugged in, but this is an electrical problem between the SD card SPI lines and the FPGA configuration flash SPI. (The v4 VERA fixed this by adding a digital switch that disconnects the SD card from the SPI bus until after the CDONE signal from the FPGA.) In fact, @Frank van den Hoef's VERA design and FAT32 code has been remarkably reliable (as long as files are named using only uppercase, that's a limitation of the original CBM code though). I've asked @Michael Steil about his SD card experience as well and he also has never encountered this issue. I livestreamed my youngest playing both FlappyX16 and Chase Vault on my Breadboard16 compatible hardware to a small audience on Discord tonight which included @ZeroByte (author of FlappyX16) and @SlithyMatt (author of Chase Vault) and we all learned a bit about the differences between the hardware and the emulator and flagged some interesting corner cases for follow up (notably that the emulator significantly overestimates the available work units for sprite rendering in the hardware). In any case, I've emailed David Murray about the details of his SD card because at this point I'm suspecting the problem is his card more than the X16 hardware or software. Hopefully it doesn't end up in his spam folder!
  4. I probably need to update this thread now that my Breadboard 6502 "X16 Compatible" is nearing completion, after adding the audio components, the power consumption shot WAY up. Currently at 4MHz with both VERA and YM2151 generating audio, I'm measuring 500mA - or about 2.5W. I don't have the tooling to measure component-by-component to see where all that power is getting consumed, but it jumped after the Audio, OpAmps, and DACs were added. The YM2151 is warm to the touch (not hot, but not room temp either) so I figure that's one major culprit.
  5. Progress is slow, but steady. Tonight I was able to list the contents of an SD card - which happened to be blank. I've not yet stress-tested it to see if I can repro the SD card issue shown in the update video from August. Being built on a breadboard with an extra dose of stray capacitance on every single pin, I've not had luck running stable at 8MHz, but 4MHz seems to work okay. Additionally, I have built an Arduino Nano based keyboard buffer that has fixed the keyboard issue - at least, it has for me. Even at 8MHz, KERNAL did not miss the single keystroke I was able to hit before it went haywire. We can say with certainty that the keyboard problem is entirely one of timing. Here is the 4MHz key-smashing test video I shared on Discord: 4MHz_Keysmash.mp4 The Breadboard16 looks substantially less clean than it did before with numerous fixes, reworks, and outright kluges. Between the main board and the PS/2 connector in the lower right is the Arduino Nano key buffer that allows my USB to PS/2 keyboard adapter to work at 4MHz. Above and right of that, up against the multimeter, is the world's first third party X16 peripheral with two banks of 8 LEDs corresponding to $9F60 and $9F61 (assuming it is plugged it into the /IO3 select line). VERA and the SD card socket are on the left side. The unplugged component on the top half of the VERA breadboard is the DAC waiting its turn for integration testing. Resting above the two breadboards, posed just for this photo, is the assembled but not yet programmed or tested ATTiny and RTC board containing the power, reset, and NMI buttons. It will be exciting to get that working as my "reset switch" is currently the blue wire draped across the ROM (in the ZIF socket). To the upper right, the "reset switch" disappears under the YM2151 test rig waiting to get rebuilt onto the top half of the VERA breadboard.
  6. At the command prompt with a flashing cursor (not performing any stressful workloads), my bread-boarded computer w/ similar hardware (VERA, 65C02, 2x VIA, 2x SRAM, 1x NAND flash, 8MHz clock, all discrete 7400-series address decoding logic, PS/2 keyboard) pulls 0.072A at 5V, or 350mW @2MHz while sitting at the READY prompt. If the real CX16 pulled twice that, it would still be under 1 watt. Edit: I just cranked the clock up to 8MHz and the current measured was 0.114A, so ~0.570mA. If the real CX16 pulled twice that it would be OVER ONE WATT!!! All signs point to very lower power consumption.
  7. For those who like pretty pictures, here's the logic analyzer trace after I got it working. The two yellow dips in the middle were the problem children. If you draw a line straight down the middle of them you may note that the first 5 lines (from top to bottom) are "00011" ($03) representing VERA register $9F23 aka "DATA0" for both. The bottom 8 lines are 0010_0000 ($20) for the first and 0110_0001 ($61) for the second. Those are the correct values; previously it was reading $20 for both. The more astute viewers may notice unusual spikes on D7 and WE_N appears to be asserted for the entire trace. D7 isn't working and I think it needs to be recalibrated. WE_N was "asserted" the whole time because the probe fell down out of position and I didn't notice
  8. I root-caused the auto-increment issue to a VERA address bus hold time requirement. VERA is taking action on the register read based on the contents of the address bus when CS# (or RD#) is deasserted. The GPIO expander was changing all of those within a few hundred picoseconds of one another. By changing the code to first deassert CS# and RD# and then change the address bus, the issue went away. On the CX16, CS# assertion appears to be combined with PHI2 which in theory causes them to change at the same time but in reality delays the critical CS# deassertion by the propagation delay of the gate(s) between the two and the stray capacitance of the signal wires. Pushing things to the edge like this is quite the game of chicken. If you push timing margins like this too close to the edge, small variations in board and IC manufacturing could cause instability in a relatively large percentage of devices in the field. That said, the big question now is: could this be the cause of the SD card issue? After looking at the HDL again with this in mind, I think I found the problem with SD card access. It's a little technical but there is a reasonable-sized window of opportunity where CS# needs to deassert while the read strobe is active or the SPI auto transfer will not start. This bug would exhibit itself to the user as the disk randomly just not responding after they start some activity such as loading a program or the disk directory. Does that sound anything like what was demonstrated in a video a few months ago? More technical details posted on the VERA repo on GitHub: Narrow timing window may prevent SPI auto tx from initiating · Issue #5 · fvdhoef/vera-module (github.com)
  9. After lots, and lots of debugging -- finally breaking down and pulling out the logic analyzer probe, I think I may have identified a bug on VERA that affects reads. So far it has only been seen on back-to-back auto-incremented VRAM reads, so it is possible the issue is specific to auto-incremented reads, but if the issue is caused by fast back-to-back reads then SD card read accesses (e.g. getting a directory listing, loading a program, etc.) is going to be heavily impacted by this. It's still possible that this issue is caused by an error in my I2C->GPIO implementation, and I'm hoping that is the case. I've sent the logic analyzer trace to Frank; hopefully he will have time to take a look.
  10. You absolutely could. It would run faster too since you would not have simulate a real data bus with it. A better option would be to build SPI into the FPGA since you can easily run it 20-30x faster than I2C. That's what the Gameduino did. In this case I want to keep the VERA bus interface as is, but I do have another UPduino...
  11. Fixed the color issue; I had all of the DAC bits swapped.
  12. I got my Raspberry Pi 3B+ to drive the VERAduino using an MCP23017 I2C GPIO expander. Then thought to myself that if I were sufficiently clever, I could redirect all of the emulator's traffic to its emulated VERA out to the real VERA on the protoboard. A hundred or so lines of code later and now I have everything emulated except for VERA: Colors are a little off; I think that I need to double check all of my DAC wiring because it looks like I may have some bits swapped. Ignore the missing text on the left, this monitor likes to cut off the first 30 or 40 VGA pixels for some reason. But there it is! A bit slow because the I2C is pegged at 400kHz; I am ordering an SPI GPIO expander (MCP23S18) to see if I can't improve that some.
  13. If it were me, I would probably go with the DE10-Lite. I like the look of the Cyclone IV EP4CE6 dev kits better, but the DE10-Lite has a substantially more capable FPGA, and I believe has better documentation and community support. Two big questions I would suggest finding answers for before committing to a purchase one way or the other: Can you get the development tools for free or at a reasonable price? It isn't unusual for the big players to charge hundreds per month or thousands per year for a tools license. Some of their older stuff they license for free. Make sure that whatever you get will not just be a doorstop unless you shell out a few hundred more dollars. How big is the support community for each? I believe the DE10-Lite has a bigger community but check my work. I'm not certain about this. My first FPGA was a $15 Cyclone II EP2C5T144. It's the FPGA I used when I made the prototype VGA sprite w/ alpha channel. However, the only help for getting started with that FPGA that I found was a single YouTube video. It's hard to get motivated when you feel like you're on the playground by yourself.
  14. As construction of my Breadboard16 continues, I acquired 5 YM2151/YM3012 pairs of ICs for audio. Unfortunately these are frequently counterfeit and sold by unscrupulous vendors on eBay, AliExpress, etc.. In the past two months, all ten YM2151s that I purchased from eBay were remarked counterfeits (they were all 6116 SRAMs, 9 of them passed burn-in testing as SRAMs). I turned to my trusty RaspberryPi 3B+ and a bit of Python to create this vintage audio IC test rig: My choice of OpAmp was maybe not the best, as I suspect I'm getting distortion at relatively moderate volume. But otherwise it sounded great. All 5 of the new YM2151s and YM3012s passed testing as authentic, functioning ICs: YM2151_MarbleMadness2.mp4
  15. 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.
  16. 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.
  17. 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!
  18. I'm going to disagree with #2 for all but trivial features. Every feature is an opportunity for more bugs. A feature added "in your spare time" is not likely to have bugs found only "in your spare time." What was an innocent addition done when things were quiet may the source of fire drills holding up the product. I think that feature creep generally happens because: 1) it's really (cool / better than the current way / the way we did at my last job); and/or 2) my load is light and I'm bored. In my opinion, adding audio to VERA was originally feature creep; however I suspect that it will move into the "essential" bucket because YM2151s are more difficult to source than eBay would have you believe; I have ten 6116 2kx8 SRAM chips remarked as YM2151 that can attest to this fact. (And possibly because it is not possible to meet the YM2151 read timings on an 8MHz 6502 with no clock stretching, so the YM2151 on an X16 could only reliably be written to.) Adding hex translation to BASIC is kind of borderline because while it wasn't a must-have feature and has the potential to be a source of bugs, it was trivial and not likely to have any. I don't think the idea of using the currently available microcontroller to handle PS/2 has been fully explored. There have been requests for the technical rationale behind this, but nothing has been offered yet. "Frank was having trouble" isn't technical rationale; it could mean "Frank needed to remodel his kitchen" which is a valid reason but not a technical one. David has since clarified that Kevin's plan may be to use a bank of VIA pins, which makes me think they are looking to copy Ben Eater's design. This isn't all bad since Ben Eater's design is known to work, however it is still feature creep (and uses up half of the available GPIO pins).
  19. Last I heard it sounded like they may be down to two working VERA boards. I'm in the process of modifying an iCE40UP5K dev kit to be as close as possible to a real VERA. Everything is on a breadboard, so I doubt that I can run at 8MHz stable, but I'll keep my fingers crossed. Someone elsewhere pointed me towards the Upduino which looked like it might also work and was only $25 (so I have ordered 2). As lo ng no wires come out of my breadboarded X16 and there are no fires to put out at work, I might have something to test with in a week or two.
  20. Re #1: The VRAM uses the on-board SRAM while the audio uses embedded block RAM. It would be a very small increase to VRAM along with a additional complex logic to determine when a VRAM access should go to SRAM and when it should go to BRAM. Re #3: Larger FPGAs with more embedded SRAM are generally much more expensive. The FPGA used is an odd one in that it has a modest number of logic elements with a large synchronous SRAM for a bargain-bin price. Normally if you want that much SRAM the expectation is that you'll add an SRAM component to the board (basically what you put in #4).
  21. Not much, unfortunately. The SPI controller uses just 28 LUTs and 26 registers. Removing SPI increases the number of available logical elements by about 1%. There's quite a bit of room available in the FPGA to increase VERA's capabilities as long as you do not need block RAM, SRAM, or a hardware multiplier.
  22. You can also add `vsync=none` to the box16.ini file and will not have to put it on the command line every time. Or once box16 is running, go to File->Options->Save to box16.ini and it will write out the ini file with `vsync=none` in it.
  23. The HDL was briefly public on Frank's GitHub and there are a couple of forks of it still available. Only gotcha I saw in there that would affect FPGA porting is that unless you choose an FPGA with a large SRAM (the iCE40UP5K has two 16x32Kbit single ported, synchronous SRAM blocks) you'll need to tack on an external 32-bit SRAM with an access time ~20ns or better. There are plenty of affordable SRAM components that fulfill this requirement, you will also need at least 52 pins dedicated to the external memory. Keeping all other things fixed, that's a lower bound of 90 external IO pins.
  24. The render of the Rev 3 board shows this 6 pin header labeled "I2C" adjacent to VIA #1. Interpret that as you may. I'm not sure why the header is 6 pins.
×
×
  • Create New...

Important Information

Please review our Terms of Use