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 51 comments and join the conversation51 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
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…
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 🙂
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 hdmi.org 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…
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: https://stardot.org.uk/forums/viewtopic.php?t=19158
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.
@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.
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.
@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.
Here is the IIe AUX slot pinout: https://www.apple.asimov.net/documentation/hardware/schematics/Apple%20IIe%20Auxiliary%20Slot%20Pinout.pdf
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: http://www.1000bit.it/support/manuali/apple/technotes/iigs/tn.iigs.068.html
Yeah, video on the Apple II is complicated, but ingenious considering how little circuity Woz used to pull off color video!
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
@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.
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.
@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.
I’ve been considering a similar project. I don’t know what all the fuss about HDCP above is. You’re not outputting protected content, there’s no need for HDCP support.
I was looking at shadowing the memory the same as you proposed, although for a simple project I may see if I can make something that takes into the right points to produce a composite signal with better timing. The Apple II confuses a lot of capture devices and LCD TVs.
If you stick an FPGA on the bus you should be able to instantiate a dual-port RAM, then it’s just glue logic for modes and paging, plus a character generator. If you want a silly but probably effective solution you could just grab the relevant bits of one of the Apple II cores people have published.
take a look at the Carte Blanche ii http://www.applelogic.org/CarteBlancheII.html. Several projects available with source to implement hdmi.
If the carte blanche was still available, that’s the way I’d go. At some point I plan to build carte blanche ii or re-create it with newer Xilinx to further develop the code.
While the VidHd seems like a nice solutio, my understanding is that it takes some time to boot up, I’d rather an immediate display thus FPGA solution.
ALso in the plan is a FPGA based 65C816 accelerator faster than transwarpgs.
How about the new Raspberry Pi Pico – it is dual core (eg one core to snoop the bus and the other to do the VGA signal). There is already code on GitHub for generating a VGA signal.
Wouldn’t a raspberry pi pico solution be more or less the same as the vidhd bu
Bill – I was under the impression there is no boot up time for the Pi pico – it just starts running code on power up. Does anyone know how long the delay to the vidHD startup is? Any solution would need to be up and running fast enough to see the initial reads by the video hardware.
Hi John, there would still be a boot time for the Pi pico. I doubt it is that much faster than a regular pi but I could be wrong. I would say that usually any sort of application is based on the raspbery pi os, it takes time for the linux kernel to boot. If one wrote an application without os/kernel, then the boot time could be quite fast. Not sure what Vidhd does, probably implements fast boot of the os, there are many links on that, but still on the order of several seconds.
According to the blueshift web site “After about six seconds from power-on, your HDMI display shows the Apple II video output”
I looked at the pico doc more, looks like it might be a bare metal boot to the application, if so then yes it should be very quick to boot.
Looked at a little more, the number of IO, 26 might be an issue for the pico. Need at least 28 or so pins for the AII slot and then a bunch of pins for the VGA output. Unless address decoding is done with separate logic such as a small FPGA.
Bill – I am with you on the need for an instant on. RE the Pi Pico – I was aware of the number of IO pins was a potential issue. If I knew how to do a bus snooping cirsuit then I would at least try a text mode as it could be done with just one pin for the VGA to give a white signal. In the mean time I am building one of these to see how it works – https://github.com/hoglet67/RGBtoHDMI/wiki Just go the boards in from JLCPCB.
From what I know of the Pi Pico, it’s basically a “fast microcontroller” similar to others I discussed in the Hardware Choices section. So the pros and cons would be similar to other modern microcontrollers like the STM32. I don’t think the Pico has much in common with regular Raspberry Pi models except for the name. I still think an FPGA is likely a better choice for this application than any microcontroller.
I wish the carte blanche II boards (http://www.applelogic.org/CarteBlancheII.html) were still available (or at least the board gerbers). I sent an email sometime ago, no response. Would be a good board to do some development on. there are several projects available for the card that do HDMI. While there are many FPGA development boards, they don’t include the necessary 5V to 3.3V conversion, which with the number of signals is not straight forward to cobble together. then one would have to port the code to a new FPGA….
When I’ve finished with my openhab (https://www.openhab.org/) project and a few others, I’ll probably buy an FPGA board and put a DIP version of the IDTQS34X245 on a Apple II proto board. And perhaps find a daughter board with a ADV7125 and TFP410 or equivalent.
sorry clarification, poor wording on my part, not implying openhab is mine, I’m building a hub with a raspberry pi and a first gen insteon hub which has a separate modem and processor board. Raspberry pi replaces the insteon processor board.
Actually, there’s another option you haven’t discussed– make a device that plugs into the composite output. Because the apple ii uses artifact colour, all of the detail present in the original image is in at the output. The signal it outputs is really monochrome, its just that the way TVs decode colour, using a notch filter, means that they will interpret high frequency information– repeating patterns of very small pixels– as colour. They remove this high frequency information from the brightness signal, causing the Apple II’s pixels to blur together.
Something else to consider is a card that will produce analogue rgb that would be compatible with something like a Sony PVM, or Commodore 1084S. I would love to see my Apple IIe displaying colour on one of these monitors, and it seems to such options are currently available.
Both the 1084 and PVMs have native composite input. Just plug the IIe into it. You aren’t going to get accurate color Apple II video without color fringing, its the nature of the beast. The RGB solutions for the IIe (Apple’s aux slot RGB card among others) and the IIgs’s native output do not properly support artifact colors!
Heya Chris. Yeah I know they have composite in and you don’t get colour, what I didn’t know is that an RGB solution would not properly support artifact colours 🙁 I’m a relative newby to the Apple II and IIe. So would that mean that if an application wanted to use an RGB solution for colour the app would have to specifically support an RGB card, and present the user with a config screen where they could select the video output?
Hey there! I was actually able to build an Apple II+ VGA card using a RPi Pico microcontroller module like some others had suggested. It works pretty well with support for all the original Apple II+ video modes (hires too 😅) and all the parts were inexpensive and easy to obtain.
I put all the schematics and source code on github https://github.com/markadev/AppleII-VGA for anyone else interested in this topic.
Hello..
It’s an Apple 2 hdmi output video card that I made with a Raspberry Pi board years ago
https://m.blog.naver.com/msgx/222580561132
https://m.blog.naver.com/msgx/222557917795
I am currently upgrading my hardware and adding various functions
Is there any update on a new video card for Apple II ?