Thoughts on an Apple II FPGA Coprocessor
I’ve been kicking around the idea of using the on-board FPGA in my Yellowstone Universal Disk Controller as a general-purpose Apple II coprocessor. With an FPGA on a peripheral card connected to the 6502 address and data buses, I can’t make the CPU run any faster, but maybe I can make calculations faster by offloading them to some type of coprocessor that’s constructed within the FPGA. As a simple example, I could implement a fast PicoBlaze soft-CPU or something similar, and provide a way for the 6502 to run/halt the PicoBlaze and read/write from its memory space. The 6502 could upload a short PicoBlaze program and its required data, wait for the PicoBlaze to finish running, and then read the results back out.
The existing Yellowstone hardware can already do this. It would just be a matter of firmware development.
What would this be useful for? I’m not sure. But the Yellowstone firmware already implements a very simple taste of this idea, because I needed it in order to achieve the disk timing requirements. It’s not a coprocessor, but it’s an extension that shaves a few clock cycles where they’re most valuable. There’s a specific magic address in the Yellowstone card’s address space, and when the 6502 reads from that address, Yellowstone performs automatic GCR decoding of the most recent disk byte.
I had a crazy idea to use this like a classic computer hardware emulator, except that the Apple II wouldn’t be emulating an older computer but a newer one. The 6502 program could just sit in a tight loop reading bytes from the FPGA coprocessor and writing them into the Apple II frame buffer, so whatever appeared on the screen would be the result of the coprocessor program. It would still be limited by the Apple’s physical screen resolution and color palette, but panning around a larger virtual screen should be possible. And conveniently I’ve already implemented a Macintosh Plus FPGA core, so in theory we could see MacOS running on an Apple II? Or more realistically, this scheme could turn an Apple II into something like a Commodore 64, or a 1980s video game console. Probably impractical for any serious use, but at least it would make interesting discussion for r/vintagecomputing!
Read 9 comments and join the conversation9 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Let’s be realistic – non of this stuff is actually necessary, and if it is there are faster/cheaper ways to achieve it. We do it because it is fun!
It sound like you are half way there, so if you can get the Mac Plus core running that would be cool, even cooler if it could read Mac disks.
Sounds like you’re adding a 3Dfx to a Pentium II.
The only issue then is Glide… and software to use it!
Wow, you’re taking me back with that 3Dfx Glide reference. Didn’t the original 3Dfx card (Voodoo?) operate as a video pass-through, with the output of the normal graphics card connected to the input of the 3Dfx? 25 years ago I was a video game developer at Electronic Arts, and my first development system was a Pentium III with a 3Dfx graphics accelerator. https://www.mobygames.com/game/windows/tiger-woods-99-pga-tour-golf
So I have always wondered if it would be possible to “wedge out” the floating point math in Microsoft Basic, to use something as an FPU.
Could be an interesting use case? 🙂
I have some ideas for a proportional-spaced-text accelerator design which I think could have been somewhat practical back in the day. The basic notion would be that fonts would be stored with bytes representing vertical strings of pixels, and the act of storing each byte into the device would write it into a buffer, rotated. Once all of the characters whose top line would land on a certain scan line were drawn, the contents of that line could be copied to a double-hi-res display, after which the buffer would be shifted. I would expect that with a level of hardware support that could have fit on an Apple II card without custom logic, it would be possible for an Apple //e to achieve text rendering performance on par with a Macintosh.
Let me know if you’d be interested in more details.
This idea may not be any different from the Z80 or 8088/86 co-processor cards out there. I have experience with the 8088 co-processor cards. The card can technically run an OS like CPM-86 or MS-DOS. But if you want to use the co-processor to just speed up existing Apple II code, it can be a bit trickier. If you have Applesoft or Integer BASIC code you want to speed up, a driver would need to run before running your code. The driver would intercept certain BASIC operations and re-map these operations to the co-processor card. And then the co-processor card has its own firmware to translate those operations. I don’t however see this workable if the code is pure 6502 machine language.
I love the idea of using the FPGA for other functions.
There was the Mill for math co-processing going way back. There is a little support for this. GSOS has SANE for math that could be used by the FPGA.
I really am excited by the C64 or old console ideas. The FE could be the cart and the YS would be the console.
I think a good use of this would be to act as a SSL/TLS coprocessor so you can get your Apple II online without an external proxy to strip the encryption off connections!
I was actually thinking about something similar. Kind of a “Radius Rocket” but for the Apple II. Have a fast 65816 or 65C02 that can take over the host system with DMA, or act as a standalone superfast expanded Apple II with a way to daisy chain multiple cards together and share one output display. Kind of an AppleCrate in an Apple II setup. The DMA takeover would let you turn any Apple II (with slots) into a different Apple II entirely. You could even have a partially populated Apple II motherboard with no RAM, ROMs, chargen, cpu, or video circuitry acting as a passive backplane with just the keyboard and joystick port active. Any cards in slots 1-7 would work as expected. A decent sized FPGA with 128K or more of BRAM should be more than capable of the bus arbitration needed.