Open A2 Firmware Specification

Seems to be an interesting idea, alas, I could not download the pdf from your github page ... the link can be clicked but instead of a download I get a "Not found" message.

So I can't comment on what you are doing except for this:

Apple II firmware-in-ROM is a "brew" made (and copyrighted) by two different companies:

Microsoft wrote the APPLESOFT BASIC and has the Copyright on it, and Apple was just another licensee. Microsoft "freed" the source code in September 2025 under a very liberal license, and as far as I seem to understand it, you can grab the source code, modify it, and make derivatives you can even sell for profit !

ALL the other code in the ROMs was written and is Copyrighted by Apple (the corporation).

This is the reason why you can find both "(c) Apple" and (c) Microsoft" messages on these ROMs.

It is quite interesting to explore where the boundaries between the two are in the actual code. I've rendered the source code from Microsoft for a more modern assembler and the result is here:

https://www.applefritter.com/content/uncle-bernies-rendering-microsoft-6502-basic

and if you actually run the assembly process you can see that roughly 2/3rds of the code came from Microsoft, and since September 2025 is up for grabs, not worrying about Apple's Copyright, because this part is Microsoft's. The other 1/3rd comprises graphics routines like the "Shapes" and what I'd call the "BIOS" of the Apple II, including the monitor program, and all these are very well documented in case of the early Apple II and II+ , the source listings were in the Apple II manual.

So it would be quite feasable to write a functionally equivalent for the 1/3rd of the code which is Copyrighted by Apple.

This has been done, back in the day, by one of the Taiwanese clone manufacturers, who simply bought a source code license from Microsoft and then wrote the rest by themselves, and IIRC, their ROMs were 100% legal, so Apple could not stop them.

However, I think that now, almost 50 years after the Apple II came out (in 1977), we should try to nudge / petition Apple to "free" their part of the Apple II ROM firmware, including the 256 Bytes long DISK II bootstrap loader, preferably under the same, or similar, MIT License which Microsoft used to "free" Microsoft 6502 BASIC.

This would allow the few hobbyists from all around the world who keep the Apple II alive to make kits including the original firmware-in-ROM, and there would be no waste of time amd no worries about software incompatibilities.

There also is one big risk with using LLMs (aka "AI") to "generate" source code because how that works, in the end, is that the LLM "steals" the original source code found on the web, and regurgitates it in an obfuscated way, as far as it "understands" it, and the outcome may be so close to the original code that any use of that code can be litigated. This happens regularly with works of art or writings or lyrics or musical scores, and it is litigated, and the first court rulings are in and the plaintiffs won, because the "work" of the "AI" was found to have been too close to the original(s).

If I wanted to be cynical, I could say that the business model of "AI" is fraud and theft of intellectual property and infringement on copyrighted works, where the "AI" obfuscates the fact of theft in a multitude of ways and the "AI" companies act as a "fence" (aka peddler of stolen goods) because they take money for that. Much the same thing as organized crime gangs sending kids into supermarkets for shoplifting according to a "order list" given to them and then fencing the stolen goods on Ebay, except that in the case of "AI", the "goods" are found on the internet and the "wish list" is made by the "AI" users who may not think that they incite the "AI" to commit a crime (theft of IP, infringement on Copyrights and Patents, etc...)

And unlike human thieves, the "AI" can't be arrested and hauled into a courtroom.

The whole legal situation about "AI" is very fluent and unclear now and it is not yet clear because "AI" being used in that way is a new phenomenon. But a whole flood of lawsuits have been filed worldwide against "AI generated" material which, the plaintiffs claim, infringes on their rights, and IMHO, if enough of these lawsuits get won by the plaintiffs, using "AI" for theft of intellectual property and artistic works will soon become untenable, and this questions the whole business model of "generative AI".

So, as far as I'm concerned, I'm not going to ask "AI" to write any code for me, because whatever the "AI" spits out, may be stolen IP or a plagiarization and hence, draw the wrath of the rightful Copyright or Patent owners. Unless the "product" made by the "AI" comes with a guarantee to not infringe on any third party rights, it's worthless and unfit for commercial use. (Not that our Chinese friends from mainland China would honor any Copyright or Patent anyway, but this is only because they can't be sued in a Chinese Court of Law).

This is the "Achilles Heel" of  "generative AI".

I don't want to go any more in details, but be aware that even if you ask "AI" to write a contract, it might produce a text which contains "boilerplate" grade legalese, but some law firm, somewhere, actually may have a Copyright on that text, or parts of it, and the same applies to any other work ripped off by "AI" which is practically inevitable if the "AI" was "trained" on such copyrighted or patented materials.

Just my opinion, and I'm not a lawyer, so don't take any of that as legal advice. I just wanted to point out the concerns I have about the use of "generative AI" to produce anything that is supposed to be sold commercially.  As long as the "AI" company does not give ironclad guarantees, in a legally binding contract, that the "product" of their "AI" does not infringe on any third party rights,  and that they would fully indemnify and hold harmless the user of that "product" in case of litigation by said third parties claiming infringement on their IP rights, I simply would not use that "product".

And I think the "AI companies can't do that, ever. And this means they will - most likely - fail to be a viable business. Unless they are so wealthy that they can bribe all judges and juries in all courts running such litigation. But this is is another topic. Just sayin' that all this is in unfathomable and treacherous waters I don't want to venture into. So I don't use "AI", ever.

- Uncle Bernie

Except for running ELIZA, I am taking a break from using “the word-guessing program” a phrase I attribute to Cory Doctorow.

WOZNIAC wrote:

To be clear, the scope of this project is exactly the “other 1/3” you mentioned. It produces a specification document only — no ROM code. The goal is to create a modern, living specification that could support clean‑room ROM implementations written by humans, very much in the spirit of the classic example you referenced. LLMs are used only to help synthesize the baseline text of the spe

The most notable cleanroom ROM implementation was the one done by Central Point Software (best known for Copy II Plus and larer aquired by Symantec) for VTech, the Hong Kong based clone (and later handheld, educational toy and wirelesss phone/answering machine) company for their Laser 128 line.  Unlike most other clones which Apple was usually able to successfully force off the market by legal action or threats thereof (like Franklin for example), VTech's machines remained on the market more or less until they quit selling like Apple's products largely did due to the onslaught of the IBM PC clone market.  The reason for this from what I remember back in the day was Central Point signed a separate license agreement with Microsoft for the 6502 BASIC code (Apple's license wasn't exclusive) and they painstakingly documented the clean room process they used to re-create the monitor and other Apple supplied/modified code.

It seems like what you want to do at least closely parallels what CPS did back in the day.  It's too bad that as far as I know nobody who worked for CPS back in the day is still around and active in the retro Apple II hobby.  Insde insight they could possibly provide would at least be very interesting.

VTech is still around but hasn't made any Apple II related products since the 1990s and Symantec is still around but probably nothing of the original CPS they purchased still exists except any IP rights.  Perhaps someone could reach out to VTech and Symantec to see if they would release those rights to the Laser 128 ROMs?  It's probably about as likely as getting Apple to do it, but it's at least a different possible angle.  The hardest part even if you can get someone there to communicate would probably be finding anyone who knows anything about it since the CPS aquisition was over 30 years ago, and VTech completely dropped out of even PC manufacturing almost that long ago.

In post #4, "WOZNIAC" wrote:

" It produces a specification document only — no ROM code. The goal is to create a modern, living specification that could support clean‑room ROM implementations written by humans ... "

Uncle Bernie comments:

Exactly. I fully agree. Once your spec is complete,  humans  should write the compatible code, without peeking at the original source listings in the Apple II manuals. I know it can be done, as it has been done (see 'softwarejanitor's post #5) and I've developed my own LORES and HIRES drivers for my Apple-1 color graphics card (which is 100% Apple II/II+ graphics system compatible, but currently I work on a redesign with extra features).

I also agree that this thread shall not be turned into a thread arguing about the legalities of so-called "AI" - but I found it necessary to point out the risks and pitfalls with it. I did look into the current "AI" quite a bit, because for me it's a very interesting technology, and it has it merits and some "legally safe" applications, but I did run a few test cases asking "AI" to produce code for very narrow and obscure applications, and I got the impression that it just "steals" from published works, with the twist of "obfuscation", for instance, the variable names it chooses are totally different (and may make more sense, BTW) but the algorithms - or the program "skeleton" - are the same as what has been developed by humans and can be found on github or sourceforge. I'm still trying to get "AI" to infringe on my own patents (long expired, because I'm that old) by asking it to "design" the same sort of device for me. This would fully prove my point / criticism of "generative AI". This is forensic work in progress. But as said, you can safely use "AI" to compile your specification document - I think it's a great tool for that - and then, as you said,  humans  should write the code. Once you ask "AI" to do that code writing it will - most likely - find the original copyrighted Apple code on the web, or an annotated disassembly, and give you a obfuscated version that won't be "clean" in the legal sense - it might be an aggregate infringing on the IP rights of several people other than Apple (the corporation) itself.

As for the release of the Apple II ROMs by Apple (the corporation), I'm trying to find a channel into Apple to make this proposal, but so far no success.

- Uncle Bernie

UncleBernie wrote:

...

Once you ask "AI" to do that code writing it will - most likely - find the original copyrighted Apple code on the web, or an annotated disassembly, and give you a obfuscated version that won't be "clean" in the legal sense - it might be an aggregate infringing on the IP rights of several people other than Apple (the corporation) itself.

...

Hmm, that sounds exactly like what a human might do... :)

In post #7, "CVT" wrote:

" Hmm, that sounds exactly like what a human might do... :) "

Uncle Bernie comments:

Exactly there is the problem: if you do a "clean room" copy of a device (or of software), you can't allow the designers/coders in the "clean room" to access any technical documentation of the company which made the original product(s), because the risk of verbatim copying of significant parts is too high. This, of course, is a simplified view, as some materials can be used, such as published sales brochures. Use any disassembly listing, or reverse engineered schematic,  you may get in trouble if you copycat product is ever litigated in a court of law. The whole topic on how to do a "clean room" design in the right way is too involved for this forum, but in the end it's two teams, one of which designs the functional copy, and another team which does the reverse engineering and testing of the copy against the original. This second team can only tell the first team where there is a discrepancy and which one and under which test conditions it appears and what the correct behaviour would be, but they can't tell the first team how the original does it on a circuit, microcode, or software level. All these communications are tracked and registered for defense in a possible later lawsuit. This process is extremely time consuming and expensive and hence, is only done if the "knockoff" product will be highly profitable and cannot be defeated by a lawsuit. There are a lot of stories out there how this was done for certain microprocessors and other ICs, and how the lawsuits went and were lost and won and why. If the "clean room" approach is not 100% "clean" and the plaintiff can prove that, the plaintiff will win in most cases and this will ruin the copycat(s). So taking the time efficient "shortcut"  by using "generative AI" to do the "work" is just too risky, at least for a business wanting to sell that "work", and this is why even as hobbyists we should not do that to make replacement Apple II firmware. This is because at some point, somebody would want to sell an IC kit using that firmware. While I think that it is highly unlikely that Apple (the corporation) would sue for millions of US$ in damages, they might send a "cease and desist" letter and this would be the end of the kit sales, and all the efforts would be wasted.

The bottom line here is that we need a "clean" solution that is really "clean", and this means we can't use "AI" to write the code, but we can have humans write the code based on "AI" generated specifications. Which should have the benefit of obfuscation of the source(s) the "AI" did use, so it might be a "clean" specification insofar as not not containing verbatim copies of critical materials which may have been "leaked" but still could be treated / labeled as company trade secrets. This may sound weird and nonsensical as once a "secret" has been leaked to the public, it ain't no "secret" anymore, but alas, the courts still can treat it as such. Hence, the human codes should refrain from looking into Apple's original source code or disassembly listings.

I think that making a "clean" replacement for the DISK II bootstrap loader may be the most difficult challenge, despite it's only 256 bytes long. The problem with it is that lots and lots of software out there jumps into that code in weird ways not recommended by Apple. Change anything, even the slightest detail, and this may break many software titles out there in the wild. This is why Apple (the corporation) marked this code as sacrosanct and frozen ("do not change anything here"). I tried to find a solution but no luck so far. All other firmware routines in the Apple II ROMs can be replaced by clean code which might even run faster at the expense of being larger in size, but this size issue can be solved with bank switched ROMs. Which would also take a lot of wind out of the sails of any possible legal action against it ... it would - very obviously - be a completely different thing. The bank select logic would fall back to the default pages containg the "official" entry points once a firmware routine returns to the caller outside the firmware. I think this would be a clever way to stay clear of the original, copyrighted code.

- Uncle Bernie

In post #7, "CVT" wrote:

 

" Hmm, that sounds exactly like what a human might do... :) "

UncleBernie wrote:

...

Exactly there is the problem: if you do a "clean room" copy of a device (or of software)

...

My point is that even before AI came into the scene, humans used to cheat the software "clean room" process by doing exactly what you described AI might do. Some got caught, but the ones that were really good at it and understood the process did not, and no one could prove that they cheated.

Of course, this whole discussion is purely academic, since in reality Apple doesn’t care about the Apple 2 firmware being copied and used in the 21st century. If they did, they would have taken steps to remove it from AppleWin during all these years that it came with it. Not only that, but in 2024 they started allowing Apple II emulators on their App store.

I don't think Apple has cared much about he Apple II firmware or any associated software they distributed or sold for the Apple II in at least 20 years.  They DO care about Trademarks though, even ones they no longer actively use like "Apple Computer, Inc" or the rainbow Apple logo.  So tread on those with care.  As far as firmware goes they haven't even showed much interest in supressing older Mac ROMs like  the 68k era, and less and less even PPC.  Even PPC is two major generations removed from the current ARM based architecture, so I would expect them to start losing interest even in the Intel era stuff before too many more years pass.

In post #9, 'CVT' wrote:

" Of course, this whole discussion is purely academic, since in reality Apple doesn’t care about the Apple 2 firmware being copied and used ... in 2024 they started allowing Apple II emulators on their App store. "

In post #10, 'softwarejanitor' wrote:

" I don't think Apple has cared much about he Apple II firmware or any associated software they distributed or sold for the Apple II in at least 20 years."

Uncle Bernie comments:

All professionally run companies have internal rules for when to sue Trademark, Copyright and/or Patent infringers. I don't know where Apple (the corporation) draws the line.

On the Trademark issue:

I agree with 'softwarejanitor' that Apple (the corporation) may see Trademark infringement as being something they must take action against in any case, and the root cause here is not reason and logic about how much such a defensive action does cost them vs. possible damages collected (is there a profit to be made ?), but Trademark Law which spells out that if the holder of a Trademark does not take action against Trademark infringers, then the Trademark gets weakened and may lose its protection. (This is based on an old book from the 1980s, so I can't say which rules and conditions apply today, but I'd think the "need to defend" is still there). It used to be that a "Cease and Desist" letter would be enough to count as such defensive action being taken, and if the infringer does not stop to use the Trademark, this can be litigated. But there is a backdoor (at least in some nations) - if a Registered Trademark has not been used by its owner for a certain number of years, you can file a request with the Trademark Office to delete this unused Trademark, and claim it for yourself.

I attempted that about 40 years ago which prompted the owner of the long disused Trademark I sought for my products to stamp their trademark "TURBO" on a few dozen four function pocket calculators and they displayed a basket full of them in front of a kiosk in the subway station near the Trademark office, and so they had their proof of using the Trademark, and my fees for the deletion request were wasted. AFAIK, they never used that stupid trademark again after that event (they made office machines like typewriters and calculators which are NOT known to be fast nor are they turbocharged) and a few years later they went out of business, which means all of their trademarks were up for grabs, but at that time I was not interested anymore in getting it, as my products were already obsolete at that time, and I had moved into the CAD software business.

On Copyrights and Patents

Copyright and Patent infringement is a much more difficult topic because proving such infringement in a court of law requires expert witnesses and rakes up huge costs for lawyer's fees, so the "internal rules" for those companies from which I had the opportunity to "learn" these rules said that they would sue only of they could rake in several millions of US$ in damages, or, if they could stop an infringer having really significant impact on one of their product lines.

Conclusions for the present Apple II firmware situation

This said, it is highly unlikely that Apple (the corporation) would sue some hobbyists over use of long obsolete but still Copyrighted firmware code which Apple did use in a product line they have abandoned to make several decades ago. The patents on the Apple II have long been expired, too. But a Copyright lives for 50 years after the death of the Copyright holder, and IMHO this is a flaw in U.S. Copyright law, because a Corporation never dies - unless they go bankrupt and nobody picks up the pieces as a new owner of the IP.

Apple (hopefully) won't go bankrupt so they will have the Copyright on that old firmware forever and ever. And don't underestimate the impact of this ... as a recent example, the Atari 8-bit scene has a huge problem because some weird company has allegedly - this company claims - bought all the Atari IP related to Atari's 8-bit homecomputer line, which - I think - went through several hands. But this weird companyrecently  took legal action against a replica of the Atari 800XL, and as the story is told on the internet, they claimed infringement on the industrial design of the enclosure, so even if the makers of that replica would have called it "Irata 800XL", or such, the weird company still would have leverage for litigation.

This is just one example that even the IP of long dead companies can "pop up" like zombies from their graves, to cause trouble for makers of replicas some decades after the bankruptcy of the original manufacturers.

My take on it

As fas as I'm concerned, I don't want any such surprises for my work, and so I call my Apple IIe compatible replacement "Replica 2e" (at the moment, the 'e' might go away) and I have developed an innovative code morphing technology which can use the contents of one (one !) original Apple II ROM to emulate, on-the-fly, but never in memory, all known versions of Apple II firmware. So this is my backdoor for the case that Apple won't "free" their ROMs in the near future.

I do not want to use some fishy weasel wording like "the ROM images can be found on the internet" - nudge, nudge, wink, wink - this is stupid and up to my ethical standards. I want a clean solution - plug in an original ROM salvaged from an Apple IIc (the much disliked "FF" ROM being the best candidate) - or use a "clean room" reimplementation of functionally identical code that has been written by humans. For which the "AI generated" specification proposed in this thread would be a good foundation, so I welcome this work, and hope it succeeds.

- Uncle Bernie

I agree that for the purposes you state that an unencumbered firmware would at least be greatly beneficial.  I don't do iPhone/iPad as I have Android devices and I'm not sure if the same issues exist with the Google Play Store when it comes to rules like that.  Given that I can't find a single Apple II emulator on the Play Store, I would guess it is probably an issue there as well to some extent.

The Disk ][ Controller Card P5 PROM that is relevant for booting (the other one is the state machine, and not really needed for most emulator implementations) is only 256 bytes and really the only entry point is the start.  What it does is position the head to track 0 (by pretty much brute force, which is why the rattle at boot) and then find and read sector 0 into memory and run it.  Very little of anything ever calls into anywhere else in that code.

FWIW, a lot if not most of the clone controller cards back in the day more or less just copied Apple's P5 boot code directly, and that was rarely ever anything Apple complained about.  They didn't go after 3rd party floppy drive products much, even though they obviously competed directly with Apple.  The target of their legal intimidation was mostly the actual clone units themselves, Franklin Ace 1000 being the most prominent target as one of the more popular US made clones.  Of course they also worked to block imports from places like Hong Kong and Tiawan, Orange, Pineapple, Unitron, etc.  To get around that a lot of clones came in as parts with no ROMs installed on the motherboards and then they were assembled and EPROMs were burned and installed at local clone shops which were mostly too small and de-centralized to get the direct attention of Apple.

I also agree that the pressure on a firmare image for the purposes of an emulator to be 110% perfect is greatly lessened if the user has an option to supply their own image.

WOZNIAC wrote:

Are you aware of any specific Apple II emulators currently on the App Store? I haven’t been able to find anything other than ActiveGS (Best of FTA), which is essentially unusable in its current form. Provenance doesn’t include an Apple II core. RetroArch (MAME) would be the other obvious candidate, but the App Store build doesn’t ship with Apple II support, and App Store rules prevent downloading additional cores, so there’s no way to enable it.

...

I only know of ActiveGS as well and I read somewhere that RetroArch is working on the Apple II part. But if there is a change in policy, I am sure better quality emulators will follow.

Relevant links:

Call-Apple: https://www.callapple.org/emulation/activegs-best-of-fta-back-in-the-app-store/

App Store: https://apps.apple.com/us/app/activegs-best-of-fta/id405115025

WOZNIAC wrote:

...

Because of that, I currently believe that a functional, unencumbered ROM is a key requirement for maintaining an Apple II emulator on the App Store over the long term. Without it, any emulator is always at risk of rejection or blocked updates.

...

This can cause a different problem: some programs for Apple II purposely only work with the original Apple II firmware. ProDOS prior to version 2.4.1 is one example.

It is mostly copy protection schemes that fail due to detection of non-Apple firmware.  A few games do a ROM checksum and refuse to run if it doesn't match.  I suspect this was because of crackers use of things like the Freeze's F8 ROM.  One thing of note is that these copy protections usually only work on one or two particular series of machines.  Like for example only on a ][+ or a non-Enhanced //e.  Often they will fail on the Enhanced //e or //c, because those machines didn't exist when the program was released.  I remember encountering one protection scheme back in the day that would lock the machine up if it detected a ROM card in the machine, because I assume they knew people like me were going to use that in order to switch in a non-Autostart F8 or a modified one like Freeze's.  That was one of the main ways I cracked software back in the day.  That along with a card to generate the NMI signal.  Those simple methods worked on quite a few titles.  But I digress.

In the case of ProDOS's ROM checks, it was mainly to keep it from running on clones like the Franklin.  If I remember right, they looked for specific values in the ROMs, not an entire checksum.  There were also patches to get around that back then.

Anyway, I wouldn't worry about it so much because as I say, titles that are that picky about running like that usually have issues with a lot of authentic Apple supplied hardware as well.  And obviously a lot of common clones like the Franklin, Laser 128, etc, will probably not work with them either.  If it runs the vast majority of titles, then it still serves pretty well.

And since it is primarily copy-protection that causes the problems, a lot of titles that won't run from original media there already exist cracked versions which may work.

If someone is developing a new emulator or enhancing an existing one, something to keep in mind is that if the option to substitute a different firmware is there it would be even better to be able to easily switch between multiple different ones, say, ]the open one[, ][+. original //e, Enhanced //e, //c, etc.  Some emulators also allow switching between different CPU personalities, like original 6502 vs 65C02.  I don't know if any of them have separate modes for the slightly different  instruction setvariants of 65C02 , the common one, Rockwell, WDC, etc.  A useful thing would also be to have a 65802 mode for a //e emulator as that is something that can be done.  I've got a couple //e which I put 65802 in.

In post #16, 'CVT' wrote:

" This can cause a different problem: some programs for Apple II purposely only work with the original Apple II firmware. ProDOS prior to version 2.4.1 is one example. "

Uncle Bernie comments:

Can you enlighten us more about this issue ? How does any ProDOS prior to version 2.4.1 check if it's the original Apple II fimrware-in-ROM ? By a checksum ? How difficult would it be to knock out the checksum check ? Changing more than one or two bytes in PRODOS ? Or, depending on which checksum algorithm is used, how many bytes need to be tweaked in the new ROM to yield the same checksum result (trivial for sums, less trivial for CRC, but with 21st Century computing power, any such algorithm that was feasable to run on a 1 Mhz 6502 can easily be defeated by brute force, not much cryptographer's skills needed anymore).

In any case, my "code morphing" technology is immune to that but as it is hardware and requires an original Apple II ROM, it can't be used for a software only emulator. What the "morphing" process essentially does is to provide the ability to "morph" the later original firmware code back to earlier versions, without needing any copy of this earlier code being physically present. So in the specific case of my Replica 2e, if you plug in the original Apple IIc ROM version "FF", and select IIc mode, the morphing circuit is deactivated and the 6502 "sees" the unchanged code from that original ROM, and as this ROM is an original ROM coming out of a real Apple IIc, there is no legal leverage against it. If you then select, say, an early II+ mode, the morphing circuit turns on and changes the Apple IIc code into the II+ code, on-the-fly, and as no actual image of the II+ code is ever present anywhere, this is no Copyright infringement either (I think, but I did not yet spend money on expert opinions on that).

However, I'd prefer that Apple (the corporation) would "free" all these old Apple II ROMs in the same way, under the same MIT license, as Microsoft did "free" their Microsoft 6502 BASIC. This would save us (the Apple II aficionado community which keeps the "spirit" alive) from technical crutches like "code morphing" or spending many man-years on rewriting code, just to stay legal. But if we can't find a way to nudge Apple (the corporation) into giving us that freedom, we at least know ways to dodge the Copyright issue. But be warned ... it must be dodged cleanly, without any Copyright infringement, and all the hints in this thread to just ignore this issue (or call it "academic") is no good advice.

The key point here is that there is a big difference between a hobbyist throwing some emulator with the binary images of the Copyrighted ROMs "over the fence", up for grabs, on some more or less obscure websites, and actually selling such an emulator or IC kits to build a functionally equivalent of an Apple II. And I think that the ability to sell such a kit which is free of any Copyright infringement is a requirement, otherwise, the whole "Replica" mission falls apart because most people who would want such a kit (despite I'd not expect a larger "crowd" than three figures) would want a complete solution, "batteries and ROMs included". Otherwise the three figures "crowd" of prospective builders of such a kit would - most likely - quickly shrink to a few dozen hard core enthusiasts which are willing to tackle the "missing ROM" issue in their own way. And designing a PCB and a builder's manual for just a few dozen people worldwide (from 8+ billion people on the planet) is simply not worth the effort and time expended.

So far my thoughts about the issue. There is still a lot of time until I need to make a decision how to proceed with my "Replica 2e" project, as it still lacks some subblocks in the circuitry, such as an Apple IIc compatible mouse interface. As I did not intend initially to support an Apple IIc mode, I left this mouse interface out of the design of my IOU replacement. But once I had the 'IWMless' up and running, I got the itch to add a IIc mode, too. And until all this work is done, I'm hopeful that some solutions for the firmware ROM copyright issue other than the code morphing is available (the code morphing engine is spread over several ICs which I'd rather strip out of the design, if I could).

- Uncle Bernie

If memory serves, the ProDOS ROM check was looking for "APPLE" at a certain spot in the monitor ROM code.  And yes, there was a patch available which disabled the check so that ProDOS could be used on machines like the Franklin ACE 1000/1200.  Some people also replaced the EPROMs on their Franklin machines or other clones with copies of Apple's ROMs.

softwarejanitor wrote:

If memory serves, the ProDOS ROM check was looking for "APPLE" at a certain spot in the monitor ROM code.  And yes, there was a patch available which disabled the check so that ProDOS could be used on machines like the Franklin ACE 1000/1200.  Some people also replaced the EPROMs on their Franklin machines or other clones with copies of Apple's ROMs.

That is correct and that spot in the ROM happens to be what is displayed on the screen then the machine boots. The patched version was pretty popular in Bulgaria as well, since the original ProDOS would not work on any of the Pravetz machines (they all displayed ПРАВЕЦ) and version 2.4.1 of ProDOS would not come until 2016. Most of the ProDOS disk images on Asimov come with an earlier version of ProDOS, which does not contain the patch. So this new firmware you guys are considering will have to violate Apple's trademark by displaying "APPLE" if you want all these ProDOS titles to work on it. But assuming that Apple would care (I am 99.9% sure it does not), that might be OK, since the machine being emulated is actually Apple II, so what else are you supposed to call it‽

WOZNIAC wrote:

...

Apparently there is indeed more to this check than a simple string compare. Based on the description in the article, it looks like the function ProDOS uses is specific enough that other byte patterns might be able to satisfy it, without needing to reproduce the original “APPLE ][” sequence at $FB09–$FB10, as Uncle Bernie suggested.

 

Thanks for pointing this out!

To play with that you can download older versions of ProDOS from their official site: https://prodos8.com/releases/

AppleWin is also a good tool, since it is fairly easy to switch to a clone firmware, like a number of supported Pravetz machines. Furthermore, you can modify the various firmware ROMs directly from the EXE file using the free Visual Studio 2026 Community edition. Simply open AppleWin.exe in the Resource editor and you can modify any of the firmware under "ROM" in a Hex editor:

AppleWinResources.png

The numbers correspond to the following IDs:

   APPLE2_ROM: 126

   APPLE2_PLUS_ROM: 127

   APPLE2E_ROM: 129

   APPLE2E_ENHANCED_ROM: 130

   PRAVETS_82_ROM: 140

   PRAVETS_8M_ROM: 141

   PRAVETS_8C_ROM: 142

It would be interesting if someone modifies any of the firmware ROMs to show something other than APPLE and still boot an older version of ProDOS.

Btw, in the upcoming firmware release of my ESP32 SoftCard I am also adding an Apple II emulator and the firmware ROMs will be simply located on the SD card for easy manipulation.

In post #26, 'CVT' wrote:

" It would be interesting if someone modifies any of the firmware ROMs to show something other than APPLE and still boot an older version of ProDOS. "

Uncle Bernie comments:

Ouch ! Had I known this before, it would have saved me a lot of time wasted with experimenting with my PC-48, a Taiwanese clone. They had copied the Apple II+ ROMs verbatim except for the "APPLE" string which they - of course - had changed to "PC 48", and so I lost a lot of time trying to make it load PRODOS, but then, finally, I suspected some ROM differences and put the right ones in, and it worked ! (The irony here is that I do have several original Apple II motherboards, which don't work anymore, most likely due to their low quality = cheap IC sockets, but their ROMs can't be plugged into the PC-48 because the original Apple II ROMs have a mask programmable chip select feature, common for mask ROMs at the time, which EPROMs don't have).

Telling this story here because it might be that it was the PC-48 clones which made Apple put the test for the "APPLE" string into PRODOS. The PC-48 was very popular in Western Europe. The Pravetz clones also could have been the target, as they also had a different text there, but AFAIK, they never were sold in Western Europe, at least not in any significant numbers. But all the computer shops were full of Taiwanese clones of both the Apple II and its slot cards. The originals were just too expensive, and the reason was - tariffs !  Criminally high tariffs to protect the incompetent and uncompetitive European computer industry against the flood of microcomputers coming from the USA. The humble price of $800 or so for the original Commodore PET-2001 turned into 3000 DM despite of a US$/DM exchange rate in Y1978 was about 2DM. No wonder why the original Apple II were too expensive for most people. It was the tariffs ! Commodory responded by opening an assembly factory in Germany, to dodge these heinous tariffs. Apple did not.

But back to our "compatible firmware" project. I had an epiphany which I want to share:

Why not use an emulator to find out which entry points are used by software titles ? The emulator code could be extended to track all entries into the ROM space originating from RAM. By running a lot of software on such a modified emulator, all the ROM entry points software uses could be mapped. And the self-running demos of "Total Replay" could be a good automated way to start this. Because otherwise, you really would need to play the games ... which is very time consuming. Maybe "AI" could be nudged into playing the games ? The question here is if "AI" could do that at all, understanding the rules of a game and then playing it via keyboard and joystick commands. I doubt that. Could be a good test for the capabilities of "AI". It could also slow down the emulation as needed to keep up with the gameplay. This would allow for a cheaper platform to run the "AI". Fascinating idea, I think. Let "AI" play 40 year old computer games to find out the ROM entry points. If the "AI" fails, can't do this, in the digital trashcan it goes ! I think it would be very interesting to test "AI" with that, it's not just a game - this could provide insights into the true capabilities of "AI", the only problem I see is how to write the interface such that the "AI" can play these games. (You might ask why use "AI" to do the game play and not just analyze the code of the game - the answer is that static code analysis will only find obvious JSRs or JMPs into the ROMs in the resident part of the game code, but many games load overlays from disk, and unless there is an efficient ("AI" ?) way to get there, the work will be too tedious, too time consuming, and, hence, very likely incomplete).

Once we know all the entry points, those into Microsoft BASIC require no coding work, as Microsoft has "freed" their 6502 BASIC for use by third parties. And for the remaining entry points,  functionally identical routines could be written. If Vtech finds and releases their code (see post #22 by 'WOZNIAC') then this would speed up the work considerably.

- Uncle Bernie

UncleBernie wrote:

Why not use an emulator to find out which entry points are used by software titles

 Lua could be used to do this. Check out the A2Desktop foray into this.

Also, the APPLE ][ string checked by early ProDOS can be still be used while displaying a different string on boot. The //c for example does this. Just modify the TITLE routine in the F8 ROM to look elsewhere. While keeping the APPLE ][ string where it is.

WOZNIAC wrote:

...

Changing $FB09 to $C0 ("@PPLE ][") allows it to boot.

...

Yes, in AppleWin also changing the A to @ in the Apple IIe ROM lets ProDOS 2.4 boot, while changing the A to B does not.

ATppleIIeFirmware.png

ATppleIIe.png