rasz_pl wrote on 2022-03-02, 18:48:

pi yes, arduino no unless all you want is HID or serial […]
Show full quote

Shreddoc wrote on 2022-03-02, 06:24:

by way of devices like the Pi and Arduino.

pi yes, arduino no unless all you want is HID or serial

Shreddoc wrote on 2022-03-02, 06:24:

So, the USB4VC an already working proof-of-concept that a generalised "USB Host -> Protocol Convert To Legacy"

at that point you can just remove PC altogether and run dosbox on the pi 😀

Shreddoc wrote on 2022-03-02, 06:24:

Again, not in the specific ISA-card sense, but knowledge of ISA is not what is holding anything back here.

Its not "knowledge of ISA" that is the problem, but strict bus timing requirements forcing use of FPGA unless you are willing to write software support from scratch (then dual ported SRAM will suffice)

There is a difference between:

-connecting PI in some standard way like serial/PS2/keyboard/gameport and emulating standard devices. This is easy and pi is huge overkill.

-connecting PI in non standard way like LPT/dual ported ram. This requires custom software on the PC, devices interfaced thru PI wont "just work" in DOS programs. For example http://www.smbaker.com/raspberry-pi-virtual-f … -xtat-computers

-fully emulating devices on the ISA Bus level (register/memory map) transparently to the PC and DOS programs.

We are discussing in the past few posts digger's suggestion - to paraphrase: "An intelligent ISA USB card that exposes the USB devices you plug into its backplate as typical DOS compatible devices". You seem to be claiming his idea is not technically feasible. If that is the case, then so be it. I'm not the person to say so.

Yes you could just use Dosbox on a Pi instead, as you jokingly noted. However, naturally, if the goal is to interface new gear with old computers, then simply playing on a Pi instead is not meeting many of the project's goal requirements. 😉

In any case, the USB4VC, despite it's limitations, still begins to illustrate the true complexity involved in any such project. And that's just for controllers into ports. Extrapolate that complexity out to digger's idea of doing similar for ISA soundcards ... and I think we both agree that would be a rabbit hole a mile wide.

This is no denigration of having the idea - it's only through discussions like this that we as a community whittle our way towards valid conclusions.

Shreddoc wrote on 2022-03-02, 19:59:

We are discussing in the past few posts digger's suggestion - to paraphrase: "An intelligent ISA USB card that exposes the USB devices you plug into its backplate as typical DOS compatible devices". You seem to be claiming his idea is not technically feasible.

Not infeasible, there is a misalignment of complexity expectations. When you have low level SB/Covox/WSS/Adlib Gold/PAS implemented in FPGA/CPLD the process of actually outputting audio is the trivial bit requiring either 2 GPIO pin pins, some PWM and a filter or $1 codec chip (ES9023). Involving USB in this last step creates needless complications. mcu able to run as USB host and usb audio stack are serious business unless you just throw $pi$ at it ending up spending >$50 for something $1 ES9023 does better.

rasz_pl wrote on 2022-03-02, 23:07:

Shreddoc wrote on 2022-03-02, 19:59:

We are discussing in the past few posts digger's suggestion - to paraphrase: "An intelligent ISA USB card that exposes the USB devices you plug into its backplate as typical DOS compatible devices". You seem to be claiming his idea is not technically feasible.

Not infeasible, there is a misalignment of complexity expectations. When you have low level SB/Covox/WSS/Adlib Gold/PAS implemented in FPGA/CPLD the process of actually outputting audio is the trivial bit requiring either 2 GPIO pin pins, some PWM and a filter or $1 codec chip (ES9023). Involving USB in this last step creates needless complications. mcu able to run as USB host and usb audio stack are serious business unless you just throw $pi$ at it ending up spending >$50 for something $1 ES9023 does better.

We agree that the sound card aspect is difficult.

Anyway, when thinking about an all-in-one device, I prefer the Linux-y philosophy of "do one thing, do it well". Rather than a device trying to immediately be Everything At Once, I would prefer to see separate devices developed first, to show competence, and gain efficiency (of cost, and technicality). Then, combining into Swiss Army Knife Do-Everything version can come later, and is conceptually simple once the separate functions are mastered.

Now massive ROMs are cheap. could you just take envelope parameters as an address offset and it kinda spits out the right pattern to sum to a generic waveform, resulting in something that does FM/adlib with a large ROM, adders, bit of logic and a big old pile of resistors DAC. Kind of nearly wavetable but not. ROMs are a bit like a dumber form of FPGA if you abuse them right.

BitWrangler wrote on 2022-03-03, 01:45:

Now massive ROMs are cheap. could you just take envelope parameters as an address offset and it kinda spits out the right pattern to sum to a generic waveform, resulting in something that does FM/adlib with a large ROM, adders, bit of logic and a big old pile of resistors DAC. Kind of nearly wavetable but not. ROMs are a bit like a dumber form of FPGA if you abuse them right.

You can "reduce" anything to a (in)finite state machine.

The other salient question is "who shall be decompiling all the existing popular soundcards, then programming FPGA versions of them?".

(frankly unnecessary sarcasm follows!) We should cut the long list down to a shorter few candidates and volunteers. :p

Shreddoc wrote on 2022-03-03, 02:16:

The other salient question is "who shall be decompiling all the existing popular soundcards, then programming FPGA versions of them?".

There already are a few open source SB reimplementations, with BLASTERBOARD Blasterboard : A SB 2.0-compatible ISA sound card being much better than the original.

Hi,

I was going to start a similar thread but found this instead.

A few days ago I finished setting up my Amiga 500 with Pistorm and Emu68 and I was amazed from the quality of the HDMI video output, if compared to any old pc with vga graphics I own.

So if somebody have in their mind anything similar for a motherboard with ISA slots, I'm interested!
I have many AT motherboards laying around, finding more suitable cases for them is an exhausting effort that means spending loads of money and cluttering up the house.
I'd prefer something that would sit horizontally on the ISA slots (and VLB if present), offering HDMI graphics, SB sound, a network interface,disk i/o and UART if necessary
Something like the ZZ9000 but for ISA and not upright. Taking advantage from the bare metal raw power of a raspberry pi, similarly to emu68.
No need for a standard AT case anymore, everything can be fitted into a smaller 3d printed case that makes a nice appearance in a living room.
This kind of adapter would be good for motherboards with ISA/VLBUS slots, so I think another shall be made, with more advanced features, for those with PCI slots.

So, how do you like it?
Also, what is a cool name that could be given to these sawed-off retro systems?

Somebody's relevant project.

https://hackaday.com/2022/11/13/emulate-any-i … pi-and-an-fpga/

https://github.com/eigenco/frankenpi

From the github wrote:

This is an experimental project to connect Raspberry Pi with the help of cheap Cyclone IV FPGA board to 8-bit ISA bus to act as […]
Show full quote

This is an experimental project to connect Raspberry Pi with the help of cheap Cyclone IV FPGA board to 8-bit ISA bus to act as multiple different devices.

What is currently implemented (to some degree), i.e. PC can access through ISA

• Mass storage access from a file on the Raspberry Pi (written sectors are flushed every 2 seconds by default)
• Adlib output to optical SPDIF
• Sound Blaster 8-bit mono with DMA and IRQ (basic functions only), output to optical SPDIF
• Gravis Ultrasound (basic wavetable only), output to optical SPDIF
• Roland MT-32 (UART only), output to optical SPDIF
• USB mouse plugged into the Raspberry Pi will appear as a kind of serial mouse in DOS, custom ctmouse driver is provided (start with /v)
• Boot from custom TVGA9000i VGABIOS, i.e. no other devices are required to be present in the ISA bus besides FrakenPi and VGA-adapter

In addition to the PicoGUS project, of course, which is already under discussion in it's own Vogons thread.

The first time I heard about such an idea was here: The one sound card to rule them all

Many soundcards on one board is quite appealing to me, graphics-cards on the ISA bus not so much.

A good Soundblaster with RAM, GUS, MT32 and SC55 is hard to get and pretty expensive. And then there's stuff that only supports SB 2.0 or SB Pro or whatever. Replacing all this with one solution is the only way for many people to experience it at all.

Compared to this, ISA-VGA cards are cheap and easy to get. And I wouldn't use ISA VGA on anything >=486

Sorry to resurrect this thread if it's not ok to do so.

I am interested in a Raspberry Pi (Zero, etc.) on an ISA card like the PicoMEM (https://github.com/FreddyVRetro/ISA-PicoMEM), or a card like the Graphics Gremlin (https://github.com/schlae/graphics-gremlin) or Graphics Gremlin HDMI (https://github.com/yeokm1/graphics-gremlin-hdmi) with an FPGA with more LEs (maybe just the 8k version of the one used there). There is also the FrankenPi (https://github.com/eigenco/frankenpi).

What's the best avenue for something like this? My main interest here is that I'd like to emulate an IBM PGC card.

Mini DisplayPort doesn’t have any license fees at all for comparison.

So VGA+ mini DisplayPort should be the free option

thisisamigaspeaking wrote on 2025-04-20, 15:13:

Graphics Gremlin HDMI with an FPGA with more LEs (maybe just the 8k version of the one used there).

Interesting trivia: I have heard that the ICE40HX4K chip actually has the 8K die inside, and icestorm should be able to program it with an 8K bitstream.

kdr wrote on 2025-04-21, 05:06:

thisisamigaspeaking wrote on 2025-04-20, 15:13:

Graphics Gremlin HDMI with an FPGA with more LEs (maybe just the 8k version of the one used there).

Interesting trivia: I have heard that the ICE40HX4K chip actually has the 8K die inside, and icestorm should be able to program it with an 8K bitstream.

Really!

I do not know much about HDL or FPGA (or even how to correlate LUT on one platform to LE on another) but it seems like 8K LUT would be enough for a PGC? It's possible 4K is enough for all I know though. If an 8088 takes 1K or fewer LUT, that's the main part of a PGC. I see the Gremlin has a SST26VF080A-104I/SN flash chip which ought to be able to hold the PGC's ROMs no problem? I think the designer felt the memory bandwidth for the framebuffer might be a limiting factor for a EGA or VGA board though (and I would assume PGC, as it's 640x480 8-bit).

For me, that would be a hugely ambitious project when I already have a number of things on my plate. I actually have a real PGC too, I'm just strangely fixed on bringing the platform back to life for more people.

kdr wrote on 2025-04-21, 05:06:

thisisamigaspeaking wrote on 2025-04-20, 15:13:

Graphics Gremlin HDMI with an FPGA with more LEs (maybe just the 8k version of the one used there).

Interesting trivia: I have heard that the ICE40HX4K chip actually has the 8K die inside, and icestorm should be able to program it with an 8K bitstream.

Do you know where I can find out for sure whether this is true? That would be the deciding factor for me in getting a Graphics Gremlin or not. Thank you.

My ISA card wish list.
1) Sound Blaster Rebuild kits with NEW PCB and Capacitors
2) Video card ET4000 or Cirrus logic with 2mb RAM
3) Better Sound cards with built in Roland MT32, GUS, Roland GS. RCA, Digital out.
4) ISA controller card with 2 SSD’s and 2 floppy’s

I recently made a new CL-GD5434 but waiting for funds to get it built.

Modern RAM (IC41C16257-35k) gives the possibility to overclock the memory from 50 to 80Mhz for windows GUI/direct draw games. If it doesn't reset to 50.

The Tseng ET4000 W32i can be made with fast DRAM also.

There's no datasheet for the Mach64. The Matrox Impression 220 can be made but needs the ISA bios (90% likely) and donor chips from the PCI version. The Oak OTI-105/107 can't be made due to rarity of bios & chips.

MikeSG wrote on 2025-04-29, 13:54:

Modern RAM (IC41C16257-35k) gives the possibility to overclock the memory from 50 to 80Mhz for windows GUI/direct draw games. If it doesn't reset to 50.

The Tseng ET4000 W32i can be made with fast DRAM also.

There is almost no difference between a Trident 8900D (when using their April 1995 beta driver and not the MS driver) and a GD5434/ET4000 W32i when it comes to WinG/DirectDraw performance at the same ISA speed, and overclocking the memory on the GD5434 will not help there. Same goes for most other cards classed as a "Windows accelerator", as the acceleration is typically only relevant for GDI functions. It is effectively the same as benchmarking DOS games - I do have a weird anomaly in my tests where a GD5429 runs Quake 2 at 320x240 at 20.0 FPS compared to 17.2 FPS that most top speed ISA cards were benching (Trident 8900D gets 16.9 with their driver, compared to 16.1 with the MS driver - ATi mach32 VRAM and S3 928 were significantly worse at 14.5 and 15.4 respectively), while having identical results on everything else with my ECS P5ST-BR mobo running a K6-2 at 83*6 FSB. 640x480 benchmarks had no difference whatsoever all across the board. (EDIT: Just checked the 640x480 S3 928 benchmarks closer and there's a mix of identical results with Forsaken and Unreal while Quake 2 and Breakneck are significantly worse)

Where the real benefits of the GD5434 and Tseng ET4000 W32i chipsets (along with GD5424/26/28/29, S3 911/924/801 but NOT the 928 - I don't have an 805 ISA) are is that their Win9x drivers can do 320x200/320x240 at 16-bit colour, and that they don't bomb out with newer DirectDraw games like Breakneck (something which GD542x and S3 911/924/801 fails at). Games like Twisted Metal 2 are very much playable at 320x240 - in fact, I was surprised to see Forsaken benchmarks hitting ~13.0 FPS at 320x240 while Twisted Metal 2 felt like it was going at well over 30 FPS. Diving deeper into this is a high priority interest for me, along with testing my cards that only have 256 colour output like the WD90c30.

MikeSG wrote on 2025-04-29, 13:54:

The Tseng ET4000 W32i can be made with fast DRAM also.

The point of the "i" in W32i is RAM bank interleaving, doubling the throughput without needing faster RAMs. In bank interleave mode (2MB RAM, 2 banks of 256K * 32), the ET4000/W32i, 60ns is clearly fast enough for the W32i. Even worse: The bank interleave mode of the ET4000/W32i works by toggling /CAS between the two banks (when reading from memory), and the ET4000/W32i is aiming to hit maximum performance with 60-80ns RAM. It uses "quite short" /CAS pulses for them, so short that the time for the RAM to respond to the /CAS signal and the data to get to the ET4000 chip is about as long as the pulse itself. For this reason, the ET4000/W32i samples the data shortly after the /CAS pulse ended at the ET4000, relying on the time the RAM requires to react to output enable going inactive again. This works fine, and is the reason why the ET4000/W32i cards ware able to pull off "VRAM-like performance with DRAM", even in 16-bit color modes, using cheap FPM DRAM without requiring excessively fast RAM.

On the other hand, if you have more modern RAM that responds very quickly to /CAS being deasserted, the ET4000/W32i data sampling point might be too late. That's most likely what hit ALEKS on his EXCELGRAPH ISA card: Re: EXCELGRAPH - ISA Video Display Controller (ET4000/W32i) . Ultra-fast modern DRAM (faster than 50ns) on the ET4000/W32i in bank interlave mode has already been attempted and failed. IIRC are reports that the design by ALEKS works fine with 50ns-70ns RAM. I suggest retro ISA card designers do not spend their time on repeating that experiment, but either go with a different graphics chip, or if you insist on exploring the ET4000/W32i, check the specification in the 4MB non-interleaved mode (1 bank of 1M * 32). That mode might be less reliant on data hold time (see my linked comment for relevant data sheet sections), and possibly can make better use of ultra-fast DRAM. OTOH, while 4MB on an ISA card might sound very cool, I expect the ET4000/W32i in non-interleave mode to hit similar bandwidth limit issues than the Cirrus GD542x series, which is known to not even profit from a second MB of video RAM (unless you need offscreen memory for acceleration purposes, or you don't mind interlaced output). It might be possible to get slightly more performance out of the W32i than you can get out of the GD542x series, or clock it higher, but I highly doubt 4MB vs. 2MB makes any new modes available. So even my suggestion of building a 4MB card might be quite pointless, although it surely has novelty value.

DEAT wrote on 2025-04-30, 01:43:

There is almost no difference between a Trident 8900D and a GD5434/ET4000 W32i when it comes to WinG/DirectDraw performance at the same ISA speed [...]

By DirectDraw games I mean Starcraft & Diablo that use BitBLT in the actual game. On a CL-GD5429 those games are both a 5FPS slideshow. On a Chips 65545 & S3 928 they run borderline playable but not quite. This is at 640 x 480 x 8bit.

On the ET4000 W32i (excelgraph) it runs playable with a full screen of units: https://www.youtube.com/watch?v=Q-47q33atbk&t=215s

So I think it's worth exploring if a CL-GD5434 can't do it.

mkarcher wrote on 2025-04-30, 05:57:

EXCELGRAPH ISA card

I'm aware of the reflections, interference, capacitance, delays etc of memory lines. IMO the excelgraph had extra noise issues... The 0.1uf caps on the memory are too far away and on the main VCC/GND planes instead of each VCC input (three per chip). The memory ground is also not separate from the main IC ground which is recommended in the CL-GD5434 manual. The analog circuit is connected to the VGA connector shielding ground as well which collects noise. But I would do the same as he did with increasing the inline resistor values for the memory.

If it's possible in registers to max the memory speed I would probably explore it.. there's no way it can't make a difference in BitBLT'ing.