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