Re: PC-card (4)

jbevren_at_starbase.globalpc.net
Date: 2001-04-13 15:53:50

On Thu, 12 Apr 101 g.baltissen@hccnet.nl wrote:

> Hallo David,
> 
> I think there are some misunderstandings but they could partly be blamed 
> due to language problems (from my side :).

Could be ;)

> First you say "you don't need the wide window", then you talk about 
> "controlset".
> I presume you mean with controlset all the I/O that the C64 needs to 
> perform the actions. The 8237 is 16 bytes and for what I have in mind I 
> need less then 8 bytes.

This control set is a register set that controls the location of the 128
byte window in the ISA address space, and whether its located in the I/O
region or the memory region.  It should be a fairly small set of
registers.:)

> If we forget the DMA at all for the moment, then we need a way to address 
> that 16 MB of memory plus a lot of I/O. The C64 cannot address this so we 
> need about the same technique the C64 use to switch between I/O, CHARROM 
> and RAM: Bankswitching. Bankswitching is in fact selecting different 
> selectlines. What we need here is pageswapping, the same technique used 
> with EMS, Expanded Memory S (???), on a PC. The memory area where all this 
> Expanded memory is situated is called frame (that's what I meant with 
> "window")  The amount memory which fits in such a frame is a page. 
> I think you agree if I say the bigger the page the lesser you have to swap. 
> That's why I prefer a 256 byte frame or window.

I understand EMS fairly well.  It swtiches a 64k window about in a 16meg
address space on a ramcard. ;) (ot: what I dont get is why it didnt die out
until the pII was designed)

> The above is the basic interface I had in mind.

Okay.  I do see your point covering the need for a way to access the 16M of
ram the ISA bus can address.  Let me cover this quickly with a tiny idea:
If you DO use the 256 byte ram window at an I/O block (I'll use DF00 for an
example), you should set it up such that a read to byte $ff would increment
the page pointer registers.  This way you can copy larger amounts of memory
into the c64 without rewriting the control register.  Simply let the window
byte counter overflow, and the page pointer into the ISA space will
increment before byte 0 is read again, resulting in a read from the next
ISA-space byte.

> 
> DMA on a PC works in the way that an I/O-peripheral outputs a stream of 
> bytes which the 8237 directs to the right memory locations one by one after 
> each other. Of course the oway round is possible as well.
> This is what I had in mind when talking about adding DMA to the interface. 
> 
> Now I have the idea that what you mean with DMA is what the REU does: it 
> copies/swappes an amount of memory situated outside the C64 from/to/with an 
> amount of memory inside the C64. I haven't thought about this idea. But you 
> need two 8237's to perform this trick. And then you need 32 bytes for the 
> DMA alone. 

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;)

> If we only had to deal with memory, then you are absolutely correct with 
> saying you don't need any window. I even can dream up a scheme where you 

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)

> use DMA to read/write from/to the I/O area. But imagine what an amount of 
> instructions are needed to send ONE char to a printer....  With this in 

I've seen the code for Nate\DAC's REU-based modplayer.  It grabs one byte at
a time from the REU as needed.  *shudder*  I think I have a fair notion of
the amount of trickery involved in doing simple transfers via dma
controllers, and have no intention on making programmers do this ;)

> mind we definitly need a window. The only thing we could discuss is the 
> size of the window. My intuition tells me to stick to the 256-byte version. 
> I could give you several reasons to support this feeling.
> 
> The result of this little story is that now my goal will be using two 
> 8237's to get a REU like copy-function. This will make a more effective use 
> of great numbers of attached memory.

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. 


-
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.