BMOW title
Floppy Emu banner

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 5 comments and join the conversation 

5 Comments so far

  1. Vincent - January 22nd, 2023 7:36 pm

    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.

  2. Steven - January 23rd, 2023 4:59 am

    Sounds like you’re adding a 3Dfx to a Pentium II.
    The only issue then is Glide… and software to use it!

  3. Steve - January 23rd, 2023 7:57 am

    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

  4. John Parker - January 28th, 2023 1:22 am

    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? 🙂

  5. John Payson - January 30th, 2023 2:34 pm

    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.

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.