Interfacing old PC cards to homebrew 8-bit computer

[obiwanjacobi]

I am considering making an ISA interface onto my homebrew 8-bit Z80 computer.
The idea being that I perhaps may then reuse some of the old 8/16-bit ISA PC cards, like parallel ports, network and perhaps even video cards...? (I have some 8/16 bit parallel, serial and network cards)

I just have no idea how hard it is to reverse engineer these card to a degree that I could write the drive code for it, or if this type of information is freely available these days. Perhaps there is even the source code of one of these (x86) drivers to be found somewhere...?
Or perhaps there is one specific model (card) that has been cracked and choosing that one will enhance my chances of success?
Are there user groups / communities that do this sort of stuff?

I have found info on the parallel port - it's pretty basic and standardized.
Not so sure about video and network cards though...

Is this a path worth exploring or is it a waste because I am never gonna find enough info to get these (more complex) cards actually working?

Ideas?

[Kean]

There would be plenty of driver source code in open source operating systems like Linux or Open/FreeBSD.

[T3sl4co1l]

You have some advantage here because the binary "drivers" are already on the card -- the boot ROM.

Not that that's terrifically helpful to you, as it's x86, but, it's a starting point?

As for things that need OS device drivers, you'd have to port those to your OS API as well as the actual IO operations. If you have DOS drivers, you can still do some disassembly, but it will be that much more faffing...

Does you computer have all the bus operations that ISA supports/requires? Easy to inspect the card pinout and see if it needs them, only a little harder to substitute... Say if it needs DMA and you don't have it?..  Well, good luck...

Tim

[Ian.M]

IMHO you've missed the bus by about 15 years, and more like 25 if you want to interface to 8 bit XT bus cards.

8 bit cards are rare like hens-teeth and generally not particularly useful even if you have some.  e.g. good working monitors for pre-VGA graphics cards are rare and expensive (except CGA cards with composite TV out), and you'll have a hard time finding 8 bit network cards with even 10base TX - they are usually 10base2 or AUI or worse, something entirely proprietary and non Ethernet compatible.

Considering 16 bit ISA (AT bus) cards:
4:3 aspect ratio VGA monitors are getting harder and harder to find and most old VGA cards cant sensibly drive widescreen monitors.  Also the 8:16 bit bus conversion is going to be a real bottleneck - I would expect graphics modes above CGA resolution/bit-depth to be unusably slow, just due to the size of the bitplanes and the convolutions you will have to go through to map them in the Z80 address space.

Z80 <> ISA AT bus for PATA IDE used to be worth doing, but good PATA IDE drives are also getting rare, so you might as well bite the bullet and buy new CF cards and get guaranteed 8 bit mode support. 

Ethernet's just about possible, but its going to be a bitch porting the protocol stack to run on a Z80, and when you've done that you wont have enough memory or processing power left to do anything useful.   You'd be better off designing a Z80 fast hardware SPI port to access a WIZnet W5100 Ethernet controller as that has a built-in TCP/IP stack.

ISA sound cards might be fun, but they are likely to require DMA, although if you dust off the *REALLY* old 8 bit ones in your collection, you might find something that's usable without.

[T3sl4co1l]

FYI, my Amstrad PC has EGA on board, but still through 8 bits.  Of course it's in the full address space so the 128k is fully accessible.

To be fair, 640x350 is painfully slow to use for much graphics...

[obiwanjacobi]

So it either too much work to get working or not really usable if/when I have it working.
I was afraid of that 

I guess I have to find some other use for the ISA backplane I've got...

Thanks.

[woodchips]

How depressing, if you have missed by 15 years then what about my Burroughs accounting machines?

Get hold of a copy of the PC-XT, or PC-AT technical reference manuals, full of circuits, assembler code and everything else you need. Then make an informed decision.

There is also the ISA BUS technical reference from Intel which will tell you all you need to know about the 8 and 16 bit busses.

[Ian.M]

There's a considerable difference between a native 'retro' build using period appropriate parts, and hacking together an interface to build a Frankenstein machine.  IMHO legacy ISA PC cards are best used in a 'retro' DOS era PC build, though I admit I have a strong preference for the end of that era and Windows for Workgroups 3.11 on a 486.

I may have been a little too scathing about 8 bit cards.  *SOME* 8 bit cards are very useful. e.g there was a Maplin 8255 based 24 line I/O card,  or Microsoft Inport Mouse cards which with an adaptor could be used with any two or three button TTL level quadrature mouse, not just the original Microsoft one, and were the best way of adding a mouse to a pre-PS2 mouse motherboard if you had a slot free, or multiple COM port and LPT port cards.   All applications where 8 bit I/O wasn't a significant bottleneck and half or 1/3 length cards were always better for airflow in the case.

[David Hess]

There used to be some great books on this subject which included all of the ISA bus details.  The 8088/8086 datasheet and application notes along with the 82xx peripheral datasheets pretty much cover it.  On the card side, it comes down to an 82xx series peripheral chip and some external address decoding to drive the chip select line as needed.  You can literally make an ISA to IDE/ATA controller board with an address decoder and a couple of buffers and transceivers; I have done it.

[wilfred]

So it either too much work to get working or not really usable if/when I have it working.
I was afraid of that 

I guess I have to find some other use for the ISA backplane I've got...

Thanks.

There's no rule that says you have to find ISA cards to add a ISA backplane to your Z80.

[obiwanjacobi]

Get hold of a copy of the PC-XT, or PC-AT technical reference manuals, full of circuits, assembler code and everything else you need. Then make an informed decision.

I think I have scanned a couple of them, but I (remember I) could not find any details on how to address specific cards. I think I did saw LPT ports sample, but that is pretty basic.

There is also the ISA BUS technical reference from Intel which will tell you all you need to know about the 8 and 16 bit busses.

This one?
https://ia801602.us.archive.org/33/items/bitsavers_intelbusSpep89_3342148/Intel_ISA_Spec2.01_Sep89_text.pdf

There's no rule that says you have to find ISA cards to add a ISA backplane to your Z80.

I thought of designing my own bus based on the backplane I have -only a couple of pins are dedicated or have pullups- but I liked the idea of being able to reuse some of that old tech.

Another idea I played with was using the ISA bus (backplane) to create a multi CPU computer. I have a working core Z80 compute unit (lets call it that, it has only RAM, no storage and only serial IO) and thought that perhaps I could add one or two to do parallel tasks (like driving the video display). To that end I scribbled down a schematic that interfaces the Z80 compute unit(s) with a dedicated (bus) DMA controller (and a couple of bus registers: 74xx646) to the ISA bus. This should allow the Z80 compute units to talk to each other and to every IO card in the backplane.

There's a considerable difference between a native 'retro' build using period appropriate parts, and hacking together an interface to build a Frankenstein machine.

I am definitely making a frankenstein version here. Have a PSoC5 and a CPLD on there too.

[Berni]

If you are going for a Frankenstein build and have no software for any of the add in cards then indeed it might be easier to just build your own cards from scratch. You can still stick to the ISA bus specification so these cards can work in other machines provided someone writes a driver for it.

A lot of expansion cards have very little smarts on them. The old parallel ports are mostly just a glorified GPIO register built from off the shelf logic. The serial cards just use a standard chip with standard register sets (Many chips use the same compatible registers, even todays modern SPI interface ones) and sound cards can be as simple as hanging a few resistors off a LPT port(Tho those are a pain in the ass to drive in software, so you probably just want a FM synth chip glued onto the memory bus and that's it). Something like a PATA IDE disk controller doesn't need much in the way of smarts in it (Its pretty much like a SD card with a giant parallel bus). You can essentially clone existing ISA cards and have both your clone or an original card work in there allowing you to mix your DIY cards with real ones.

The cards that are hard are things like video cards or advanced sound cards with wavetable synthesis support and all that. These will have big complex and proprietary drivers and are going to take a lot of effort to get working. But today FPGAs can implement such functionality pretty easily. So if you want a capable video card id just simply put a $30 FPGA chip on a ISA card and give it modern VGA output over a resistor ladder DAC. Making the FPGA present a raw framebuffer on the bus and draw it to the screen is easy to do. Adding a text mode for consoles shouldn't be hard and from there you can add extra graphics functionality as needed. For example those features a lot of home computers had but the PC didn't. Like sprites, color palletes, smooth scrolling, bitblit etc..

[obiwanjacobi]

When I have to build my own cards, I don't see the need to stick to the ISA standard. Chances of my 'cards' being reused is close to zero. I would rather implement another bus design I have been theorizing on, just to see if it would work.

The whole idea of reusing ISA video cards is because of my experimentation with the PSoC5 as a video controller, which -due to my lack of in-depth PSoC knowledge- was harder than I expected.
Could be that the PSoC5 just doesn't have the grunt to make a comfortable VGA processor, I did have some other ideas on that, but thought the PSoC5 could get me started in character mode anyway...

The simpler stuff, like parallel, serial IO and basic sound etc are not an issue to make indeed. VGA and network are, though...

(I have done some simple CPLD logic in VHDL but do not consider myself fluent enough to effectively implement an FPGA design - at least that would be quite a learning curve.)

[Berni]

That SAMBA bus in your link is meant more as a bus for use on ASICs and FPGAs rather than for card cages. It requires some digital smarts at every tap on the bus so every slot would need a chip next to it. The sort of bus only really makes sense if you have a lot of masters on a bus that all access different nodes on the bus.

Things like an ISA bus are well suited for how most computers work. Pretty much all old school buses that provide fast agile access to peripherals work the same way. Its a big pile of data and address lines along with a few control signals. This works great with a single master and is very fast. So unless you have a weird oddball use case your optimal design will end up looking much like a ISA or PCI bus. Basic peripherals are nothing more than memory mapped registers so a simple memory bus is all that's needed.

Im actually quite surprised about getting a Cypress PSoC chip to do VGA output using programmable logic. Im not familiar with those chips all that much but it feels like that's not quite what that miniature CPLD inside of it was meant to do. If you want to build a graphics card using a MCU then you are better off using a MCU that has what's commonly called a "LCD interface". Those basically have a simple "graphics mode only" video card inside that barfs out pixels in RGB format onto a parallel 24bit bus(8bit red 8bit green 8bit blue) from a place in RAM where a frame buffer sits. These are often used to drive high resolution color LCD displays, but can be turned into a VGA signal by simply sending it trough a R2R ladder DAC, or turned into HDMI/DVI via a converter chip. Often such MCUs also have a external memory controller that can memory map any external memory that looks like SRAM into the internal MCUs memory map (often useful when your framebuffer is too big to fit into internal RAM). But there memory controllers are always masters, so you can't use this to act as a memory slave for your Z80 to write into, so interfacing would have to be over some other method like bitbanged GPIO.

If you want to build a video card yourself id recommend getting a real FPGA from Altera/Intel or Xilinx. You already bit the bullet by learning verilog, the rest is the easy part of learning how the vendor specific tools work. The real deal FPGAs are very powerful and can easily pump out some VGA. They can also act like anything you want to the host CPU that is going to be using the video card. Just by changing the code in it they can go from looking like SRAM memory to looking like ISA card to looking like PCI card or to even looking like PCIe card. Tho if you want to have high resolutions (past 320x240) you might need to add external SRAM to your FPGA so that it can hold the whole framebuffer. FPGAs don't have much internal memory because the memory they have is heavily speed optimized. Best to buy a dev board with SRAM already on it. These FPGAs can also run DDR3 memory, but you don't want to go there right away as it can be complex.

[obiwanjacobi]

That SAMBA bus in your link is meant more as a bus for use on ASICs and FPGAs rather than for card cages. It requires some digital smarts at every tap on the bus so every slot would need a chip next to it. The sort of bus only really makes sense if you have a lot of masters on a bus that all access different nodes on the bus.

Yeah I know. But it would allow parallelism on bus level. I found that really appealing. Have not made it of course, just wrote and drew up some ideas on how to get a high level, smart bus interface. The bus would do all sort of higher level functions in order to allow interfacing with a lot of different techniques. I wanted from: bulk dump video bits -to- interface with an serial (uart) Arduino. Pretty wild and probably overly complex. Was fun to think it up though.

Im actually quite surprised about getting a Cypress PSoC chip to do VGA output using programmable logic. Im not familiar with those chips all that much but it feels like that's not quite what that miniature CPLD inside of it was meant to do. If you want to build a graphics card using a MCU then you are better off using a MCU that has what's commonly called a "LCD interface". Those basically have a simple "graphics mode only" video card inside that barfs out pixels in RGB format onto a parallel 24bit bus(8bit red 8bit green 8bit blue) from a place in RAM where a frame buffer sits. These are often used to drive high resolution color LCD displays, but can be turned into a VGA signal by simply sending it trough a R2R ladder DAC, or turned into HDMI/DVI via a converter chip. Often such MCUs also have a external memory controller that can memory map any external memory that looks like SRAM into the internal MCUs memory map (often useful when your framebuffer is too big to fit into internal RAM). But there memory controllers are always masters, so you can't use this to act as a memory slave for your Z80 to write into, so interfacing would have to be over some other method like bitbanged GPIO.

Yeah that sort of is what that design is about, although I was set on using the EVE chip. Not so sure about that now. I got a feeling that a 180MHz STM32F4 would be plenty strong for some light VGA work. Must have misted the LCD display interface option. Will look at that again. The idea of the video controller was to provide a 'smart IO device'. This would allow using a protocol to convey the intent and not the bits to pass on the result... Which would cut down in needed bus bandwith. Higher level function in the video controller (STM32) would allow common graphic operations (scrolling/transparency and the likes). The external RAM would be a place for the program to store graphics (once) to be reused throughout the running program. Aim was to build a retro game console like platform.

If you want to build a video card yourself id recommend getting a real FPGA from Altera/Intel or Xilinx. You already bit the bullet by learning verilog, the rest is the easy part of learning how the vendor specific tools work. The real deal FPGAs are very powerful and can easily pump out some VGA. They can also act like anything you want to the host CPU that is going to be using the video card. Just by changing the code in it they can go from looking like SRAM memory to looking like ISA card to looking like PCI card or to even looking like PCIe card. Tho if you want to have high resolutions (past 320x240) you might need to add external SRAM to your FPGA so that it can hold the whole framebuffer. FPGAs don't have much internal memory because the memory they have is heavily speed optimized. Best to buy a dev board with SRAM already on it. These FPGAs can also run DDR3 memory, but you don't want to go there right away as it can be complex.

Yes I would love to build a VGA video card using an FPGA. I do not think I have learned VHDL yet, that code was painstakingly put to gether with about 2-searcher per line  . I used Quartus to make the (Altera) CPLD code. Didn't understand the simulation yet, though. Anyway, can't decide if using the STM32 or the FPGA is a better choice. I am fairly inexperienced in both... (I do have an STM32F4 and an Altera Cyclone II laying around)

To go a little back on topic: I think the consensus is that using an ISA video card is pretty much hopeless, unless I have a detailed example of how the driver works...?

[Berni]

Yeah that sort of is what that design is about, although I was set on using the EVE chip. Not so sure about that now. I got a feeling that a 180MHz STM32F4 would be plenty strong for some light VGA work. Must have misted the LCD display interface option. Will look at that again. The idea of the video controller was to provide a 'smart IO device'. This would allow using a protocol to convey the intent and not the bits to pass on the result... Which would cut down in needed bus bandwith. Higher level function in the video controller (STM32) would allow common graphic operations (scrolling/transparency and the likes). The external RAM would be a place for the program to store graphics (once) to be reused throughout the running program. Aim was to build a retro game console like platform.

Well one of the products i designed uses a STM32F7 to drive a 640x480 LCD with 16bit colors while using 32MB of SDRAM to get more room to work with. It did need some optimization from the software guys to get it to run fast but it is perfectly capable of drawing a decent looking UI at that resolution with good responsiveness. Its being helped out by its built in 2D DMA that can move bitmaps around in memory and draw them onto frame buffers. Its pretty capable.

But the functionality you are describing is actually more of a graphics accelerator than a video card. For a long time graphics cards in PCs never had any actual processing power. They would simply pump the video memory out to the screen. The most advanced processing they could do is a character map lookup or a color palette lookup. The main CPU still had to set each pixel one by one by writing to video memory. This is the reason why PC games looked like shit while being outdone by other home computers with less processing power while gaming consoles looked amazing in comparison. All of those computers with games in mind had crude 2D graphics accelerators hidden inside graphics chip. They would commonly draw sprites and titlemaps live from memory as it was drawn, so that the CPU only needed to update sprite coordinates or titlemap IDs while providing offset functionality to allow for smooth scrolling. All of this functionality is implemented on a hardware level and can take a good deal of CPU grunt to perfectly emulate since its drawn as fast as the CRT can refresh.

Yes I would love to build a VGA video card using an FPGA. I do not think I have learned VHDL yet, that code was painstakingly put to gether with about 2-searcher per line  . I used Quartus to make the (Altera) CPLD code. Didn't understand the simulation yet, though. Anyway, can't decide if using the STM32 or the FPGA is a better choice. I am fairly inexperienced in both... (I do have an STM32F4 and an Altera Cyclone II laying around)

Well an FPGA will provide more graphics horsepower when used correctly as video processing is what these chips are very good at, able to move massive amounts of pixels and do all sorts of things to them without slowing down at all. The advantage is that FPGAs can work on data as its moving trough it in a pipelined fashion, applying 10s or 100s or even >1000 operations to the data in a single clock cycle, pretty much only limited in speed by how fast it can be fed new pixels from RAM. Additionally the flexibility of the FPGA allows it to provide any interface  to the outside, no matter how weird of a bus it is. This lets it connect to a Z80 as just another thing on its system bus, making for fast low latency access to the FPGA that is just as quick as reading from main system RAM.

On the other hand a ARM microcontroller is forced to work on an image pixel by pixel, applying every operation step by step. This limits how much pixels it can push. Also since there is no native slave memory interface means that talking to the Z80 also takes up CPU time. Tho if you just want to emulate the graphical capabilities of a old home computer its still plenty fast enough. But getting SNES level graphics out of it might be tough work.

To go a little back on topic: I think the consensus is that using an ISA video card is pretty much hopeless, unless I have a detailed example of how the driver works...?

Yeah its way too hard to be worth it. You can replicate the "braindead barfing out pixels from video RAM" functionality of old PC video cards on a FPGA or properly equiped MCU within a day of work.

To get the fancy smart autonomous pixel drawing abilities you need to step up to the Penium era of 3D graphics accelerator cards.

[David Hess]

Another place to look for details on ISA interfacing are application notes which discuss interfacing Intel 82xx series peripherals to Z80 processors.

[obiwanjacobi]

@Berni: Yeah more accelerator like, indeed (although I see it as a layer on top of a generic video card). I like the parallel nature of the FPGA (many bits at the same clock cycle) but I fear having to implement (more) complex algorithms in logic. I know it can be done, I just don't know if I can do it.
I am a software dev so programming a STM32 MCU would be (way) less of problem in that aspect. Also these MCU's come with nice external memory interfaces, that have to be implemented in the FPGA separately (I do not mind looking at sample code, but I really like to understand all code I add to my project - which would mean delving into interfacing synchronous dram - I don't know much about yet).

Another place to look for details on ISA interfacing are application notes which discuss interfacing Intel 82xx series peripherals to Z80 processors.

What app notes would that be then? Would that be the app notes of say the 8237 DMA controller - or would it be more Z80 related.
(a quick search did not yield any usable datasheets that had app notes)

[David Hess]

Another place to look for details on ISA interfacing are application notes which discuss interfacing Intel 82xx series peripherals to Z80 processors.

What app notes would that be then? Would that be the app notes of say the 8237 DMA controller - or would it be more Z80 related.
(a quick search did not yield any usable datasheets that had app notes)

The ISA bus was based on the 8088/8086 bus which directly interfaced with the older 82xx series peripherals which were for the 8080.  I know I have seen application notes about using these peripherals with the Z80 but practically everything is pre-web so difficult to find now.  The 8255 Programmable Peripheral Interface, 8254 Programmable Interval Timer, and 8251 Communication Controller (UART) were popular targets.

This example sort of shows how simple it is with an 8255.

I have a great book on the ISA interface but it is in storage and I have not been able to find it online.

[Berni]

Yeah an ISA bus looks much like SRAM memory. The simplest and most widespread of memory busses, most buses from the era look similar.

If you plan to implement complex functionality in your graphics accelerator then it will indeed be easier to implement using C code in a STM32. Getting the external memory controller up and running on a STM32 is also not very hard, just initialize it and set the correct timings and boom the external memory is part of the internal memory map. But keep in mind that this memory controller will only be usable to let the ARM CPU read and write some external SRAM or SDRAM memory. It will not be usable to for interfacing to a Z80 bus because the STM32 memory controller can only act as a master and not a slave. For the Z80 to talk to it you with need to connect your STM32 trough something similar to a LPT port that the STM32 drives with bitbanging, or implement some glue logic to adapt the timings of a Z80 bus to something the STM32 can drive trough GPIO pins in software. But a 10MHz Z80 will likely be able to execute read/write operations to the STM32 faster than it can respond to them in software so you might need to stick some NOPs around your graphics driver. Usually computers want a very fast interface to the graphics card (Hence why we kept sticking graphics card in special buses that are faster than all others).

The memory interface to the Z80 with a FPGA is easy because it can instantly respond on the bus, and such vintage CPUs have very simple buses so its not hard to implement. As for memory controllers to run external SRAM frame buffer thats also very easy to do as you simply output an address on the pins and the data shows up on the data pins. Its the other stuff connected to the memory controllers and bridges that can become complex in a FPGA. You basically end up with another system bus inside your FPGA where the various modules sit on and talk to each other, so you need a switch fabric inside that routes the data around as needed, manages arbitration and priorities etc (Tho Altera has tools that automatically build this part for you) and of course the graphics accelerator itself where implementing complex functionality could become a lot of work.

Since i assume its a hobby project, just do whatever sounds more fun to you.

[woodchips]

Yes, that looks like my ISA bus specification.

The ISA bus is simple, can't get it any simpler, so just use it with just about any chip that has a /WE and /RD pins, not R/W like Motorola.

The PC bus has allocated memory areas for different functions, network, video etc which is why you won't see it mentioned, it is assumed.

[David Hess]

Yeah an ISA bus looks much like SRAM memory. The simplest and most widespread of memory busses, most buses from the era look similar.

It is practically the 8080/8088/8086 bus so Z80 interfacing to ISA looks pretty trivial.  I do not remember if the original PC buffered the ISA bus from the microprocessor bus but this is easy enough to do.  I think latches or flip-flops are needed in some cases for demultiplexing but it has been a long time since I have done it.

[james_s]

There's a considerable difference between a native 'retro' build using period appropriate parts, and hacking together an interface to build a Frankenstein machine.  IMHO legacy ISA PC cards are best used in a 'retro' DOS era PC build, though I admit I have a strong preference for the end of that era and Windows for Workgroups 3.11 on a 486.

I may have been a little too scathing about 8 bit cards.  *SOME* 8 bit cards are very useful. e.g there was a Maplin 8255 based 24 line I/O card,  or Microsoft Inport Mouse cards which with an adaptor could be used with any two or three button TTL level quadrature mouse, not just the original Microsoft one, and were the best way of adding a mouse to a pre-PS2 mouse motherboard if you had a slot free, or multiple COM port and LPT port cards.   All applications where 8 bit I/O wasn't a significant bottleneck and half or 1/3 length cards were always better for airflow in the case.

That reminds me, when I was about 14 I built an IO card based on a 8255, I think I found it in a magazine because there was no internet back then. I learned a ton of stuff playing with that thing, of course now you'd just do all that with an Arduino which is probably a lot more capable.

[digsys]

I was making cards for the ISA bus right up to 2003+ - mainly multi-comms > RS485, fiber > up to 4Mb. Used Altera CPLDs to do all the main bus decoding /
interfacing. Life was so easy, being able to "talk" directly to any IO on the MBoard
https://pbase.com/digsys/image/169402784
https://pbase.com/digsys/image/169402785 way earlier

[obiwanjacobi]

Yes, I understand how to interface SRAM, that's easy. I was thinking of SDRAM in order to have bigger video buffers (mutiple MBs) to store graphics for the program, where the higher graphics functions (in the accelerator) can reach them... Doing that in an FPGA sounds complex.

About interfacing the Z80 to the ISA bus: I read that other cards can take ownership of the bus and that process goes through the DMA controller - to be honest, I did not fully understand that process - but then I have read the text only one or two times (I can be a bit slow sometimes  ).
I do have a System Controller (PSoC5) that also plays DMA controller - perhaps I can reuse that for the ISA bus. However only have a few pins left to play with.
[My setup is a bit unusual (see signature link for more info): no ROM (yet), max 1MB RAM. So at boot time the System Controller halts the Z80 and waits for serial commands from the PC. You load your program from the PC interacting with the monitor in the System Controller. When all is set, you release the Z80 and of it goes. I also support simple debugging (breakpoints and reg dumps) and you can pause the Z80 at any point.]

Question is -the topic of this thread- is it worth it to spend the effort if I cannot -realistically- reuse old PC ISA cards?
(I guess not)