Do yourself a favor and get both your proto boards from circuit specialists. None of those hobby companies offer hard gold on the edge connector which is *very* important on something like a proto card that will be cycled many, many times.

Can you get away with running wires to a breadboard? Probably, ISA stuff is pretty slow. But you are defeating the purpose of the proto card. Just solder the components in and rearrange as needed.

I personally don't think shit of wire wrapping, if you lack confidence in your ability to solder and desolder repeatedly without damaging stuff I think you should spend some time on tools and technique before worrying about design.

Microcontroller will not be fast enough to capture ISA cycles and do other stuff too so you'll want an address decoder that decodes at least one IO port and some buffers to hold data for both way comms.
Writes from the ISA should get stored in an 8bit FF (574) and optionally generate an interrupt for the MCU so it knows to grab the byte, and another port that gives ISA whatever MCU had previously written (574+245). This takes away all the timing sensitivity from the process. For more stuff you'll quickly need many more chips and CPLD or FPGA becomes necessary...

Handling DMA and bus mastering is a lot more effort and you should start looking at CPLDs or FPGAs since a good handful of logic chips are necessary to do those functions.

Tiido wrote on 2020-12-22, 18:52:

Handling DMA and bus mastering is a lot more effort and you should start looking at CPLDs or FPGAs since a good handful of logic chips are necessary to do those functions.

I figured I would be writing some Verilog eventually (sorry VHDL fanboys). A CPLD or FPGA would greatly reduce the component count on the board as well. The question is, for 40 KiB / sec of continuously streamed data, which is better, 16-bit DMA or bus mastering?

Maybe I'm overthinking this. 16-bit DMA on the PC/AT maxes out at 1.6 MiB/s, and with the 64 KiB (or is it 128 KiB in 16-bit mode?) size limit per transfer, even one second's worth of data can be DMA'd in one go, taking only ~2.4% of the available time. DMA looks easier to implement, and if it takes fewer gates, that could mean fitting it all in a CPLD instead of an FPGA.

Normal DMA is gonna be lot less headache because all the work is done by 2 signals and bandwidth will not be a problem for this little data.

Bus mastering is more complicated on both software and hardware side, and I imagine there will be chipset related difficulties too. It probably can be done faster though as it should be able to handle CPU memory cycles timing which is faster than IO cycle timing. With a CPLD or FPGA in the mix you probably get to try it out too assuming you have bidirectional buffers for the address bus and all the control signals...

Tiido wrote on 2020-12-22, 20:50:

Bus mastering is more complicated on both software and hardware side, and I imagine there will be chipset related difficulties too.

Extremely strong agreement with this point. Just try to dig up how many discussion threads there were in usenet about problems with the AHA1542 SCSI controller, the most wide-spread busmaster ISA DMA card. And that is with a lot of engineers and compatibilitly testing at Adaptec. Busmastering ISA needs an extremely good understanding of all the fine details of the ISA bus, as well as understanding the quirks of the mainboard(s) the card is going to be used in. If you want to do busmastering *for the challenge*, go ahead and do it. But if you goal is getting a working card quickly, busmastering is the one ISA feature I strongly suggest to avoid. If you try busmastering as the only option for the card, there is a significant risk that the card project fails due to difficulties getting busmastering done correctly. If you still prefer busmastering, because its the "technological better" version, do your project in two steps: In the first step, design your card with 16-bit ISA DMA, and only if that works, make a second version that uses busmastering. Both steps might be around the same amount of work. If implementing busmastering fails, you still have a working (although less "advanced") card you can use for the intended purpose.

most of the problems from bus mastering ISA cards are attributable to the fact that ISA can only address 16MB of RAM

the other main problem with bus mastering with the 1542 was that it doesn't respect the MEMCS16# assertion (or lack thereof as it were) for parts of the UMA, which makes trouble if you have EMS on an 8 bit card

mkarcher wrote on 2020-12-23, 18:19:

Tiido wrote on 2020-12-22, 20:50:

Bus mastering is more complicated on both software and hardware side, and I imagine there will be chipset related difficulties too.

Extremely strong agreement with this point. Just try to dig up how many discussion threads there were in usenet about problems with the AHA1542 SCSI controller, the most wide-spread busmaster ISA DMA card. And that is with a lot of engineers and compatibilitly testing at Adaptec. Busmastering ISA needs an extremely good understanding of all the fine details of the ISA bus, as well as understanding the quirks of the mainboard(s) the card is going to be used in. If you want to do busmastering *for the challenge*, go ahead and do it. But if you goal is getting a working card quickly, busmastering is the one ISA feature I strongly suggest to avoid. If you try busmastering as the only option for the card, there is a significant risk that the card project fails due to difficulties getting busmastering done correctly. If you still prefer busmastering, because its the "technological better" version, do your project in two steps: In the first step, design your card with 16-bit ISA DMA, and only if that works, make a second version that uses busmastering. Both steps might be around the same amount of work. If implementing busmastering fails, you still have a working (although less "advanced") card you can use for the intended purpose.

You've convinced me! DMA it is.

Looking at the Snark Barker schematic, why does it run the IOR and IOW signals from the ISA bus into AND gates, where the other input is just a pull-up resistor to 5V? The resulting RD and WR signals should be logically identical to the IOR and IOW signals. Is it there for amplification or bus isolation, if there were a bunch of cards on the bus for example? More modern ISA cards with single custom chips just connect to IOR and IOW directly.

LightStruk wrote on 2021-01-25, 17:26:

Looking at the Snark Barker schematic, why does it run the IOR and IOW signals from the ISA bus into AND gates, where the other input is just a pull-up resistor to 5V? The resulting RD and WR signals should be logically identical to the IOR and IOW signals. Is it there for amplification or bus isolation, if there were a bunch of cards on the bus for example? More modern ISA cards with single custom chips just connect to IOR and IOW directly.

Yes, it is for amplification. Classic TTL chips (74xxx, 74Sxxx, 74LSxxx, but not 74HCxxx) have inputs that pull the signal up. So the more inputs you put in parallel, the stronger the combined pull-up is. The main board is specified to be able to drive two 74LSxxx chips per ISA bus card, so if you don't resort to CMOS logic chips, you may only connect two chips to each of /IOR and /IOW. The snark barker uses considerably more than two gates on /RD and /WR, so it needs amplification.

Those single-chip cards might very well have a buffer for /IOR and /IOW integrated, or they use CMOS logic that doesn't inherently pull inputs up, so dedicated buffering is no longer needed.

hows the isa design going? I'm kicking around doing some, I want to convert the 1mb ram card and 2mb ems card into 1 card, but my goal is to enable the framing to be lower than the lo-tech allows, and I want to allow the 1mb ram to be selectable by 8kb chunks rather than lotech designs 64kb chunks..

mostly my goal is to maximise ram space on my tandy, allocating the ems frame at 0xA000 would free up C000 through to EFFF, and I could then reassign xtide to 8kb at c000, so I'd have a contiguous umb space of 160kb.. right now I loose 64kb at C000 because of an 8kb ROM, and the EMS is at E000, so I only get 64kb at A000 and 64kb at D000...

its a bit of a pipe dream but should be quite doable, but its low on my design project list.

BloodyCactus wrote on 2021-01-26, 01:06:

hows the isa design going?

Not so bad, so far. I have the necessary ICs laid out on my KiCad schematic, and just a few more wires and labels to add. There's a LOT left to do. I have microcontroller code to write, a DOS TSR to hack, a PCB to layout, a board to stuff, and many cycles of debugging ahead before I succeed.

I've found the ISA Bus Timing Diagrams PDF to be quite helpful.

LightStruk wrote on 2020-12-22, 20:22:

Maybe I'm overthinking this. 16-bit DMA on the PC/AT maxes out at 1.6 MiB/s, and with the 64 KiB (or is it 128 KiB in 16-bit mode?) size limit per transfer, even one second's worth of data can be DMA'd in one go, taking only ~2.4% of the available time. DMA looks easier to implement, and if it takes fewer gates, that could mean fitting it all in a CPLD instead of an FPGA.

128KB boundary in 16-bit mode, 64KB in 8-bit mode. If you only need 40KB/sec then even 8-bit DMA would be reasonable. But either way, when doing a large block transfer you need to relinguish the bus at least every 15us for memory refresh.

BTW, what kind of software support do you plan for the card? I don't know what your application is, but I was just thinking that since bus mastering is initiated by the card then it can be used to read/write memory at will, regardless of the software that happens to be running. That might be useful for a hardware debuggeror who knows. But using 8237 DMA means you'll need a program to set it up, and if you're going to write such a program anyway then it might be even easier to just generate an interrupt and have the CPU transfer the data using a REP OUTS instruction.

bakemono wrote on 2021-01-26, 18:08:

If you only need 40KB/sec then even 8-bit DMA would be reasonable. But either way, when doing a large block transfer you need to relinguish the bus at least every 15us for memory refresh.

If you use just 40KB/s, you are most likely going to use single mode DMA. Single mode DMA relinquishes the bus after every transfer (byte/word). Even in block and demand mode transfers, the controller suspends a transfer for refresh cycles. Of course this means that the DMA controller needs to acquire the bus for every cycle, so there might beExpect some latency after asserting DREQ before the DMA controller gets the bus and has no pending higher priority transfer. The byte is available as soon as DACK is asserted. The "release the bus after 15us" rule is most important forapplies only to bus masters, but busmastering has already been dismissed as too difficult.

EDIT: strike through applied to misleading statements, added clarifications in italics.

mkarcher wrote on 2021-01-26, 18:14:

If you use just 40KB/s, you are most likely going to use single mode DMA. Single mode DMA relinquishes the bus after every transfer (byte/word). Of course this means that the DMA controller needs to acquire the bus for every cycle, so there might be some latency after asserting DREQ before the DMA controller gets the bus. The byte is available as soon as DACK is asserted. The "release the bus after 15us" rule is most important for bus masters, but busmastering has already been dismissed as too difficult.

My primary concern is starving the system. If my card occupies the ISA bus for a large fraction of the available time, because DMA slows down the bus to 4.77 MHz, then that's a lot of time that the rest of the machine will struggle to do useful work, particularly on pre-VLB or pre-PCI systems. Am I missing something?

As for the transfer mode, I was under the possibly mistaken impression that it's not the peripheral's job (or the software's job) to break up the DMA transfer, single or block, to make room for REFRESH cycles. If that were true, then the limit of 64 KiB per transfer would be way too high, because you'd never get 64 KiB transferred in 15us!

LightStruk wrote on 2021-01-26, 19:12:

mkarcher wrote on 2021-01-26, 18:14:

If you use just 40KB/s, you are most likely going to use single mode DMA. Single mode DMA relinquishes the bus after every transfer (byte/word). Of course this means that the DMA controller needs to acquire the bus for every cycle, so there might be some latency after asserting DREQ before the DMA controller gets the bus. The byte is available as soon as DACK is asserted. The "release the bus after 15us" rule is most important for bus masters, but busmastering has already been dismissed as too difficult.

My primary concern is starving the system. If my card occupies the ISA bus for a large fraction of the available time, because DMA slows down the bus to 4.77 MHz, then that's a lot of time that the rest of the machine will struggle to do useful work, particularly on pre-VLB or pre-PCI systems. Am I missing something?

As for the transfer mode, I was under the possibly mistaken impression that it's not the peripheral's job (or the software's job) to break up the DMA transfer, single or block, to make room for REFRESH cycles. If that were true, then the limit of 64 KiB per transfer would be way too high, because you'd never get 64 KiB transferred in 15us!

Don't worry about starving the system. 40KB/s is the same transfer rate as the floppy controller uses while reading or writing high-density (1,44MB) floppy disks. The same is true for the Sound Blaster 2.0 or Sound Blaster Pro. Both of these systems also use single-mode DMA, which is the easiest but least efficient transfer mode. Neither floppy access nor the Sound Blaster starve systems in a significant way. The DMA controller in AT-class machines runs at half the ISA bus clock, typically 8 or 8.33MHz, so DMA clock is 4 or 4.16MHz, even lower than the 4.77 of the original PC/XT. A single-mode cycle takes four DMA cycles (IIRC, maybe 5), which is 1 microsecond. 40KB/s means you need a byte every 25µs. This means the bus utilization is around 4%.

You are right that even in block mode, refresh is handled by the DMA controller. That's why the IBM PC has refresh on DMA channel 0 (highes priority). A pending refresh cycle will interrupt a block mode transfer on DMA1 to DMA3. But that's not the case for AT busmaster transfers, though. In the case of busmaster transfers, the bus keeps being assigned to the master until the master deasserts /MASTER. So bus-master cards need to actively release the bus after at max 15µs.

I've completed my first draft of the schematic, and for fun, I did a preliminary PCB layout and autorouted the traces. I made it all fit on a 2-layer PCB, half-height / low-profile expansion card. That said, it's a little bit crowded.

Which makes me think - if this were a PCI card, then sure, there are lots of slimline PCs that benefit from low-profile PCI cards. But is that a thing for older PCs? Are there any slim AT class computers that used low-profile ISA cards, or did they all just use riser cards to make the expansion cards horizontal?

There were ISA microATX motherboards that people put in low-profile cases. I’ve seen quite a few of those.

I dunno if any major OEMs created systems with low-profile ISA slots, in any significant numbers, though.

- Alex