> > 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 email@example.com. - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail firstname.lastname@example.org.
Archive generated by hypermail 2.1.1.