Hallo David, > you should set it up such that a read to byte $ff would increment > the page pointer registers...... <snip> My first goal is to keep the amount of hardware to a minimum. We would need 8-bit wide loadable counters with tristate outputs. I don't know any, only smaller ones. I know situations where I prefer to start from $FF counting downwards. I know situations where I need to read a $FF address several times (COM-ports). This asks for more hardware to disable the feature. So it seems we need quite some hardware only to make the software a little bit faster. If FPGA's were common good I would say yes but for the moment this guy has to solder everthing by hand using plain old TTL-IC's, so I personnally unfortunally have to reject your idea. Thanks anyway. > Remember, one of these 8237's is on the ISA side, and would be accessed > via the ISA window. Thus we need 16 bytes for "our" 8237, plus a few > bytes for the control registers. To access the ISA side's 8237 and start > the transfer we use the window and point it at the lower I/O addresses;) To add another 8237 I only need an 74245 bi-directional buffer. (why this particular buffer is needed I explain later but not in this email) Adding it at the ISA-side means I also need an decoding circuit and some more. And what address should I use? (most possible answer: where we find the 8237 on a PC motherboard) These extra 16 registers won't hurt so I prefer to keep it on the C= side. > aha! This is were we misunderstand. I'm not eliminating the window. I'm > simply shrinking it to 128 bytes, so that we can have half the page used > for > our control registers (and 8237), and the other half for the window into > outer sapce. (hehe) But I have still mixed feelings about the 128-size. With 256 byte you can use the full power of: - indexed addressing: LDA ($xx),Y , LDA $DF00,Y etc. - internal addressing of the 8237 - 8 bits are easier to work with then 7 bits. > controllers, and have no intention on making programmers do this ;) Thank you :) > Is an 8237 on the commodore's side really necessary? I think it could be > quite possible to use a counter/register circuit that's part of the glue > logic to provide an address for the 8237's data. This way, we can simply > act as yet another ISA bus master. I'm not quite sure what you mean, especially this part: > ... to provide an address for the 8237's data. This way, we can simply > act as yet another ISA bus master. I have been thinking about using registers, counters and buffers to perform the DMA actions but then I would end up with something that almost would be a REU (and that's another discussion :) To save me a lot of time I rather prefer to use the "ready" 8237's, even if it would mean less speed. About the second 8237: the first reason I mentioned it was that it featured a memory-to-memory mode. Using one 8237 means a maximum of 128 KB/sec M2M-transfer. Using two 8237's means a 256 KB M2M-transfer. Another remark: 256 KB is only a quarter what the REU can archive but is IMHO more then fast enough to support a 1.44 MB drive. Groetjes, Ruud http://Ruud.C64.org/ - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.
Archive generated by hypermail 2.1.1.