Jump to content

picosecond

Members
  • Content Count

    29
  • Joined

  • Last visited

Everything posted by picosecond

  1. 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.
  2. That youtube thumbnail image is hysterical. Nice one.
  3. 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.
  4. “Fill the steins to dear old Maine” and welcome. I’m a Maine native living now in the land of Live Free or Die.
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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".
  12. 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
  13. Here is a recent thread discussing development of a new FPGA-optimized 65C02 core. http://forum.6502.org/viewtopic.php?f=10&t=6332
  14. I think mine arrives in a few days. Thanks for the review video.
  15. Have you considered enlisting help from the community? An independent design review couldn't hurt. All of the secret sauce is inside Vera so sharing the prototype board schematics seems pretty harmless. I know at least one person here makes a decent living on timing issues...
  16. I did. Are you suggesting that some people comment on videos without watching them? All of this is hindsight of course, but it seems easier to start by focusing on the monitor. It appears, at least superficially to be completely standard for the era. It has a video cable, a switch and a 3-conductor power connection. If we assume it really is just a standard monitor what it the probable wiring of the power connector? As for the rest of his response, I am setting that to one side and looking forward to his next video.
  17. I can't speak for the vast majority but this electronics engineer thinks the paper clip thing was pretty foolish. The thing about electronics is, at some point everybody does something foolish. I expect most people here have a long list of goofs. David had a couple things working against him: a little knowledge that seemed like it should be applicable (but wasn't) and working in a hurry. In this situation those turned out to be an unfortunate combination. David deserves more credit than he has received for sharing his mistake in the first place. He also deserves way less criticism than he received for not owning that mistake particularly well. That being said, a brief "oops, here's what I should have done..." segment would have gone a long ways toward avoiding the big negative reaction. Addressing the original poster's question, I think CX16 will succeed or fail on its own merits. This controversy is orthogonal.
  18. Some folks (not the ones commenting here) may have the wrong idea about what VERA hacks would look like. Unless Frank and team release the source HDL, VERA is a blank slate to aspiring FPGA designers. It's an FPGA development board with VERA-compatible connectors. It's great that re-imaging is supported. It saves the non-trivial task of rolling your own mechanically and electrically compatible PCB. But any hacks will be completely new designs, not minor tweaks to the existing VERA. Depending on which FPGA they have chosen it might even make a nice standalone development board. I'm hoping for Lattice Semi's ice40up5k.
  19. Well that's the real trick, isn't it? I think we are mostly saying the same thing but I will elaborate anyway. The 6502 bus is fully synchronous and there is no concept of an idle cycle. Every cycle does something. There are four "regular" cycles: read, write, read but discard the result, and wait. Read/discard serves as an idle cycle from the 6502's point of view, but the addressed target has no idea of this. So while a DMA controller can take as many bus clock cycles as it wants to do its business, every signal needs to follow legal 6502 timing on every cycle. Whatever target happens to be addressed will do as it is told on every cycle. Mostly this means address and RWB need to be set to safe values with correct timing on every bus clock. So a hypothetical Z80 doesn't have to run synchronously with the system bus, but some logic between the Z80 and the system bus definitely does.
  20. None of this matters. The bus cycles are locked to your 8MHz system clock and DMA controllers are required to match the 65C02 protocol. The internals of the DMA card have nothing to do with what a bus cycle looks like.
  21. There is a small point here that I have not seen discussed yet. Expansion card DMA can address only zero wait-state targets. There is no way to extend a DMA cycle because RDY is already negated to halt the 65C02. This doesn't seem like a big restriction. Assuming it is still true that nothing on the system board adds wait states with RDY, the only concern is DMA to slow expansion cards. That's very niche.
  22. Of course. I guess my comments were not clear because I did not mean to imply you should change any hardware. But you should be more explicit that software must enable DMA cards only one at a time. I inferred from your comments that you think sampling RDY/BE is good enough to prevent (most) conflicts between competing requestors. It is not. Now, on to other hazards for expansion card designers to consider: Read-modify-write operations are meant to be atomic. Expansion cards should not take the bus during these. The 6502 marks RMW cycles with MLB=0. It is probably not safe to take the bus during cycles to certain IO spaces. Writes to Vera auto-increment addresses come to mind. Might two increments end up happening if one of these cycles is paused? Maybe the safe route is to take the bus only during opcode fetch (when SYNC=1). When doing this MLB can be ignored.
  23. I agree, assuming you correctly specify the worst case timing. Like I wrote before, I am dubious “assume 20ns” meets that criteria. Sorry, I can’t help being picky about timing, what with it being my livelihood and all.
  24. This will not work reliably. If multiple cards can take the bus at the same time they definitely will. Without hardware arbitration there isn’t much choice except for software to enable only one DMA capable card at a time. I can think of a few other possible hazards but I want to mull over some details before bringing them up.
  25. Is it? It is hard to judge without seeing the logic. 20ns sounds reasonable-ish for typical delays. It sounds low for worst-case delays. Consider letting expansion card designers decide how aggressive they want to be with the timing. I am puzzled why you mention BE in your example. Most expansion cards can ignore BE (leaving it undriven). Only cards that need to drive the address bus need to drive BE low to take control.
×
×
  • Create New...

Important Information

Please review our Terms of Use