Make the Apple IIe Option Card software 32bit compatible?
- Thread starter Ron's Computer Videos
- Start date
I’ve wanted my IIe cards to work with > 8mb of RAM, for a long time. So, I think this would be a great project.
It’d also be neat to get the card working on the alternate OSes (NetBSD, Linux 68k) that can run on the LCs.
- Alex
It’d also be neat to get the card working on the alternate OSes (NetBSD, Linux 68k) that can run on the LCs.
- Alex
There's something magical about the IIe Card, so I fully understand why @Ron's Computer Videos started this excellent thread. It would be great to accomplish today what those back in the day could not. We just need to overcome that negative ROI. Make it a long-term positive ROI like AAPL or BRK-B or even MCD, and I'm in!
As a 24-bit PDS card that is trying to work in a 32-bit machine, it's likely going to need a Hardware Abstraction Layer (HAL) with embedded micro doing the translation with a memory buffer on the IIe side and a buffer on the 32-bit bus side. Or, in other words -- a virtualized PDS slot with micro and buffers. Just let it think it's talking to a 24-bit 68K processor. It will just think it's in an LC.
You could probably even breadboard it with a Raspberry Pi Pico, not to mention the fact that the Pico also has wireless N. New Pico versions may also include BLE - many crazy remote control/programming/wireless IIe video options. Anyway, wireless would facilitate development. The IIe runs at, what...2Mhz max? A 2.4 Ghz processor should be able to keep up as an interpreter/emulator/bus translator. And, it's cheap - $4.
So, the IIe card would plug in to the fake PDS connector on a Pico HAL card that is a 32-bit PDS interface card. But, it's not going to magically work. The app side needs a quick UI rewrite/rewire and dump the original app after figuring out what it's doing. You could probably even put the whole 8Mb fake RAM space for card on the HAL card (cheap) and then use the Pico to read out of its RAM - frame buffer, etc. It really depends on what the card is doing and how it's doing it. If the card is calling the toolbox, then the micro will need to add that to the interpreter, along with 68K support.
Anyway -- as before, these are just very rough suggestions for someone crazy enough to attempt this project.
You could probably even breadboard it with a Raspberry Pi Pico, not to mention the fact that the Pico also has wireless N. New Pico versions may also include BLE - many crazy remote control/programming/wireless IIe video options. Anyway, wireless would facilitate development. The IIe runs at, what...2Mhz max? A 2.4 Ghz processor should be able to keep up as an interpreter/emulator/bus translator. And, it's cheap - $4.
So, the IIe card would plug in to the fake PDS connector on a Pico HAL card that is a 32-bit PDS interface card. But, it's not going to magically work. The app side needs a quick UI rewrite/rewire and dump the original app after figuring out what it's doing. You could probably even put the whole 8Mb fake RAM space for card on the HAL card (cheap) and then use the Pico to read out of its RAM - frame buffer, etc. It really depends on what the card is doing and how it's doing it. If the card is calling the toolbox, then the micro will need to add that to the interpreter, along with 68K support.
Anyway -- as before, these are just very rough suggestions for someone crazy enough to attempt this project.
I'll let Steve Jobs get the final word on that...these are just very rough suggestions for someone crazy enough to attempt this project.
The card doesn't really need to be able to deal with the full 32-bit, does it? The driver just needs to be tweaked to understand the 32-bit environment and make sure the card is allocated memory space and buffers that it can reach. It's the same sort of issue as using 8 or 16-bit ISA cards on 32-bit PCs, or 32-bit PCI devices on 64-bit processors. The IIe card requires a system extension anyway, right? So grabbing resources in the low regions it needs shouldn't be a uniquely difficult challenge.
Is the target to make it work on newer machines that have a different slot architecture or to use it on a machine for which it was intended, using a more modern system -- like OS8.1 on a Quadra 605?
My own needs are merely to use the Apple IIe card on an LC575 motherboard inside my Color Classic.
i know IIe cards are not impossible to get...
but it would open up to who would buy something if we actually just make a NEW IIe card with new software from scratch.
IDK> if you are going down the path of creating new hardware to make it 32bit compatible ANYWAYS. maybe just fpga up an Apple IIE and put that in a nubus mac.
i have no idea how feasible that is . sounds more fun too me though.
but it would open up to who would buy something if we actually just make a NEW IIe card with new software from scratch.
IDK> if you are going down the path of creating new hardware to make it 32bit compatible ANYWAYS. maybe just fpga up an Apple IIE and put that in a nubus mac.
i have no idea how feasible that is . sounds more fun too me though.
They are hard to get at a decent price, and ones that come with the cables are harder to find and even pricier. I just happened to see a guy in a vintage Mac FaceBook group selling his, which looked absolutely awful because the cables were dirty and the card had leaked cap fluid all over it. But I didn't see major trace damage, so I decided to buy it from him. He cleaned it with alcohol before shipping it to me, and it looks quite good in terms of the PCB. I've just not had the spare time to recap in order to do formal testing.
All said, a modern card solution would truly open the door for many vintage Mac users. How many would buy it? As with everything, that would depend on cost. But some things are a shot in the dark. For example, @Zane Kaminski thought it worthwhile to create a brand new modern accelerator for the Macintosh SE (which he's still working on). I suspect a good number of people would buy that, but exactly how many? I don't really know. With a good number of YouTubers showing people how these gizmos work though, I suspect that would be adequate advertising to get the word out. It's all about spreading the word!
That probably would be the best route since the IIe card is black boxed. Sniff, snoop, and whatever to see what it does as it communicates via PDS to the Mac. Then, emulate all that. INIT and CDEV for the 32-bit Macs to virtualize the PDS as 24-bit for the IIe card. Right?
The Apple II series have a lot of modern solutions that are exciting to keep using those computers. It can be done for the Macs. I know its hard as Apple did become a lot more secretive and it seems tough, such as the black boxed Apple IIe card. I wonder, with reverse engineering efforts, how much reverse engineering can be done if a card, interface, or board is black boxed? Is it harder to scan the cards or boards itself to see all the lines to reverse engineer? Are there too many traps placed to fool people trying to reverse engineer? I think it is fascinating that we can have fun with the vintage computers thanks to the efforts of people who work hard to make it happen.
Also, why the repeated comments that the “card” isn’t 32bit capable? I’m no expert, but it seems like the limitation is possibly the 24bit software written for a card bundled with a budget machine sold to schools that once installed was never supposed to be moved to another newer computer… once the LC and LCII left the market and schools started buying more Macs, there was incentive to update the software - so it wasn’t.
Seems like a 32bit clean rewrite of the software would be the place to start before all this talk of virtualized PDS slots. :|
Seems like a 32bit clean rewrite of the software would be the place to start before all this talk of virtualized PDS slots. :|
If it sounded as it I was flippant with your excellent idea, Ron, please know that I was not and still am not. I had hoped my participation in this thread would serve to illustrate my keen interest in seeing this happen. My earlier remarks, which were deliberately made humorous and terse, were basically asking the following, more-to-the-point question...
How much MONEY needs to be funneled to WHOM in order to achieve what specific development PLAN?
I suppose that some eagle-eyed accountants like @MacEffects might them chime in with their own questions about how funds would be managed, but I myself won't go that far.
Suffice it to say, I'm a very frugal, conservative and realistic guy who loves details. @BFEXTU is absolutely amazing when it comes to details, which is why I love his posts tremendously. He's a former SuperMac engineer, and I am thrilled to the core that he chose to join our forum and share so much with us! The reason I think that is so rare and special is because how many former members of big named Mac product companies actively interact with vintage Mac fans today? Answer: almost none. Henry Spragens from Beck-Tech is about the only other engineer from a big named company back in the day that I continue to interact with privately, and I've been trying to get him to share some stories and info here on Tinker Different. That's why I am excited whenever I have the chance to interact with BFEXTU on this forum. I also love our private conversations about the Levco SuperMac Speedcard for the SE.
So, if there's at least one capable developer (and I am NOT suggesting it be BFEXTU or Zane or anyone specific) who can hash out a reasonably specific plan and a rough idea of when, if ever, that initial investment could possibly pay off, then it becomes worth not only investing in individually, but also worth trumping up support from others. Without even a basic plan to be put into action, any investment and interest (especially in the long term) would be so limited the project may never get off the ground. No, I am not asking for a formal business plan on paper, but for the record, I have written one before.
Again, I am not trying to pop any bubbles, reduce general interest, or poo-poo the great idea of making an Apple IIe card work in 32-bit mode inside a Mac. No! I'm just a very meticulous person when I get serious about something. Tinker Different founders know that!
Thanks, JDW. Very kind words! I don't do much engineering anymore...but I really like this site! It is definitely rekindling my interest in programming and my old Macs, sometimes with sad discoveries, like my IIsi disaster. But, great to hang out with such talented and interested users! I also really like the open, friendly and respectful posting standards!
I am not very passionate about the IIe, but I did used to spend many hours trying to make address-swapping hardware devices work in 24- and 32-bit modes. It was a pain, I had full internal access, and not all the problems were solvable (hardware or device limitations). I may have alluded to some things in previous posts like _SwapMMUMode, _StripAddress, related low-memory globals, problems with high-order handle bits by the OS in 24-bit mode (like maybe for 'CODE' resources - I forget), etc.
I think the IIe card is interesting, and I have a full-size IIe and III somewhere (not working). But, I agree with Patrick about abandoning the specific card design. Besides the Black Box issue, there are likely other practical problems -- 6502 integration, etc. It's a classic 'Make vs. Buy' decision, and in this case Make might be the winner.
Again, I think it's a great card and piece of history to have for its target configuration/OS, but to go forward, it would be important to understand what hardware/internal limitations might be present before leaping down endless rabbit holes. If all that were required were just an external software fix, that would be amazingly lucky (and maybe somewhat unlkikely). But, maybe Apple might consider making some or all of the technical design specs/docs/source/firmware/VHDL, etc. public domain to support the retro Mac/IIe community? It might be worthwhile sending them an inquiry - never hurts to ask - it's great PR for them to have a thriving retro community.
However, my point in previous posts (which was not to denigrate "Passion Projects" in any way - I have plenty of my own) was that, given other available technology, it seems like it would be much easier to use newer buses and building blocks. For example, you could use a RPi with a Serial Hat -- or maybe a Pico would work. For example, rewrite/recreate the GUI (relatively easy) and hook it USB with an emulator running on the RPi. The presence of WiFi and BLE would also be incredibly useful (and a major advantage over the legacy card). Which one of you zealots is going to port Firefox to the IIe?? Anyway - the video data is relatively low bandwidth and the frame buffer could be passed over USB (or not), along with other types of data i/o channels. Or, if you wanted it to be on some other mac-related bus type, you could mount a Pico to something else -- not unlike the concept behind BlueSCSI.
Just some other suggestions. My weekend folly is that I think I can reassemble a vintage Southbend lathe that is completely disassembled and may have missing pieces. So, I am throwing no stones from my Passion Project glass house!
I am not very passionate about the IIe, but I did used to spend many hours trying to make address-swapping hardware devices work in 24- and 32-bit modes. It was a pain, I had full internal access, and not all the problems were solvable (hardware or device limitations). I may have alluded to some things in previous posts like _SwapMMUMode, _StripAddress, related low-memory globals, problems with high-order handle bits by the OS in 24-bit mode (like maybe for 'CODE' resources - I forget), etc.
I think the IIe card is interesting, and I have a full-size IIe and III
somewhere (not working). But, I agree with Patrick about abandoning the specific card design. Besides the Black Box issue, there are likely other practical problems -- 6502 integration, etc. It's a classic 'Make vs. Buy' decision, and in this case Make might be the winner.Again, I think it's a great card and piece of history to have for its target configuration/OS, but to go forward, it would be important to understand what hardware/internal limitations might be present before leaping down endless rabbit holes. If all that were required were just an external software fix, that would be amazingly lucky (and maybe somewhat unlkikely). But, maybe Apple might consider making some or all of the technical design specs/docs/source/firmware/VHDL, etc. public domain to support the retro Mac/IIe community? It might be worthwhile sending them an inquiry - never hurts to ask - it's great PR for them to have a thriving retro community.
However, my point in previous posts (which was not to denigrate "Passion Projects" in any way - I have plenty of my own) was that, given other available technology, it seems like it would be much easier to use newer buses and building blocks. For example, you could use a RPi with a Serial Hat -- or maybe a Pico would work. For example, rewrite/recreate the GUI (relatively easy) and hook it USB with an emulator running on the RPi. The presence of WiFi and BLE would also be incredibly useful (and a major advantage over the legacy card). Which one of you zealots is going to port Firefox to the IIe??
Anyway - the video data is relatively low bandwidth and the frame buffer could be passed over USB (or not), along with other types of data i/o channels. Or, if you wanted it to be on some other mac-related bus type, you could mount a Pico to something else -- not unlike the concept behind BlueSCSI.Just some other suggestions. My weekend folly is that I think I can reassemble a vintage Southbend lathe that is completely disassembled and may have missing pieces. So, I am throwing no stones from my Passion Project glass house!
To date, Apple has indirectly helped the vintage Mac community by turning a blind eye to things like Reloaded motherboards, logo usage and the like. They are without a doubt aware of what we do, but I guess they've decided that letting Mac fans have the freedom to love very old Apple devices in their own way actually helps Apple via good PR. That's something we can all be thankful for.
But in terms of Apple more proactively helping out the vintage Mac community by making technical information public domain, well, that hasn't really happened yet, with most of that remaining in some secret vault in Cupertino (I am assuming).
Perhaps @pocketscience might know some people who in turn know some people to ask.
I concur with @JDW. Apple has arguably the most extended list of vintage products of any technology company in the world, even much more variety and fun than IBM. As a $3+ trillion company, Apple has many more opportunities in the future and continues to surprise the world.
Sure, Apple has quirks here and there, but it hasn't lost the "why" - building products and serving the customers that they believe in.
Sure, Apple has quirks here and there, but it hasn't lost the "why" - building products and serving the customers that they believe in.