List of tested ISA cards

[kuenzign]

This looks like a great project and it's very exciting. I think that in order to gain more support from the community, it would be a good idea to provide a list of cards that have been tested with the ISASTM (showing which cards do not work and cards that do work). Personally, I have been hoping that ISA floppy controllers would work, but that's probably a bit of a pipe dream. Thanks for the hard work!

[Manawyrm]

Hey,

so, in general every 8bit ISA card is able to be supported. There are 2 main issues: a) real-time operation b) USB latency / frame-timings

The other issues like missing/very broken DMA support are just software problems and could be fixed in the firmware.

The lack of real-time operation (because the emulator isn't always running at 100% CPU speed and can vary it's frequency by quite a bit) is normally not an issue, but for specific applications like measurements, motor control (think old CNC machine controllers, etc.) this will be a big issue. I don't see any way to support this kind of device.

The USB standard requires a minimum frame time of 1ms per frame (125µs for USB 2.0 HS), which means you will need at least 2ms for a single byte transfer. Writing data can be done a lot more efficient/faster with clever coding, but reads are always bottlenecked by this.

I have successfully used:

• a floppy controller card (with a flash floppy USB emulator thingy)
• a serial port card
• a parallel port card
• a port 80h diagnostic card
• several sound blaster card (using the AdLib functionality)
• a Creative Gameblaster card
• several VGA cards
• a RTL8019 network card

Things that don't work (and why):

• Sound Blaster (digital sound, needs properly working DMA support, pretty sure fixable)
• IDE controller cards (need upper 16bit IRQs and 16bit data for ATAPI commands, no supported by hardware)

In general, the USB idea was pretty okay for a proof-of-concept, but if you would want to actually use this thing for any real usage, the board would need to be redesigned to use something like an FPGA and use a bus like PCI. Talking via Thunderbolt/PCIe/PCI to a media bridge and letting it map the ISA bus 1:1 would work much, much better. Interrupts could be handled as MSIs, DMA would just be done as writes/reads to a mailbox (probably?!).

But I don't think I'm going to implement that anywhere in the near future.

[toncho11]

Hi,

Great project!

So how does it work exactly? I want to use a 360 KB floppy and controller on Windows 10. So I need to build and put your card and the floppy controller on an ISA backplane. But then we need a Windows driver that will emulate the floppy on Windows? This part I do not understand.

[Manawyrm]

Hi toncho,

this project is converts a set of USB messages to actions on an ISA bus. In theory, yes, you could build a Windows driver for it. I don't think that's a useful thing, though.

What you'd do is start an emulator (like PCem) and do your work in there (with the "real" floppy being pass-through).

The project is not a point where it is usable for any proper work, at all, though. I would NOT recommend you go build one of these, unless you want to find out every single little detail about the ISA bus.

If you want to work with floppy drives, use Greaseweazle, KryoFlux or similar: https://github.com/keirf/Greaseweazle https://www.kryoflux.com/ They are easier to assemble and will do what you need, much better and easier.

[laf0rge]

I have a number of questions about this project, and since there seems to be no mailing-list or forum, I'm hijacking this github issue for it..

so, in general every 8bit ISA card is able to be supported. [...]]

Is there a specific reason to go for 8-bit ISA only? The rather high-end microcontroller chosen should have plenty of additional I/O pins around?

The USB standard requires a minimum frame time of 1ms per frame (125µs for USB 2.0 HS), which means you will need at least 2ms for a single byte transfer. Writing data can be done a lot more efficient/faster with clever coding, but reads are always bottlenecked by this.

The question here is whether 125us (x2) is "good enough" for most use cases or not. Sure, FS-USB 2ith 1ms (x2) is probably stretching it a bit too far for any but the most trivial use cases.

In general, the USB idea was pretty okay for a proof-of-concept, but if you would want to actually use this thing for any real usage, the board would need to be redesigned to use something like an FPGA and use a bus like PCI. Talking via Thunderbolt/PCIe/PCI to a media bridge and letting it map the ISA bus 1:1 would work much, much better. Interrupts could be handled as MSIs, DMA would just be done as writes/reads to a mailbox (probably?!).

That's of course a completely different complexity (schematics, layout, cost, ...), and a bit overkill for the good old ISA, IMHO.

btw; any spcific reason for putting 32MiB of SDRAM in the design? The use case of translating small MMIO / PIO transactions between USB transfers and the ISA bus doesn't really look like anything that would be very memory-heavy. Just trying to find the reason for the design decision to understand the project better.

Thanks!

[Manawyrm]

since there seems to be no mailing-list or forum

True, I have a nasty habit of abandoning projects after I get bored with them :laughing: But you know my Twitter account and IRC handle :)

Is there a specific reason to go for 8-bit ISA only?

Yes, it's a 4-layer board and back then going over 10x10cm was very expensive (for a hobby project) at JLCPCB. I think that's changed by now, so a second revision might be useful.

The question here is whether 125us (x2) is "good enough" for most use cases or not.

Yes, but USB 2.0 is broken on the card. I'm still not a fan of USB, but I'm fairly certain that the STM32 is incompatible with the USB PHY due to a hardware bug. There are other ULPI PHYs that should be compatible (USB3300 maybe? untested.).

I wanted to do "retro fun" stuff like attaching VGA cards and sound cards via USB, especially VGA scrolling via 1ms latency was getting very painfully slow. For stuff like machine control, sensor aquisition, etc. it might be perfectly fine? Just a small caveat: IRQ support is experimental at best, DMA support is practically non-existant. I/O works pretty well.

any spcific reason for putting 32MiB of SDRAM in the design?

Yes! :smile: We've ported a full 486 emulator onto the plattform and were able to get the card to run a "full" computer all by itself. Unfortunately, it only boots into the BIOS and it fails after the memory check (which only goes up to 640KB, although 4MB are available). I think it's something to do with 32bit alignment, but I wasn't able to figure out what the exact issue is.