pentiumspeed wrote on 2020-10-14, 21:28:

[..] what is your purpose of doing this?

I wanted to learn about PC busses (ISA, PCI, etc.) for a while now.

I'm also building a RC2014-based Z80 computer, which would benefit from a nice VGA output.
All currently available options are either too modern (ESP32, Pi Zero, etc.) or too crappy (40char composite video, etc.).
Using VGA cards would be pretty retro and the Z80 bus is pretty similar to ISA, so this should work pretty well.

Building a small x86 emulator card directly on the STM32 would also be cool, this way I could build my own little PC with extendable peripherals, kinda like a hybrid between emulation and one of these FPGA x86 PCs.

I don't think this whole project will get too serious, implementing proper support into emulators needs a lot of work (Windows support, GUI configuration, queueing/threading, proper configuration options for I/O mapping, etc. etc.).
I'm currently skipping all of this because I don't need it, but it would be pretty much necessary for regular users to be able to use the hardware.

If you forward the VGA ports to the PCem on the STM32, you could do hardware based scrolling. That should be pretty efficient.

Awesome work anyway! This is like emulation++, using emulated core, but real peripheral hardware. Extremely cool!

It's fun and interesting to follow your progress with this project, manawyrm.

I have a question, by the way, which I admit isn't entirely on-topic, although somewhat related.

You mentioned using the USB CDC-ACM protocol, and how it met the performance needs for your project. How is the latency?

I'm asking this, because I've been toying with the idea of developing a USB parallel port adapter that would support bit banging. The motivation for such a project is the fact that USB parallel adapters that you can find on-line don't expose low-level access to the parallel ports, but instead allow only abstracted high level access through the Printer Device Class. Naturally, that's only useful when you're hooking up printers. The device I'm envisioning might even offer more than one parallel port on a single adapter.

I would want the parallel ports on such an adapter to offer performance comparable to a parallel port on, say, a 386 class PC. I'm not so much concerned about the throughput, since USB, especially USB 2.0 and higher, should easily be able to offer that. It's the latency I'm uncertain about.

Now I read something about an "isochronous" transfer mode offering the lowest possible (or at least a consistently low) latency over USB. Is that what you're using as well?

I guess that if you can use this to drive a VGA card, it's most likely enough for the use case that I'm describing here as well, right? Is there anything that I need to take into account when choosing the right kind of microcontroller for this?

It's very much related and I think we're both at the same point now.
USB CDC-ACM is basically just serial over USB, very simple protocol, basically just writing plain text data into endpoints and it's done.

The latency isn't great, but I haven't done any measurements yet. Gut feeling: ~1ms per (write command, read answer) full transfer is probably the right order of magnitude.

The isochronous mode and maybe also the low latency mode usually used for stuff like keyboards might be better. But I really don't have a lot of experience and kinda hate the complete USB ecosystem.

You might want to take a look at the STM32F723 controllers, integrated USB 2.0 PHY, very fast, a lot of resources, pretty affordable.
My project just uses the STM32H743 MCUs because I already had another board using them, had a ready-made SDRAM layout and knew how to work with them. The external USB 2.0 PHY isn't ideal and will most-likely cause me a lot of headache in the near future 😒

digger wrote on 2020-10-15, 20:28:

I'm asking this, because I've been toying with the idea of developing a USB parallel port adapter that would support bit banging. The motivation for such a project is the fact that USB parallel adapters that you can find on-line don't expose low-level access to the parallel ports, but instead allow only abstracted high level access through the Printer Device Class. Naturally, that's only useful when you're hooking up printers. The device I'm envisioning might even offer more than one parallel port on a single adapter.

Sounds like the USB2LPT adapter, which admittedly is a bit outdated. At least the website has a lot of information on gotchas to keep in mind:
https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/

Been seeing this VOGONS forum thread URL starting to make the rounds today on Discord, IRC and Twitter. Good job, manawyrm. 😀

manawyrm wrote on 2020-10-14, 21:42:

I'm also building a RC2014-based Z80 computer, which would benefit from a nice VGA output.
All currently available options are either too modern (ESP32, Pi Zero, etc.) or too crappy (40char composite video, etc.).
Using VGA cards would be pretty retro and the Z80 bus is pretty similar to ISA, so this should work pretty well.

Very neat! One of the things I'd like for RC2014 is a video module with memory-mapped VRAM that can output to a relatively modern display. The existing boards are mostly serial terminals or hide the VRAM behind a TMS9918A or CPLD. I realize the downside is that it'll take up valuable memory space and require cooperation with the RAM/ROM modules.

I've wondered if Sergey's Super VGA (Trident-based) card could be adapted to the RC2014 bus. I've also considered an ISA <-> RC2014 bridge (probably as a backplane extension with jumpers/switches to set the I/O and memory address lines that exist on the ISA bus but not RC2014). But I've only been designing modules for less than a year now and this is a bit beyond my knowledge...

manawyrm wrote on 2020-10-15, 20:52:

It's very much related and I think we're both at the same point now. USB CDC-ACM is basically just serial over USB, very simple […]
Show full quote

It's very much related and I think we're both at the same point now.
USB CDC-ACM is basically just serial over USB, very simple protocol, basically just writing plain text data into endpoints and it's done.

The latency isn't great, but I haven't done any measurements yet. Gut feeling: ~1ms per (write command, read answer) full transfer is probably the right order of magnitude.

The isochronous mode and maybe also the low latency mode usually used for stuff like keyboards might be better. But I really don't have a lot of experience and kinda hate the complete USB ecosystem.
...

Neat project!

I found USB to be complex, and this site helped me a lot: http://www.usbmadesimple.co.uk/index.html

USB full speed is polled at 1ms increments (bInterval
in the endpoint descriptor). USB high speed uses 0.125ms units.

Finding a way to batch multiple reads into a single packet would be a large win in terms of bandwidth. Would a read ahead cache on the vga memory area work?

CODOR wrote on 2020-10-16, 13:10:

manawyrm wrote on 2020-10-14, 21:42:

I'm also building a RC2014-based Z80 computer, which would benefit from a nice VGA output.
All currently available options are either too modern (ESP32, Pi Zero, etc.) or too crappy (40char composite video, etc.).
Using VGA cards would be pretty retro and the Z80 bus is pretty similar to ISA, so this should work pretty well.

Very neat! One of the things I'd like for RC2014 is a video module with memory-mapped VRAM that can output to a relatively modern display. The existing boards are mostly serial terminals or hide the VRAM behind a TMS9918A or CPLD. I realize the downside is that it'll take up valuable memory space and require cooperation with the RAM/ROM modules.

I've wondered if Sergey's Super VGA (Trident-based) card could be adapted to the RC2014 bus. I've also considered an ISA <-> RC2014 bridge (probably as a backplane extension with jumpers/switches to set the I/O and memory address lines that exist on the ISA bus but not RC2014). But I've only been designing modules for less than a year now and this is a bit beyond my knowledge...

You don't want to build on Sergey's SVGA card. It is a great card, and I have a couple.
The problem is that the 9000i chips are getting very hard to find at a decent price.
My guess is that anything based on an original ISA chipset will soon become very expensive to build.

manawyrm wrote on 2020-10-14, 20:17:

Hey, […]
Show full quote

Hey,

I've made quite a bit of progress on this topic:
IMG_9670.JPG
IMG_9671.JPG
IMG_9653.JPG

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$.
IMG_9675.JPG

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:
IMG_9683.JPG
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.

Tobias

Take my money, i need this badly 😉
That's so great man ! Wow !!

Best regards
Philippe Dubois

manawyrm wrote on 2020-10-14, 20:17:

Hey, […]
Show full quote

Hey,

I've made quite a bit of progress on this topic:
IMG_9670.JPG
IMG_9671.JPG
IMG_9653.JPG

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$.
IMG_9675.JPG

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:
IMG_9683.JPG
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.

Tobias

Hi ,
I'ved seen your post for the first time today. Impressed by this work .,

After following all the posts/replies, didn't figure out where was this version, and where can I get more information on your work .
I'm in need of a similar solution for another reason , and it fits just right. .

Did you share this project anywhere else?

Best regards,
And congrats.,

Hi,

do you know the Flea86 ?
it emulates x86 CPU on 80C51 😀

https://fleasystems.com/flea86.html

Design a custom regular video card let it be ISA, PCI or AGP using typical video chipset like Trident 8900D, Oak OTI077 or Tnesg ET4000, WD90C30 or cirrus logic, or S3 with regular bios and 1MB or 2MB VRAM;
Capture the vram contents by watching passively as video chipset's VRAM is written or read instead and upscale the contents on modern processor with own separate memory and output at standard resolution like 1080p letterbox.

This way you remove the horizontal and vertical frequency issues as VRAM is just a memory timing at regular memory timing say, 80MHz is easier to deal with.

Cheers,

Hello
Is it possible to tell me what data you sent to the graphic card when you drived it through the command line of arduino?
thank you.

Hi @manawyrm!

How is this project going?

I have been playing with the CH367 development board and the Arstech USB2ISA adapter.

They both seem to work to some extent but the software is absolutely awful. The Arstech adapter seems quite nice from a hardware perspective but all the source and drivers are proprietary... and leave things to be desired. So I was wondering what state your project is in? Is it working okay from an electrical point of view or are there patches needed for the schematics?

phix wrote on 2023-05-26, 06:53:

Hi @manawyrm! […]
Show full quote

Hi @manawyrm!

How is this project going?

I have been playing with the CH367 development board and the Arstech USB2ISA adapter.

They both seem to work to some extent but the software is absolutely awful. The Arstech adapter seems quite nice from a hardware perspective but all the source and drivers are proprietary... and leave things to be desired. So I was wondering what state your project is in? Is it working okay from an electrical point of view or are there patches needed for the schematics?

A lot of folks have seen noise issues with the usb2isa. Were you able to resolve those?