Jump to content

picosecond

Members
  • Posts

    64
  • Joined

  • Last visited

Everything posted by picosecond

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. While a full characterization at some future point will be great, there is an easy way to help expansion card designers now. 1. Specify the voltage (5V, +/- some tolerance if you want to get fancy) 2. Specify the clock waveform (8MHz, 50/50 duty cycle I guess?) 3. Publish a schematic of the logic between the 65C02 and the expansion slots. Everything else can be omitted. There should be no secret sauce here, it's just simple glue logic. I think that covers the most important stuff. I'm sure someone will chime in if I forgot something. Anyone capable of designing an expansion card should also be able to derive the timing requirements from the above information and device datasheets. Obviously the logic and timing is subject to change. Anyone designing to a moving target needs to embrace the possibility of breakage in the future.
  12. ...which makes it all the harder to understand why a 16C550 was not included as a standard feature.
  13. http://www.westerndesigncenter.com/wdc/documentation/w65c51n.pdf It is not really the interrupt that is broken. Instead, it is the Transmitter Data Register Empty status bit itself. So you can't even poll the chip to know when it is safe to write new data. You have to know the baud rate and pace writes using a software loop or other means. See the descriptions for "Transmitter Data Register Empty", pages 8-10. WDC could have been more intellectually honest about this bug, instead of writing "This feature of the W65C51N works different from earlier 6551 designs". [emphasis mine]
  14. Greetings from the Northeastern corner of the U.S. I have been lurking on the FB group since video #1. It is great to see a proper discussion forum being rolled out. I am here because I find retro systems a relaxing change of pace from my day job. I am a work-from-home ASIC design engineer for a well-known silicon valley company. Counting picoseconds in multi-billion transistor ASICs has its rewards, but the joys are different from the 80's designs of my early career.
×
×
  • Create New...

Important Information

Please review our Terms of Use