maxtherabbit wrote on 2022-05-14, 14:26:
The Adaptec 154x cards can perform bus master DMA to ANY memory address in the first 16MB. This included video RAM and any other RAM mapped to the UMA on peripheral cards.
Thats the theory, the nitty gritty details is where I cant find any information
mkarcher wrote on 2022-05-14, 22:25:
The might be stuff in the fine print spoiling direct ISA-to-ISA DMA, though: ISA dynamically negotiates bus width (8 or 16 bits), and I don't know whether the Adaptec host adapter performs negotiation. Possibly, the Adaptec host adapter blindly assumes that the ISA target is able to perform 16 bit cycles and doesn't bother to check MEMCS16. In that case, bus mastering to (and especially from) VGA cards might or might not work, depending on the card
1540 documentation mentions LA lines (address pipelining), might suggest it strictly expects to be in 16bit capable slot and nothing else. document linked by maxtherabbit claims it shouldnt have trouble talking to 8bit devices:
1540A.DOC wrote:16- and 8-bit transfers Odd and Even starting address transfers and odd or even data lengths
on the other hand very fun topic by again maxtherabbit Re: Why does EMS suck on my 286? discovered otherwise
mkarcher wrote on 2022-05-14, 22:25: Another point in the fine print of ISA bus mastering: There is nothing in the specification mandating the mainboard to drive IOCHRDY or 0WS when you bus master to/from memory.
Seems Adaptec thought otherwise? :
1540A.DOC wrote:The I/O Channel Ready signal automatically slows the system further if required by the host memory.
but still no mention of handling NOWS signal or any hint if motherboards generate one.
mkarcher wrote on 2022-05-14, 22:25:So a bus master issues a memory cycle to the ISA bus and then waits for "an appropriate amount of time" for the cycle to actually complete. That's why you need to set the rate on the Adaptec 1542, you choose the "appropriate time".
This bugs me. ISA clock is fixed, how would bus master wait anything between 2 and 3/4/5/etc clocks? its either 8 or 5.3 or 4 MB/s etc, other numbers could only be derived by dropping bus mastering every x transfers - something AMD LANCE manual mentions. 1540A.DOC also states default 11us bus on time and 4us off time. That translates to ~70% bus utilization. 8MHz * 70% = ~5MB/s sort off. This would explain default "5.0 MB/s". On the other hand 2 clock cycle is only possible when target generates NOWS, do motherboards do that? With 3 clock bus transfers numbers again stop making sense 🙁 Unless Adaptec DGAF and just blasts 2 clock transfers even at the slowest 250ns setting.
1540A.DOC wrote:AHA-1540A/1542A MEMORY CYCLE TIMING
STANDARD tRR TIMING
SPEEDS tWW
5.0 MB 250 A
5.7 MB 200 A
6.7 MB […]
Show full quote
AHA-1540A/1542A MEMORY CYCLE TIMING
STANDARD tRR TIMING
SPEEDS tWW
5.0 MB 250 A
5.7 MB 200 A
6.7 MB 200 A
8.0 MB 150 A
10.0 MB 100 B
wait what, 5.7 and 6.7 are the same, a placebo setting? 😀
Fastest standard ISA Bus cycle takes two clocks, 250ns at 8MHz. So do those higher settings simply mean 154x could potentially be able to work at up to 20MHz ISA clock without waitstates? That would finally make some sense!
mkarcher wrote on 2022-05-14, 22:25:
Keep in mind that the ISA bus is not specified as a synchronous bus with cycles taking an integer number of bus clocks and signals being evaluated at specific phases of the clock signal. Nearly everything on the ISA bus is asynchronous.
that doesnt sound legit 😀
mkarcher wrote on 2022-05-14, 22:25:
A memory write cycle starts when /MEMW is pulled low. It takes a "default duration", but will be extended when IOCHRDY is pulled low. It can be shortened when /0WS is pulled low (on an AT or newer, there is no /0WS on an PC/XT). And here's the point why I wrote nearly everything is asynchronous: The /0WS signal is the only signal that's specified to be sampled in a specific clock phase.
From what Im seeing in ISA System Architecture Third Ed everything (but CHRDY?) is happening at specific clock edges and is very much counted in integer bus clocks.
1540A.DOC wrote:2.1.3 8 Bit Memory
During normal DMA operations, nearly all transfers to and from memory are 16
bit transfers. At the very end, […]
Show full quote
2.1.3 8 Bit Memory
During normal DMA operations, nearly all transfers to and from memory are 16
bit transfers. At the very end, or the very beginning of an odd address
boundary, an 8 bit transfer on the upper data bits (D8-D15) will occur
according to the AT bus architecture. Some memory in the I/O space, such as
video RAM, is 8 bits only and always transfers data only on the lower data bits
(D0-D7). The AHA-1540A/1542A will transfer 16 bit or 8 bit memory in the
address space between 0A0000 hex and 0BFFFF hex depending on the signal line
MEM16 on the AT bus. If this signal is active, 16 bit memory is assumed, and if
inactive 8 bit memory is assumed. Outside of this address space 16 bit memory
is always assumed.
now this is weird and just adds to the confusion 😀
>Some memory in the I/O space, such as video RAM, is 8 bits only and always transfers data only on the lower data bits (D0-D7).
This must of talked about specific IBM models with specific video adapters? maybe it was still true in 1989 when it was written.
>Outside of this address space 16 bit memory is always assumed.
and this would mean Adaptec obeys M16 only in 0A0000-0BFFFF range?!?! 😀 Re: Making my first ISA card, as pain-free as possible Re: Why does EMS suck on my 286? amazing 😮
Whole reason for this topic is my curiosity if it was at all possible to release a 2D sprite accelerator in late 80 286 to very early 90 slow 386 era, a PowerVR PCX1/2 of its time 😀. One alternate history timeline could see Atari introducing Lynx Suzy blitter (1989) on an ISA card. Another option is basic DMA engine. Something like 1984 Commodore REU can only perform ~1MB/s block transfers, but is able to deliver Sonic on C64 https://www.youtube.com/watch?v=XAc-em-Kugk.
30 fps sprite games would be solidly in reach of such a contraption. 2MB/s VGA writes + 2MB/s of reads from ram. Maybe even 60 fps with own buffer/cache on board.
Card with dedicated 128KB for work framebuffer and some sprites and only two block commands:
-copy to/from main ram
-internal only copy, conditional on source value (transparency), optional conditional on destination value range (could define custom planes by assigning color palette ranges), optional trigger on destination value range (collision detection)