Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by picosecond

  1. Right. I omitted that intentionally, which makes it all the dumber. I was thinking applications would schedule writes on their own. But the schedule would be for blocks of writes, not individual ones. Thanks for the correction. Anyway, I suppose it is possible reads are working on the bench but that is almost worse. It is much better for things to be broken-broken, not sometimes-broken or sometime-in-the-future-broken. It would suck to have a batch of slow parts causing sound problems halfway through a production run. It's even worse if the slow parts break a bunch of DIY kits.
  2. Those are logical ports, and maybe that is what Bruce meant by "truly dual-ported". I inferred he was describing the internal construction of the FPGA RAM blocks.
  3. Exactly. Gating the raw decoded chip select with PHI2 obviously puts /CS well after PHI2 rise. They missed the setup window. Controlling only the YM2151 /CS is sufficient. All of the data timing parameters reference the last control signal change. Zero wait state operation isn't so easy at 8MHz. Access time is 180ns so reads are totally broken. But those are used only to check interrupt status. Interrupts might not even be connected. The easy fix is to simply disallow reads. Zero wait state writes cannot meet the timing requirements by using PHI2 edges for pulse forming. Using the typical design pattern will violate Tcw(100ns) and Tds(50ns). That probably works fine on the bench at room temp but may not be reliable across a production run. Some kind of /CS pulse stretching is needed to satisfy the datasheet requirements. After the VIA timing problems I imagine the team reviewed every chip's timing requirements, and have a plan to address this in proto#3. Or maybe they just plan to screen YM2151s before using them. Do such versions exist? I have never encountered a reference that suggests this, let alone a datasheet that quantifies the timing differences.
  4. That's not an unreasonable intuition but TTL doesn't work that way. Timing is an interesting subject. If you are interested in testing your understanding, can you explain which violated timing parameter Adrian fixed on proto #2?
  5. Yes, TTL and CMOS have different specifications for low and high voltage levels. Let's assume a minimum VCC of 4.5V for this example. For the F521, a "1" at the output means a voltage greater than 2.5V. This is the VOH(min) parameter in the datasheet. For the AC11032, a "1" at the input is guaranteed to be recognized only if the voltage is 3.15V or greater. This is the VIH(min) parameter in the datasheet. So a perfectly valid "1" for the F521 could be wrongly interpreted as a "0" by the AC11032. Obviously that would be bad. If you ever wondered why there are both AC and ACT logic families this is the reason. ACT input voltage thresholds are shifted downwards to be compatible with TTL output voltages. This article has a more complete explanation: https://www.allaboutcircuits.com/textbook/digital/chpt-3/logic-signal-voltage-levels/ As an aside, in your last schematic you could connect RW to that unused 'F521 input and save some glue logic.
  6. Replace the '574 with '273, and use its built-in clear function. Be careful mixing logic families. 'AC11032 VIH is not compatible with 'F521 VOH. You can replace all of the jelly bean logic used to generate both bank register clocks with a single '138, similar to BruceMcF's comment above.
  7. Geez, where is my head? Bank registers need to be initialized at power on. That is easiest using a resettable flop, like the '273.
  8. Right, CLK and D are the only inputs that affect flop state. OE only connects or disconnects the flops' outputs to the '574 outputs. The logic diagram on page 2 of the data sheet illustrates this pretty well.
  9. Nope. It's neither necessary nor helpful. Just ground the OE.
  10. Probably not. I don't remember comments describing how Vera clocks are generated, but it appears PHI2 is generated from its own 8MHz crystal oscillator.
  11. That youtube thumbnail image is hysterical. Nice one.
  12. It sounds like steady progress has resumed. That is good to hear. I hope someone studies the YM2151 datasheet timing diagrams before the next build. There are several requirements that may not be easy to meet.
  13. “Fill the steins to dear old Maine” and welcome. I’m a Maine native living now in the land of Live Free or Die.
  14. Supply crapping out and poor quality parts are different things. FPGA YM2151 gets 10/10 from me. Then it would be 100% new, off-the-shelf parts. I don't care if parts are fixed-function vs programmable. I do care if they are new vs used. If a suitable new fixed-function part isn't available FPGA is a great solution. BTW, despite not posting here often I do read every one of Lorin's posts. Don't assume I am uninformed because my perspective is different from yours.
  15. The scale is wholly arbitrary so I don't see why any score should be labelled "silly". I thought I was being generous. Here's the thing: I don't care at all about purity tests. I care about building reliable computers. Using these parts poses risks that nobody on the design team can quantify. Maybe the supply will be great quality and they have no problems. But if not, what then? Pay someone to screen the parts? Develop a test procedure (not so easy) and screen parts themselves? Hope for the best and ship spares to kit builders who complain about no sound? What about damaged but not dead parts that die some months after systems are shipped? None of this matters for hobbyist builds. All of it matters when shipping systems in quantity. It's just not worth the risk to reputation and personal bank accounts to take chances with iffy semiconductors. Maybe 2/10 was too generous.
  16. 2/10: OFF THE SHELF COMPONENTS Gray market YM2151/3012 do not meet the criteria. I am quite certain others will disagree with this opinion.
  17. Confusion here is understandable. Wasting so many connector pins this way is not intuitive. https://www.commanderx16.com/forum/index.php?/topic/862-hardware-expansion-and-driver-handling/&do=findComment&comment=6010
  18. This is a good idea that can be done natively using the expansion connector, with only minor changes to the current design. First we need to free up some expansion connector pins. I never understood the peculiar idea to send five IO selects to every expansion connector. It wastes four connector pins and burdens every expansion card with switches to pick one of them. Instead, send a different IO select to each connector. 32 bytes of memory-mapped IO is plenty for most applications. For those that want more we can exploit the unused ROM banks as described next. Each expansion slot now has four free pins. Use one pin as the slot select, which is a trivial decode of ROM bank register upper bits and the existing ROM address space decode. The remaining three bits can be just the three LSBs of the bank register. This sparse decoding "wastes" lots of ROM banks but they were unused anyway. Now each slot has eight banks = 128KB of address space to use as desired. Nothing says ROMs need to live here of course. It can be used for anything. A dumb frame buffer might be a fun project. Yes, this idea does require a minor addition to decoding glue logic. I think it's a bargain but this isn't my project. What to do with the remaining unused IO select? I would use it for a UART but I doubt the team has the stomach for that.
  19. I thought we were keeping things simple. A fuse is not going to protect any ICs from metal objects and clumsy fingers. At best it will avoid vaporizing some main power traces that got treated to a dead short. If someone accidentally does that, lesson learned and break out the rework wire.
  20. Adrian Black is a class act. What a gracious and generous video. I have enjoyed his channel and hope he keeps producing new content for a long time. This is an important step. I hope folks in the community realize how much engineering work remains between "mostly runs on the bench" and "ready for production".
  21. Here are some thoughts for @Kevin Williamsabout his latest video, "Commander X16 Hardware Changes for Proto #2". I see several youtube commenters suggesting an MCU for debounce and soft power-on. I attached some ideas for jellybean logic implementations for these. The debounce is a standard RC delay followed by a Schmitt trigger. There is plenty of literature available for this circuit, some of which I referenced below. The reset debounce includes a power-on reset for the 65C02. The first soft power-on is a light modification of the one featured in Kevin's video. It replaces the 555-based debounce with a Schmitt trigger, adds initialization for the toggle flop and removes the unnecessary Q2 (ATX PS_ON# is TTL compatible) The second soft-power-on is mostly stolen from http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch. The latch is built using a weak feedback inverter, similar to how SRAM bit-cells are constructed. Pressing the switch overrides the feedback to change the state of the latch. The circuit should oscillate if the switch is pressed indefinitely, so the RC time constant is a trade-off between responsiveness and unwanted state changes. Disclaimer: None of these circuits have been tested or simulated. RC time constants likely need some adjusting and there may be more serious errors. Fortunately it is simple to breadboard these circuits to do testing with actual switches and power supplies. At the very least I hope they provide some inspiration and provoke discussion. Cheers. References: https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-1 (total of 9 parts) http://www.ganssle.com/debouncing-pt2.htm http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch cx16 debounce.pdf
  22. Here is a recent thread discussing development of a new FPGA-optimized 65C02 core. http://forum.6502.org/viewtopic.php?f=10&t=6332
  23. I think mine arrives in a few days. Thanks for the review video.
  • Create New...

Important Information

Please review our Terms of Use