Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Wavicle

  1. The 3-to-8 demux (CD74ACT138E) generating the IO CS signals internally ANDs 3 pins (G1, /G2A, /G2B): The AND operation of CS and PHI2 could happen implicitly if G1 was connected to PHI2. That said, this would make the timing issue worse since that would mean CS would arrive 12ns after PHI2. I think that to avoid this the best option would be as you suggest - allow CS glitches through and also pass PHI2 through the bus transceiver to the fpga. VERA would then sample A0-A4, CS, RW#, and PHI2 on posedge PHI2. Accessing SPRAM during the same PHI2 clock as the host read is probably a non-starter. The contention with the scanline composer means that you need one cycle to determine whose address goes into SPRAM and the SPRAM IP will respond one cycle after that. Since all VERA addresses are functionally registers, I don't think any operation needs to do this. VRAM reads require the address to be pre-configured, so there is time to fetch the memory and have it waiting in DATA0/DATA1.
  2. You are correct - I'm not sure why I thought each IO had 16 addresses. It might be because the VIAs share a single 32 address range. I believe that a problem here is that the state of the address bus is indeterminate from the end of tAH until the end of tADS. It's possible, and legal, for them to briefly have $9F2x/$943x during that time which would cause the address decoding logic to briefly toggle VERA's CS. For the SRAM and flash NAND components, a glitched CS isn't a big deal because they are completely asynchronous components. However for VERA, I don't think that's the case. One of negedge CS or posedge PHI2 is going to strobe the design to latch the address bus (and possibly the data bus) and respond to it. For this reason, I would suspect that CS and PHI2 must be ANDed together for VERA. This would match with what Adrian said in his X16 video (VIAs will not work if CS is ANDed with PHI2 because CS will not have propagated to the internal edge-sensitive flipflop in the VIA when the edge of PHI2 arrives and the access will get ignored).. If so, VERA (or any similar IO device that cannot handle CS de-assertions mid-operation) would have from posedge PHI2 until start of tDSR to put valid data on the data bus. With a 62ns high pulse width, a 10ns tDSR, and 6ns x 2 crossing the bus transceivers, that's exactly 40ns or 2 cycles of a 50MHz clock left over. Because we can't be certain of the alignment between the VERA clock and the system clock, we can assume that if VERA's bus interface were synchronized with its system clock, it would have to be able to respond in a single 50MHz clock in order to stay within timing constraints. If it took 2 clocks (1 to latch the input and 1 to update the data bus), then it is possible that VERAs clock edge would hit just before CS is strobed and VERA would have to wait a minimum of half a clock (10ns) to check again (if not one full clock) meaning 2.5-3 clocks (50-60ns) to respond. Hence the reason I suspect the bus-facing logic may be completely asynchronous to the system clock or have single cycle latency. I think this only hits read operations. Writes can be posted. This timing sensitivity would impact SD accesses (which are read intensive) far more than most graphics operations (which are write intensive).
  3. Looking at screen caps again, I'm going to amend my guess and say that I think VERA probably has two CS# pins. There's a CD74ACT138E that I assume is being used to generate the IO CS# signals and I don't see anything to combine the $9F2x and $9F3x range signals. I can also see VERA has two SN74LVC4245A bus transceivers, which makes me think maybe VERA IO reads are fully asynchronous. Synchronizing to the 50MHz clock and having the ability to respond on the same clock cycle the bus is sampled still means a worst case of say 39ns (if CS# was asserted 1ns after the clock edge VERA samples on) and adding to that the delays crossing two bus transceivers (2 * 6ns), the mux (10ns), and the read hold time (10ns), the result exceeds the 62ns pulse width. This would probably hit SD card access the hardest since graphics operations tend to be write heavy.
  4. I found out about the project after the first "Building my dream computer" video, so I am not certain about things prior to that, but in that video 6502 was definitely part of the plan. The original plan was to use a C64 with the video, keyboard, and storage hanging off expansion ports. This would give a stable platform for developing the kernal and once done the C64 PCB should be replaceable by any commodity (or bespoke) 6502 PCB. I've worked on teams building hardware or silicon ASIC products for the last 15 years and thought this original plan was well grounded: it kept things simple; started from a known working point; and provided a fast path for the software team to start developing on real hardware. Somewhere along the way, feature creep came to visit and promptly made starting with a C64 impossible. My experience told me that this was going to result in higher cost, longer dev time, or both -- but that experience is limited to commercial efforts at companies with deep pockets so maybe it wasn't tuned for this environment... or maybe it was. Switching to an MC6800 variant would be committing to this all over again unless there is a readily available source of commodity MC6800 boards.
  5. I think what was said is that VERA register access is async to the host system clock. It likely is synchronous to either the PLL-derived dot clock or the system clock. My guess would be it has a 48MHz clock, like the x8, giving it a 21ns cycle time which would make VERA accesses look very similar to the 40ns SRAM. PHI2 isn't needed, so the "obvious" 8th pin would be IRQB, however unlike the data bus which is bidirectional or A0-A4, CS, and RW which are input only (to VERA), IRQB is output only. The 65C02 datasheet says Vih must be Vcc * 0.7 (3.5V) which is close to 3.3V, but 3.5V isn't an approximate value, it is an absolute minimum so while driving IRQB directly from VERA at 3.3V will work most of the time, it isn't guaranteed to trigger reliably. (Oh man was that embarrassing, IRQB is active low, it says it right in the signal name. It shouldn't be a problem driving it from VERA as long as there wasn't an issue with the pin normally pulled up to 5V.)
  6. I was going to say because they don't make them anymore, but apparently that isn't true. That said, new stock is expensive and limited to 2MHz.
  7. If you're concerned about gouging, suppliers like Mouser will allow you to place a preorder at the normal price. You will have to wait until they get their next reel (currently 11 months out) but you can buy 100 of them for $5/unit.
  8. The iCE40HX8K-CB132 is a tough sell for a couple of reasons: It's a BGA package which is a bit more fiddly for non-machine placed parts and cannot be soldered without a reflow oven. It requires 4 PCB layers with 3.35 mil traces to access all IOs. It lacks the 1Mb SRAM in the iCE40UP line (this is why the X8 has 64K main memory + 64K VRAM, it's using the SRAM for both) With only 128Kb of block RAM, it would require external SRAM no matter what
  9. The TR50 only refers to how the parts are packaged for pick and place machines. All SG48 components are 48 pin QFN. The "I" refers to industrial grade. This is covered in section 5.3 of the datasheet:
  10. TR50 refers to a specific packaging of the FPGA (50 part tape and reel). That packaging option has been discontinued. The iCE40UP5K-SG48I (which comes in the default 2,000 unit tape and reel) is still being produced and very popular. The reason for discontinuing the TR50 option is probably that they are simply making too many to cater to quantities that small. If you want less than 2,000 units, you go to Mouser or Digi-Key and they will cut a strip of them off the reel for you (for a fee, of course).
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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?)
  16. 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.
  17. 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.
  18. 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.
  19. 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)
  20. 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.
  21. 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.)
  22. 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.
  23. 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.
  • Create New...

Important Information

Please review our Terms of Use