Re: PC-card (4)

g.baltissen_at_hccnet.nl
Date: 2001-04-13 23:08:34

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.