• Please review our updated Terms and Rules here

Reprogrammable ISA card?

Malvineous

Experienced Member
Joined
Jun 18, 2010
Messages
119
Location
Brisbane, Australia
Hi all,

I was looking at the XT-IDE project this morning and it got me thinking. (But please excuse my ignorance, I'm no expert in any of this!)

Would it be possible, or even worthwhile, to create an embedded system (like a router with an ARM CPU, for example) and build it onto a card that could be inserted into an ISA slot? If the ISA signals were routed into the embedded processor, it would be possible to run some code on the processor which could then directly interact with the ISA bus.

What I am imagining is a card you insert into an ISA slot, and it has a USB (or even an Ethernet) plug on the back. When power is applied, the card downloads firmware from a host machine and starts running it. That firmware is a program which controls how the device works. You could have firmware that makes the card appear as a hard drive controller, and the card accesses a disk image on a remote PC and makes it appear as a local disk. You could load different firmware that makes the device behave as a sound card, but it streams the audio back over the USB/network for playing/recording on another PC. Another firmware program could make the card appear as a display adapter, sending the display output to another PC. You could make it appear as a network card, with IPX support running from a ROM so you don't need to load any network drivers.

If it were possible to do this, it seems like it could be a really versatile device. Does anything like this already exist? Would anyone even want something like this?

Does anyone know whether normal memory read and write operations were sent over the ISA bus? Or was that direct from the CPU to the RAM? The reason I ask is that another use for a device like this could be to debug a running machine. You could watch all the traffic on the ISA bus live on a remote machine, read and write to memory locations and I/O ports, and so on. If all memory reads and writes went over the ISA bus, then these could be monitored too, triggering an action if a certain memory location was accessed or changed. From reading some ISA info, it sounds like you can become the bus master to effectively pause the CPU in response to something like this, allowing you to alter values in memory before letting the program continue to run.

I think this could be a very useful tool, but I don't really know enough about any of it to know whether it would be possible. Would it, or does the ISA bus work in a completely different way to how I think it does?

Thanks!
 
There are certainly ISA cards where you download firmware onto them.
The biggest problem I see is that for what you're describing, the electrical specs of the signal are very different. VGA would need high-frequency, 50 Ohm impedance lines. Audio, low frequency 20 k impedance, MFM, digital, with some lines following RS422, 10baseT would need high-frequency differential signaling digital lines, and so on. Trying to come up with one circuit to handle all those different specs would be a challange.
On PC's, the memory is in fact connected via the ISA bus, so normal read/write is sent over the bus. However, there's a set of tools known as ICE's, (In-Circuit-Emulator) that plug into the 8088 socket, which let you capture everything. The debugging action of pausing, changing memory, continuing, can also be done via a single-step interrupt.
Your ISA bus monitor idea is pretty cool, though. If it were cheap enough, I'm sure lot's of folks would be interested.
patscc
 
Re disk image over the network; personally I think we can achieve that already with an 8-bit Ethernet NIC and an XTIDE Universal BIOS extension to support ATA over Ethernet. Server components are readily available.

Re debug, yes that's possible to an extent. Every slot (except PC/XT slot 8 ) includes both address and data bus lines and the command lines (IOR/IOW, MEMR/MEMW). How much of system memory access is visible depends on the rest of the system though.
 
Last edited:
Thanks for your thoughts! Just to be clear I'm not proposing to create a universal ISA card with many different plugs on it, for exactly the reasons patscc describes. But the card could appear as if it were one of these types, to the machine it is plugged in to. Using the video card as an example, it would provide all the video BIOS routines, but of course it would lack a connector to plug a monitor in to. The card would have to store the data written to video memory and pass it back to the host PC over the built in USB or Ethernet connection for display there. I admit the usefulness here would be somewhat questionable, but some of the other ideas (like a driverless network card or the ISA bus monitor) could be more useful.

Rather than a universal ISA card, it would be more like an emulated ISA card, which could appear as anything (even multiple devices at the same time) depending on what code you run on it, but it would always be limited by only having a USB or Ethernet connection to the outside world.

Good to know that even system memory goes over the ISA bus, as that would make a snooping tool even more functional.

I didn't know that ATA over Ethernet was already possible, that's very interesting! However my interest in this project is less about competing with these existing specific devices, and more about getting a platform to experiment with the ISA bus. I would find it very interesting if you were able to design a "device" in a programming language like C, then run it on a real PC to see how it works.
 
At the risk of insulting you... are you familiar with VHDL and CPLD/FGPA type devices?
 
I know what they are, but I've never used them - I would like to learn though. My only issue with using something that needs VHDL is that it raises the barrier to entry for anyone who would like to experiment. I was thinking that if you used a CPU that could run a C program fast enough to do the interfacing with the bus, then anyone capable of writing a simple C program would also be capable of writing an emulated device.

Of course there aren't many CPUs with ~100 I/O ports, but many FPGAs have way more than 100, so it would certainly appear to be more practical with an FPGA. Maybe combining the two would be the way to go.
 
A FPGA to implement a register file and bus interfacing and an MCU with USB OTG interface to implement the back-end functionality is the best way to go.
 
Hmm, that's a good point. Using USB OTG would let you link to a host PC via USB, but you could also use a USB Ethernet device to connect to a network instead.
 
Back
Top