Re: PC-card - DMA/SBHE

From: Ruud Baltissen (Ruud.Baltissen_at_abp.nl)
Date: 2001-04-17 10:41:43

> > SHBE  A0     Transfer
> >   0    0       word
> >   0    1       byte on D8..15
> >   1    0       byte on D0..7
> >   1    1       will never occur says the doc ***
> >
> > *** and what about older I/O cards???
>
> Older cards??

If you insert an 8-bit LPT-card into the slot, SHBE is (H) due to the
internal pull-up resistor. Address an odd address and the above situation
occurs. Then one can say: "This won't happen with 16-bit cards!". OK, then
tell me how a PC recognizes the fact that a card is 16-bit at all?

<think...think..>

When the address is presented to the card, the card informs the PC it is to
be a 16-bit transfer by pulling MEMCS16/IOCS16 (L). A mechanism INSIDE the
PC then decides what to do with the transfer. There are several
possibilities:
card:     transfer:   address:  |   result:
8-bit       byte        even    |   normal transfer using D0..7
8-bit       byte        odd     |   normal transfer using D0..7
16-bit      byte        even    |   normal transfer using D0..7
16-bit      byte        odd     |   transfer using D8..15 and A0 = 0
8-bit       word         -      |   1) CPU is halted
                                    2) transfer of low byte using D0..7
                                    3) incerement address
                                    4) transfer of high byte using D0..7
                                    5) enable CPU
16-bit      word        even    |   normal transfer using D0..15
16-bit      word        odd     |   1) CPU is halted
                                    2) transfer of low byte using D8..15
                                    3) incerement address with 2
                                    4) transfer of high byte using D0..7
                                    5) enable CPU

So the above table could be read as:
> >   1    1       will never occur when a card signals a 16-bit transfer.
I think that that makes more sence.

> Remember our word-wide latch?  Grab a 16bit transfer from the card, and
> spend two cycles transferring it, a byte at a time, into the c64.

The above also makes me to reconsider my 16-bit design. Until now I used a
temporary buffer to store D8..15. The idea was, when writing a word, first
writing to this temp and then writing to the card. But what to do if you
don't know to what address you are writing to (compilers, assemblers) ???
I think that we have simply forget this temporary buffer and write to D0..7
or D8..15 depending on the xxCS16-signal and addressline A0, in other words,
some hardware does this job. Only one 245 needed. Bonus: no more writing to
the temp needed, or faster software :)

Two other remarks about the SBHE-line:
1) This morning it occured to me that only peripherals able to initialize a
DMA can steer this line. This makes sense not finding an output steering
this line on the memory-card.
2) I'll use an OC-output. Should be save enough for the moment.

> hooked to a0-a23, and incrementts by one. DMA channels 4-7 are 16-bit
> channels, and transfer 16 bits at a time. This further leads me to assume
> that DMAC 1 is hooked to A1-A23, and increments by 'one'.

Sounds as a very good deduction. Hat off, my friend.

Strange enough I didn't receive my own email (maybe due to the fact that our
emailserver was down this morning), so I don't know exactly what I wrote
last days.

The above redesign partly simplifies the DMA-transfers as well. In case the
card doesn't drive SBHE we'll do it and again can use the (245/extra HW) to
transfer data.
For reading data when the card activates the SBHE-line itself, the above
mechanism can be used as well. But what about writing data??? In that case
it seems we need a temp buffer in D0..7.

Please, think about the above.

Groetjes, Ruud

http://Ruud.C64.org


> Remember our word-wide latch?  Grab a 16bit transfer from the card, and
> spend two cycles transferring it, a byte at a time, into the c64.
>
> > Regarding 2) IMHO if it is a 16-bit transfer then the 8237 either does
not
> > use A0 or must increment with 2. AFAIK it can't increment with 2. And it
> > has to use A0 as well as it is needed with 8-bit cards.
>
> My (possibly incorrect) memory of the DMA arch on the PC (from the
> programmer/sysadm's point of view): DMA channels 0-3 are 8-bit.  I.e. they
> transfer 8 bites at a time.  This would lead me to assume that DMAC 0 is
> hooked to a0-a23, and incrementts by one.  DMA channels 4-7 are 16-bit
> channels, and transfer 16 bits at a time.  This further leads me to assume
> that DMAC 1 is hooked to A1-A23, and increments by 'one'.  This results in
> each transfer being a word apart, two addresses in ram.
>
> > I found a 1984 16-bit 4 MB memory card and looked for pins connected to
> > this line using a beeper. I only found inputs.
> > Tried to do the same with some networkcards and an old MFM-controller
but
> > ended up in big custom-IC's.
> >
> > At this moment I don't know what to make of it. What could help is the
> > missing page 14 of IBM's original schematic of the AT. Can anybody help
me
> > in this?
>
> Post what you find ;)
>
> > Any comment is welcome.
>
> Important comment: Your discoveries, along with ours, are extremely
helpful
> with many projects.  Not just the isa project. ;)
>
> -
> This message was sent through the cbm-hackers mailing list.
> To unsubscribe: echo unsubscribe | mail
cbm-hackers-request@dot.tml.hut.fi.


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