mkarcher wrote on 2020-09-05, 19:35:

Some video BIOSes might use 16-bit I/O instructions to write to indexed registers. You need to split them in the same way as 16-bit memory writes.

I have put an assert() on any 16bit I/O writes but haven't seen any yet.

Haven't made progress with the topic so far and I'm beginning to think that I still have an underlying hardware or firmware issue.

I've put an ISA Post diagnostic card in the board:

and wrote to 0x80 and that works like it should, so basic I/O seems to work fine *hm*

So,

I was wondering if my ISA implementation was somewhat sane. I had previously used an ISA serial port card succesfully.
I've ported the Linux isapnptools to use the same serialisa-layer the x86 emulator uses:

The result surprisingly is: working first try. I can read and set the Plug & Play configuration of any card I've tested.

Creative SoundBlaster AWE64 Gold:
https://gist.github.com/Manawyrm/53f4235fdef3 … stfile1-txt-L19

Aztech AZT2320 PnP:
https://gist.github.com/Manawyrm/2aba29f47594 … 8e71711d981b129

Which is very neat, because I can now play around with an AWE64 Gold as a standalone MIDI synth 😁

Still don't have a really good idea on what my VGA stuff is missing...

Here's the setup playing a VGM file from the ATmega2560's PROGMEM directly to the Adlib of the Aztech card.
My desktop PC is running isapnptools to initialize the card to it's correct I/O addresses (at 0x338 in this case) and then the ATmega2560 plays the VGM file internally.

The player is pretty rough and was quickly cobbled together, but still seems to work fine 😀

You can also see the OSC clock generation as well as the ultra janky -5 and -12V generation (with 2 reversed DC-DC isolators in series).

https://www.youtube.com/watch?v=HoJRgIH7HL8

(Sorry for the triple post... Is that ok?)

I can't speak for everyone else here, but I definitely don't mind the triple post. 😄 You're doing some pretty cool stuff here. I actually appreciate you updating us with your progress.

Do you think that this could eventually be used to develop some kind of ISA bridge (to USB or something) for modern systems that could then use ISA cards with DOS software running under a VM with a Hypervisor that would then use this to "pass through" the ISA cards, so to speak? And could it be made to work with DMA stuff as well? That would be great for sound cards!

digger wrote on 2020-09-06, 11:09:

Do you think that this could eventually be used to develop some kind of ISA bridge (to USB or something) for modern systems

That already works for some (non-timing critical) applications, I've quickly hacked my lib into PCem and can talk to the Aztech sound card from the VM. It's enough to get Adlib sound (but a bit stuttery, because of all the inefficient, non-optimized stuff, like ASCII protocols and the slow 16 MHz Arduino). It needs some pretty advanced I/O mapping configuation though, because you'll need to forward all calls to a specific set of addresses to the card (which is card-specific). Not to mention the mapping nightmare called Plug & Play 😁.

digger wrote on 2020-09-06, 11:09:

And could it be made to work with DMA stuff as well? That would be great for sound cards!

That would be really cool, yes! I haven't looked at how DMA works at all, so I can't tell you if it's possible.

Could this project be transferred to an STM32? They are 3.3V parts, but 5V tolerant and the 3.3V I/O voltage is 5V TTL compatible.
The higher processing power, integrated DMA peripherals and often integrated USB support would simplify a lot of things.

If 5V TTL compatibility is not sufficient, a couple of 74HCT buffers would solve that problem by providing CMOS output levels.

Benedikt wrote on 2020-09-06, 12:35:

Could this project be transferred to an STM32? They are 3.3V parts, but 5V tolerant and the 3.3V I/O voltage is 5V TTL compatible.
The higher processing power, integrated DMA peripherals and often integrated USB support would simplify a lot of things.

If 5V TTL compatibility is not sufficient, a couple of 74HCT buffers would solve that problem by providing CMOS output levels.

Yes, a STM32 is also my platform of choice. I've implemented support for PCem now, and it's working quite nice, but I'm running into a performance bottleneck with the Arduino (and the USB-Serial connection).
I _really_ despise USB, it's brought nothing but pain and suffering everytime I've touched it (I'm a network guy by day), but I still think it's the right solution for this setup.

In addition to PCem, do you think it would be a lot of work to add support for this to a hardware-assisted Hypervisor such as KVM/QEMU or VirtualBox as well? That would be particularly nice for the later more demanding 32-bit games that used DOS extenders. It's harder to run such games smoothly under emulation, even on faster modern systems.

Adding support for your hardware bridge solution to QEMU would form a nice compliment to kjliew's work to get DOS games with 3dfx support to run under QEMU with 3D hardware acceleration through a pass-through solution: Topic 60950

Regardless, please keep us updated on your progress with your project. I'm fascinated with any project that manages to interface old hardware with new hardware. There's just something very cool about that. 😊

I don't think this will be particularly high-performance in the end, mostly because I'm not going to use ultra high-speed hardware here.
An FPGA using PCIe on one side and ISA on the other would be ideal for this task, but that's way above my target here.

I'm mostly hoping to get some (slow!) VGA cards (and maybe some old interface cards like ISDN or special old MFM controllers) working.
Interrupts and DMA are 2 topics I haven't touched at all yet and I'm not quite sure how to properly implement. These topics will suddenly make the communication between PC and ISA-Adapter much more complex, because I not only need to listen for command-acks in a loop, but also asynchronously listen for interrupts and DMA transfers at the right time. Not sure how to implement something like that into an existing emulator.
But that's a topic for a much later date.

I'm currently designing the new hardware and still scratching my head about some electronics design choices...

manawyrm wrote on 2020-09-07, 12:23:

I don't think this will be particularly high-performance in the end, mostly because I'm not going to use ultra high-speed hardwa […]
Show full quote

I don't think this will be particularly high-performance in the end, mostly because I'm not going to use ultra high-speed hardware here.
An FPGA using PCIe on one side and ISA on the other would be ideal for this task, but that's way above my target here.

I'm mostly hoping to get some (slow!) VGA cards (and maybe some old interface cards like ISDN or special old MFM controllers) working.
Interrupts and DMA are 2 topics I haven't touched at all yet and I'm not quite sure how to properly implement. These topics will suddenly make the communication between PC and ISA-Adapter much more complex, because I not only need to listen for command-acks in a loop, but also asynchronously listen for interrupts and DMA transfers at the right time. Not sure how to implement something like that into an existing emulator.
But that's a topic for a much later date.

I'm currently designing the new hardware and still scratching my head about some electronics design choices...

I'm sure you'll figure it out. And don't mind me any my crazy ideas too much. You're right to focus on the basics of what you set out to do. 😉

There are quite a few talented people here who will be able to help you.

Have you also posted your question on the Vintage Computer Forum? There are quite a few knowledgeable people over there as well.

Good news:
VGA init seems to work now.
I've integrated support for this device into PCem (more specific, the tvga.c driver) and it's now directly controlling the real card.

This allows me to successfully initialize the card (and the VM can boot into DOS).
Unfortunately, writing into the video RAM does not work (yet). I have tried to write into A0000, B0000 and B8000 manually, but couldn't read my data back.
The screen is showing random data/uninitialized memory.

manawyrm wrote on 2020-09-13, 01:25:

Good news: VGA init seems to work now. I've integrated support for this device into PCem (more specific, the tvga.c driver) an […]
Show full quote

Good news:
VGA init seems to work now.
I've integrated support for this device into PCem (more specific, the tvga.c driver) and it's now directly controlling the real card.

This allows me to successfully initialize the card (and the VM can boot into DOS).
Unfortunately, writing into the video RAM does not work (yet). I have tried to write into A0000, B0000 and B8000 manually, but couldn't read my data back.
The screen is showing random data/uninitialized memory.

Progress! Nice. 🙂

Any idea what's preventing you from writing to the video RAM? You might need more than what my knowledge can provide here, but I'm willing to act as your "rubber duck" if that helps. I might even learn a thing or two as you explain these complexities to me. 🦆

digger wrote on 2020-09-13, 12:48:

Any idea what's preventing you from writing to the video RAM?

Not quite, yet.

I/O Read/Writes work fine, I know that because I can do all the Plug & Play stuff. Also, most of the VGA init (CRTC) works fine.
Memory reads also work fine, because I can read the video BIOS (at 0xC0000), which is using memory reads.

It might be either an electrical issue or some wrong init of the card.
I don't really think it's an electrical issue, I've checked with an oscilloscope and verified that the MEMW line is present directly on the card and looking correct.
I've tried to write some bytes at 0xA0000 and 0xB0000 manually and reading them back, which always resulted in 0xFF.
I'm not sure if there's some other I/O port I need to pass-through to the card to get it to map its video memory to my system memory.

List of my current I/O mappings:

10x03b0, 0x0030 bytes long (general VGA registers)
20x46E8, 0x0005 bytes long (Trident-specific registers)
30x4AE8, 0x0005 bytes long (Trident-specific registers)
40x0102, 0x0002 bytes long (not sure, but the video BIOS seems to write here?)
50x0094, 0x0001 byte long ("system board enable/setup register", "bit 5 = 1  enables VGA", "bit 5  = 0  setup VGA")

(I'm aware that some of these are too large, but I wanted to be on the safe side 😀 )
Are there any I/O ports I might need?

I've tried to write some bytes at 0xA0000 and 0xB0000 manually and reading them back, which always resulted in 0xFF.

that means the memory isnt there, in the sense that ram lines are pulled high when non-existant.

I presume the card is doing its own ram refresh...

I also assume you meant 0xB8000 because B0000 will be locked off in text modes (depending) and read as 0xFF, so to for A0000 when your not in graphics mode etc.

BloodyCactus wrote on 2020-09-13, 14:26:

I also assume you meant 0xB8000

I've tested the whole range between 0xA0000 and 0xBFFFF to make sure nothing works.

The RAM chips now get pretty hot (~40-45°C) after the init works, so I'm guessing that the refresh works as intended.

manawyrm wrote on 2020-09-13, 14:06:

I/O Read/Writes work fine, I know that because I can do all the Plug & Play stuff. Also, most of the VGA init (CRTC) works fine.
Memory reads also work fine, because I can read the video BIOS (at 0xC0000), which is using memory reads.

Have you ruled out timing issues?
Maybe the delays between setting the address, starting the read or write pulse and expecting the result to be valid are not long enough.
The timing requirements can differ between different types of memory or I/O. Additionally, the card might try to insert wait states.

Have you ruled out timing issues?

Not really.
I have a lot of delays in the code and the AVR is pretty slow in general.

The AEN and ALE lines could be part of the problem. I'm currently not using both of these, AEN is pulled low permanently, ALE is pulled high.

Additionally, the card might try to insert wait states.

Wait states are implemented correctly, the AVR will wait for the card.

Hey,

I've made quite a bit of progress on this topic:

I've overcome my hesitation to deal with USB in order to get this to work properly 😀
This PCB ISA card is using an STM32H743 microcontroller to talk to the ISA bus.
I'm using an already open-source and freely available ISA backplane to connect to other cards and to supply voltages.
The backplane PCBs are very cheap and ISA slots are very expensive (~4$/pcs!), so it makes sense to be able to swap out the ISASTM card without needing to buy another set of ISA slots for 30$.

The STM32 is actually way too fast for the ISA bus when running at full speed, so I'll have to do some timing adjustments. For now, I'm running with -Og and debugging enabled, which slows the card down enough.

I'm still using the same serial protocol, but over USB CDC-ACM this time. This is nice because USB CDC is basically packetised data without needing to deal with libusb. I might still have to do that later (because "misusing" CDC ACM as a packet interface is an evil hack).

If anyone is interested, here's the PCB and firmware. Please don't buy any of these PCBs (yet), there are still some issues!
https://github.com/manawyrm/ISASTM
https://github.com/Manawyrm/ISASTM-Firmware/t … master/Core/Src

With the new setup (and some other code changes, mainly related to the memory write timing), VGA memory can now be written to:

My modded PCem can now use a real VGA card, a real Adlib card, detect and initialize ISA PnP devices. I'm still missing software support for interrupts and DMA (but the hardware has support for it).

[Video] Using an Aztech soundcard in Adlib mode in PCem:
https://www.youtube.com/watch?v=0lqWBF858E8

[Video] Using a real Trident TVGA9000 VGA card in an emulator:
https://www.youtube.com/watch?v=5jW1dGRhmsE

The scrolling performance is pretty bad, because scrolling needs to copy the whole screen content one line higher in the video memory. As reads are done as single bytes and USB transactions are polled, this takes a while.
I could implement a shadow video buffer on the PC and just reply directly to VGA memory reads, but I would need to support VGA paging/memory layouts. (don't think I'll do this soon).
Tested and working video cards: ATI VGA Wonder 16, TVGA9000 and TVGA8900. Each with their own video BIOS directly mapped.

The USB interface is currently using USB FS (12 MBit/s), not High Speed (480 MBit/s). The hardware has a seperate USB 2.0 HS connector with the appropriate transceiver chip, but that one needs a bit of configuration to work and I've never worked with USB 2.0 HS or ULPI transceivers before, so this will need some fiddling.

Manawyrm

thats some amazing work you have done! nice mate!

I'm curious, what is your purpose of doing this?

I'm interested to know more. 😀

Cheers,