Uncle Bernie's "Replica 2e" (WW Prototype of an Apple IIe replica)

In post #5, "frozen signal" wrote:

" There is another replica project done by Henry from ReactiveMicro. It's not available right now but he sent me a pre-production version last september so I could test my IOU / MMU replacements. At first, I thought that this was an original board. Every detail has been replicated. "

Uncle Bernie comments:

Pleeeeeeeezzzze do not call a "clone" by the name "replica". What you and Henry have done is to make a "clone" of the Apple IIe, not a "replica".

I do not want to be nit-picking, but ambigous and inaccurate language about the Apple-1 "clone" versus Vince Briels Apple-1 "replica" has cost me hours with emails clarifying the differences and some posts here in Applefritter. The habit with people throwing both terms into one pot also has caused a few people to buy the wrong thing - they bought the components for building a Briel Replica-1 and not the components to build a clone based on my famous IC kits (now sold out). And then they approached me and whined about having been lured into the wrong corner of the Apple-1 scene. Sigh !

IMHO, both "clones" and "replicas" have their purposes and a right to exist. I really appreciate your project to make a "clone" of the Apple IIe, and I might even buy one of Henry's kits, if the price is right, because the only Apple IIe I have is the PAL version, which does not have the proper NTSC colors. (The previous owner of this Apple IIe was into CP/M and never had a color monitor attached to it, so he didn't care  about the colors issue)

At minimum, I'd need one of your MMU replacements because my MMU original was damaged during the reverse engineering process (not ESD, which I keep under control, but a pin now has no internal connection anymore, which could be bond wire contact failure from mechanical stresses when putting the IC in and out of sockets all too often).

Proposal for the use of  the term "clone":

A faithful reproduction of the original hardware down to the smallest details, same PCB board layout, same IC set, same circuit, same firmware in ROM, in other words, the same "genetics". For those being unfamiliar with genetics, remember the "Clone Wars" from the fictional Star Wars universe, were all the clones came from one warrior prototype, and all had the same genetics, the same DNA. In the real world, we can't clone humans yet. But a sheep has been cloned (allegedly) and there are rumors that Chinese billionaires pay a lot of money to have their pets cloned. There seems to be an underground cloning industry, if this is true. Note that in your case, frozen_signal, your IOU and MMU replacements do not really qualify as "clones" as they are NOT faithful reproductions of the originals in the strict sense - to get there you would need to use the same full custom IC layout / photolithographic masks and run a wafer lot on a NMOS process (which does not exist anymore). So you have a border line case of "clone" with drop-in substitutes for the unobtainable original custom ICs. Fair enough. I would still call the resulting machine a "clone" as long as your IOU/MMU substitutes drop into the same DIL-40 footprint. Similar borderline cases exist in the Apple-1 world when people substitute the 2519 with a small daughter card - this even deviates more from the "clone" ideal. But even that I'd still call a "clone".

Proposal for the use of  the term "replica":

A reimplementation of the original hardware using different ICs, different circuits, different technology, different PCB layout and size. The goal of a "replica" is to provide the same functionality as the original hardware, as far as the software running on it is concerned, using more easily obtained components, and at a much lower price point. The Briel "Replica 1" is a good example for that. Note that a "replica" can be "dressed" to have the same "looks" as the original, if the PCB is hidden from sight in a suitable enclosure. Such a "thing" would deceive an observer and give him/her the same user experience - until the lid of the enclosure is opened. This is an excellent option for computer museums who want to present a "live" Apple-1 to their visitors at a budget.

Of course, my above proposals for a more concise wording to distinguish between a "clone" and a "replica" of computers is NOT canonical - yet. It's just my attempt to prevent confusion of prospective builders / buyers of kits.

I'm well aware that dictionaries define "replica" to be "an exact copy or remake of an object made out of the same raw materials. The term is also used to closely resemble the original, without claiming to be identical".

So here you have it, the term "replica" is already blurred and imprecise as it gets. I've seen "replicas" of the 1970s Lamborghini Countach based in a VW Beetle chassis and engine. These things really exist ! They even were reduced in scale somewhat. But they were public road legal, could be driven, and from a distance  (and the engine off) nobody could tell the from an original. Whereas a "clone" of the same car would be a faithful reproduction down to an exact copy of the famous V12 engine.

Maybe I'm jousting against windmills here, but I think my proposed clearer distiction between "clones" and "replicas" at least in the Apple computer world would be helpful for the common cause by avoiding undue confusion of onlookers and prospective builders / buyers about what they would get.

I will never make a "clone" of the Apple IIe. I want a much smaller, cheaper, solution which is  more hackable than a "clone" can ever be. "Purists" of course would go with a "clone". Hardware hackers and cheapskates like me would want a "replica". You don't want to hack a "clone" to try out things. I did that with a few Apple-1 clones I have built and the outcome is always ugly, cut traces and criss crossed flight wires everywhere.

I think the Apple IIe is the best and most interesting version of the Apple II line. It has all the desirable features like 80 char/line text and 128 kBytes of memory built right in. And Woz always wanted it to be a hackable machine which can be modified by the user. But some of the "hackability" was lost when the MMU and IOU custom ICs were introduced. The intent and purpose of my "Replica 2e" project is to bring full hackability back and create a robust development platform which can serve multiple purposes. Think of a "universal" 6502 platform. Of course, it would be great to have a PCB for that. But I need at least 20-30 takers for such a PCB to justify the time and effort to design one and have it produced.

But right now (and in the following weeks) I must focus on bringing all the extra functions online. This morning I modified the MMU EP910 so I hope I can do a first try with the original Apple II firmware this afternoon. It will be Apple II+ and not IIe yet (I anticipate that the IIe version may not recognize the keyboard yet). But I will make all of that work, step by step.

- Uncle Bernie

In post #12, CVT wrote:

" The use of the word “replica” by frozen signal is correct. It means an exact clone. "

Uncle Bernie agrees, and I'm very well aware of how "clone" has been (mis)used in the computer world. This use of the term "clone" which came from biology / genetics always has been incorrect as far as the computer world is concerned. In other words, in the computer world, the term "clone" has been misused since decades, and as a consequence has assumed a different meaning compared to biology / genetics. Only recently with the "vintage computer" scene  using the term "replica' and 'clone' indiscriminately, there has been confusion.

I just wanted to point out how we could avoid such confusion between the terms "clone" and "replica" in the Apple  computer world by adopting  a new convention which is compatible with what we have as specimen (Apple-1 "clones" definitely being not the same animal as a "Replica 1").

But as I remarked in my post #11, it's jousting against windmills. Typical computer people don't know anything about genetics, nor do they care.

I'm still worried about the proper naming conventions. How can I name my Apple IIe - ish "thing" without deceiving people into thinking it is a perfect reproducion of the original PCB which drops just right into an original Apple IIe enclosure ?

- Uncle Bernie

Hi Fans -

Other than the fruitless discussion about proposed non-confusing use of the terms "replica" and "clone" (above) some more progress has been made. After making a few edits to the MMU's EP910 the machine is now able to run 12kBytes of firmware ROM (and not only 8kBytes which was only enough to run the DRAM test).

But there have been some observations which spell T-R-O-U-B-L-E for anyone engaging in building an Apple IIe replica (or clone) ... now I'm myself not sure anymore which word to use, after the rebuttal against my proposal by 'CVS' in his post #12.

Here is what happened this morning.

After the MMU upgrade, I put in an EPROM with the image of a 12k firmware version which is supposed to autostart "Applesoft" BASIC if no disk drive is attached, and to boot the floppy disk if a disk drive is attached.

It did neither. Instead, after power on it just gave the "Apple ][" message and entered Applesoft but the BASIC did not work properly. It would accept a new BASIC program entered manually and this would list OK, but after RUN the BASIC would complain about a syntax error in a BASIC line number which did not even exist (and could not be deleted).

And worse, after power cycling the machine with a brief pause before power up, THE SAME BASIC LISTING WAS STILL ON THE SCREEN !

This is known as the ATARI 800XL DISEASE (and may have led to the demise of this otherwise fine Atari 8-bit computer).

Here is a little bit of history and how this is relevant for Apple II replicas or clones:

There was a time in the mid 1980s where computer discounters dumped Atari 800XL (and the occasional 600XL) dirt cheap. They came in the original box, but it had signs that somebody already had "pre-owned" these machines, as the boxes showed signs of wear and tear. The Ataris inside looked new. But most likely, they were warranty returns. They would turn on fine the first time and accept typed in BASIC programs. But if power cycled, they would crash. Even if the desperate owner would wait for a minute, or two, before turning on the power again, they still would crash or the BASIC would just not work properly. (See a connection to our Apple topic above now ?)

My root cause analysis at that time (~1985/86) came to the following conclusion: When Atari designed the Atari 400/800 back in the late 1970s, after 1977 or so, the 16k x 1 DRAMs of the time were still a bit ... imperfect. This means that they worked just good enough to be sold, but they would be forgetful, as is expected with DRAMs. The small charges stored in the DRAM bit cells would leak away quickly, in a matter of a few 10's of milliseconds, and so the RAM would lose its contents unless that contents was regularly "refreshed" - which is why there are refresh cycles in any machine using DRAM. Turn the power off and the refresh cycles go away, and soon after, all the bits crumble away, too.

Atari engineers did exploit this fact to let their firmware-in-ROM find out if it was a "cold start" or a "warm start" for the machine. By storing a $00 or $FF value (bad choices !) in a zero page location (IIRC, $08) they could determine if it was a cold start (from power up) or a warm start. Or so they thought. Which later turned out to be a fallacy:  Only in case of cold start they would initialize the built-in BASIC.

Applesoft BASIC seems to do the same stupid  thing with the same stupid consequences.

All this DID work fine in the first decade of the "golden age of home computers", but only until the semiconductor industry ran into massive yield and quality issues when attempting to build the next generation of DRAMs (which had even smaller bit cells, and hence, even smaller charges to store information, which leaked away too quickly for the targeted refresh cycles). As a remedy, massive investments were made both in the wafer fabs (more cleanliness in the clean room, better tools, purer process chemicals) and in the wafer material itself. The Japanese were leading the pack. And soon, DRAMs "Made in Japan" would never forget - even when the power was turned off for a few minutes. This sabotaged the cold start / warm start discrimination of legacy systems. Some bits would crumble away, though, but if the byte at the cold start / warm start detection address did stay the same, the BASIC would do a warmstart and try to work with that crumbled mess. Which caused a plethora of weird symptoms. Leading the buyers of these machines to bring them back to the dealership. Who sent them back to Atari. Atari turned them on (once) and they worked fine. Back to the dealership they went. A vicious cycle ...

CONSEQUENCES for 21st Century Apple II replicas or clones

We need to find a way to fix the warmstart / coldstart discrimination process which just won't work anymore with modern DRAMs.

One way to fix it is to keep a stash of older DRAMs around which are forgetful enough under temporary power loss. This is how I fixed my prototype, I replaced the two main RAM ICs (Samsung KM41C464P-8) with a "016" date code (whatever that means) with much older ones made in 1986 (NEC D41464C-10). Which are forgetful enough, but still need a few seconds of waiting (maybe 5 sec) before the power can be turned on again to get a cold start.

Another way is to put some more sophisticated hardware and firmware in which intercepts the RESET vector, looks for a real, hardware 'cold start' flag, and when in coldstart initializes the relevant RAM addresses (or address ranges) with a value appropriate to cause a real cold start from the otherwise unmodified Apple firmware.

THIS PROBLEM IS REAL !

Don't underestimate it. Unless a solution is provided, none of the clones / replicas will work as intended.

AFTER THE DRAM SWAP: SUCCESS !

With the older DRAMs, Applesoft BASIC worked fine, and with a standard Disk II controller plugged in, I was able to boot the game "Frogger":

PDRM4510B.jpg

If you know this version of "Frogger" you might notice that the truck now is really red, and the frog is really "froggish" green.

These colors don't exist in standard Apple II hires graphics. This is no bug in my prototype, but the effect of an addtional trick I put in, which instead of the usual four allows for eight colors plus black and white (the latter two, strictly speaking, are no "colors" at all, as they are "shades". Again, sloppy use of words by computer folks, much like with "replica" and "clone".)

The jury is still out if this very cheap trick (one added macrocell in the timing GAL) really brings a new useful color palette or is just too cheap and dirty to be useful. More tests will tell.

So far the state of this work as of today. More things to do. Need to get the "open apple" and "closed apple" keys in and make the machine ready to run the real Apple IIe firmware. It also still lacks sound and the cassette interface, for those there is only a wired up space to plug in a to-be-built module yet. This space is in the right corner of the circuit board, just where the white  power rail ends.

Stay tuned !

- Uncle Bernie

In post #17, "CVT" wrote:

" Could the cause of the issue be the required initial pause difference between the NMOS and CMOS chips ?"

Uncle Bernie answers:

No, this requirement has nothing to do with the fact that the legacy cold start approach does not work when the DRAM has the audacity to keep the contents of the coldstart indicator address intact even when power is off.

The 200 us pause looks to me as if a substrate back bias charge pump is involved, which needs to pump the internally generated negative voltage to a sufficient level before the other  circuitry really is ready to be put to work. On the older NMOS DRAMs with the extra -5V supply voltage pin there was no requirement for any such charge pump.

Lattics GALs, BTW, also need a small wait until their internal charge pump has generated the substrate back bias.

But typically, the power on RESET period is set such that it is orders of magnitude longer in duration than these humble time allowances demanded by the DRAMs (or the GALs).

I've actually analyzed the issue with these DRAMs foiling the naiive coldstart detector schemes by having long data retention even in power off very thoroughly. It was a huuuuge issue back in the 1980s and a lot of companies were hurting because the newer and better DRAMs caused trouble for their stupid tricks. I don't think that any seasoned digital designer who was active in the 1960s minicomputer arena would have fallen into that trap. Because these minicomputers (the likes of DEC PDP-8, PDP-11 and Data General Novas) used magnetic core memory which does not forget its contents neither when the power is turned off. If the write drivers were properly designed and gated during power down and power up, you could turn off such a machine in the evening and come back next morning to turn the power on again, and your program and data would still be there in the core memory. Just toggle in the address where you did stop the program, and turn rotary switch from "operator" to "run" (or whatever that was named) and your program would resume running where you stopped it, with all the work intact.

- Uncle Bernie

In post #21, "reifsnyderb" wrote:

  " Is there any way this color change, to add two more colors, could be "added" to an Apple II Plus ? "

 Uncle Bernie answers:

 It's actually a very trivial mod as long as you are willing to write complex software that is "racing the beam" like all the programs in the Y1977 Atari VCS (aka Atari 2600) do. You see, the mod itself  only adds ONE macrocell in the timing PLD and I think two TTLs added to the Apple II or II+ which have no  timing PLD (the "TMG HAL" of the Apple IIe/IIc) could do the same trick, just adding a half M14 clock delay to the video dot stream, and having a 2:1 MUX to select between the normal and the delayed bit stream.

Controlling the color palette change

 Where the complications are is how to tell that MUX which position to assume. The Apple II has no unused  bits in the video bytes: seven bits are for pixels, and the MSB is for the phase shift to turn the two natural "color artifact" colors into four. The earliest Apple II did not have that phase shift control bit, and hence, had only two artifact colors plus black and white in HIRES mode.

 The most rotten trick I can think of to add the extra phase control bit for eight hires colors would be to slave a part of the user program to the screen scanner. This is known as the "vaporlock" programming technique. There would be an exactly timed loop which turns one announciator signal soft switch (AN0...3) on and off as needed, and this would control the choice of colors.

 Despite I did not write that program yet, I'm sure it can be done. But the applications for these extra colors would be limited. You can't write action games when the CPU spends 60% of its time on racing the beam. But for the sole application I was interested in, a full color version of my 'Codebreaker' game, this simplest implementation for extra colors would probably be good enough.

 But if we wanted to have automatic choice of these extra colors, some more functions need to be added in hardware, such as combining two phase bits from even/odd video byte addresses to allow for the four possible color palette choices. Again, this is not overly complex, but then we are at a level of complexity where a small GAL16V8 would make more sense than adding several TTLs.

So with adding one GAL, and some trace cuts and some flight wires, any Apple II or II+ could be equipped with eight hires colors.

If anyone is interested, this could be yet another Uncle Bernie project. I will develop the GAL anyways to test it out on my Apple-1 color graphics card. So why not make that GAL open source ? Anyone interested ?

- Uncle Bernie 

Here is a photo of the total amount of hardware involved:

Rep2e_both_top_B.jpg

The smaller PCB is the MMU/IOU substitute which I made for the original Apple IIe, and which then - inevitably - lured me into the project to design and wire wrap a whole Apple IIe substitute. This was not planned ! But I tend to get lured into investigating interesting things and starting more projects than I have time for to finish. ;-)

Here is a photo of the annotated motherboard (you can find the photo the the annotated MMU/IOU substitute board it is own thread):

Rep2e_both_top_D.jpg

And here is the description what all the building blocks in the color coded regions do:

CPU ISLAND

The "CPU Island" (green) features a 6502B, three 74LS373 octal latches, one 74LS244 octal tristate buffer, and one GAL22V10 which controls the "island".  Two IC sockets are still empty but already wired in. These are for faster SRAM so that the CPU could run at faster clock speeds than usual for the Apple II. But this is a very tricky business. I don't know if I can make this work. I would love to have higher clocks speeds for running chess programs such as Sargon III and Fidelity Chessmaster 2100. I have a huge collection of Fidelity Chess computers, especially the wooden ones, which back in their heydays were very expensive but these are hard to keep in proper functional order even for me. So I have interest in having a 6502 based platform where a program lifted from these computers could be run at the same speed as in the machines they were written for. But this is where my interest in speeding up the 6502 clock ends. I think with most games on the Apple II, any increased clock speed will break them and / or make them unplayable and their sound effects may suck bigly. Trying to remedy this is most likely futile. The "FastChip //e" tried that. I don't know how well it works with which games, because I don't have one. It costs $150 (ouch).  More than a complete Apple IIe should cost. My clock speedup (if it works) costs below $6, BOM wise. One nice feature that is certain to work is that the "CPU island" already remedies the address and write data hold time problem seen with the classic NMOS 6502 when using super fast modern RAMs. I have reason to believe that this circuit, when put into my Apple-1 color graphics card, will remedy the problem with the bogus addresses onthe Apple-1 expansion bus. But further development and characterisation is needed.

VIDEO

(Red area to the right). Same circuit as in the Apple IIe. But it got a trivial addition to be able to show eight colors plus black and white in standard hires graphics. I need this for my Apple-1 color graphics card. To make a 'Codebreaker' game based on colored pegs instead of letters. Alas, the new colors did not turn out to be as nice as I hoped for. There is a new real red, a new dark blue, and two new greenish-yellowish colors. But the pure yellow I had hoped for from inspecting the NTSC color space did not appear. Probably not only a color subcarrier phase, but also a luminance problem. Real yellow color on a TV has some of white in it. The primitive Apple II video circuits can't produce luma variations except in lores graphics and double hires. These modes can make a nice yellow. Alas, lores resolution is not high enough for an aesthetically pleasing 'Codebreaker' display, and double hires with its twin screen buffers can't be put into my Apple-1 color card, as it would get far too big to still fit into existing enclosures, which is a problem anyways (still trying to get the IC count down).

TIMING

The areas surrounded in yellow lines near the CPU island produce the master clock, 14.31818 MHz, and all derived timing signals for the system. I use a GAL22V10 in lieu of the 16R8 timing HAL seen in the original Apple IIe, to have these extra hires colors mentioned under "VIDEO" above. They need one macrocell more at that point, but a little bit more logic is needed to make the color palette choice from the screen buffer, and not by "racing the beam" with a software loop, which is only good enough for test pictures to be analyzed with a vectorscope.

I also use a ready made crystal oscillator which saves a lot of grief with finding the right crystals that would work with the usual two transistor oscillator circuit seen in the original Apple II.

SLOTS

(dark orange) Two slots are supported at the moment, SLOT A and SLOT B. Their slot numbers are user programmable, at the moment only by reprogramming GALs, but later the slot numbers would be selectable by rotary DIL switches, if I adopt this dual slot solution. Still not sure if two slots are enough for typical users. Certainly depends on how many useful peripherals are built into the motherboard. There will be a Disk II compatible floppy disk controller which I will just lift out of my Apple-1 floppy disk project. The 74LS245 in the dark orange rectangle is the usual slot databus transceiver seen in the original Apple IIe schematic as "UB2".

DRAM

128 KBytes of DRAM (red area) has been provided. Same RAM size as the original Apple IIe equipped with the optional "80COL/64k MEMORY EXPANSION" card. But it uses only four 64kx4 DRAMs in lieu of the sixteen 64kx1 DRAMs of the original Apple IIe. I think 128 kBytes are a "must have", because only then, "Wings of Fury" can run on this machine. I never played this game (I prefer to fly real airplanes) and only run it to marvel at the fantastic side-scrolling action and the pseudo 3d looks of the very detailed animated little airplanes. This is a great demo to show what the Apple II can do, despite having no hardware scolling and no hardware sprites, and as of now is the only software I know of which needs 128 kBytes.

Tell me if there is other software needing / using 128 kBytes - I would like to run it, too, to further test the hardware.

Note: more DRAM is not feasable without either adding more 64kx4 ICs or revising the DRAM refresh scheme. There are 256kx4 DRAMs (and even larger ones) but these typically need more refresh addresses. The Apple IIe in its present form does not account for these added refresh requirements of larger DRAMs. Use of larger DRAMs could be done, though, but may require a complete resign of the DRAM subsystem, and design effort to add some sort of bank select, which should follow established examples to stay compatible. Tell me more about that, if you can, so I could make up my mind if I want to go there. I think without important software needing more than 128 kBytes of memory, it probably not worth to have. Back in the day, there were many "extra RAM" expansions for all popular 8-bit computers, but most were only used as another, faster, emulated floppy disk drive. Which had merit for compilers etc. but nowadays we develop all software for these machines on a Linux box, and the need to have this extra RAM-Disk drive is all but gone. You can try to convince me otherwise if you want more than 128k of RAM.

ROM / FLASH

There is a DIL-28 socket for 16 kByte ROM/EPROM and a DIL-32 socket for a 128 kByte or 256 kByte FLASH EEPROM (yellow area). The FLASH control functions in the GAL22V10 are not implemented yet. And the ROM socket is really meant for a ROM, preferably an original Apple IIc ROM.

The reason for this arrangement is as follows:

The "FF" ROM for the Apple IIc is universally hated and hence, usually gets substituted for later, less bug ridden, and expanded versions of the Apple IIc firmware-in-ROM. But most people don't throw the original "FF" ROM in the trash when they do this upgrade. And here is the chance for us to have a 100% legal Apple IIe replica or clone which does not violate Apple's copyright on their ROMs. As long as you plug in an original Apple II ROM made by APPLE (the corporation), and not a bootleg copy, you are perfectly legal. Or so I think (no warranties and no liability of any kind given or implied --- try that at your own risk).

The pesky little problem that any Apple IIc firmware won't run on an Apple IIe can be solved by the FLASH. It would apply real time patches to the code from the ROM to correct it as needed. Without containing any fragment of copyrighted Apple code in the FLASH itself. Sounds like black magic, right ? I call this almost trivial trick "real time code morphing". But so far it's only a theoretical concept. I'm quite sure the hardware works, but if it would fly in a court of law, is the more difficult question, also considering the corruption and the cronyism found there. I think that corporations can buy themselves the verdict they want. In any court of law in any nation of the world, not only in the USA. This how the world works, dear reader. So have no illusions. The rule of law is dead. Now it's all about corporate gangsters who rape, poison, give cancer and disability to, and kill  off the population for their profit, and as they own the courts of law and the governments they can do that with utter impunity. Modern times. Or a sort of "Logan's Run" mixed with "They Live", "Soylent Green" and "1984". But I digress. Just wanted to show you my reasoning why any legal battle over "code morphing" would probably not end well for any of us. But the technical idea behind it is certainly sound !

PORTS

The usual I/O ports found on any Apple II motherboard, keyboard and game port. I even found a stash of the elusive NE558 quad timer at Anchor Electronics in Santa Clara. At the moment the keyboard port only supports Apple-1 keyboards and not even legacy Apple II keyboards. So, no "open apple" / "closed apple" keys yet. I'm not sure which keyboard solution(s) should be supported on a possible "Replica 2e" motherboard. What I definitely won't support is the original Apple IIe keyboard and its elusive LSI keyboard controller.

Would like to hear your comments which keyboards to support. Would PS/2 be OK for you ? To implement an USB port would require too much work for me, and I could not tap into my 1000's of older microcontrollers which do not have an USB peripheral. I have about 1000 PIC16C66 waiting for a job. With them I could do a lot of useful things, and I have the PS/2 keyboard driver software wirtting in PIC assembly code ready. I think anyone who would want to use a USB keyboard with the Replica 2e could also use of of these little green USB to PS/2 converters.

OPEN QUESTIONS (COPYRIGHT ISSUES AGAIN)

The contents of the video ROM is copyrighted by APPLE (the corporation), too. So it is a no brainer to NOT use their ROM. Instead, a independent and copyright free character generation EPROM can be made from freely available sources in the web. For instance, Signetics never copyrighted the bitmaps for the character sets in their early 1970s character generator ROMs (type 2513, which came with several standard character sets, uppercase, as used in the Apple-1 and early Apple II, and there were variants with lowercase, etc.) Even back in the 1970s this oversight enabled competitors like General Instrument to make drop-in substitutes (their RO-3-2513 family). These are 1:1 copies of the same character set, and probably the source where APPLE (the corporation) copied their character sets from (as the character bitmaps are identical as far as I have checked). EXCEPT for the so-called "Mouse Text" characters which seem to be a unique APPLE creation, despite some characters therein look as if copied from the Commodore PET 2001. But little gems like the "open apple" and "closed apple" symbols are a dead givaway that APPLE did not only "appropriate" characters from third parties. These are genuine Apple creations depicting the iconic (and trademarked) "bitten apple".

Throwing "Mouse Text" out ?

Due to these legal issues with trademarks and copyrights we can't use those if we want to sell IC kits for building these replicas. As far as I'm concerned, I would just leave the "Mouse Text" out and put in some other nice symbols, like the little tanks and submarines found in the "Superboard II" of Ohio Scientific, who also forgot to copyright their character generator ROM (I know for sure, as I have an original Superboard II). So everything found therein is up for grabs.

I showed you what I think about the topic and showed you the solutions I would use. But I'd like to see your opinion on the caracter set needed in an Apple IIe, too. I do not know of any software that would use the "Mouse Text" characters. Tell me if you know one !

LIST OF TECHNICAL ISSUES TO BE FIXED

The cold start problem decribed above in post #15 is probably the most pressing one to be fixed. This requires some hardware and software design, and I plan to put the solutionn in the planned revision of the MMU/IOU substitute. It will be a new slot card again, but it will (hopefully) have more free space to add more goodies and improvements.

Tests with legacy software on disk

Since the start of the tests with legacy software started two days ago, I already have found some issues. Some games don't load (i.e. Atarisoft "Centipede") . "Burger Time" refused the joystick calibration, so I could not play it. This may be due to the digital joystick adapter I use, though.

"A.E.", "PAC MAN", "CHOPLIFTER" and "DONKEY KONG" run fine without any joystick calibration. "BANDITS" seems to have no joystick support.

APPLE INTEGER BASIC as loaded from their DOS3.3. master disk won't run the Apple-1 game "HAMURABI" but this seem to be syntax error problems: a "IF X < A THEN ..." seems to be misinterpreted as "IF X < AT HEN" which makes no sense to the interpreter, so it complains.

The COLOR TEST program from the same disk (also BASIC) works but it seems that it leaves the subscreens too soon, which might be due to spurious keyboard strobes: I had some trouble with that throughout the development of the IOU/MMU substitute and needed several iterations of the logic to make it with an original Apple IIe keyboard. Now, with my Apple-1 keyboard emulator cable the problem may be back. Needs further investigations. But I'm sure can be fixed once the root cause is found. It's really a weird effect. If I let the machine sit either in BASIC or in the monitor program at their prompts, even after hours there are no spurious keystrokes popping up. But all the selections in the COLOR TEST program (which is in BASIC) quit after a short while without a key being hit. On my Taiwanese PC-48 clone I could run KALEIDOSCOPE for hours.

CONCLUSION (SO FAR)

I have shown that in just a few weeks, anyone fluent in digital electronics can design and build a "Replica" of the Apple IIe. In my case, from the completion of the MMU/IOU substitute development (20th November 2023) to the first start up of the wire wrapped Replica 2e prototype (9th January 2024) took only seven weeks, in which all the schematics were hand drawn, all the PLDs were developed, and everything was wire wrapped.

And I and did not work 24/7. Due to age, I can only do wire wrap for no more than 3 hours per day, with a long pause in the middle. This is because of the strain on the eyes to focus on that sea of wire wrap needles and count through rows of them. (They once made plastic labels with pin numbers which would fit on WW needles, but they are useless once the fabric of wires get too thick, see photo below). I think my younger self could have done the same work in maybe four weeks / one month. Making a PCB layout would cost much, much more precious RQLT, if you know what "RQLT" is.

Here is the photo of the wire wrap side:

Rep2e_both_WW.jpg

I ran out of most colors, but still use green for GND, and red for +5V. The orange wires are "temporaries" which will be removed when further functions are brought online.

OUTLOOK / HINTS WANTED FROM YOU

My work on the Apple 2e Replica will continue. All I ask you for is to read my posts in this thread thoroughly, and if you know something about Apple II hardware and software relevant to technical issues mentioned, feel free to comment or send me a PM ("Send PM").

My own exposure to 6502 based Apple computers back in the 1970s and 1980s was too limited so I can't possibly now which peripherals / slot cards are must and which are not needed. Nor do Iknow much about the most popular Apple II games. Tell me about them in the comments for this thread.

I need to know the titles of them to be able to test them if they run on this new hardware. (I'm not a gamer but I think this is part of developing a "Replica" of any computer, to avoid trouble with software incompatibilities later on).

Any hint or link to sources of information needed for this work is much appreciated ! (i.e. I still did not find any good explanation / example source code for "vaporlock" as used in different Apple II games but I do know that the 4th screen of "Drol" hangs on the version of "Applewin" emulator I use on Linux, and I've traced the issue down to suspicious code which looks like vaporlock routines that don't work on that emulator. So I modified the emulator code to give it the right token at that screen, triggered by executing that instruction. Not really good. Emulator now can only run "Drol".

So I'm very interested in finding ways to test "vaporlock" programming techniques on my prototype. The reason is that I have much less parasitic capacitance on the MD[7:0] data bus, since I use only 2 DRAMs there and not eight. And the less capacitance is there, the more volatile the "bit vapors" will be. I've been contemplating to add some ICs to make "vaporlock" work under any condition (known as "bus holders") but unless proven to be necessary, I won't do that. It's weird anyways that 47 years later, we need to investigate a dubious Apple II specific programming technique relying on "bit vapors" lingering on a floating data bus. But too many games used that foul trick so it must be preserved on any sort of Apple II replica and emulators, too.

I think that the designers of the Apple IIe at APPLE (the corporation) were also scratching their heads how to make "vaporlock" work on the Apple IIe. The may be the reason why they used the peculiar system architecture for the main DRAM and how it connects to the data bus on the slots via that octal bus transceiver mentioned above. I don't dare a guess how long they had to work to design and develop the Apple IIe system architecture. Certainly longer than the seven weeks it took me to design and build the "Replica 2e" prototype. But I copied their system architecture and just made minor substitutions towards more modern DRAMs and ROMs. So much of the "footwork" was already done for me.

Comments invited ! Tell me your wishes in which direction this project should proceed !

- Uncle Bernie

In post #24, "reifsnyderb" wrote:

"For the CPU:  Why not use a W65C02S in place of the 6502?  My thought is the W65C02S has a Bus Enable (BE) pin that could be used to simplify the isoaltion of the 6502."

"For the DRAM:  Why not replace the DRAM chips with a single AS6C1008 SRAM chip?  If nothing else, this would still provide 128k and be another chip reduction".

Uncle Bernie answers:

The current wire wrapped prototype has been designed to take either a NMOS 6502 or the W65C02S, from which I have a few that are able to run at 14.31818 MHz. But I don't know yet if I can make a GAL which would run the CPU island at that speed.

The drawback of using any CMOS 6502 is that it has "new" opcodes in lieu of the "illegal" opcodes of the NMOS version, which do more useful work than the latter. But some copyprotected games use these "illegal" opcodes in their loaders, and hence, these games will not run on a CMOS 6502. Most "cracked" versions of the same games run on 65C02, but being cracked, they are not the real deal, and some cracks suck because they took out nice intro screens, or don't run with later firmware ROMs because of use of undocumented entry points, etc. I prefer to use original floppy disks only.

There is no benefit from the BE signal to be had in an Apple II system, especially when having a CPU island that runs at faster speed than the slot bus.

Replacing the 4 DRAMs with SRAMs is possible, but that would require a complete reimplementation of the MMU/IOU substitutes with larger CPLDs (or FPGAs) having many more pins. This is because with SRAMs, you would need to isolate more than twice the address lines from the slot bus and as the double hires and 80 char  screen modes require two bytes fetched from the screen buffers at the same time, you would need a 16 bit wide SRAM, with all the added complications to now isolate 16 data lines from the rest of the system - even more pins needed on your FPGA.

If I would go there I'd put the whole Apple II on one FPGA, including the CPU.

But this would not be the 1980's compatible, easily hackable and buildable system suitable for typical hobbyists anymore. Hobbyists would botch the soldering of that BGA (ball grid array), leadless FPGA more often than not, and probably the other SMDs, too. It also would not be a 5V system anymore. Level translators needed on the slots to be able to plug in legacy slot cards requiring 5V. All this would need to be pre-manufactured, like the Raspberry Pi. And this is only commercially viable if you can sell 10000's of them.

So I'm not going into that direction. I do not want to buy any ICs either. So I can use only what I have in my stash. Which is huge. But old, like me.

- Uncle Bernie

In post #30, "Modnarmi" wrote:

" AppleWorks

Mouse text: Ringoban, a Sokoban clone from 8bitshack.org

A2desktop "

Uncle Bernie wants to know where to get 'AppleWorks' and 'A2desktop'. (and the other games, but these two seem to be the most important). Did 'AppleWorks' and / or 'A2desktop' come with the Apple IIc ? Since I bought some Apple IIc back in the day I have all the original floppy disks by Apple which came with the IIc. But I need to search for them which is sort of an expedition and dangerous. Because piles of stuff in my basement of horrors might start to slide and bury me underneath. And somewhere in these piles are all the Apple II floppy disks. So before I start to dig there I'd like to know if they came with the Apple IIc.

Any hint welcome ! (You can also send a PM)

- Uncle Bernie

Hi Fans -

since my "Wings of Fury" original disk got damaged, my Replica 2e project was stuck. This was the only software I had which uses double hires graphics. And with that floppy disk not booting anymore, I could not test the double hires mode of the hardware under development. Frustrated, I kicked off a little side project, the eight color mod for the normal Apple II, see here:

https://www.applefritter.com/content/extra-colors-hires-graphics-wanted

But yesterday the "BMOW floppy emu" from "Big Mess O Wires" arrived in my mailbox. I had ordered the "deluxe bundle" for $129. It's a steal ! I'm very impressed with what I got for my money. Very nicely done and worth every penny (Frankly, I don't know why they sell them so cheap --- now I have regrets that I did not buy one earlier, just because I thought that at that price, it can't be any good. Big mistake of mine ! --- Had I bought the BMOW floppy emu earlier, I could have saved the money that went into buying some original floppy disks off Ebay).

Here is my current development rig:

PDRM4537.JPG

In the above photo, the BMOW floppy emu is in the yellow oval. You can see that it runs just fine with the Replica IIe - but note I still use an original Disk II floppy controller card. (Let's see later down the road what happens when I use my own, GAL based version I developed for the Apple-1).

One fault detected and fixed !

"Wings of Fury" being back immediately did expose a fault in my wire wrap prototype: the double hires graphics mode did not work. Which was traced to the AN2 line being hooked to the TMG GAL, and not the AN3 line. Yikes ! That happens when wire wrapping such a complex board without drawing proper schematics which show every detail. The piece of paper with the GAL footprints had "AN3" on the TMG GAL, but somehow I still wired it to AN2.

Stupid mistake ! Maybe it was too late at night when that happened. Anyways, as you can see in the above photo, the fault was fixed, and double hires now does work (the dark bar is from the TV frame rate not being synchronized to the still camera frame rate, it's not a fault in the hardware).

But there still is a problem ...

But there still is a problem, for which I need your help, if you happen to have a BMOW floppy disk emulator with the same WOZ file for "Wings of Fury" hooked to a real Apple IIe (mine is broken now, needs a new MMU, sigh, yet another casualty of the ongoing development battle). So if you happen to have that setup (original Apple IIe and the BMOW floppy emu), please boot SIDE A of "Wings of Fury" and touch NOTHING, neither the keyboard nor the joystick. Watch and see if the self-running demo appears (which my original floppy disk did). So the little airplane will take off from the aircraft carrier, and fly around, and bomb some enemies on islands. Tell me if that works in your case. Because on my "Replica 2e", the demo never starts and instead,  the message "PLEASE INSERT WINGS OF FURY DISK SIDE B" appears. Which according to the game manual should only happen when a key is being pressed. But no such phantom key presses could ever be seen when running BASIC. Weird ! (I suspect there are issues with the keyboard port, but still not sure where to start looking.)

Further development:

The next days I will try to upgrade the Replica 2e to "enhanced Apple IIe" with a WDC65C02 and the appropriate firmware ROMs. Let's see how that works out. At the moment I can't run the official "Apple IIe Diagnostics" from APPLE. It boots fine but then spits out:

                                     Apple II

                  ProDOS 8 V2.0.3     06-May-93

         REQUIRES ENHANCED APPLE IIE OR LATER

... whatever that means. The wiki page says that the 'enhanced Apple IIe' - which, because the 'e' already means 'enhanced' is a bit confusing - involved changing the NMOS 6502 against a 65C02 and the old ROMs on the motherboard against new ROMs. But was that all of the 'enhancement' ? No other circuit changes ?

Lets see ! I will find out soon !

Stay tuned !

- Uncle Bernie

P.S.: please don't forget to do the "Wings Of Fury" test if you have an original Apple IIe and the BMOW floppy emu.

In post #35, 'nick3092' wrote:

" I can confirm that with the FE running the WoF WOZ image on my enhanced IIe that the title screen shows for about 10 seconds, and then it changes to a demo ..."

Uncle Bernie comments:

Thanks 'nick3092' for doing this little test for me. Now I know definitly that something is wrong in my Replica IIe, most likely the keyboard port. But what exactly does happen must still be investigated. I've changed the keyboard logic several times because I saw issues from the beginning. The IOU/MMU substitute card in my original Apple IIe produced a whole string of the same key code for each keystroke, if I typed RUN then what came out was RRRRRRRRRRRRUUUUUUUUUUUUUUUNNNNNNNNN. I took out the autorepeat function by reprogramming the GAL but the problem was still there. Hmmm. It turned out that the keyboard strobe signal was too long. I put in an edge detector to shorten it to one CPU cycle and the problem went away. This worked fine with the original Apple IIe which has the keyboard controller on the motherboard. The same card was then plugged into the Replica 2e prototype and the problem was back, but in a milder form, 'only' one or two excess characters per keystroke.

I put a small state machine into the keyboard GAL  to fix this and could type in BASIC programs. No excess keystrokes seen anymore.  But somehow some programs still seem to think there was a keyboard entry when the keyboard was not touched (or is disconnected, the strobe is then pulled low by a resistor). So no fake keystrokes should ever happen. I am quite sure it depends on how the software scans the keyboard, too. BASIC works fine, for instance. The built-in monitor program works fine, too. BASIC and monitor use the keyboard input routine in the firmware. I wrote a test program using that routine and no fake keystrokes were flagged, ever. So this part works. Where the problem manifests itself is with some, but not all, software loaded from disk. I'll try to find the routine in "Wings of Fury" to see what they are looking for and how this differs from the code in the firmware ROMs.

These are nasty bugs which are time consuming to hunt down. So before engaging in a wild goose chase, I had to have the confirmation that "Wings of Fury" does enter the demo mode on a real Apple IIe ... you did that experiment. Thanks again !  I was not sure if it was a bad disk image, and even suspected that my original "Wings of Fury" disk (now damaged / unloadable) was a special one, as it came with a sticker "Dealer Demo" or something like that, which I peeled off and threw away. And my original Apple IIe now is down, too., as the original MMU was damaged, most likely, a broken bond wire inside, and not ESD.

So the highway towards the "Replica 2e" on a custom made PCB is already littered with casualties left and right (some other floppy disks also were damaged, but are not that important). Seems that working with ~40 years old hardware and software on floppy disks has a high fallout rate.  But this is not unexpected. It's the reason why we design and build "Replicas" and why floppy disk emulators became available. I think we need to get this substitution work done before all of the original hardware (and all of the original floppy disks) don't work anymore. Working specimen are needed for substitute developments, to see if there are any differences which need to be ironed out. But we are still in a time window where working examples of original hardware and software are still available.  The same substitute development work probably could not be done anymore in Y2050 and beyond... then the retro comuting scene needs to make substitutes for the substitutes ;-)

- Uncle Bernie

In post #38, MacFly wrote:

" I am in shock: Uncle Bernie isn't trying to tell us, he had never used AppleWorks... "

Uncle Bernie comments:

You probably would be even more shocked if you knew my true identity and what I did in the 1980's 8-bit scene. Hint: I never did own or use any Apple product back then. But I bought a few Apple IIc after they had been discontinued, at a greatly discounted "sale" price. And my motivation was not to use them at all. I just bought them because a) I needed tax writeoffs, and b) I had a gut feeling they they would become cherished icons of industrial design, and be worth a fortune in the 21st Century.

I was right about them becoming an icon of industrial design, one Apple IIc system is on exhibit in this institution of Modern Art:

          https://en.wikipedia.org/wiki/Pinakothek_der_Moderne

(they also have fine examples of the likewise excellent industrial design of early Olivetti computers, among other exhibits).

So I was right with my taste for excellent industrial design as far as the Apple IIc was concerned. But I was wrong about them becoming worth a fortune. From time to time, you can buy an Apple IIc in pristine condition on Ebay for about $500. So investment wise, my acquisition of these Apple IIc was a flop. Instead, I should have invested the same amount of money in AAPL 'stonks' (pun intended). Which sucked bigly around that time. Now,  that  would have been an excellent investment. But hindsight is 20:20. Back then it looked as if APPLE (the company) would go out of business.

So indeed, I never used AppleWorks. I did not use any 8-bit computers since the beginning of the 1990s. I ran through all generation of 80X86 computers instead, including a pile of very expensive notebooks which became obsolete all to  soon. I must have spent more than what that Porsche 911 did cost on these computers alone. But I also made a fortune with the CAD software I developed on these computers. Once Linux became useful (IIRC, around Kernel 1.3.8.) I switched to Linux and never looked back.

As for the hilarious ad, I had a good laugh and nearly spilled my coffee all over the place. Had to wipe some coffee drops from the computer screen (again, a notebook). The audacity to compare any Apple II computer to a Porsche 911 is so blatant. Unbelievably blatant ! The Apple II never was in the league of high performance home/personal computing, when compared to its 8-bit competitors. But what it had was 80 char / line capability which all its competitors lacked. So it was attractive for small businesses. And this explains why AppleWorks became so popular. But I never had to use it. All my accounting, correspondence and taxes were done by people I paid for that. I always regarded this type of paper shuffling work as a waste of time.

More about my mission objectives and criteria:

After retirement, I had to find a topic which keeps my mind and my skills sharp. So back to the 8-bit computers I have collected over my whole life !

From which the 6502 based Apple computers (Apple 1 and Apple II) are the most attractive for hardware hacking. All the others use custom ICs which are a huge hindrance for the type of hardware hacking I want to do. While the custom ICs in the Apple IIe and IIc can be tackled with PLDs, the custom ICs  in the Commodore 64 and the Atari 400/800 need FPGAs to replace them.

Why hobbyists should avoid FPGAs:

And FPGAs are not exactly hobbyist friendly. They have short life cycles on the cutthroat FPGA marketplace, and the CAD software needed for them gets more and more expensive or unobtainable for hobbyists. Just a few days ago I saw people complaining on the web that Lattice took away the 'eternal license' for ispLEVER, and also the 'free' version of ispLEVER Classic is gone, see here:

https://www.eevblog.com/forum/fpga/any-open-source-tools-for-lattice-ispmach-4000/

... which is very bad news for hobbyists wanting to use Lattice CPLDs/FPGAs. It is not economically viable for hobbyists to pony up $600 or so per year just to keep the license for the CAD tools. But it's not only Lattice who have sucha  sh*tty design software policy.

All PLDs/FPGAs affected !

This greed is an old problem dating back to the advent of PLDs. For instance, ALTERA had a very toxic and expensive licensing policy and snarky industry insiders mocked that "ALTERA is just a software company pretending to be a semiconductor company." This is why I'm only using the EP310, EP610, EP910 parts from ALTERA because the old ABEL software I bought back in the 1980s supports them. It still have lots of interesting PLDs around which I can't use because the CAD software for them is long gone or too expensive. Among them ALTERA MAX EPM7128ELC84-15. Or XILINX XC2018-30 and XC2064-50. I even have some rare ACTEL A1020-2PL84C FPGAs (the ones with the Antifuse technology). I absolutely would   love   to put a few of my designs into them, just for fun, and to see how these ICs compare to other PLDs. So, no money to be made with that, just a hobby, a curiosity and hence, no intent to ever pay even a dime for the CAD software needed to do such experiments.

Many hobbyists think the same way as I do when it comes to CAD software acquisition: if no money is made with using it, it must be free !

Of course the manufacturers of PLDs and FPGAs think differently, and lend no helping hand to hobbyists (which may have been future customers buying lots of their ICs, if some hobby project turns into a business venture, which happens more often than not). IMHO, it is unfair that colleges and universities get all these CAD tools for free. They even get the Cadence tool suite for full custom IC design for free. And if you and me tries to get a licence, it's about six figures ... per year. (ouch !)

No way to do that. So, sorry, no Apple IIe on a single full custom IC. (At least not from me, despite I know how to do such a design, I just lack the tools).

This is why I try to implement the Replica 2e with GALs for which design tools are available even for hobbyists. It seems I can replace the EP910 in the MMU substitute with four GAL16V8 and four to five TTLs (the latter are mostly for the soft switches). You may call this 'deintegration'. But for the IOU, there is not much hope to replace the EP910 and EP610 in it. It sure could be done, but not very efficiently. Maybe I will do it despite of that. Let's see.

This said, you might understand what drives me. It's just a hobby, killing time, and keeping my mind and skills sharp. But I want some useful outcome, a design which can be built, understood and hacked by other hobbyists. It could also be a great educational tool for students of electrical engineering. Some colleges and universities let them design and build a TTL based computer on solderless breadboards. After the task is completed, the computer is taken apart again. I once ran into such a student here in Colorado Springs. He was desperate and showed me his breadboard. What a waste of time ! I think a better way to learn the art would be to design the PLDs for a Replica 2e computer, and then keep that computer as a trophy.

Anyways, these are some thoughts I have around this project. Comments invited !

- Uncle Bernie

In post #37, 'nick3092' wrote:

" . . . I just looked at my FE SD card, and the copy of the official v2.1 diagnostic for IIe and //c  I have has ProDOS 1.4 on it.  It will boot on a plain 6502. "

Uncle Bernie is happy:

Thanks, 'nick3092' for posting these diagnostics. They do indeed run on my Replica IIe with a NMOS 6502 and it passes all the tests, including the MMU/IOU and memory tests:

PDRM4556.JPG

Here is a closeup up the upper screen:

PDRM4554.JPG

It says "There are no errors logged". Which is good news ! (Sorry for the poor quality of the photo, but I could not get a better one).

I'm almost there ... except that the keyboard bug persists. I've tracked it down now to the IC where it comes from and when I disconnect the output pin #17 from this GAL22V10 and tie the net to ground, the fake keystrokes are gone and the demo mode of "Wings Of Fury" runs just fine. What eludes me so far is how this simple circuit:

PDRM4559.JPG

... could produce spurious keystrokes out of thin air, even when its input pin #9 is grounded. It's just a synchronous edge detector that should be absolutely bulletproof, especially when its input is hard tied to a fixed logic level. I'm still investigating this. Maybe the GAL is bad or has a bad ground connection.

I was able to load a lot of programs, including "Battle Chess", which also has a nice intro screen:

PDRM4558.JPG

... but somehow I can't make any entries to move pieces. This game has no copy protecttion on the disk, but asks for a move from several classic chess games printed in the booklet. Since I do have the original game set, I do have the booklet, too. Maybe I would need cursor keys to make selections, but my current keyboard emulator does not support this yet, as it was meant for the Apple-1, which doesn't use cursor keys. This will be fixed later.

So further progress was made with this project !

Once the keyboard bug has been killed dead, I will wire wrap a new MMU/IOU card which is currently under design, and uses more GALs in lieu of one of the rare and expensive EP910. I'm also trying to shoehorn the whole MMU logic into a Lattice ispLSI1016, from which I have many leftovers from my more glorious days as a PLD guru. But this would not be viable for hobbyists as Lattice has taken away the "eternal" and "free" licenses from later versions of ispLEVER. I happen to have bought one in the early 1990s when these CPLDs came out, and it still has an eternal license. So I can still crank out JEDEC files for these long obsolete devices. Their advantage is that they are 5V powered ones. No level shifters, no "core" voltage regulators, no complications with power supply sequencing. But other than being obsolete, they also may be too hard to solder for hobbyists, if interested how such a hand soldered TQFP with a 0.8 mm pin pitch looks, here it is:

PDRM4539.JPG

The jury is still out if this device works at all in this type of Chinese made adapter board they sell very cheap on Ebay. The issue is that there are no power supply bypass capacitors and there is no ground plane. The traces to the pin pads are quite long and so they will have lots of inductance ("lots" in the context of good power supply). I'm curious how that works out or not. I could put a few 100nF size 0805 SMD capacitors on top of the IC package wired to the four VCC and GND pins of the device. But soldering  that  contraption by hand would be a nerve wrecking exercise ! --- If everything fails I just continue with the easier to handle GALs in DIL packages.

- Uncle Bernie

This bug was mentioned in the previous post. What happend is that from time to time, the computer thought that there was a keystroke despite that the keyboard never was touched. This caused my favorite test program "Wings of Fury" to leave its self-running demo mode. Which is bad !

It turned out that is was a fault rooted in many weaknesses of the build. It was not only one failure point where the fake keystrokes came from. It had multiple sources of the trouble. This leads to the "Onion Model" of debugging: after one layer of the fault(s) has been peeled away (under "tears" ;-) and has exposed a failure mechanism which then was  fixed, the fault(s) still are not dead and gone, so the next layer of the "Onion" has to be peeled, and so on.

In this case, the first culprit was the location of the keyboard pulse detector GAL (on the end of the ground bus on the motherboard) vs. the location of the GAL which contains the "Key Ready" flag (on the slot card with the MMU/IOU substitute). The "grounds" were bouncy enough to cause the latter GAL to occasionally "see" a input pulse despite there was no keystroke. This occured at a rate of maybe once per minute, and depended on the kind of program running. When entering BASIC programs or working with the monitor program in the firmware, no fake keystrokes were apparent.

Fix #1: added a Schmitt Trigger for more robustness against corrupted signals

The Schmitt Trigger was found in a 74HCT132 on the MMI/IOU substitute slot card. It once did the autorepeat function which had been disconnected earlier, so it was free to be repurposed.

Effect of fix #1

The rate of fake keystrokes went down considerably, to maybe one per hour. But there still was a problem.

I tried to catch it with this BASIC program:

PDRM4560B.jpg

And indeed, from time to time, maybe once an hour, another number was printed out, indicating a fake keystroke. But "Wings Of Fury" now did run long enough in demo mode to see if there are any other problems  (more on this later).

It turned out that if I disconnected the keyboard cable after typing RUN, there were no fake keystrokes anymore. This cable came from my keyboard emulator running on a notebook computer. Which never did cause any issues when plugged into an Apple-1 !

So I did attach a genuine Apple II keyboard which was adapted for the Apple-1 keyboard connector (everything I have for Apple computers is Apple-1 "standard" - to avoid fatal mistakes like plugging an Apple II keyboard with the original cable into an Apple-1). With this keyboard, there were no fake keystrokes anymore either. The rig now looks like this:

PDRM4564B.jpg

The 'smear' effect about mid screen is an artifact from the still camera not being synchronized with the TV frame rate. It is not a program crash, the program runs just fine for human eyes.

(You may note that I plugged in the keyboard encoder card upside down - this gives a much less wobbly keyboard which lies flat on the table. This trick is fine if you observe two things: a) make sure that pin #1 goes to pin #1 and pin #25 goes to pin #25 --- these pin numbers are found on the keyboard PCB and on the encoder PCB, and , b) use a 25 pin row to "open" the contact springs in the connector before sliding in the pins of the encoder PCB from the other side. Just a little bit of opening of the contact springs is enough. You can then gently push the pin row of the encoder card in which pushes out the "helper" pin row).

I'm currently running various games having demo modes 24/7 so see if they crash. Some run fine (like the "Galaxian" seen in the above photo).

But, alas, "Wings Of Fury" freezes after running for a few hours. In different places of the self-running demo. It's not "crashing" in the sense that the display gets screwed up. It just stops running and freezes. Because I have no 6502 ICE, I need to build a special rig to see what's going on. I'm not inclined to bring the logic analyzer up and running (it's in disrepair since may years, I repaired the CRT board, but never put the instrument together again). BTW, using an ICE trying to diagnose such a problem often is futile. Because you pull out the CPU and plug the ICE in. So you change the system ! Over the past 40 years I've seen all too many cases where plugging in an ICE made the problem go away, so the root cause could not be diagnosed with help of the ICE. Logic Analyzers do not replace the CPU, but only probe on it, but unless somebody pays me a lab technician, I can't do that even if my Logic Analyzer would be up and running. It's so boring and tedious to set everything up, make all the connections, program the instrument, it's just terrible drudge work. This is why Logic Analyzers are in the group of the most hated instruments you will find in any industrial lab.They ususally sit in a shelf or cabinet, gathering dust, never to be used. Until they get sold for $1 after the company decides to get rid of them. And the happy (?) new owner (most often an employee) brings his new trophy home, never to use it. And then, after decades of non-use he puts it up on Ebay - just to find out nobody buys Logic Analyzers at any price.

So there must be better ways. If my "Replica 2e" would have reached a higher state of development with the FLASH memory and its control logic fully implemented, I just could push a button to enter a monitor program, and then see where "Wings Of Fury" hangs. But I'm not there yet. So I'm tempted to reschedule my development plan to put that "Freezer" function in earlier than planned. What it does is to generate a NMI upon press of a red button, and then it intercepts the NMI by bending the vector. This leads to a special firmware in the FLASH which otherwise is invisible (undetectable for copy protection routines in games which sometimes look for such hacker tools)  and this firmware preserves the system state (which is simple for the Apple II) and enters a monitor program with debugger, load and save of system state from and to floppy disk, etc. --- upon exit of the tool, the system state is being restored and the RTI brings the game back to where it was so rudely interrupted. This is a great tool for hackers, crackers, and gamers. The gamers can save the progress of the game at any time and reload it at the same point again and again - as long as is needed to master a new challenge - or to defeat the "boss" at the end of the game.

So far I have found no game other than "Wings of Fury" which would hang. Hmmm.

BTW, "Battle Chess" also is a great test for double hires graphics.

Discovery of a bug (?) in the real MMU

I've also resynthesized the logic for the MMU into a single ispLSI1016 CPLD (from Lattice, long discontinued 5V part). When running the verification I discovered a difference to the real MMU which was brought about by a small, harmless looking mod I did to the ROM equations. The term:

     ROMEN = PHI0 & !INH & RNW;

was introduced recently to fit the equations for the EP910 into GAL16V8, where pins per package are at a premium. As a consequence, ROM1 did not activate anymore during   write   cycles. In the original equations, which match the real MMU as proven by various methods, there is no '& RNW' factor in some product terms within the $CXXX address region. Hmmmm.  This means that in both the Apple IIe and Apple IIc, it is possible to issue a  write  command to the ROM located at $CXXX, and there will be a clash on the data bus, the ROM fighting against the data bus drivers of the 6502. I was surprised that the designers at Apple did allow that 'feature'. It eludes me if that was intentional (to be used for which purpose ?).

Maybe somebody reading this has some knowledge about this 'feature' buried deeply in the original MMU custom chip. As far as I can tell from the official Apple IIe and IIc schematics, there is no way to prevent that data bus driver clash. The only intention behind it could be that they planned to use a weird ROM bank select scheme somewhere in the future, but they never did that. This hypothetical bank select scheme would use a custom designed ROM which has special output drivers that can detect a bus clash / counterdriving. This information allows up to eight bank select bits to be jam loaded into the ROM. But I never saw that weird scheme with any homecomputer of any manufacturer. It only has merit for some legacy systems using small ROMs in need to get an upgrade in ROM space  without  giving anyone a clue that bank select is involved. Pity the cheapskates which try to make a knockoff EPROM copy of such a special ROM. They are in for a surprise !

Comments invited !

- Uncle Bernie

In post #43, ggb wrote:

" My understanding is the address space CXXX is decoded without R/W."

Uncle Bernie answers:

yes, this is true. My question was about the ROM1 and ROM2 enable outputs which only go to the on-motherboard CD and EF ROMs as an 'output enable' and they have nothing do to with what happens on the slots. (There are soft switches to invoke parts of the CD ROM in the CXXX area, but I don't mean these).

In my first iteration of the MMU substitute I had the original logic for ROM1 and ROM2 and got a 100% match in a hardware compare with the real MMU custom chip. Which however got damaged somehow when put back into the Apple IIe it came from, so I can't repeat the experiment, but have about 250 kBytes of challenge/response trace files which I now use in my verification runs to check my newer versions of the RTL against the traces of the original MMU.

I'm trying to optimize the RTL to split better into smaller PLDs, hence, the ROMEN equation which enters ROM1 and ROM2 equations, so now the motherboard ROMs will only activate in read cycles, and there will be no data bus clashes. Any slot operations hinging on the CXXX signal are not affected. They are the same as before.

But this is a deviation from the 'golden unit' and so I asked the people if there could be any legit purpose for Apple designers to allow the data bus clash during write cycles to motherboard ROMs. If that was just an oversight, I will go with the clash free version. But once the decision is made, I can't go back (at least with the GAL16V8 implementation of the logic, for the ispLSI it doesn't matter and can be changed back at any time).

It may look weird that I'm developing different ways to implement the "Replica 2e" logic in parallel, but I believe that GALs are more hobbyist friendly than CPLDs (like the elusive ispLSI1016) or FPGAs. You still can buy GALs from various vendors (all varieties, 16V8, 20V8, 22V10) and open source design software and programmers are available. Whereas all CPLD and FPGA solutions require expensive proprietary CAD suites and on top of that they get obsoleted so quickly that anyone adopting them will be on a permanent redesign process. This is why I seek a GAL solution (PALCE from AMD are the second source for the original LATTICE parts). But for speeding up my own development (exploring alternatives) I do use the ispLSI parts. Alas, they are obsoleted / out of production.

- Uncle Bernie

In post #46, CVT wrote:

" Where did you get them?? They are very rare and super hard to find to a point where if you ever see one for sale, you buy first and ask questions later. I know guys in Bulgaria not being able to find one for years in order to fix their Pravetz 8A computers. "

Uncle Bernie comments:

Seems you have the same pain as me, a dead MMU in some Apple IIe. The mine was damaged en route from my MMU test vector board back to the Apple IIe. It certainly was not ESD, I use full professional ESD protection equipment when working with MOS ICs. So I'm now looking for a replacement, too (I still need my PLD based IOU/MMU substitute PCB for my Replica IIe work).

'frozen signal' who seemed to be ahead of me with his MMU replacment design, see here:

https://www.applefritter.com/content/question-about-weird-thing-mmu-schematics

.... could have a solution. I just don't know when and how they release it. I'd buy one from them (unless too expensive to save an Apple IIe which can be had for a song in a 'for parts only' condition, as millons were made, and most often the keyboard is bad on these machines).

In the meanwhile I've fitted all the MMU logic in a LATTICE ispLSI1016, except for one type 74257 multiplexer, which was needed because the ispLSI1016 does not have enough pins to generate all the multiplexed addresses. I'm still in the verification phase but theoretically, at some point in the future, could make a PCB for that, which would drop into the socket - but there are issues with the 22 year old PC to which my ispLEVER design software is node locked. The machine is getting wonky / unreliable. Just yesterday I had several hangs of ispLEVER in which the database in the project library was screwed up so badly it would not allow a resynthesis / refit even after rebooting the machine. I had to create a new project and copy the source file into it to make it run again. This is not looking good - once I'd lose that machine, the war is over, and lost. No more ispLSI designs ! In hindsight, anyone who decided for pushing node locked software licenses on unsuspecting customers should be drawn and quartered, in a public place, if you know what that means.

Don't know how I can get out of that danger zone. If that machine dies, I'm finished, lots of vintage CAD software on it (and node locked to it).  Don't know if virtualisation of the machine would resolve the problem. Don't want to waste my time with trying that unless I know all the nasty node locking protection software would run on the virtual box. I feel to have been scammed / defrauded by these bastards. Back in the day, I paid a lot of money for all these software licenses and now, when the machine dies, all that is lost ! Hence, my desire to see them being drawn and quartered !

Other than that, progress with the project was mostly in reimplementing the MMU with a bunch of GAL16V8 and designing the 'code morphing' part which is essential to be able to make legal "Replica 2e" kit which do not infringe on APPLE's (the corporation) copyright on the firmware-in-ROM. With my code morphing innovation, all you need is an original Apple IIc 16kByte ROM (c) APPLE 1984 (Apple part #342-0272-A) also known as the "FF" version of the Apple IIc firmware. Then you can dial any version of the Apple II firmware using a rotary hex switch. Oh, and in position #1 would would get an accurate Apple-1 emulation, too. But this is under development. I'm still not sure if I should give the machine a real 6520 PIA to account for every possible Apple-1 programming trick which would change the PIA configuration. Otherwise I just could intercept and re-route any access to the PIA registers to fully emulate it in software. I'm working out both versions and then see which one is cheaper. But the final decision would also be based on the usefulness of having a PIA on board. This could be nice for people wanting to interface their own stuff to the Replica 2e in Apple II mode.

What do you think ? Do you want a real PIA on board ?

Comments invited !

- Uncle Bernie

As I have mentioned already in post #34, I found that "Wings of Fury" freezes after running for while in demo mode. So far I didn't build the tools to investigate the causation. My original Apple IIe is in disrepair (the original MMU IC was damaged during my reverse engineering work). So I can't use it anymore to run experiments on it.

Part of the "problem" is that I can run all the diagnostics software for the Apple IIe on the current Replica 2e  for days and nights, with no error messages / no crashes / no freezeups, ever. I'd assume that if the diagnostics software is not just a joke, it should detect and flag any hardware issue.

So I started to get the suspicion that "Wings of Fury" might freeze not due to a bug in my Replica IIe hardware, but due to an issue with its copy protection. Remember, it's a "WOZ" file from the BMOW Floppy Emu. So what I did (don't try that yourself !) is to unplug the Floppy Emu after the game reached the demo mode, and then did hot plug a real floppy disk drive in. With the original "Wings of Fury" disk which does not boot anymore due to damage in the first track.

Now, what I found is the following:

"Wings of Fury"  when running from the Floppy Emu freezes after a few hours, but never after the same elapsed runtime.

"Wings of Fury"  after plugging in the real floppy disk drive, freezes after maybe two days and nights.

As these tests are extremely time consuming, I do not have done  enough such experiments to have a statistical basis for sound judgement if the actual media (Floppy Emu WOZ file vs. the real, original floppy disk) have any correlation with the elapsed runtime until freezeup.

So if anyone has a functional Apple IIe and a BMOW Floppy Emu with a "Wings of Fury" WOZ file, please repeat my experiment and let it run in demo mode for a few hours / days / weeks  ;-)   and tell me if it ever freezes up.

This would be very interesting. It could prove if it is an issue with my Replica IIe hardware that can't be detected with the diagnostics software but affects "Wings of Fury". Or whether it's really an issue with the game. I know cases where copy protection schemes based on "weak bits" aka unformatted gaps on the floppy disks did not work properly and did cause trouble for the software manufacturer. Because depending on the way the "weak bits" are being checked by the copy protection routines, there may be a nonzero probability that the check fails even with an original floppy disk.

Because what happens is that if the read amplifier in the disk drive electronics does not get flux change pulses, it will increase the gain of its amplifier (there is an automatic gain control - AGC - servo loop) until it "sees" pulses again, which, however, are due to random noise.

So if the copy protection check was written by idiots, it might misinterpret that "noise" in the wrong way, causing the check to fail even on a legit original floppy disk.

Knowing this, you may understand why I'm suspecting this problem might be the culprit for the "Wings of Fury"  freezes and not a fault in my hardware. But this is just conjecture - I do not know which type of copy protection "Wings of Fury"  uses and if it was programmed to freeze up later when the check fails.

Any volunteers ?

Comments invited !

- Uncle Bernie