Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Wavicle last won the day on April 3

Wavicle had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Wavicle's Achievements


Newbie (1/14)



  1. Hard to tell without a schematic and a description of the failure, but assuming this screen cap is still the board: I'm guessing that R38 and R8 are current limiting resistors for the LEDs and R39 and R40 are pullups for I2C, so you have no external resistor on the daughterboard connected to RESET_BUTTON_PIN. The ATTINY does have internal pullups that can be used on input pins, but that functionality appears to require you to specify the pinMode as INPUT_PULLUP (see lines 95 and 101 here: https://github.com/SpenceKonde/ATTinyCore/blob/a2387a8d5551272e6860fb830099c2473a6da22a/avr/cores/tinymodern/wiring_digital.c): //Button Setup pinMode(POWER_BUTTON_PIN, INPUT); pinMode(RESET_BUTTON_PIN, INPUT_PULLUP); // don't leave this floating pinMode(NMI_BUTTON_PIN, INPUT); If this were the problem and I'm reading the code correctly, I think it would show up as a floating pin so the attiny could think the button was still down even after being released. Alternatively, you could have a pullup on the motherboard and this isn't the problem at all. That's my best guess after 10 minutes of investigation . If that is the issue, the other two buttons probably need the same change.
  2. The HDLs are generally hardware agnostic but they describe digital logic architecture not analog - basically anything that can be crafted using gates (the first thing the HDL compiler does is reduce your RTL into a synthesizable gate netlist). Most designs today either use an external DAC IC (e.g. X16's VERA uses a resistor ladder DAC on the PCB for VGA) or they have a single DAC block internally and pass the digital signal to it as the last step before heading to the pins. They do this because the design and verification tools for digital logic are easier and cheaper therefore it is much more cost efficient to push the analog conversion to a dedicated analog IC or a pre-defined generic DAC that can dropped into the design (and can usually be implemented as an R-2R ladder since precise impedance values are very difficult to manufacture in an IC but relative values are not). What is the hobbyist fab getting us that isn't done faster and much more cheaply using FPGAs or commodity ARM-based SoCs? I guess compare this to the many options you have for a hobbyist etching/milling their own PCB to sending your board out to be manufactured. Unless you're really in love with the idea of making your own PCB in your garage, you send your board Gerbers out to be manufactured.
  3. You have mentioned many chips that have significant analog circuits in their design. FPGAs don't generally handle that bit of ASIC design and if they do it is in the form of a hard IP block which you cannot have manufactured into your design without a license.
  4. I'm not quite sure that I follow. I looked at the pin-to-port mapping file tonight; pin 16 (SPI_SS) is mapped to the flash_ssel_n port so the same wire used to select the flash component on the SPI bus during configuration is also used for reading flash ROM (presumably where KERNAL lives and is loaded by the bootloader). Whatever external circuit you have in mind must keep the expected behavior at that time. Also, it looks like pin 34 (IOT_44B) is mapped to the unconnected exp3 port. According to the design as it stood at the end of last year, there was one unused IO pin.
  5. I started prototyping an implementation using an ATTINY85 that I have. After I had a circuit assembled, test programs written, and everything tested (Arduino UNO as I2C master, ATTINY85 as I2C slave and PS/2 host) I started looking to integrate it into the sketch attached here and noticed that the only thing done is initialization of the Wire library. (By funny coincidence, we selected the same I2C address - we may have read the same books in the 80s or something.) It doesn't look like there is any I2C receive/request handlers implemented. Is this correct? (Is this the current state of the sketch, or is this maybe an older version of the sketch?)
  6. The SPI master configuration process is documented in the iCE40 Programming & Configuration technote (TN 2001) section 9.4. The SPI_SS pin is expected to have an ~10kohm external pull up which is how the SPI master configuration mode is selected. Once the mode select is detected, the FPGA will assert SPI_SS and begin downloading the design configuration from the SPI flash. It's an automatic process that begins after POR or regular CRESET_B rising edge transition and cannot be modified. Whatever mechanism you plan to use for multiple SPI chip select lines, that pin must still function as expected during that critical time period. Again, keeping in mind I'm basing this on Verilog code posted 8 months ago and I'm not an authoritative source -- The debug serial port as implemented is driven from a UART design that is in Verilog and not a hard IP block in the FPGA. I'm not sure that making the X8 an I2C slave makes sense, but in any case the component I mentioned does not operate as an I2C master. I'm not aware of any such component that does.
  7. The SPI flash is also used to configure the FPGA during reset, a sequence which is driven by either a hardware state machine or embedded microcontroller. If the CS pin for SPI flash goes low, that component must start responding or the FPGA will fail to configure itself properly. You could use an SR latch connected to the SD's CS (set) and reset (reset) to drive a multiplexer select, but that's adding even more external hardware. I'd consider repurposing the the debug UART as I2C and plug a board with an I2C to UART chip into it when a serial connection is needed for debugging (e.g. MaxLinear XR20M1280IL32-F). If I2C isn't fast enough and enough extra pins are available, that IC can also be configured to communicate over SPI.
  8. The exceptions are during initialization with the ACMD41 command. In other cases, the host is free to stop the clock and forget that the SD card is there at all, but ACMD41 starts the card power-up sequence and you must check back to see if that is finished at intervals of 50ms at most. You may stop the host clock during that interval, or leave it running, doesn't matter as long as it is getting polled every <= 50ms and the clock frequency, when the clock is on, is between 100 and 400 khz. I've spent several years as a silicon architecture engineer finding hardware bugs and driving RCA on them. With just the 6502 source code and an unclear description of SD card problem though, it's challenging to do any meaningful analysis. If we could get the dev team to sell a pre-release VERA board (and maybe release the RTL), I should be able to find the problem.
  9. This would probably be best taken to a new thread to avoid cluttering this one with non-PS/2 related discussion. VERA drives SCLK so the CPU frequency should have no impact. The 100-400khz SPI clock requirement is only during transfers; the clock may stop between transfers. (See section 4.4 Clock Control of the SD Physical Layer Simplified Spec)
  10. I don't think that's quite right, unless I am looking at the wrong branch: spi_write: sta SPI_DATA @1: bit SPI_CTRL bmi @1 rts That writes a byte to the SPI data register and then waits for the busy bit to clear. That looks like a complete hardware implementation. It would be nice to get a better description of what the SD failure mode is. Nicer still to hookup my protocol analyzer to the SD slot and probe traffic to see if the problem is the wire protocol or the hardware state machine. Regardless, since the X16 is acting as SPI master, it has control of SCK. As long as it isn't driven faster than 25MHz (the guaranteed minimum speed supported in the SD spec), that should be fine. I've written SPI bit bang drivers for bootstrap code with an effective clock speed around 0.1 MHz and did not see an issue on any card tested. The one problem I did see was un-branded cards that did not correctly implement SPI in their hardware, but this was roughly 10 years ago - I'd like to think all SD card manufacturers have figured that out by now. Are you mixing SD and PS2? The keyboard is a PS2 interface.
  11. One might be surprised - the feature exists mostly for security, though cost savings helps a little also. The iCE40UP5K used in VERA is part of Lattice's ultra-low power, high performance FPGA line. If you want to believe Lattice's marketing (??!) it is the "World’s Most Popular Low Power FPGA". It costs ~$6 in single unit quantities and has a one-time programmable configuration ROM (or, as they call it "Non-Volatile Configuration Memory"); here's an example from the the iCE40 Programming and Configuration Tech Note: Personally, I like the iCE40 primarily because Lattice doesn't charge me $400/month for the software tools to program it *cough*Intel*cough*. (Maybe there are free tools out there for Intel's mid-range FPGAs, but I haven't found them. Lattice gave me the tools for free and if they pulled the free license, there are open source toolchains for iCE40 FPGAs also.)
  12. Many (possibly most?) FPGAs have one-time programmable fuses in addition to SPI bootstrapping. That way a bad actor doesn't flash a new design onto your stove and have it think that it needs to run the gas for 300 seconds instead of milliseconds before igniting it. And your company doesn't have to pay to have the design fabricated into an ASIC.
  13. In re-watching David's original dream computer video, he mentions that the VIC-20 was simple enough that a hobbyist could understand what every chip on the board does. I assume he didn't use the C-64 because it had a PAL to handle the address decoding complexity. I think that is driving the 74xx series vs. GAL/SPLD decision. While internally an SPLD is a very simple circuit, the implementation is still hidden from you.
  14. I can do the embedded implementation, and I have an oscilloscope and logic analyzer on my bench to verify timing correctness. I haven't worked with an ATTINY861 before and I only have ATTINY85s in my bins here so I'd have to order an 861 from Mouser and hope that the 861 has a pretty similar toolchain to the 85. I'm not sure what the 861 needs for programming, but I assume if nothing else, my TL866II can do so. It would help, but isn't completely necessary, to have the X16 schematic page (or portion of a page) that details the 861 connection so that I can replicate a similar circuit on my benchtop. I'm competent with most assembly languages, however I'm probably all thumbs when it comes to 65xx assembly specifically. I can read it well enough, but have limited hobbyist experience writing it and zero professional experience with it. I'd be most useful for the embedded/861 implementation. I'm in the Seattle area (I work at the tech giant in Redmond) so it would have to be all remote work. Send me a DM if interested and I'll order the 861 parts from Mouser and we can take this to email/zoom.
  • Create New...

Important Information

Please review our Terms of Use