• Please review our updated Terms and Rules here

Universal Multi-I/O Controller & RAM Expansion

Great Hierophant

Veteran Member
Joined
Mar 22, 2006
Messages
1,928
Location
Massachusetts, USA
It would be possible to design a multi-I/O controller that can work in either an 8 or 16-bit slot (uses a 16-bit ISA connector) and can provide the following features :

IDE 8-bit, 16-bit & 16-to-8-bit translation
2 x Serial (16550 UART)
1 x Parallel (Uni & Bidirectional, ECP/EPP possible?)
1 x Game (w/speed adjust knob)
RTC w/replaceable battery
BIOS Extension Socket
HD Floppy Controller

If you had a board long enough, you could do all this with off the shelf chips. The BIOS extension could provide support for HD floppies, XT-IDE BIOS, RTC, etc. If custom logic were required to replace the glue logic, then you could still use a 765 or 8272 for the FDC and 16550s for the UARTs. Perhaps we could go even further and offer memory expansion as well. Perhaps a pair of 30-pin SIMMs that could be mapped according to the system's needs. So if you had 2MB on the board in an IBM PC, you could map 384KB to conventional and the remainder as EMS. On an IBM AT, 128K could be used to fill the memory to 640KB and the remainder available as extended memory. Obviously, such complex memory mapping, in addition to everything else, could not be done in standard off-the-shelf logic on a single board. How feasible would it be to do this? I assume you would probably need a large, 5V tolerant FPGA to feasibly get it all on one board. At that point, settings should be done via EEPROM, not jumpers or switches.
 
Possible to design? Sure. I'm just not sure what it would solve. There are already multi-I/O board you can buy off eBay that add 2S/1P/1G/RTC. You can already buy 16-bit IDE controllers that have all of the former plus HD floppy. XT-IDE satisfies 8-bit hard drive. For 8-Bit, the only thing you're missing from your list is HD floppy and I'm not sure how many people are with you on that.

I have a parallel design for a different board but with the same ends I think you had in mind. However given my work schedule lately, it will be quite sometime before I get a lot of progress made. Though I did manage to hit the order button on kit + PCBs for 3. Maybe that will lite a fire when it gets in. Though people here have mentioned it would be an abomination to retro computing if it were made.

Largely unfinished schematic and board files:

http://www.retrotronics.org/svn/eagle/projects/
 
Perhaps a pair of 30-pin SIMMs that could be mapped according to the system's needs. So if you had 2MB on the board in an IBM PC, you could map 384KB to conventional and the remainder as EMS.

Do you imagine how much effort is necessary to accomplish this? Both hardware and software... it can't be worth.
 
Possible doesn't always equate to feasible. To my mind, the only real use of such a card is for those that don't like combing ebay for the $1 specials of existing cards, and/or people that only use a limited-expansion box such as the 5150, PS/2 8525 and 8530, etc and wish to maximize their usage of each slot.

Not a bad idea at all, but I just don't see there being a whole lot of demand for the card unless the price point is low enough to make the effort of tracking down conventional solutions pointless.

Besides, I'm still hoping that someone besides me will jump on the bandwagon for Chuck's SD-card solution for a floppy emulator so it can be taken to the next level ;)
 
It's an interesting project certainly. CPLD must surely be the easiest route for it though?
 
It's an interesting project certainly. CPLD must surely be the easiest route for it though?

I'm going to assume that we're after port-level compatibility. Otherwise, you could do much of this in an MCU.

By far, I think the easiest solution would employ a 486-era "Super I/O" chip. I have a feeling, however, that such things no longer grow on trees.

I don't know if you could find enough through-hole components either, unless you stumbled on someone's old stock.

You might be able to fit it all into an FPGA, but doing a FDC and UART in the same package might get "interesting". Lots of I/Os as well.
 
You can still get Super-I/O chips. They are in-stock at Arrow. But they do only come in 100 SQFP packages now.

As far as fitting everything in an FPGA, see the design files above.
 
I love to see a project born process...

Would be nice to have Tandy 1000 EX support too, and also a intelligent MPU.
 
Where's the VHDL for the AT-compatible floppy controller?

My intent was to use the board as a V2.0 eval platform for a number of ideas. One of which was to bring in Pemberton's Ferret code as a starting point. I've looked at it quite a bit so far and while I haven't seen a synthesis report from Quartus or yet tried to bring it into Diamond, I see no reason why it wont fit. The Cyclone II part he is using is similarly sized but with a bit more efficient routing architecture than the XO2-7K I plan on initially stuffing on the board. As far as register level compatibility, that can be done either by a) directly changing the front-end register file and it's correlation to the back-end state machine or b) similarly to any other device you want to emulate at a software level - define a register map in FPGA FF's and interrupt generation on change to an MCU either on board (LM8, ZPU, Z80, etc) or off-board (the STM32 also on the card). With USB connectivity, arbitrary register file emulation by the PLD, and an MCU, you could literally emulate any legacy device with modern USB equivalents - think serial mouse -> USB mouse, NE2000 -> USB Wifi dongle, FD controller -> real thing or file on SD card or USB stick, hard drive -> SD card/USB stick, serial port -> virtual com port to PC host, etc, etc, etc.

The driving design point is the meat of the emulation is in the MCU as you've suggested numerous times. However the PLD off-loads the MCU from having to deal with fast real-time requirements of bus interfacing and decoding.

My only goal in this is a selfish one - just to see if it can be done. Thus it's a spare time intellectual indulgence only atm. The only reason I'm mentioning it here is the OP asked if a similar idea was possible. The basic answer is yes - although in practice it's a lot more involved. That and worse than anticipated compatibility issues with gamut of PATA devices in the last failed through-hole project has led me to this evolution.
 
Yeah, but we're talking about a port-compatible board, not a whole-track handler--and that includes timing and function. Given the way the Ferret works, that's going to be pretty tough.
 
We'll it's now a reality. I soldered up the first prototype tonight. I just need to find time to write HDL and MCU code in my busy schedule. I start a new exciting job role at work next month. One that's even a bit in-line with this type of project work. I'm seriously considering taking a week off to work solely on this straight. See how far I can get. Now that the board is a physical reality and passed the all important smoke test, it's starting to call out to me!

tubbie_front.jpg
tubbie_back.jpg
 
I see an 8 bit ISA connector right...
and then I see two USB ports right...

and now I need to go to the little boys room

(excellent work btw, can't wait to hear how it goes)
 
It's basically just an eval platform at this point to see what's possible. Essentially it's a beef stew of 64MB RAM, 8MB flash, 168 MHz ARM Cortex M4 with 2 USB OTG ports and SD card slot, a floppy interface header, and a large CPLD to tie things together. The MCU also has hold of the PLD JTAG lines so the whole firm ware can be updated via a USB stick. What's to come of it is still a bit up in the air. I have a lot of ideas, just not a lot of time. Some possibilities include:

- PnP operation
- Either DiscFerret inclusion or a more evolved native floppy controller alternative
- EMS memory pool
- ISA logic probe
- Audio media extender (MP3/tracked music)
- Emulation of any legacy device at a register level with backend functionality provided by USB equivalent. For example:
* WiFi dongle -> NE2K
* USB headset -> GUS or SB
* USB storage stick or SD card -> IDE hard drive or Int13 hard drive
* USB game pad -> game port
* USB mouse -> serial port with virtual attached MS or MM mouse
* In addition a host PC could provide a back-end for emulated legacy devices

The basic premise is to emulate the register file of a legacy device in the PLD. Throw an interrupt to the MCU on change and allow it to provide the functional back-end meat, update the register file or on card RAM, and throw an interrupt or DMA request back to the host PC. It starts to get a bit silly if you really start to think of the possibilities. And the idea has been called an abomination by some. And I have no intention of selling it. It's really just an itch I'm scratching atm - all open source. So I'm looking for technical collaborators. I have an earlier design with a functional ISA->WB bridge, SRAM, and a few cores running in it (serial port, SPI flash, etc).

It's actually a cut down version of a larger 16-bit design where the MCU interfaces to the PLD via eMMC and where one of the USB ports is high-speed creating a 48 MByte/s pipe between the two. Such a connection with the large RAM pool would allow for a real-time ISA bus traffic monitor in a host PC Windows GUI. Would be "interesting" to say the least. At the moment both USB ports are OTG but only full speed as the STM32F2/4 series needs an external ULPI phy. In this 8-bit design, the MCU is connected to the PLD over a single lane SPI interface (up to 30 MHz).

-Alan
 
Last edited:
Don't mind me, was just asking if flash drive support would be in it, but your post above explains that :p
 
Last edited:
Back
Top