BMOW title
Floppy Emu banner

Apple II Video Card Thoughts

Recently I’ve been toying with the idea of building an Apple II video card. Like many of you, I’ve grown tired of searching for the dwindling supply of monitors with a native composite video input, and frustrated with available solutions for composite-to-VGA and composite-to-HDMI conversion. This card would fit in an expansion slot of an Apple II, II+, IIe, or IIgs, and provide a high quality VGA output image suitable for use with a modern computer monitor. I welcome your thoughts on this idea.

Why Do This?

Another Apple II video solution? Aren’t there enough options already? It’s true there have been many different Apple II VGA solutions over the years, and a smaller number of HDMI solutions. Unfortunately almost all of them have been retired, or have very limited availability. I’m also interested in this project as a personal technology challenge. It could combine some of my past experience with Yellowstone (Apple II peripheral cards) and Plus Too and BMOW1 (VGA video generation).

How Would It Work?

I see three possible paths for a high-quality Apple II VGA video solution. One is to convert the signals from the computer’s external monitor port. But monitor ports are only present on the Apple IIc and IIgs, and so that wouldn’t meet my goals. The second approach is to tap into a few key video-related signals directly from the motherboard, before they’re combined to make the composite video output. This is a viable approach, and others have been successful using this method. The downside is that it requires a snarl of jumper wires and clips attached to various points on the motherboard, and the details vary from one motherboard revision to the next.

I’m considering a third approach: design a peripheral card that listens to bus traffic, watches for any writes to video memory, and shadows the video memory data internally. Then the card will generate a VGA video output using the shadowed video memory as its framebuffer. It’s simple in concept, but maybe not so simple in the details. The first two approaches require only a comparatively dumb device to do scan conversion and color conversion. In contrast, the bus snooping approach will require the video card to be a smart device that’s able to emulate all the Apple II’s video generation circuitry – its weird memory layouts and mixed video modes and character ROM and page flipping and everything else. But it promises a simple and easy solution when it comes time to use the card. Just plug it in and go.

To be specific, for basic support of text and LORES/HIRES graphics, the card will need to shadow writes to these memory addresses:

$0400-$07FF TEXT/LORES page 1
$0800-$0BFF TEXT/LORES page 2
$2000-$3FFF HIRES page 1
$4000-$5FFF HIRES page 2

and these soft switches:

$C050/$C051 graphics / text
$C052/$C053 mix / no mix
$C054/$C055 page 1 / page 2
$C056/$C057 lores / hires

Can It Work?

For basic 40 column text mode, I hesitate to say this will be easy, but I don’t anticipate it being difficult. LORES and HIRES graphics may be more challenging, because the memory layouts are increasingly strange, and because determining what color to draw will depend on careful study of NTSC color artifact behavior. But I’m relatively optimistic I could get this all working well enough for it to be useful.

After finishing the basics, there will remain several more difficult challenges. First among these is sync. If the vertical blank of the VGA image isn’t synchronized with the vertical blank of the Apple II’s composite video, then tearing or flickering may be visible in the image. Carefully-timed program loops that attempt to change video memory only during blank periods won’t work as intended. Fortunately motherboard revisions 1 and later provide the SYNC signal to peripheral cards in slot 7, which can be used to synchronize the VGA and composite video outputs. For installation in a different slot or on a revision 0 motherboard, a wire can be connected to the motherboard for the SYNC signal, or the card can run unsynchronized.

What about European PAL models of the Apple II? I think Eurapple machines should work OK, since the card’s function is based on bus snooping rather than the actual video data. The VGA output will be the same, since fortunately there are no NTSC/PAL distinctions to worry about for VGA video. I’m less sure about Eurocolor machines. I believe these already have slot 7 occupied with an Apple video card – can anyone confirm? If so, my video card will have to go in a different slot, where the SYNC signal won’t be available. That’s probably no great loss, since software designed to sync with a 50 Hz composite PAL display can’t be synchronized with 60 Hz VGA anyway.

Can double-hires graphics and 80 column text be handled too? I think so, but I haven’t looked at these modes in much detail yet. From what I’ve seen, they both involve bank switching RAM between the main and AUX banks. Supporting these modes would mean shadowing some additional areas of memory, and a few more soft switches that control bank switching, as well as more software complexity. But they should be doable.

Non-standard character ROMs are another question. The video card will need to duplicate the contents of the character ROM in order to generate text. The most obvious solution is to simply assume the character ROM is a standard one, and include a copy of the standard character ROM on the card. But in some models of Apple II, it’s possible to replace the normal character ROM with a ROM containing an international character set in place of the inverse characters. These seem to have been common for Apple II computers sold in several countries. My card won’t know about the custom character ROM, and won’t render those characters correctly. I don’t see any easy answer for this issue. Possibly the card could use DMA to read the character ROM, but that would be a major increase in complexity.

Finally there’s the question of the Apple IIgs. Will the card even work in a IIgs? Maybe not, if writes to video memory on the IIgs are handled specially, and the address and data never appear on the peripheral card bus. That will be easy enough to test. Another question to consider is super hires graphics on the IIgs. I don’t know anything about how this works. I can’t think of any fundamental reason it couldn’t be handled in the same way as the other graphics modes, but it might be very complex.

Hardware Choices

What kind of hardware would be appropriate for a video card like this? It needs at least 18K of RAM to shadow the memory regions for text, LORES, and HIRES graphics. If 80 column text and double-HIRES are also supported, then the RAM requirement grows to something like 54K. The hardware must also be fast enough to snoop 6502 bus traffic and to shadow memory writes that may appear as often as every 2 microseconds. And it must also be capable of generating a VGA output signal with consistent timing and a pixel clock about 25 MHz.

What about something like a Raspberry Pi? Yeah… it might work, but it’s not at all the kind of solution I would choose. Those who’ve read my blog for a while know that while I’ve used the Raspberry Pi in a few projects, it’s not my favorite tool. I strongly prefer solutions that keep as close to the hardware as possible, where I can control every bit and every microsecond. That’s where the fun is.

Could it be done with a fast 32 bit microcontroller, something like an STM32? 54K of RAM would be no problem, and a 100 MHz microcontroller could probably handle an interrupt every 2 microseconds just fine. That would be enough to snoop the 6502 bus and shadow the writes to RAM. I’m less confident that a microcontroller could directly generate the required VGA output signal. If the caches could be disabled, it might be possible to write carefully-timed software loops to output the VGA signal. But the interrupts for RAM shadowing would probably screw that up, and make a hash out of the VGA signal timing.

A small FPGA is probably the solution here. 54K is rather a lot of built-in RAM for an FPGA, so the FPGA would need to be paired with an external RAM of some type – most likely SRAM or a serial RAM. Or the FPGA could be paired with a microcontroller, providing both RAM and some extra processing horsepower.

Read 32 comments and join the conversation 

32 Comments so far

  1. Heath November 17th, 2020 3:38 pm

    Isn’t VGA already fairly well deprecated? I don’t love HDMI, but possibly that’s the more mainstream output now? I think DisplayPort and USB-C are the other common modern ones…

  2. europlus November 17th, 2020 4:00 pm

    europluses have a sticker over Slot 7 saying it’s only for use by the PAL Encoder Card presumably because of the SYNC signal). But it can be used for other cards. I’ve never tried to grab SYNC from the mobo to the PAL card in another slot. But with your card, the PAL encoder card wouldn’t be needed. I’ve tried converting a europlus to NTSC, but the colours are off – it’s being troubleshot by the local enthusiast who did the conversion for me. I for one would welcome your card. And I have several mobo revision europluses and an International NTSC //e (none of which work very well to more modern composite TVs) I’d be happy to test on, but I’m in Aus and need to get most of my europluses working 🙂

  3. Steve November 17th, 2020 4:01 pm

    Yes, good point. HDMI would be great if you could have your pick of video outputs. The problem is that HDMI is very complex to generate, probably outside the realm of what’s possible for the hardware we’re talking about here. Same for DisplayPort. USB-C is not a video format, although it can carry HDMI or DisplayPort video data. VGA is simple to generate and is still supported by most modern displays, and seems like the best tradeoff for now.

  4. Joshua Bell November 17th, 2020 5:21 pm

    If you can support the Le Chat Mauve/Video7/AppleColor RGB Card modes, especially DHGR 560×192 monochrome, I’d be interested.

    The AppleWin folks have been doing the most research/reverse engineering of these semi-standard modes.

  5. Alex Ferro November 17th, 2020 5:34 pm

    Not that I’m volunteering here, or even the target market, but HDMI (for the DVI only subset that’s video only) is generally fairly simple, and many FPGA families directly support it with the I/O standards and serdes hardware. There’s also chips from the likes of Texas Instruments, and Analog Devices (as well as others) that take a 24-bit (or less with hardwired inputs, given the device) data bus, and a couple of clocks and control signals and do all the DVI/HDMI stuff internally. But 25MHz pixel clock is only 250MHz digital data streams per pair, and really isn’t excessive for any FPGA that will have the logic resources you likely would use.

    Also, besides tooling and annoying BGA pitches, the smallest ECP5 (just to pick something, and the open source tooling is quite nice IMO) FPGA has over 56KB of block RAM.

  6. Anthony Ortiz November 17th, 2020 5:47 pm

    I’ve been meaning to do this as part of a much bigger project, one that extends the Apple II’s capabilities way beyond anything so far, and as part of the grand scheme of things all the issues you’re encountering regarding external ram and VGA/HDMI is already solved. A couple of years ago I got it interfacing with the Apple II as a peripheral board but needed to do a tiny bit of it in FPGA to get the timings right for accessing/writing to memory but just as I was learning VHDL to make it happen I had to put things on pause. Reading this sort of gets my juices flowing again, I might revisit the old project again.

  7. Joshua Bell November 17th, 2020 8:35 pm

    I find it hard to believe that you aren’t aware of John Brooks’ VidHD project, but since you don’t mention it: the VidHD is existence-proof of the questions you ask about the feasibility of handling DHR and SHR.

  8.   November 17th, 2020 9:35 pm

    I wouldn’t say that 54 KB of RAM is a lot of internal memory for an FPGA these days. For example, this could be done with a Lattice HX8K or any FPGA from the ECP5 series. Both are pretty cheap and have a free toolchain available.

  9. Tim Buchheim November 17th, 2020 10:09 pm

    I’d prefer DVI (or HDMI like the VidHD). Although I already have a perfectly good VidHD card in my GS, so I probably don’t need another video card unless jr can do something the VidHD can’t. (That card does every mode supported by the stock GS hardware: 40 column text, 80 column text, low res, high res, double high res, and super high res. And it has a few extra high resolution text modes (80×45 120×67 240×135) to take full advantage of its 1920×1080 output. (These modes include firmware routines to handle the standard text output hooks.)

  10. Michael South November 18th, 2020 12:04 am

    If I’m reading the original II schematics right, it looks like the video ram is echoed to the periperal connector data bus while being scanned. If so, it would be interesting to use a Propeller chip to snoop the _reads_ and generate VGA; they’ve got built-in DACs with special VGA modes, but have too little RAM to shadow the higher res modes. It should be fast enough to handle it, but limited and wierd enough not to be massive overkill.

  11. Robert Sheehan November 18th, 2020 1:17 am

    I have a VidHD (it is great) and I would be very interested in another card if it does the mixed mode DHGR (colour 140×192, b&w 560×192 in the same display) provided by Le Chat Mauve/Video7/AppleColor RGB Cards. VidHD doesn’t do the mixed mode. Also with respect to the character set, it would be great if users could load their own via a simple native program to talk to the device. Something else VidHD doesn’t do.

  12. David November 18th, 2020 3:04 am

    ECP5 + some voltage translation, and a simple VGA DAC. You can do DVI-I, which covers all the bases for video out VGA/DVI/HDMI. Plenty of blockram to do all you want and more.

    80 col & DHGR stuff is a bit trickier to do than the base level Apple II / II+ video, but not too bad for an FSM. You could do a lookup table by bus address that contains X & Y coordinates and which state to go-to continue processing the byte of memory being written. Delay the artifact processing till the output stage, store hires modes as 3 bits per pixel in blockram… You could even support a blind upload of charrom and still keep the card as just a passive listener on the bus… Dummy Read $C7FF to select Slot 7, Write $C800-CFFF.

  13. Todd November 18th, 2020 3:14 am

    It needs to be instant on, so we don`t miss the logo or ability to press keys to enter various mass storage devices. Maintain a 4:3 ratio and allow for empty borders. In other words don’t fill the screen from edge to edge. And be VGA … not HDMI. There are so many choices of 4:3 monitors in VIA. HDMI is all widescreen.

  14. Steve November 18th, 2020 8:52 am

    So many great comments — thanks everyone!

    I think I can build a proof of concept using my old prototype Yellowstone card, and a hand-wired DB19 to VGA adapter (!!!). That card is basically just an FPGA (Lattice MachXO2 1200HC) on a plug-in card with programmable I/O connected to the DB19. That should be a fun a project regardless of whether it ultimately turns into a product that’s useful to somebody other than just me. If it works well, VGA output could possibly be updated to DVI or HDMI later, using one of the encoder chips that @Alex Ferro mentioned. 250 MHz bitstreams do scare me though, since I’m hopeless with the FPGA timing tools, and my PCB layout skills probably aren’t enough for 250 MHz signal traces.

    Yes I’d heard of the VidHD, but I thought it had been retired, since I couldn’t find any place to buy one. Glad to hear it’s still going.

    I hadn’t considered the more esoteric video modes like Le Chat Mauve. My primary interest is just simple and sharp-looking output of standard video modes. If that much works, I don’t see any reason other modes couldn’t be supported too if they can be generated by the same hardware.

    @David and @Robert Sheehan I like the idea of a utility program that can upload the character set to the card. It might be tricky, depending on where the charset data is actually stored on the card – in an external EPROM or in the FPGA itself.

    @Todd I agree 100% about the need for instant on. This is one of my biggest beefs with the Raspberry Pi and similar devices, along with the need to do a shutdown instead of just cutting the power.

    @Michael South you raise a very interesting idea! Instead of watching the bus for writes to video memory and shadowing the framebuffer on the card, the card could watch for reads from video memory by the motherboard’s own video circuitry. This would have a lot of advantages. Much less RAM would be needed on the card. The card could be less complex, because it wouldn’t need to understand all the weird memory interleaving and bank switching. There would be no concern about character ROMs with international characters – they would just work. The only downside I can see is that the card would be more or less limited to the standard video modes supported by the motherboard. But for ease of design and overall simplicity, I like this idea.

  15. Classics For X November 18th, 2020 8:56 am

    I agree with VGA as output.

    Me, I’ve done some older Macintosh computers in the past (Pismo + Titanium with native VGA output, IIGS with IIGS-to-VGA adapter made by Manila Gear/ReactiveMicro), and all of them work with VGA-to-HDMI adapters on HDMI devices.

    So I would assume, if you add VGA output to your card, it could work with an VGA-to-HDMI adapter as well.

  16. Alex Ferro November 18th, 2020 11:45 am

    Starting with VGA they way you describe is a great plan, it’s simple, and all those benefits.

    If you do go forward with this and are interested in HDMI, I wasn’t clear about the 250MHz signals.
    1) The 250MHz signals I mentioned in the FPGA are actually generated by hard logic in most FPGAs, so your logic still all runs at 25MHz.
    2) HDMI/DVI is amazingly tolerant to PCB stuff. I have been told by a major HDMI chipset vendor FAE on a recent 6Gbps per lane HDMI design, that you actually shouldn’t do the traditional high speed design length tuning and similar. For a 250MHz bit clock, you’ll likely have no issues with anything but driving the longest of cables as long as you make an attempt at careful layout.

  17. Paul Powers November 18th, 2020 4:40 pm

    Just to throw my cheap $0.02 in on this.. the conversation seems mostly structured around the ][e-//e video system… my pennies would also request that the totally different 80 column card modes in a A2 and A2plus be included as well.. like the Videx products and the modes those addon cards supported.

  18. Doug Brown November 18th, 2020 5:23 pm

    Another checkmark against HDMI is the licensing situation. I dealt with this a year or two ago. For example, Analog Devices no longer allows you to purchase their HDMI ICs (e.g. the ADV7511) without proving you are on the HDMI adopters list. You can’t buy them through distributors like Digi-Key or Mouser anymore without proving it. I’m sure some of the DVI chipsets (e.g. the TI TFP410) aren’t affected by this situation though. Also doing the HDMI itself in the FPGA would bypass this issue too, but technically the HDMI licensing folks probably wouldn’t be happy about it. HDMI is a very hobbyist-unfriendly technology to work with.

  19. Alex Ferro November 18th, 2020 5:47 pm

    Huh, I guess I’ve not had to deal with the licensing portion of it at my job. I’ve always thought it was the “don’t say you support HDMI, but trust that people will know what an HDMI connector is” rule, just like most USB devices follow. I know the HDCP licensing *is* required if you need HDCP support, and Analog makes a number of devices that integrate that specifically and thus require a HDCP agreement. But if that is the case about the licensing, then yeah, definitely stay VGA only (or ignore anything but the DVI subset of the protocol if that works and licensing is ok).
    And yes, outside my job, I hate how so much of consumer A/V tech is hobbyist unfriendly.

  20. Doug Brown November 18th, 2020 6:56 pm

    Yeah…everyone always mentions the HDCP licensing as an issue but there is definitely more to it than that (at least with Analog Devices). I suspect that you’re correct about being safe by not saying you support HDMI, but Analog Devices’ policy definitely throws a wrench in things. It’s pretty bizarre…it’s the only time I’ve ever dealt with a situation where distributors that definitely carry a part won’t let you buy it due to licensing. I’m not sure what led to them doing that, but I’m sure there’s some kind of interesting story behind it. At my job it forced us to do a last-minute rush to change to DisplayPort instead.

  21. Alex Ferro November 18th, 2020 7:18 pm

    Doug clearly knows more about that side of HDMI than I do. I guess you should worry about HDMI for licensing reasons more than for FPGA logic speeds or signal routing? Maybe just test your system with a VGA to HDMI converter that’s off the shelf like Classics for X suggested, and let that handle anybody who can’t natively handle VGA.

    And while I know DisplayPort doesn’t automatically mean this, I always associate it with my 4k monitors and so I chuckled thinking of an Apple II driving a 4k monitor.

  22. Chris M. November 18th, 2020 8:18 pm

    Doug, Clearly the OSSC folks are getting HDMI transmitters without a license. One reason why it was DVI in initial production runs was the whole licensing issue, but that was eventually resolved. They are using an ITE IT6613.

  23. Doug Brown November 18th, 2020 9:28 pm

    Good point Chris. It’s interesting that they originally had concerns and then changed their minds. All I know is Analog Devices definitely won’t sell their HDMI stuff to you if you haven’t licensed HDMI. I don’t see the IT6613 available at any distributors, perhaps anybody can get it direct from ITE. I suspect the smaller your project is, the less likely it is that the HDMI people will care…but the answer I received from the folks was that HDMI isn’t just a trademark and there are also patents involved. I personally wouldn’t touch it with a 10 foot pole…

  24. Ramtop November 19th, 2020 5:44 am

    Steve, hopefully I can contribute a little here as I recently did something similar to this – a video card with VGA output for the Acorn Electron that works by watching for writes on the 6502 bus. My card is based on an Intel Max 10 FPGA.

    More details on that and pictures here:

    I found that it wasn’t that difficult to get something up and running; VGA output is pretty easy, and I did a fairly simple implementation using block RAM for the framebuffer and a 12-bit resistor based DAC. The Electron has 7 graphics modes and the screen layout in memory for all of them ranges from strange to positively byzantine, much as the Apple II seems also to be, and that was a pain to deal with.

    The killer problem was games compatibility. I got the VGA board to work with maybe 70% of games, the remaining ones did really odd stuff that depended on fragile, timing critical code – mid-screen palette switches, partial screen blanking, and the like – and were never going to run on a very alien display system. Even the ones that worked sometimes exhibited flickering or tearing because of timing issues and having been written for 50Hz PAL output.

    My feeling now is bus snooping video cards like this are feasible as an additional display system that possibly adds some new capabilities, but not as a fully compatible replacement for the original video hardware. Scan conversion of some kind looks like a better bet for that.

  25. Steve November 19th, 2020 6:58 am

    @Ramtop, thanks for the excellent advice. I’ll check out your design. I’m concerned about those same kinds of issues. It’s one thing to parse a static image, but quite another to handle an image where the CPU is changing graphics modes mid-frame or doing other timing tricks.

    Does your card snoop writes to video memory from the CPU, or reads from memory by the video display circuitry? I was originally planning to snoop writes, but after @Michael South’s suggestion I think snooping reads may work better, and would hopefully avoid the kinds of problems you’re describing.

  26. Chris M. November 19th, 2020 9:40 am

    The Apple II did have another shadowing video card that added VGA video modes, the Second Sight. Thing is its mid-90s video shadowing tech wasn’t all that great and nobody really took advantage of the Oak OTI-087 VGA chip. The VidHD was much improved thanks to modern tech.

    One thing to keep in mind though is that many of these cards have slot limitations. I know you need to use slot 3 on a ROM 01 IIgs due to the required signal being missing on other slots. The ROM 3 has the required signals on slots 1-6. On the Apple IIe, most of the required video signals are in the AUX (80 column card) slot, hence why so many RGB cards are installed there.

  27. Steve November 19th, 2020 12:20 pm

    @Chris M. do you know what video signals are in the aux slot (slot 0)? From what I’d been reading, I thought slot 7 was the one with SYNC. For a bus snooping design, I think that’s the only special signal needed.

  28. Chris M. November 19th, 2020 1:00 pm

    Here is the IIe AUX slot pinout:

    Slot 7 also has Sync on pin 19 and the color reference on pin 35.

    Pin 35 on the Apple IIgs ROM 01 Slot 3 and ROM 3 Slots 1-6 is M2B0. Details on why the Apple II Video Overlay Card and Second Sight requires this signal for IIgs video shadowing is documented here:

    Yeah, video on the Apple II is complicated, but ingenious considering how little circuity Woz used to pull off color video!

  29. Chris Yannella November 19th, 2020 3:21 pm

    No slot video converter to vga would be awesome. Do an add on for keyboard so I can hook my IIs to a KVM and I would be forever grateful. Where do I send my money. Lol

  30. Steve November 19th, 2020 4:06 pm

    @Chris M. I was confusing slot 0 with the aux slot. The aux slot has some useful signals, but if I understand correctly, a card designed for the aux slot would only work in the IIe and not the II, II+, and IIgs.

    I know very little about the IIgs, but there’s clearly a lot to learn, and it’s unlikely a video card designed for the II/II+/IIe would just work as-is.

  31. Steve November 19th, 2020 6:45 pm

    Oh wow. That IIgs technote that @Chris M. shared included an aside about bus fighting. That jogged some long-dormant memory about my aborted Yellowstone project (a Liron disk controller clone) from a few years ago. That card never worked 100% due to some unexplained electrical problems and crazy over/undershoot on the data bus that I couldn’t explain. I eventually gave up.

    With the clarity of hindsight, I’m pretty sure Yellowstone’s problem was bus fighting, exactly as described in the technote. In fact @Fluffysheap diagnosed it perfectly in a comment on one of my final Yellowstone blog entries, but I think my brain was too fried by that point. The good news is this should be a pretty easy fix, and if it works, Yellowstone could be resurrected from the dead.

    @Fluffysheap wrote:

    The overshoot looks rather bus-fighty to me. The data bus floating around and then suddenly snapping to high, with attendant ground bounce could easily be the sign of a bus fight.

    The time period right around the rise of phi0 is prone to bus contention. The motherboard bus driver is always in tri state mode during phi1, but with the direction set to “out”, that is driving the slots. When phi0 begins, even though ioselect is asserted, the driver still has to turn around, which can take 50ns or so. This isn’t a problem for vintage hardware because it needs time to react to ioselect, but your card reacting in 5-10ns is just too fast, and you might be causing a bus fight.

    Try delaying your driving of the bus by 150ns or so.

  32. Ramtop November 20th, 2020 8:22 am

    @Steve; my design snoops writes, but that’s because the Electron’s system memory is not connected directly to the 6502. The ULA chip that generates the video output also acts as a memory controller, so reads for video generation are never seen by the 6502 or anything on the expansion connector.

    If you have access to reads on the Apple II that may be a more compatible option.

Leave a reply. For customer support issues, use the Contact page instead of comments.