This has probably been discussed ad-nauseum, but would it be possible to create a new Apple IIe using truly modern and currently available components? Rather than a true replica, something that is compatible.
By this, I mean:
WDC 65C02
FPGA or CPLD for IOU and MMU
SRAM rather than DRAM
Flash NOR rather than EPROM / ROM
VGA output using a system similar to the Apple-II-VGA card
Compact flash or SD Card for storage
Potential to overclock to 8, 12 or 16MHz
If such a system was built, would it be compatible with existing software?
Would anyone be in any way interested?
Thanks!
In post #1, 'nrrd' asked:
" Could you make a new Apple IIe compatible from modern components ? "
Uncle Bernie answers:
Yes, it is possible to do that - as long as the "modern components" are not too "modern" and can't support the required 5V supply voltages in the original Apple IIe anymore. Of course, you could always use a modern FPGA which is not even 3.3V compatible, these are very powerful, fast and cheap, because of a low die area for more advanced deep submicron CMOS process technologies. But then you need to add lots of level translators which increase parts count, PCB area and hence, costs. There are MMU and IOU drop-in replacements using this technique. But they are pricey and I don't think they can be hand built by the typical hobbyists - too many fine pitch SMD components.
I think a better (and more hobbyist friendly) way to build a 5V compatible system (the original Apple IIe is one of those) is to use older CPLDs and FPGAs which still can directly handle the 5V. This is the way I chose for this project:
https://www.applefritter.com/content/uncle-bernies-replica-2e-ww-prototype-apple-iie-replica
Which works fine and as far as I can tell is 100% Apple IIe compatible. The MMU and IOU replacements were implemented with older, and cheap Altera EP600 and EP900 EPLDs and Lattice GALs, mostly motivated by the fact I have a huge stockpile of them. All the logic could be put into one Lattice ispLSI1032, if I wanted. But I only have a few of them left over, and buying them from greedy chip brokers is too expensive.
Note that most of the Apple IIe motherboard logic could be built with 3.3V CMOS devices, as these are able to deliver the required TTL "H" logic level. But this approach leads to marginal noise immunity and hence is not optimal.
This is work in progress. I'm slowly migrating the PLD/CPLD designs of the "Replica 2e" towards a more modern form which can be resynthesized with current industry standard FPGA CAD software (I use proprietary CAD tools I wrote around Y1990). But as I have many ongoing projects, some of which are very difficult and time consuming (i.e. I'm trying to beat - or at least match - the frequency comparision technology they have at the NIST for their famous Cesium Fountain Atomic Clocks) I can do all this Apple II and Apple-1 related work only in the few hours per week which are not absorbed by dealing with circuit gremlins invading my atomic clock project from the quantum mechanical realm they are living in ;-)
So, despite being retired, I work more hours per week than ever before designing, building and testing really weird electronics. The simple Apple-1 and Apple II stuff is a nice pastime for me to wind down and relax from my more demanding work.
So don't hold your breath waiting for me finishing the Replica 2e project. Maybe one or two years more, give or take. I'm also very demotivated by the U.S. tariffs on Chinese made PCBs, and I'm not inclined to pay the extra costs, so I don't want even to design PCBs for it. If PCB are "Made in the USA" (i.e. by OSHPARK), only very small PCBs make sense money wise, but everything larger in area than maybe fitting an an Altoids tin can quickly gets outrageously expensive. As an example, the PCB for my YAAK keyboard see here:
https://www.applefritter.com/content/uncle-bernies-yaak-yet-another-apple-keyboard
before the tariffs did cost $6 when made by JLCPCB in China, including shipping, while the same PCB with the default purple solder mask made by OSHPARK costs ~$110. This is why I never will make a "final", improved layout version of the YAAK, and when my PCB stock is exhausted, it's over with building those YAAKs.
Uncle Bernie
Olimex built one a couple of years ago: https://www.olimex.com/Products/Retro-Computers/Neo6502/open-source-hardware
It's open source, so you can base your own project on it.
If a Commodore 64 Ultimate can be built...
Has anyone tried creating software using the sprite capabilities of this card?
This is exactly what I've been working on since last year. I'm maybe a few weeks from my intermediate goal of "Boot to AppleSoft prompt". This will be a 3.3V re-creation of the Apple IIe using modern components. It will not be an emulator; a real 6502 / 65C02 / W65C02R will power this recreation and it will use my IOU, MMU, timing HAL, and no emulated part.
I want to recreate the Apple IIe as faithfully as possible; I'd like to be able to extract any subsystem, plug it on a real Apple IIe and it would just work (with proper voltage level shifting). Initially, I wanted to go as far as have the same layout on my PCB as on the original Apple IIe motherboard. But after seeing how unreasonable the cost would be, I decided to use a single FPGA (a Lattice ECP5) and not follow through with my same PCB layout idea. Plus, I want the recreation (the case) to be more or less hand sized, about 1/3 of the size of a real Apple IIe and a single FPGA design makes this much more possible.
Comparison.png
On top is my implementation, and the bottom is a real Apple IIe hooked on a AppleMonitor IIe. As you can see, the texture of the colors -- the soul of the Apple IIe's graphics, have been recreated.
The HDMI will also output audio, and since not all HDMI monitors have speakers, I have added a PCM5102A Audio DAC and a 3.5mm jack. As feature creep commands, I will probably use that opportinity to add Mockingboard / Phasor support. I'm not 100% sure whether I should have the Audio Jack/PCM5102A or not: I miss the audio jacks on electronics, but on the other hand this increase the cost for essentially a duplicated feature.
I call it the "Apple IIn", but if this thing ever becomes a commercial product, I will probably have to drop the "Apple" from that name. In any case, a lot of work still has to be done before it's finished.
Cheers
Thanks, I have read about this project before. It's a bit of a weird one - it has a Raspberry Pi Pico emulating the RAM, ROM, logic, peripherals, etc. It feels a bit more like the RPi is doing the emulation and then farming out the processing to the 65C02, almost as if the CPU is a peripheral. This seems a bit backwards. Ideally (for me) the 6502 and a clutch of supporting chips (RAM, ROM, logic, etc.) should be the computer, and a microcontroller should only be a peripheral.
Probably just my sensitivities! The Olimex does look like a cheap way to get started writing 6502 assembly language, though.
Thanks for your informative answer. To clarify - by "modern components I did mean components that run on 5V, although I also appreciate it is becoming difficult to find chips that are 5V compatible nowadays. I know next to nothing about FPGAs, etc., but even with microcontrollers very few are 5V compatible. The new (ish) Arduino R4 series are the exception, but they have been given a small amount of SRAM (32K), so are less useful than they could be for providing (for example) VGA solutions for homebrew computers.
This is interesting. The 74AC / 74AHC series of chips have quite low propagation delay and are 5V compatible, so could it be possible to recreate the Apple II motherboard logic from these? I have both the "Understanding the Apple II" and "Understanding the Apple IIe" books by Jim Sather, and the logic looks feasible - of course the II and II+ used older 74LS series chips to implement this as you know.
It sounds like you're having a great retirement! I've got another 17 years before I can retire and then work on things I'm actually interested in! :) Joking aside, my job is not bad - working as a software developer for a government research institution - but it has become very complicated over the past 5 years with the move to "the cloud", continuous integration, microservices, containerisation and orchestrated deployment of applications. AI is also starting to disrupt and complicate matters, and here I mean the hyped LLM and Agentic AI, rather than the machine learning and optimisation techniques we have always used in my field Hence my renewed interest in simpler computer systems. I had an Amiga growing up, but never had an Apple II. Both are interesting, but the Amiga would be next to impossible to create as a home project, due to the custom chips (some are available in FPGA, but not all).
I use a company called Aisler, who are in Germany (I'm in the UK). They're not quite as cheap as JLCPCB, but are in the same ball park. I don't know what the tariffs are like for Germany from the US, but the balance could be in your favour.
This looks great! Congratulations on getting it even to this stage!
I'm in two minds as to how to progress my project, and it is just at the very beginning.
I'm starting to think it might be that I create a system that it is easy to port Apple II software to, rather than go for an out-and-out replica. I'm minded of what Jim Sather wrote in "Understanding the Apple IIe"
And there are other aspects, such as outdated peripherals, the tape interface, etc. that would not be required on a modern machine.
So, a relatively simple machine with a more sane memory bank switching scheme, support for modern peripherals, maybe better graphics, etc., to make a target platform that would be easy to port Apple II software to, with the full knowledge that it is not an Apple II, and that it would probably be me doing most of the porting.
The Commander X16 is something similar, I suppose, but that project is very complicated and has some strange decisions, and also based on the C64 / VIC20.
A simpler platform that is still a computer (rather than a microcontroller + CPU), with expandability either through the CPU bus, or peripheral ports, should have an appeal to hobbyists, I think. I might be wrong!
I am not sure why you see it that way. The way I look at it when running as an Apple II using the Reload firmware is the W65C02 is the main processor and the RP2040 is the peripheral because it is emulating the Apple II peripherals. However the RP2040 is perfectly capable of emulating the entire Apple II. In fact the above-mentioned firmware does contain the source code to emulate a MOS6502. So if the firmware is configured to do that, the RP2040 becomes the main processor, while the W65C02 is demoted all the way to not used.
I think this is why I have reservations about the Olimex Neo6502. What is the purpose of putting the 6502 on there, if the RP2040 could just emulate it as well as everything else it is emulating?
I think it's largely my problem, and an aesthetic one at that! It's certainly a good piece of engineering and an interesting take on a retro computer.
Edit: also, only 64k of RAM, floating point math is done on the RP2040. At least the CPU bus is exposed.
Some people believe that when a processor is emulated, it is somehow less real than having a real chip. I think Olimex is targeting precisely those people with the Neo6502. Personally I do not share this belief, since I care what is the capability and not how it is achieved. Interestingly in the 70s when processors started replacing TTL logic chips, it was the processors that were considered somehow less real by some people.
I have not played with the Neo6502 myself, but I am certain that the RP2040 is not fast enough to emulate an Apple II running at 14 MHz. So there might be also a performance advantage to having the real chip.
I think that there have been numerous emulated solutions in one form or another, inluding software emulators liek AppleWin, the really excellent Virtual II, as well as various FPGA and RPi solutions that have in one way or another been shown to "boot to Total Replay" and play a game of Lode Runner. So such a project is totally doable.
If I were the project lead on such a project, I think that the best form factor may be the Apple IIc, becasue of its all-in-one nature. It's the closest thing to the C64 breadbox, and a modern project might be the closest thing to the Ultimate 64.
A similar form-factor with all the IIc features, but with an SD-card reader instead of an internal drive, but maintaining all the ports - modem, printer, video, smartport,, mouse/game, along with, of couse VGA and/or HDMI video, and for fun, a slot extender that you could use similar to what the Laser-128 had.
I would also convert video to the RGB standard or at least have that option, as there is nothing more annoying to me than Apple's pseudo-NTSC colour fringing on a modern monitor. IT was barely tolerable on a CRT, but on a flatscreen it's difficult to look at.
It also helps that folks like MacEffects have already recreated the keyboard and case.
Might even sell in modest quantities...
I think that would be my preferred format as well. It has the cuteness factor, and looks a bit more like the classic Mac era Apple, which people seem to really like.
With a VGA output, you could also use one of the small 10 inch monitors available on eBay / AliExpress. That and, with the lower power of the CMOS chips, plus a power bank should get a nicley portable solution.
Which ports would actually be necessary, though? What would the modem and / or printer port actually be used for? The external disc drive could be dropped. Two game controller ports would be good, using the Atari standard. SEGA Megadrive / Genesis gamepads are still manufactured and available also on eBay.
In post #8, "nrrd" wrote:
"I also appreciate it is becoming difficult to find chips that are 5V compatible nowadays. I know next to nothing about FPGAs, etc., but even with microcontrollers very few are 5V compatible."
Uncle Bernie explains:
Root of this problem is that the worldwide semiconductor industry is slowly phasing out / shutting down their 0.6um CMOS processes. This process node is the last one fit to produce simpler logic ICs running at 5V. The next step in the so-called "shrink path" was the 350nm node, and this is fit only for 3.3V supplies. (Of course, some more advanced CMOS process technologies do offer "high voltage transistors" but these are costly process options, and no, you can't plug in old designs and make them on these advanced processes, and furthermore, unless you make systems-on-chip comprising millions or billions of transistors, it makes no sense to use these more advanced CMOS process technologies: for typical 1980s era designs you would end up with a large pad frame surrounding empty space, in which there is a tiny speck, smaller than a bonding pad itself, in which there is, i.e. the complete Apple II CPU, memory, and all the logic).
It is not economically feasable to migrate older 0.6um CMOS designs to the later process nodes, there are too many differences in the devices and also in the metal stack, so a complete redesign from scratch would be needed and nobody does this, no money to be made.
A few companies continue to make 5V compatible microcontrollers (i.e. Microchip Technology) but nobody will make 5V RAMs and EPROM memories anymore, it just makes no sense for the 21st Century.
It is a challenge to keep old wafer fabs running even if you have customers buying these ICs. The problem is the "tools" (the machines) in the wafer fabs are obsolete and getting spare parts to keep them running gets more an more difficult. This is why some semiconductor companies buy whole wafer fabs when these get shut down, for pennies on the dollar, and package the "tools" in dust proof containers to store them in warehouses. Only the clean room as such gets dismantled and is scrapped. For the 0.6um process node, the "tools" are some 30-40 years old, which is far past their typical lifetimes.
My own take as a semiconductor industry insider is that once the stock of warehoused "tools" is exhausted, 0.6um CMOS can't be produced anymore. This will have profound impact on some industries still needing these long obsolete parts. Military and Avionics will be most affected - these systems typically are already ~20 years old when they first enter service and the expected lifetime is 30-40 years, so the ICs inside are 50-60 years old. Quite a challenging logistics / maintenance nightmare !
"nrrd" also wrote:
" The 74AC / 74AHC series of chips have quite low propagation delay and are 5V compatible, so could it be possible to recreate the Apple II motherboard logic from these? I have both the "Understanding the Apple II" and "Understanding the Apple IIe" books by Jim Sather, and the logic looks feasible - of course the II and II+ used older 74LS series chips to implement this as you know. "
Uncle Bernie answers:
The higher the switching speed of these ICs, the worse the current spikes on the power and ground lines and possible ringing on signals due to reflections on non-impedance controlled PCB traces. It is unlikely that plugging in these faster ICs into an old Apple II motherboard would yield a working system. 74HCT is the better option (slower = less challenging !) but even that requires care. 74HC cannot be used in a TTL environment, as the logic threshold are mismatched. This is why 74HCT was designed: the "T" stands for TTL logic level compatibility.
"nrrd" also wrote:
" it has become very complicated over the past 5 years with the move to "the cloud", continuous integration, microservices, containerisation and orchestrated deployment of applications. AI is also starting to disrupt and complicate matters, and here I mean the hyped LLM and Agentic AI, rather than the machine learning and optimisation techniques we have always used in my field Hence my renewed interest in simpler computer systems."
Uncle Bernie's take on that:
Any company using "the cloud" has a high risk of their IP being stolen, and for classified technology it is a no-go to use software systems depending on the internet.
I have a highly critical stance on the LLM based "AI" systems they push now, and wrote a lot of comments on that here in Applefritter. They do have their applications, but can't be trusted with any mission critical work, and their inevitable "hallucinations" bring high risks with it and may lead to project deadline and costs overrun, or eventually to project failure.
IMHO, it may be cheaper and more efficient to debug the crappy code you can get written for cheap by Indian pseudo-programmers in India who bought their diploma in some Bangalore back alley.
"AI" made code, if it works, may be based on theft of IP the "AI" has skimmed from the internet. And if it doesn't work, it's incredibly hard to fix, so I was told by people in the know.
Quality programming work requires lots of skill and experience and mental discipline based on 100% perfect logic and reason. LLM "AI" does not have these traits, and never will have them, as it is just a maximum likelyhood statistical engine, and a very sophisticated one, that cannot be fathomed by human minds, due to the sheer complexity. And if it can't be fathomed, it can't be fixed if it is broken.
Still, despite of these issues, "AI" will be able to replace most human jobs who don't require real brains and skills, such as writing boilerplate legalese, make summaries from bloated texts, deny insurance claims, or produce mentally retarded slop appealing only to idiots, such as cheap novels, cheap screenplays, and braindead movies of the kind where somebody gets shot or things explode every 3 seconds. Throughout human history, the unemployed masses always needed "Bread and Circuses" to keep them from revolting and killing the "elites", and "AI" is absolutely great to produce the "Circuses" part, the entertainment, at the cheapest possible costs.
- Uncle Bernie
In post #13, "baldrick" wrote:
" ... I think that the best form factor may be the Apple IIc."
Uncle Bernie respectfully disagrees. Do not put the keyboard into the box with the computer. This only drives costs and makes the machine unwieldy. I'd prefer the smallest possible box with a plug for an industry standard USB keyboard. Not only is that more flexible and cheaper, but also more efficient for fast typists (like me) where the finger movements and key positions are hardwired in the neural network (the "wetware" between our ears).
"baldrick" also wrote:
"... with all the IIc features, but with an SD-card reader instead of an internal drive, but maintaining all the ports - modem, printer, video, smartport, mouse/game, along with, of couse VGA and/or HDMI video, and for fun, a slot extender"
Uncle Bernie comments:
good idea ! This is where my "Replica 2e"project is heading, although I don't want to integrate the floppy emulator on the motherboard, to allow the user to choose the floppy emu (s)he likes best.
"I would also convert video to the RGB standard or at least have that option, as there is nothing more annoying to me than Apple's pseudo-NTSC colour fringing on a modern monitor. It was barely tolerable on a CRT, but on a flatscreen it's difficult to look at."
Uncle Bernie comments:
This is a double edged sword. The "color fringing" effects of the original Apple II hooked up to a CRT based NTSC monitor were skillfully exploited by some software authors to "blend" colors and edges in subtle ways producing awesome and stunning visual effects nobody would expect from such a simple graphics system. If you use a pure 1:1, clean, digital pixel-by-pixel representation on a modern LCD (such as in a notebook computer running an Apple II emulator), these artistic masterpieces in most cases just look awful. This is why the better Apple II emulators apply some digital filters to approximate the bandwidth limiting and color blending effects seen with real CRT based NTSC monitors.
It seems that "frozen signal" is on this track, as far as I can tell from the picture in his post #6. Avoiding the Moire effect from the shadow mask of the CRT is definitely wanted ! But this has nothing to do with the "color fringing effects".
Modern LCD based monitors and TVs use digital filtering and resolution upscaling optimized for watching movies and most expect a 100% NTSC standard conforming video signal. This inevitably causes trouble with the slightly off-standard signal generated by typical 1980s and 1990s video game consoles (and home computers). When we designed the last generation of a TV chip set for CRT based TVs back in the 1990s, we had to add a detector for these off-standard signals and then switched to a very primitive alternate color decoder that was optimized for the best visual from these video game signals. This was for CRT, mind you. Any attempt to do this for LCD screens is even more involved. The Chinese companies designing these ICs for cheap LCD TVs don't care about this dwindling user group wanting to plug in 40 year old game consoles. And this is why you get these nasty stripes or even the dreaded "No signal" message.
- Uncle Bernie
Yes but...
Since the shell and keyboard have already been reproduced by MacEffects, it makes more sense to me to use the IIc form factor.
If you want an emulator with a plug-in modern keyboard, use AppleWin or Virtual II, or any number of software emulators that work perfectly well in MacOS, Windows or Linux.
If you want to replicate the experience, like they did with the Utimate 64, then you need to replicate the form factor, too.
I disagree. The Apple game ports were based off of analogue potentiometers, and any recreation would need to have recreated joysticks. Or at the very least the analogue portion of whatever flavour of game-pad you're wanting to use.
With regards to the ports, you put them there so you can connect legacy printers and (wifi) modems or other serially ocnnected devices. But a good recreation would probably have a wifi modem already built in to one of the serial ports so that you could easily run a terminal program like ProTerm to "call" a BBS.
Do you know of the Gemini Protocol? One of the areas I'd like to explore with an 8 bit computer is whether it would be possible to display and surf the Gemini-Web.
https://en.wikipedia.org/wiki/Gemini_(protocol)
Decrypting the TLS layer might be too processor intensive for a 6502, but it would still be worth trying.
I make such a project. 2 times in fact : a motherboard with Apple //c form factor then a motherboard for a Mac mini 2018 case.
Almost same functionalities for both :
• 128Kb SRAM
• 512 Kb Flash RAM (Prodos-512kB-NVRAM-Drive integration)
• Joystick port
• Super Serial (USB-C)
• No Slot Clock
• Tape in
• Smartport
• Disk ][ support
• USB/RF Mouse (A2 USB integration)
• USB/RF Keyboard
• Slots (only one on Mac mini board)
• HDMI (A2 DVI integration)
I used an EPM7128 for MMU/IOU
IIinaMac.jpeg
In post #17, 'baldrick' wrote:
" If you want to replicate the experience, like they did with the Utimate 64, then you need to replicate the form factor, too. "
Uncle Bernie comments:
I think there is a "market" - if we can label this tiny scene with that - for many possible solutions:
- those who want the cheapest possible way to play Apple II games, will use a software only emulator.
- those who want real "hardware" to touch and interface with the real world, will use an emulator running on some Raspberry Pi, and all the real world interfaces can be put in there.
- those who want "real hardware" which implements the real circuity, will go for an FPGA based implementation.
- those who want to be closer to the real 5V TTL based logic but don't want a huge motherboard full of SSI and MSI TTLs, will use a PAL/GAL/CPLD implementation.
- those who are "purists" will buy one of the clone motherboards and populate them with LSTTL and 16k x 1 DRAMs, essentially building a "clone" of a Y1978 Apple II.
This is the whole spectrum, as I see it, from ultra cheap to very expensive (for the price/performance ratio obtained).
Every individual out there has a budget and a personal preference.
Personally, I like the PAL/GAL/CPLD implementation the most. Because this is "frozen", obsolete technology which is static and won't change anymore, so no "maintenance" of HDL source code is ever needed. FPGAs come and go. And I don't like to use Verilog or VHDL at all. IMHO the former is a botched concept leading to ambiguities which must be "linted out" with expensive tools, while the latter is precise but very verbose. Despite being largely an analog IC designer, occasionally, I was forced to use both HDLs on the job to design the digital control sections for my analog stuff and always hated them.
This is why I use, for my private designs, a proprietary logic design language I developed and coded in the early 1990s. Just as an example, with my tools of 35 years ago, in Y2016, over a weekend, I created a custom data processing engine and fully simulated it. At this time, my proprietary tools were a quarter of a Century old. A digital design consultant hired by the company I worked for then needed 3 months to implement and simulate the same thing in Verilog. And he had big trouble with the multiple clocks of different speeds, which however were unavoidable due to the power dissipation constraints of the IC package - if the whole digital block would have been run from the same fast clock, then the IC simply would have overheated and died, after giving some smoke signals.
So you can see why I despise industry standard HDLs. They are not efficient at all and would steal too much of my time. Alas, to publish my stuff I'd need to translate it. Which is difficult. How can I tell these stupid industry standard CAD tools to synthesize the same logic ? I'm working on a solution based on the final equations, which is easier to do, but this is work in progress and the higher abstraction levels get lost. So far it does not work without some manual edits to the result.
- Uncle Bernie
There are a lot of people dissatisfied with Verilog and VHDL, which is why the last decade has seen a plethora of new languages, like Bluespec, MyHDL, et cetera. Mostly they compile to Verilog, since that re-uses existing synthesizers and simulators and allows linking in existing libraries. But the verbosity of VHDL also seems like the kind of thing that can be handled with editor macros.
These look great! I found your GitHub repo, so I'll try to understand what's going on. :)
These are not yours IOU, MMU,... at all, but leaked (intentionally, or not ?) Apple's schematics. I appreciate that info, there are much more interesting ASICs which schematics is needed. Without that leakage you would have stll been only "Frozen".
Normally, this was an opensource project. But the build process need time to be properlly documented. But the few times I talked about this project, I got not much interest. And in the worst case I even received negative feedbacks. So...
And meanwhile I'm taking time to take care of my father.
I hope he is doing well, and that you are too.
Thanks for all the info and opinions in the thread. I've been thinking about this, reading quite a bit around what would be involved in making an Apple II compatible, and looking at some of the very impressive cards that are available for Apple II systems.
I've come to the conclusion that the IIe is probably too complicated for a hobbyist to implement in any decent timescale. Or at least, this hobbyist!
However, the Apple II+ does seem possible, especially if the video circuitry is not implemented and one of the aforementioned cards is used to implement VGA video instead. Also, a lot of the circuit is the RAM chips and refresh circuitry, whereas a single SRAM would take care of this.
So, I'm approaching this by considering what is important to me, which is:
As always, plans might change and this could take a few years to implement. I'm fascinated by the idea of a 50 year computer, which some of the early home micros are approaching and still in use, whereas older PCs and Macs do not seem to have the same level of enthusiasm for them. I also think that the idea of computing as a hobby has been somewhat lost (at least by me) and I'd like a system to get back to that. Hence it should be understandable and expandable, and reward tinkering.
A KiCAD project has been started. I think I've got the signals for the peripheral bus sorted so far.
I think there are aspects of the Apple II architecture that you aren't considering. The DRAM refresh and video output circuitry are closely linked, because the same logic chips have both functions in the Apple. A VGA adapter won't work without that circuitry, because it "listens" to the bus while video/refresh is happening. That's why these modern video output devices are able to work without any software "driver".
If the Apple IIe design appears strange, remember that it still uses an 8-bit CPU. Machines with such constrained main processors need to locate more of their functionality in peripheral or memory hardware, because the CPU only can address 64KB at most.
This is a good point, and warrants further investigation.
However, the A2 VGA card I'm looking at the schematics of (here: https://github.com/Retrotink/Apple-II-VGA), the Raspberry Pi Pico is clocked by PHI0, which suggests that it is bus snooping the writes to the shared video memory, rather than during PHI1, when the video circuit reads the shared memory.
I have to fully investigate by reading the code, but if it does work as above, then I think my design should work.
I'm agree. A card like the A2DVI doesn't use video or DRAM refresh cycles to generate the image. They 'just' read RAM writes and softwitches accesses. My clones are using SRAM, and I don't reproduce video or DRAM refresh cycles during PHI1. Of course, software that uses vapor bytes won't work. But there aren't that many of them.
In post #25, 'kris92' wrote:
" But the build process need time to be properlly documented. But the few times I talked about this project, I got not much interest. "
Uncle Bernie comments:
I had the same experience with most of my own projects for the Apple-1 and Apple II world, such as the Apple-1 color graphics card, the Apple-1 floppy controller card (based on the famous 'Woz Machine' but augmented to be able to work with the refresh cycles of the Apple-1 which make precise CPU cycle counting impossible from the software side), the YAAK keyboard (for Apple-1 and Apple II) and its YAAKEN encoders, and last but not least my still unfinished "Replica 2e" which could have all the features for an Apple IIe compatible machine built with modern parts and no MMU and IOU custom chips which are unobtainable in their original form (FPGA based substitutes do exist, but are pricey, not out of greed, but due to the complexity with all these fine pitch SMDs and the added level translators and voltage down regulators).
For my 'IWMless' I chose to avoid these cost driving complications with modern FPGAs by using 1990s era 5V powered CPLDs, which still can be sourced at reasonable prices. This is the only project of mine which found interest from prospective manufacturers selling to the Apple II hobbyist scene, and I hope this plan comes to fruition.
Lack of feedback / desire to build
What I got as feedback/requests/praise for all these projects I published on Applefritter was, let's say it politely, "somewhat underwhelming", with maybe 2-3 people per project who contacted me, or posted their desire to build one, over all the 3-5 years. Sorry but for such few people I can't spend my time to write up building instructions and technical documentation.
The tariff fallout on PCBs
Then, in Y2025, came Trump's tariffs on Chinese goods which made sourcing of bare PCBs from China economically unviable and turned it into an impossible gamble due to the unpredictable "handling fees" which may be slapped on by parasitic/greedy carriers: you may order PCBs from JLCPCB worth $30, pay the U.S. tariffs (JLCPCB says they 'collect' them for you) and still may be surprised that the carrier slaps on some extra $60-$200 in "handling fees" which is nothing else than the criminal act of kidnapping parcels and holding them for ransom.
The only proper way to deal with that is to tell these greedy carriers that you refuse to pay the ransom and that they can FOAD. Theoretically, they then need to send the parcel back to the sender and they have no way to make you pay a dime for that. So they lose, and rightfully so, as a reward for their greed.
But you lose the PCBs you already paid for. Which would not hurt much if you paid the $30 they were worth, but you also had to pay for the shipping and for the tariffs, and then it hurts. So the better way is to refrain from odering PCBs from China, which means that most projects can't be built anymore by any hobbyist who lives in the USA. And the EU is also bad, they recently have jacked up tariffs and then they add their VAT which runs 20-25%.
If you don't want to feed these parasites and leeches, which should be a matter of iron principles, you can't import anything anymore. And domestic PCB sources (USA or EU) are too expensive once the area of the PCB exceed the size of an Altoids tin can. And this limits what hobbyists on a budget can do in terms of building hardware. Small projects still are viable, but anything of the size of a keyboard or a motherboard will get too expensive to be fun. And a hobby must be fun ! And not subject to blackmail and extortion by third parties.
So, what these tariffs did, they took the fun out of our hobby, at least for projects requiring larger PCB areas.
Let's see if the times get better in the near or far future. I'm patient, as I can wire wrap all my projects. But these are one-offs, prototypes. For adoption by others, having a PCB is a must. And that PCB must be economically viable to source.
- Uncle Bernie
In post #26, 'nrrd' wrote (in italics, my comments below them):
" Modern and available components - a 65C02, SRAM, Flash NOR as ROM. Clock speed target of 8 to 16 MHz. At least 512KB of RAM. "
Neither SRAM not Flash ROMs are a must. DRAMs work fine if the designer is competent, and their nature with the /RAS and /CAS strobes being edge sensitive can help with mitigating some timing issues commonly observed with the 6502 bus architecture. SRAMs may react badly to what happens after PHI2 falls ... and the faster and more modern these SRAMs get, the more finicky they are when being put into a 6502 based system. Higher clock speed is fine but you need extra logic to make the DISK II (or any other software depending on precise cycle counting based timing) work. My take on this is to have a "TURBO" button like on the first Taiwanese PC clones. And unlike with these clones, where it was always on, on the Apple II, it will be OFF (slow mode) most of the time: in TURBO mode, games will become unplayable, and the sound effects will turn into eardrum piercing shrieks.
" Understandable and fixable system - use CMOS logic rather than GALs / FPGAs. "
Agree with your rejection of FPGAs but GALs are plentiful, cheap, and easy to source. And easy to program, too. Also look into the ATF22V10 made by Microchip Technology. This one part which is still in production can replace all the GAL16V8, GAL18V8, GAL18V10, GAL20V8 and GAL22V10 types, if you have at least the logic equations to migrate the designs.
" Software compatibility is a bonus, not a requirement. I accept I might have to write or adapt drivers for the peripheral cards. "
This may apply to you, but you lose 99.9% of prospective adopters for your project. Don't do this. Be 100% compatible.
" The memory system in the IIe is pretty bonkers, and I don't think it would be designed like that if it didn't need to maintain compatibility with older systems. I think a better (more understandable and easier to implement) version would be ... "
As I mentioned above, 100% compatibility is a must. But if you want more RAM and a cleaner bank select scheme, you can always add it on top of the existing scheme, if you make sure that no software can ever inadvertently activate the extra banks.
My take on the Apple II video scanner peculiarities:
As for the issues with the video scanner access / CPU access interleave perceived / mentioned in posts #27-#29, these are non-isses, I have solved them in my Replica 2e, which is able to run the 6502 at up to 20 MHz clock speed while the video system still is fully Apple II compatible, so software can "see" the difference.
As for the "vapor lock" issue, 'kris92' wrote in post #29:
" Of course, software that uses vapor bytes won't work. But there aren't that many of them. "
It is trivial to implement bit vapors which are not 'vapors' (lingering charges on floating signal lines) to make ALL software titles using the "vapor lock" technique work. Added component cost is only 25 cents.
And I want to have that as I strongly disagree with the conjecture of "there aren't that many of them".
Actually, most good Apple II games use the technique, and may hang if the "vapors" are not implemented correctly. I think that many such titles have used a robust coding of the "vapor lock" technique which avoids endless loops in case of a problem with the "vapors", but some don't, and one of my favorite games ("DROL" from Broderbund Software) hangs in the "reunion" scene when the "vapors" are wrong, and this even affects some Apple II emulators. As it requires game playing skills to even get there, most people won't notice that.
And when the "robust" technique is implemented, most people won't notice failure of "vapor lock" either, because all what happens is that some movement of "sprites" (I know, I know, these are not real "sprites" but all done in software) will be jerky and look imperfect and annoying and sub-standard. One example is the game "BANDITS" where the actual game play is smoothly animated (only possible when using "vapor lock") but the intro screen is terrible, just look at the jerky movement of the vehicle that drives away from the "launch pad". This is what you get when not implementing "vapor lock".
The Apple IIe was the first model in which there was a hardware flag which would allow to find out if the video system was in the vertical blank period or not. This can replace "vapor lock" but does not help with software titles from before the Apple IIe.
CONCLUSION
Of course, you can build whatever type of incompatible 6502 based computer you want. But it will not find enough adopters to be worth the time and effort which goes into such a project. For instance, I do have some 6502 based computer designs which do have color graphics but are not compatible with anything. So I never bothered to publish anything about them. Simply not worth the effort to even write one page of paper. For me, these were just one-off experiments to see if my ideas would work. But they never could be turned into something that people would want to build.
The bottom line is, if your proposed project is not 100% Apple II+ or Apple IIe compatible, it's probably not worth doing. If you seek a one-off for yourself, fine, but then why you did post here on Applefritter ? I concluded from that you seek some adopters and then you must be Apple II compatible. Not sure if IIe compatibility is a must (it makes the project much more complex and more expensive to build) but II+ compatibility with 64k RAM (at least) is the minimum requirement IMHO.
My reason for this "minimum requirement" is that while the IIe introduced Double Hires graphics, there are only very few software titles who need it (i.e. "Battlechess") and are desirable to own and run / play. The "why" is obvious - software companies want to sell many copies and when a new model comes up, they at least want to have backwards compatibility. This is why so few "IIe only" software titles do exist.
AN OUTLOOK
I think a II+ compatible machine based on GALs can be built with only two dozen ICs, 7-8 of which are GAL16V8 (I had such a project on and off for 40 years, inspired when the first GALs came out in Y1986, but actually never built the hardware, as it was more a test bench for my CAE tools, but it so happens that I dusted it off earlier this year and I started to wire wrap it, not yet able to generate video, but it's work in progress).
- Uncle Bernie
Not so trivial since I do not have implemented video refresh cycles (since I only use A2DVI for video output). And since I'm only using a single 7128 for SuperSerial, SmartPort, Addresses decoding, clocks, softswitches, VBL softswitches, ... My 7128 is just fully used.
Some ][+ softwares were not compatible with the 65C02 of the //e. So, do you think the //e should not be referenced on AppleFritter too ??? I'm very surprised by this statement. I didn't know AppleFritter's rules were so strict and didn't encourage even the slightest deviations. Disappointed. Originaly, it was not a one-off, but as I explained earlier, after reading several posts like yours, I did not consider it necessary to spend a significant amount of time writing the how-to for such a project on github.
My goal with my //e clone was to have a compact Apple //e computer at home. I have a lot of Apple IIs in box (][ europlus, //e, //gs, stealth gs, macintosh, ...) But I do not have eanough place to use them at home. My idea, was to have a near 100% compatible //e fully loaded with the smallest formfactor.
The good thing is that it allowed me to learn a lot about the firmware and hardware of the Apple IIs. And owning an Apple II that I redesigned myself is a source of satisfaction.