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

In post #52, 'retro_devices' wrote:

 " Bulgarian society is becoming  .... a barbarian  mafia ..."

Uncle Bernie comments:

This does not only apply to Bulgaria, my friend. It's a worldwide phenomenon. Applefritter is not a place where I want to spin my political theories and analyses, but suffice to say that when any economy fails to be profitable enough to pay good salaries and wages for a reasonably good standard of living for the masses, that society will quickly fall apart and turn into a hive of parasites, criminals, thieves, con artists, swindlers, and robbers. And many people will become hard drug addicts in an attempt to numb their misery. Governments can only print money out of thin air for welfare handouts to the desperate masses for a limited time, until the "fiat" currency returns to its inner value - toilet paper. Hyperinflation will steal all savings and the whole mess will explode in violence. There is no way out. These cycles always end with worthless toilet paper money, violence, revolution and war / civil war.

The real trick is to get out of these failing countries in person and in terms of assets before it is too late.

" @Uncle Bernie what is the exact PC hardware of yours that is failing ?  "

Not only countries / societies are failing, my computers are failing, too. It's a circa Y2000 Tower PC built with a "GA 7DX" motherboard for AMD Athlon processors. It's a quarter century old, so I have no hope to find a replacement. I have maintained it regularly, blowing out the dust, new fans, new power supply, new DRAM as needed but since a few years it got more and more wonky und unreliable. Windows XP complains about "system was restarted due to a severe error" or something like that even after initial bootup for which it sometimes needs more than one attempt. It wants to "phone home" but this machine never was connected to the internet and never will be. Microsoft has ceased support for XP anyways.

I need the Windows XP machine only because so much IC design, PCB design, and IC programmer software runs only on it. And most of these manufacturers of the software did not migrate it to later versions of Windows. They just went on and orphaned their products, if with hardware, like IC programmers, the hardware also was orphaned. This is why I even keep a Y1993 DOS machine around which has a 80486 CPU.

What I will do the next days is to make a 1:1 copy of the hard disk. Regular backups to USB sticks always were made, but this is only for the works I produce myself. But what is that good for ... if the machine dies along with my licensed copy of ispLEVER then the source code for my vintage LATTICE CPLD won't be of much use. Sure, I could migrate it to other CPLDs but these are a dying out species.

Here is some insight into the history of ever shrinking power supply voltages for CMOS and the consequences for us:

The LATTICE ispLSI parts are very attractive for my kind of development work targeting the Apple-1 and II, because they still are 5V. They were designed in the early 1990s and were based on a 0.8 um CMOS technology. Down to the 0.6 um node, 5V powered circuits can be built with the "core transistors". The next step down was 350nm and on these processes, the "core transistors" cannot sustain 5V power supplies anymore, these are 3.3V ICs.  For 5V I/O these processes had dual gox so you could make L=0.6um/0.5um I/O transistors for 5V operation. But the dual gox process technology and the new lithographic tools for the 350nm makes the mask sets and the finished wafers much, much more expensive. Out of reach for smaller fabless companies. The shrink path continued and at 120nm (I worked with that around Y2000) the core voltage was no more than 1.5V --- the next step down, 90nm, had 1.2V core supply. And then it went further down the shrink path (and, IMHO, to hell --- no way for smaller semiconductor companies to survive that).

This shrinking of the supply voltages along with the channel length is based on laws of Physics and cannot be avoided. Don't have the exact numbers in my head anymore but the electrical field strength in these structures can reach several million Volts per meter (don't try that in your kitchen !). This causes a limit for voltages in these deep submicron ICs which cannot be exceeded to avoid insulator breakdown. The consequence is that 5V digital ICs got obsoleted long ago and anyone attempting to use the low voltage FPGAs of today in a 5V environment has a lot of work to do to keep them safe and happy under all power up / power down scenarios. This is not trivial. The industry uses special "Power System Management ICs" to control and sequence all the various switchmode power supplies on a modern PCB. I have worked in the design of these ICs, too, and I believe these are too complex for hobbyist use. And improvised solutions may blow up or damage your 1V FPGA occasionally. Avoid !

This is why I have hoarded 5V supply PLD and CPLDs whereever I could get a bunch. Many electronics shops catering to hobbyists still have lots of these older, 5V capable PLDs in stock, at very reasonable prices, and finally, there is the ATF22V10 which is still in production:

https://www.microchip.com/en-us/product/atf22v10c

Microchip Technology Incorporated is a semiconductor manufacturer which IMHO has a peculiar business strategy making and selling ICs mostly based on long obsolete process technologies. They still make PIC microcontrollers in large numbers which are in many applications, i.e. car keys ("Keeloq") - and I found PICs in mass products like smoke and carbon monoxide alarms. So their peculiar business strategy seems to work ! I wish them success because as long as they can sell enough of their products made in trailing edge process technologies, they can keep these old wafer fabs running, and as long as these run, they can make ATF22V10 !

We have no guarantee, though, to have 5V PLDs forever. But as long as we (as hobbyists) can avoid the "modern" FPGAs, we have a viable solution to make troublefree substitutes for legacy Apple II systems. You may think different, but in my experience any work with FPGAs is fraught with nasty surprises and lots of unplanned extra time needed to work around these surprises, some of which are rooted in the bug ridden tools. Even 100% top notch professional digital designers working in the semiconductor industry are always struggling with that. Much of their know-how in driving these tools is how to write the RTL and the scripts to dodge these bugs. Then, there is know-how how to dodge bugs and flaws of the foundry / process related design kits and the IP they offer (such as memory generators which don't work for some memory configurations). And then, there is the know-how how to implement the proprietary system itself. You would think the latter is the most difficult part. It is not. Avoiding the bugs in the tools and the design kits is the more difficult part. And now, this said, imagine a poor hobbyist tackling a complex FPGA design. It's quite hopeless. Most of these designs, when reduced to hardware, do work - almost. And then the project gets put on github so others could find and fix the bugs.

But it's not only hobbyists who have this type of problem. The semiconductor industry professionals do have it, too. There are vendors who sell IP (i.e.CPU cores) in form of VHDL or Verilog along with a license to use it in IC products. But that source code in most cases is useless because, as explained above, it's not just "push a button on the tools" and get your GDS block that would work in silicon. So a whole cottage industry has sprung up, small entrepreneurs, who specialize in "massaging" these useless IP sources into something that works turn-key (as was the original promise from the IP vendor that was deceiving --- some would call it fraud).

It's much the same as with any complex software product: the vendor / owner of the IP throws it "over the fence" to the customer, and then the customer has to hire his own experts / consultants to make it work in his IT infrastructure. Some vendors offer their own consultants but at a ridicolous rates. Long gone is the time when vendors of hardware and software were standing behind their product. Long ago,  I was told by a "Big Blue" employee that indeed there was a time when a business could buy a IBM solution for accounting, inventory, etc., all out of one hand, hardware and software, and it just would work. Real turn-key solutions. This was what was expected in the 1960s and early 1970s. And then came the microprocessor. Hardware got ridicolously cheap and so software had to get cheap, too. So it got cr@ppy and needed endless patches and bug fixes and whatnot. The whole business model of Microsoft was based on that. Where else could you buy a complete OS for your computer for only $100 ? Lots of bugs guaranteed as a free bonus on top of the bargain price ! Today, the whole hardware and software marketplace is so diverse that it borders on a supernatural miracle that anything works at all. The good times of "all out of one hand" are long gone. But in hindsight, it made sense. That stuff did work, and no nasty surprises. You just could turn it on and it would work. But today, IT is a nightmare. And this, of course, also affects the CAD tools we need to design ICs. I really wonder how functional ICs can come out of that mess. This is true for professionals and hobbyists alike.

If you have doubts about my claims about these obstacles and problems, read post #53 of 'frozen signal' above. I think they did great work towards a MMU / IOU drop-in substitute (which, unlike the mine, would fit into a DIL-40 socket) but now they are struggling to actually produce them. This is not incompetence, don't get me wrong. It's just all the factors I've listed above in this post being stacked against them. The possibility that the Altera MAX CPLDs they have chosen are Chinese counterfeits is yet another such risk factor we have to deal with nowadays.

This type of decay of technological civilisations has been predicted by many works of SciFi, some are really dark. For a funny version, look no further than the "Shingouz" from the comic strip series "Valerian and Laureline":

https://en.wikipedia.org/wiki/Val%C3%A9rian_and_Laureline

There is an animated cartoon version, too, in which our heros visit the home planet of the Shingouz, and it's a total mess. Everything is built the cheapest way, is in general disrepair, even the roof of the space port is leaking. Similarities to our own civilisation are not coincidential. We are heading the same way. Which closes the loop to the complaint brought up by our Bulgarian commenter.

- Uncle Bernie

Hi fans -

here is another progress report on this project.

As mentioned in posts #41 and #49, "Wings Of Fury" froze up after running a while in its demo mode. I was not sure it it was a "hang" or a "crash".

I ran "Wings Of Fury" off the BMOW floppy emu for more than a week now, after I had changed the two main memory DRAMs against others (was just a hunch, because I could not remember if I ran a DRAM test on the ones I put in to solve the power up flag persistence problem). At first everything looked good, and "Wings Of Fury" ran its demo mode for 3 days and nights. And then froze again.  So the DRAM change did not really bring any improvement. I decided to give it another try. After reload, and running it over night, I got the first "real" program crash of "Wings Of Fury":

PDRM4572.JPG

This time, the program did not just freeze up, but for the first time in this long row of experiments with it, it also produced random garbage on the screen (the lines in the "sky").

So the bad news is that there is a real program crash and not just a "hang". I had some theory that "vaporlock" programming techniques in my implementation of the Apple IIe might be a bit wonky and unreliable, because I have far less parasitic capacitance on the internal MD[7:0] data bus, where the "bit vapors" from the video data fetch are supposed to linger around. Any issue with that could make programs 'hang' and waiting for the right "bit vapors" that never persist long enough to make the program exit the waiting loop. ("Vaporlock" is a very rotten programming technique).

But now I have the definite proof "Wings Of Fury" really crashes, and not just hangs in an infinite loop.

The good news is that with this new evidence, I don't need to waste any time on building diagnostics tools to see where the "hang" might be.

So, precious RQLT is saved (for newbies to Uncle Bernie terms, RQLT = "Residual Quality Life Time")

I can now focus on more important work. Maybe the problem goes away when I upgrade the CPU island controller GAL. The the moment it is the most primitive version I could make, not using any of the added capabilities the extra ICs in the CPU island may bring. But one step after another !

I just wanted to keep you posted that running "Wings of Fury"demo mode on your machine might be a waste of time, and not bring any new insights. But if you want, you might still do the experiment. If it runs on your machine in its demo mode for several weeks 24/7 and does not crash or freeze, you know that your Apple IIe (or Apple IIc) is in better shape than my Replica 2e prototype. But if it does hang / freeze, you probably have the same problem lurking in your hardware as I have. If so, please tell me !

- Uncle Bernie

In post #62, retrodevices asked:

" Do you think 64 macrocells will be enough for the MMU ? "

Uncle Bernie comments:

My own MMU substitute needs far less than 64 macrocells in "classic" PLDs where macrocells have eight PTerms each. But when I re-synthesized / fitted it into a LATTICE ispLSI1016, the device was pretty full. And it does not have enough outputs / pins to make all the multiplexed addresses, so an extra, external 74LS257 is needed to do that. But frozen_signals solution may be different.

The issue with some CPLDs like these (and the ALTERA MAX) is the reduced product term (Pterm) count per macrocell, so the fitter will spread one equation over several macrocells, consuming too many of them, and clogging up the routing ressources in the device. Some CPLDs have local Pterm sharing which allows one MC to "steal" the Pterms from adjacent MCs without consuming columns in the fuse array.

I always hated the later ALTERA CPLDs because they (ALTERA, the company) wanted to push expensive proprietary design kits on us, despite we wanted to use ABEL from Data I/O which nicely supported the "classic" ALTERA EP310,610,910,1810, and we expected (in vain) that it would be upgraded to the newer ALTERA devices. But  ALTERA turned from a fabless semiconductor company into a software company seeking the profits they could not make with their silicon by selling their terrible design software at moon prices.

The most useful of the 'Classic' ALTERA devices are the EP610 and EP910. EP1810 is a nasty kludge where they saw that just adding more quadrants without proper routing ressources between them just brings trouble and disappointment of the few users. The LATTICE parts of the 1000's pLSI/ispLSI family have a really clever solution for that problem (the global routing pool) but again, they wanted to sell their proprietary design kit (first ispEXPERT, then ispLEVER). At least, it had ABEL built in, so designs could be migrated more efficiently.

This was the "Wild West" era of the PLDs/CPLDs and a lot of people got burned by betting on the wrong horse(s).

What is worse is that after 30 years, the design software for these ancient devices disappears and the retro computing scene needing these 5V devices can't make new designs due to lack of the tools. Despite at least some types of these ancient CPLDs are still available at acceptable prices. I studied the current market situation (via IC broker listings) and found a correlation between availability and acceptable prices and design kit availability. No design kits being available anymore means that these CPLDs are cheap and abundant. Not always, but there is a trend.

- Uncle Bernie

The "WoF crashing" topic

I had "Wings of Fury" running now for more than a week 24/7, on an Apple IIc, with no crashes seen. So I'm quite confident that the game as such is not crash prone, and the problem must be within the Replica IIe. I will hunt it down and kill it (meaning: the bug) but this will take some time.

It could be that it's a similar problem like the one causing the spurious bogus keystrokes without anyone touching the keyboard. Which has been greatly mitigated but despite I did not see any more such spurious keystrokes I'm not 100% sure if that bug is really dead. But I'm sure that with a properly layouted PCB and not that mess of wire wrap on a PCB without power and ground planes, at least the keystroke problem will never manifest again.

Perils of WW construction of prototypes

I should have used one of my two remaining good WW PCBs with integrated power and ground planes, but these are unobtainium now and I wanted to reserve them for an upcoming project which I also want to do, a 16 bit computer made entirely out of Schottky TTL ICs, and based on my own computer architecture. I want to see if I could get a much higher performance than the folks at Data General or DEC had reached in the late 1960s/early 1970s, when using the same technology (STTL). But this is another topic. Just wanted to tell you why I decided to preserve these rare WW prototyping PCBs. In hindsight, I shot myself in the foot with that, and now lose time hunting down gremlins in the Replica 2e which most likely are caused by lack of proper power and ground planes (the power / ground strips I used do help, but are as not as good as copper planes in the PCB itself. Do not try to wire wrap the whole power / ground net on such a large board - that will not work.)

Some related side project - the new Disk II compatible floppy disk controller

Losing time waiting for results of running experiments is always bad, so I used the past week to build a floppy disk controller for the Replica 2e, see here:

PDRM4580_mid.jpg

Note that I put in a MMI 256x8 PROM containing the bootstrap loader. I will remove that again and repurpose the socket once I have coded the PAL which enables the bootstrap loader to reside in the EPROM/FLASH on the motherboard. This socket and the adjacent empty DIL-14 socket will become part of the new MMU which also will go on this PCB, along with the new IOU.

This is based on my DISK II compatible floppy disk controller I designed for the Apple-1, see here:

https://www.applefritter.com/content/uncle-bernies-woz-machine-based-apple-1-floppy-disk-controller

The main difference is that in the Replica 2e it needs no "Time Flux Compensator", or "TFC", because the Apple II does not use DMA / cycle stealing for DRAM refresh. This saves one GAL. No other changes are needed, except that I cleaned up the messy pinout of the IWM GAL, which could be substituted with a PAL16R6.

Ironically, using PLDs does not decrease the IC count over the original DISK II controller. It's still much the same IC set, except that four flipflops of the 74LS174 are now uncommitted because they went into the GAL, and these substitute the state machine of the original DISK II controller which used a PROM (now difficult / expensive to get) together with said four flipflops. Another small difference is that I redesigned the state machine to use a 74LS299 universal shift register and not the elusive 74LS323, which has been out of production for many years, and AFAIK never was carried over to the 74HC/HCT/AC/ACT families. The reason might be that the 74LS323 never was a bestseller - after all it was only TI's second source of the obscure 25LS23. But the 74xx299 are abundant and cheap. The difference between the '299 and the '323 is that the former has an asynchronous clear and the latter has a synchronous clear. Which means that the state machine must delay all clear signals to the shift register by one clock cycle. And that is all.

State machine equivalence ?

When I shoehorned Woz' state machine into the 16R6, I had to use a different state encoding, so this is not a 1:1 copy of the original state machine. But what I did is to run a "state machine equivalence" test on Woz' implementation and the mine. This is a very sophisticated algorithm which is part of many silicon compilers or FPGA CAD software suites.

What you see is  not  what you get (beware of modern IC design flows)

One of  the dirtly little secrets of these CAD tools is that they regularly change state machines and their state encodings into something else which you won't recognize if you looked at the mess of gates and flipflops these tools vomit out in abundance. Bad luck if you have carefully designed the state encodings such that the state transitions are hazard free, and then have fed them into asynchronous state machines - which these tools don't understand at all.

Alas, asynchronous state machines can't be avoided in all cases of real world circuit design. Also be aware that any clocks you might generate by combinatorial logic within your design may get infested by hazards / critical races due to these resynthesis / remapping / fitting procedures, regardless how carefully you designed your logic. "Don't gate your clocks" is one of the paradigms in college level engineering textbooks. True, if you can avoid it. Sometimes you can't because you need to achieve some sequencing depending on input signals and you don't have a clock fast enough to do that with fully synchronous logic. The IOU custom chip of the Apple IIe and IIc is an example for that conundrum. Some of the clocks for some of the flipflops inside the IOU must be derived from a combination of input signals coming from the motherboard. And this may be very "hazardous" indeed.

Redesignd video pipeline (my IOU version #2)

To avoid the hazards, I've completely redesigned the whole video pipeline in my 2nd generation of PLD substitutes for the IOU/MMU, and I don't follow Jim Sather's book anymore. Because I saw a lot of problems. Alas, if you want to do a 1:1 drop-in substitute for the IOU, you have to use these hazardous clocks. Unless you would invoke a PLL in your FPGA, multiply the Q3 clock by several times (up to M14 or even more) and then use that fast clock to resynchronize all input signals needed to derive said tricky timing sequencing. The hazards would be gone and the system would be robust. Except there is yet another potential timing bug which I found in the original video pipeline. Which I didn't analyze any further because I considered that a waste of time, just to find out under which circumstances it might manifest (or not). So I just redesigned everything to be spanking clean, timing wise. I have that freedom of choice because the Replica IIe IOU/MMU does not need to drop into the existing sockets of a real Apple IIe.

Current state of the project - things to do

So far the current state of the Replica 2e project. I'm still pondering if I should put an original "Woz Machine" on the new floppy disk controller board, along with a compare unit, essentially the same trick I used to verify that my IOU substitute made the same address sequences as the original IOU custom chip (see above in this thread where it is shown how this was done).

For the disk controller, it would be to gain more confidence that even the most obscure floppy disk copy protection I could obtain as test cases would not cause any difference in the stream of bytes read from the shift register. We know, theoretically, that a mathematical proof of state machine equivalence is supposed to be the truth. And theoretically, no software, ever, should be able to tell a difference between such "proven mathematically equivalent" state machines.

But we always have to keep in mind that this is based on an abstract which does not exist in the real world. In the disk controller, the state machine is surrounded by auxiliary functions which did not enter the mathematical proof. So there is indeed a small, but non-zero risk that something still might behave differently under real world conditions. Think synchronizer failure. The big question is: is it worth the time expenditure to implement and run these tests with a "compare" unit ? What are the odds that the (few) software titles I can test would uncover different behaviour, if such a different behaviour indeed exists ? It's like chasing ghosts. Or a form of paranoia. Still pondering on how to proceed !

I do have another implemenation of the Woz machine based on a PAL22V10 and a 74LS323 which I made about 20 years ago. Don't know yet if it has the same pipeline delays in it as the newer solution (software could not tell the difference in delays of the bit stream from the floppy disk) but if it could be made to work in lockstep with the new solution, a compare would be easy. This 22V10 contains the original state machine as designed by Woz. I could have used it for the Apple-1 floppy disk controller but wanted a Y1978 solution (when the first PALs came out) and the 22V10 solution was rejected for not being "period correct technology" for the Apple-1. Could have saved me a lot of time if I wasn't that discerning, but what's the point of "cheating" --- if I wanted to "cheat" I could emulate the whole Apple-1 (or Apple II) in a Raspberry Pi and call it good and done. A more "modern" solution and a total "cheat". But my mission is different - I want to show what could have been done with "period correct technology". This is why I use "ancient" PLDs for this work and not a modern FPGA. Which could swallow everything including the 6502 CPU, at the push of a button. All the source code is out there. But that would be too easy.

Stay tuned !

- Uncle Bernie

The Replica 2e will have the floppy disk controller on the motherboard, so it needs less slots. But when the floppy disk controller is integrated on the (expensive) motherboard there is no margin for error. With a floppy disk controller slot card, which can be replaced, the impact of any design flaws / inaccuracies / incompatibilities is less dramatic. But I decided to go with the motherboard solution: if it works, it's a much lower cost of system ownership (one PCB and one slot connector less).

A lot of testing is required to make sure that my implementation of the floppy disk controller is fully compatible with the original DISK II slot card.

I'm currently running some tests on the floppy disk controller when using Woz' original state machine in a 22V10:

PDRM4582_small.jpg

As you can see when you compare this version to the photo in post #64 above, the difference is very small: instead of the GAL16V8 it's now a GAL22V10 in the same DIL-20 socket (two pin pairs are sticking out / hanging in the air, but wired to clock and VCC) and instead of the 74LS299 it's now a AM25LS23 (for which the TI 74LS323 was a second source) whose /CLR pin has been lifted so it does not contact the socket, and it's air wired to pin #23 of the 22V10. This is necessary due to the circuit being different between the synchronous clear and the asynchronous clear case.

Testing procedure

I try to load all the original copyprotected floppy disks using this card in a PC-48 Apple II clone (my original Apple II motherboards don't work anymore, and my Apple IIe lacks a functional MMU, a victim of my lab work). The next phase is to load all the WOZ files I could find using the BMOW Floppy Emu - hoping that the emu faithfully reproduces the copy protection and allows the game to load. Then I list all the games which don't load correctly.

After that I will replace the 22V10 containing Woz' original state machine and the AM25LS23 with the GAL16V8/74LS299 combo. And go through all the loading attempts again.

The final test will be with the original Disk II controller, but only on those games which did not load/run on my WW prototype. If any of these would load on the original Disk II controller, there has to be a problem. Which then needs to be analyzed. The reason can be harmless like the fact that I have disabled all write operations by lifting the 7405 pin which drives the /WR_REQ signal. This is an open collector output, so lifting the pin is enough to disable writes without any extra measures needed.

I don't know which software titles would use a copy protection based on writes to disk (laser hole checks ?) on the Apple II but in the PC world this nasty copy protection was quite common. IIRC, it was called "Prolok" or something similar. I avoided to buy any such copyprotected software, so, alas, I have no physical examples. All the CAD software I ever bought for the PC either came with a dongle or a "license file". This is less nefarious / evil but when the "license" file locks the software to the serial number of the hard drive, you are in trouble, when you ever need to upgrade / replace your hard drive.

All this copy protection shenanigans are not exactly user friendly. As for dongles, try to plug a line printer port dongle into a modern USB only computer. It won"t work, even with a USB/LPT converter.

IMHO, these copy protections defraud the buyer of the software. They are evil. As a counter example, the most user friendly copy protection I ever encountered is the one of "Battle Chess": the game asks for a certain move from a certain historic chess game printed in the manual. I have bought both the Apple II and the PC versions, and lo and behold, the same manual works for both of them. There have been some other weird copy protections based on extra hardware gadgets, but some, like the "LensLok" did not age well and most specimen are now brittle / damaged and useless.

Anyways, as much as these copy protections are a nuisance, I must test them on my floppy disk controller to gain confidence that it's as compatible to the original DISK II controller as it gets. Still not sure how many tests are necessary to reach enough confidence. The designers of the IWM and the SWIM custom ICs at APPLE (the corporation) must have faced the same conundrum: how to improve / expand that concept and still make sure that all the copy protected floppy disks still would load and run. I did not even try improvements, but still need to make sure that my implementation is compatible with the original.

Why not make a DISK II subsitute slot card needing no PROMs ?

I'm wondering if there could be a need for replica DISK II controllers out there. If there is such a need, I could fork the project and design a slot card for the regular Apple II containing my PLD based solution. Don't know if somting like that already exists. Or if there is a demand. If so, let me know. (I'm well aware that an Ebay seller from Bulgaria sells a Disk II compatible slot card for $39.99 plus $10 shipping, but this is a knockoff of the original design with the only difference being that he uses four smaller PROMs in lieu of the two original 256x8 PROMs, and consequently needs a larger PCB. This is  not  a PLD based solution and hence, is not sustainable on the long run, due to the need for PROMs which are harder and harder to get, and difficult for typical hobbyists to program. My proposed card would use only common PLDs and common DIL-24 or DIL-28 EPROMs, which are abundant and cheap.)

Side benefit: testing of compatibilitiy by volunteers

This could be a nice way to spread the burden of compatibility testing to volunteers. The 22V10/25LS23 version would be a fallback solution if the 16V8/74LS299 had compatibility issues. So there is no risk that anyone would end up with a dud. The only problem I see with that approach is the bootstrap PROM. You would need to take a functional one out of an original DISK II controller, or program the code (it's only 256 bytes) into an EPROM. I could not provide that bootstrap code with the kit, due to copyright reasons, and I did not write a new one yet. I think I could write one in one afternoon, but the issue is compatibility --- it's not documented / known which entry points into the bootstrap PROM are used by all the software base out there. Such a re-write could be done, though, and then it would not infringe upon Apple's copyright. Anyone could program a suitable EPROM (EPROM programmers are very cheap nowadays, and EPROMs are still abundant).

Comments invited !

Tell me if you would want a floppy disk controller kit based on my PLD solution ! I think if it could be sold at cost, and then it may be much cheaper than buying an original one off Ebay.

I estimate the ICs with the PCB would probably not cost more than $20 or so. As always, shipping costs are the real problem.

- Uncle Bernie

In post #73, CVT wrote:

" Well, there is still a point in making them today. The one NKK sells on eBay is to people who have just burned their disk controller (which happens all the time) and want a new one that is tested and guaranteed to work. "

Uncle Bernie comments:

True that. I don't know why but the DISK II controller cards die like flies. I have a few bad original ones, and only one working one, and this is a clone (you can see in my photos in this thread). I've looked into the problem and found bad PROMs, but on other dead cards it must be other bad ICs. Over the years, I made a few PROMs for owners who wanted to repair their DISK II card, and they knew the bad PROM (by swapping against a good one from another card). Since these 256x8 PROM blanks were scarce and expensive even 20 years ago, I looked into replacing at least the state machine PROM with a PAL. Since then I do have a 22V10 based solution that uses a small DIL-20 adapter (hand wired) and drops right into the PROM socket. But I don't have a solution to replace the bootstrap PROM ... other than using EPROMs. I might have some larger bipolar N x 8 PROM blanks around but as none of them fits 1:1 into the socket and adapter must be made, and then a small EPROM is the better choice. EPROMs do no suffer from fuse growback or fuse failure. I never had an EPROM fail (lose its contents) except for those in a) Plastic packages or b) without opaque label over the window. ICs in plastic packages, which are not hermetic, will deteriorate over the decades. With PROMs it's even worse because there must be a passivation opening over each fuse. This exposes the NiCr thin film fuse filament to humidity and it will rot away (again, over decades). This is why PROMs in CERDIP packages are superior. But also much more expensive. And very hard to find. They haven't been produced since decades. We are running on fumes here.

This said, I want (and offer) a solution without any problematic PROMs. All what needs to be done is to make a new PCB layout. Such  PCB, made by JLCPCB, would probably cost less than $5. My handicap the Bulgarian does not have is that I live in the USA and could be sued by Apple if I make copies of their copyrighted bootstrap firmware. So I can't do that. The solution to the copyright problem with the whole Apple II firmware I've found for the Replica IIe itself cannot be applied to a small slot card (code morphing hardware needs many more ICs).

My current situation is that I ran out of Apple II prototyping slot cards and so I need to make a layout for such slot cards anyways. Once a prototyping slot card layout is done, it's easy to remove the prototyping sea-of-vias and to replace them with a DISK II controller substitute. This is not much extra work. Maybe 2-3 hours. The question is if there is enough demand so I could dump my excess PCBs and get my money back. I could even leave a prototype area on the disk controller version. It all depends on the "magic numbers" of drill holes etc. which, if exceeded, bump up manufacturing costs. Oh, and being a penny pincher, for me to order only the 2-3 prototype cards I need for my own work looks like a waste of money (pay more, get less). JLCPCB has has good prices for PCBs but only of you order 20+ PCBs of one design.

So I'm looking for a solution how to create demand for my leftover PCBs. I could also attach some MMU substitute strips which can be broken off.

Haste makes waste. As always, I'm seeking the cheapest possible solution with the most utility for the money invested in a production run.

Any ideas which little gadgets (circuits) could be put on such a PCB other than a DISK II substitute ? Maybe a S.A.M. audio card ? I happen to have lots of these DACs in my basement. Which are too expensive to buy nowadays, but my stash was cheap enough to buy - could not resist and now I have them in excess.

Comments with your ideas invited !

- Uncle Bernie

Started to work on a IWM substitute. While doing that I discovered how they (at Apple) solved the phantom read conundrum: they changed how the shift register control state machine works, so the IWM definitely is NOT 100% compatible anymore with the DISK II controller. I'm still investigating the consequences this might have in the context of the Replica 2e project: can I put a IWM substitute in or not ?

I could change the IWM substitute, though, so it would be 100% DISK II compatible in its 7M/SLOW mode. A few little changes are necessary anyways, to avoid the misconfiguration of the IWM by any software not aware of its MODE register (which is not present in the DISK II controller).

So in Apple IIc emulation mode, my IWM substitute would behave exactly as the IWM does, but in any other mode, like the Apple IIe mode, it would behave exactly as the DISK II controller does, and the MODE register would be forced to a default state were it behaves like the DISK II (wonder why Apple did not fix this).

Yet another IWM issue / bug.

The other issue / bug of the IWM mentioned in the Apple documents which makes the IWM useless with the NMOS 6502 could be fixed, I think, by adding a single D-flipflop in path from the SR to the data bus. This bug is real and they claim it's gone with the 65C02, because the 65C02 regenerates the contents of its data input register to full logic levels after closing the read gate (at the end of PHI2). This is a standard technique, regenerative latches (also being used as "read amplifiers" in simpler RAMs/ROMs), but the NMOS 6502 uses them only on a few critical inputs like /RES, /IRQ and /NMI, which may be asynchronous events, as permitted by the 6502 datasheet.

The regenerative latches are meant to prevent logic levels in the "maybe" range which would completely screw up the inner workings of the 6502 if such a logical "maybe" ever manifests. Alas, the solution they used is not perfect, there still is a small probability that an asynchronous event on /RES, /IRQ and /NMI may cause metastability of said regenerative latches.

So for a robust system design, you should use external synchronizer flipflops for all asynchronous signal sources going to /RES, /IRQ and /NMI. Which may get metastable themselves ... but the theory on this effect says the more synchronizer flipflops you have, the lower the residual risk. Note that for typical 6502 systems, where IRQ and NMI is generated by 65xx peripherals (like the 6520 PIA or the 6522 VIA, or the 6532 RIOT), you should be safe, as the interrupts generated by them typically are synchronous to the system clock. The whole topic of metastability and the risks for systems is difficult ... suffice to say that critical systems employ at least watchdog timers, or forms of multiple redundancy, to be able to detect and recover from any such events.

But back to the IWM bug. I think this is what made me think that the 65C02 would not work with the DISK II controller, but when I experimented with the Apple II floppy disk system about 20-30 years ago, it also could have been that what I really had encountered was that the NMOS 6502 would not work with the IWM. After such a long time, memory does not preserve all the details what really was done and what was observed. This is why design engineers keep notebooks for their professional work. Hobbyists typically don't do that.

Explanation of "phantom read":

Just as a matter of convenience for those who don't know what a "phantom read" is: when using the STA abs,X instruction on the NMOS 6502, which is typical for floppy disk software as the "X" index selects which slot the DISK II controller card is plugged into, the NMOS 6502 first reads from the effecive address (this is the "phantom read") and then writes to the effective address. Not always true, because in case of a page crossing, the phantom read will read from the previous page (the H-Byte of the address is not bumped up by 1 yet). But for the DISK II, page crossings are not used. What is used is the "phantom read" itself, because it switches the state machine into "LOAD" mode so in the following write cycle, the shift register in the DISK II will be loaded from the data bus. In the next instruction of typical DISK II code, a BIT FDC_Q6L will clear the bit #6 of the control register (a 74LS259) aka "MODE0", which brings the state machine back into SHIFT mode.

Now, if the code is written such that the STA abs,x is delayed from the nominal 32 CPU cycle periods for normal disk bytes, then the DISK II controller continues shifting out whatever is left over in the shift register, and since zeros have been shifted in while shifting out the disk byte, zeros will shift out. This is used to make disk bytes with 40 CPU cycles length, which are regular disk bytes (32 CPU cycles long) plus two "0" bits written to the floppy disk (each bit cell is 4 us long, so these two bytes take 8 CPU cycles). These peculiar. because longer, disk bytes are used as "SYNC" bytes to re-synchronize the state machine to disk byte boundaries.

Quite a clever concept, but confusing at times, and full of possible pitfalls for the unwary programmer who does not know that not all 6502 are alike when it comes to instruction cycle timing. All NMOS 6502 are the same, but CMOS 6502 do have different instruction cycle timings for some opcodes and may have or not have "phantom read" cycles.

More differences / incompatibilities between NMOS and CMOS 6502 to be aware of !

The page crossing behaviour also may be different. Some also lack the decimal mode (Japanese 6502 knockoffs used in their video game consoles and elsewhere). Those CMOS 6502 which do have decimal mode (all NMOS 6502 have it, so no worries there) add one cycle to each ADC or SBC instruction when decimal mode is turned on. All this can throw your carefully timed and cycle counted code off track in a big way. The reason for all this trouble and confusion with decimal mode is that the "on the fly" BCD correction used in the decimal mode of the NMOS 6502 was the one and only patented feature of the original 6502 (U.S. Pat. 3,991,307). So all the knockoffs had to dodge the patent as long as it was in force. The Japanese pragmatically decided that they need no decimal arithmetic instructions for their games, and ditched the decimal mode completely, and everybody else had to add one cycle after each ADC or SBC when decimal mode was turned on. This is similar to an implied "DAA" instruction known from the older 8080 CPU, and dodges the patent while still being object code compatible with the original, patented NMOS 6502. The problem is that the cycle timing now is different from the NMOS 6502 and may cause trouble with tightly timed code.

Beware Chinese "6502" counterfeits !

And be warned that Chinese counterfeiters offering "6502" on AliBaba and Ebay (and elsewhere) ruthlessly fish every kind of 6502 or derivative, NMOS or CMOS, out of the electronics junk recycling stream, grind off the original markings, and put a nice "6502" on it, most often with a large "Rockwell" logo, of course, all laser engraved. Which is the hint that these are counterfeits. AFAIK, Rockwell NEVER made laser engraved 6502. All genuine Rockwell 6502 I ever had in hand were ink stamped. So don't buy any laser engraved ones.But be aware that some counterfeiters also use ink stamps. The best way to avoid being defrauded is to NEVER buy ICs from Chinese sources. Which hurts the honest Chinese sellers, but as long as the Chinese government does not crack down on the counterfeiters, this is the only way for us: boycott them all. Never buy ICs from China. I got burned often enough that this is now my policy. I only buy ICs which never have left the USA. Anchor Electronics in Santa Clara and Surplus Sales of Nebraska are your best bet, because these are selling surplus ICs they bought as leftovers from the local electronics industry over the past decades. Anchor still has lots of 6520 PIA which came from Atari, you can see that from the "CO14795" Atari part number on them (along with the "6520"). The Nebraska guys have lots of "socket pulled" 6522 VIAs. Both have lots and lots of vintage TTLs and vintage RAM/EPROM/PLDs. No need to shop on AliBaba which is crawling with these criminal Chinese counterfeiters. I will post some useful information on good sources for vintage ICs in another thread (NMOS 6502 are getting scarce, I was told, but I found an alternative).

- Uncle Bernie

In post #80, 'Macintosh_nik' wrote:

" Not everything on aliexpress is junk  ... As you can see sometimes I manage to catch a fat fish in troubled waters.

Anyway, if you do get a fake, the refund process is very fast and much easier than on eBay. "

Uncle Bernie partially agrees but disagrees about the refund process being "very fast and easier".

First of all, most counterfeit ICs are not "junk" as such, despite a lot of them are being fished out of the "electronics junk recycling stream". I'm very familiar with this scene (as an industry insider, buyer, and seller of such ICs). The company I worked for as an IC designer had big trouble with production rejects that somehow got into the hands of these crafty Chinese recyclers / resellers / counterfeiters and they sold them. Despite they didn't work. This issue is not company specific, every semiconductor manufacturer has the same problem. Workers at the assembly houses in Asia (where the wafers get diced and the die get mounted into packages and then get tested) steal the rejects and sell them into the black market. These rejects should go to honest recyclers who grind them to dust and extract the gold. Our solution was to drill holes into the concrete floor of the test floor and instead of "reject tubes" the testers got a fixed attached, armored rubber hose at the "reject" port which would make the bad ICs fall right trough the hose into the basement. Where we had empty steel drums collecting them and specially trusted and screened employees under 100% video surveillance who were tasked to take these bad ICs out of the barrels and then smash them with hammers. And put the smashed ones into other barrels which would be sold to the gold recyclers. This stopped the problem. But of course, Chinese counterfeiters still wound continue to laser engrave our famous logo on crappy ICs made elsewhere, this way they could turn a common, low performance 10 cent opamp into one of our super high performance / precision and super high price premium opamp which sells for 100 times that. And then the defrauded buyer complains that our premium parts he bought from the Chinese are not meeting their premium specs. Except that the actual silicon they have inside is a 741 type. Oooops.

A lot of the counterfeit ICs enter China as genuine, good ICs from the original manufacturer, but they are aged (not reflow solderable anymore, after the moisture proof package was opened and then they were in storage for too long), or they are new old stock not conforming to the RoHS legislation in the tyrannical EU. So they can't be used for products anymore and ended up in the electronics junk recycling stream coming out of the EU (here in the US, they mostly went to landfills, but in the EU it is illegal to throw electronic components into the trash bin, everything is collected there and sent to special recycling centers who then send stuff to China).

So, as a hobbyist, you can be lucky to get perfectly good, genuine parts from Chinese sellers on AliBaba or AliExpress at good prices. Where the fraud and the criminal activity starts is when they restamp pre-RoHS ICs with date codes suggesting RoHS conformance, or when they turn one type of IC into another type. I was burned several times by that, I ordered 5V compatible CPLDs and got re-labeled 3.3V CPLDs of the same family. Which would die quickly when running on 5V. For my Apple-1 kits, I ordered DS0025 and the first 25 pcs (a trial run) were genuine, and at a good price, and the next, larger order all were fakes and re-stamped CMOS based MOSFET drivers which  almost  could work in the Apple-1 if it would not crash under the beatings to the supply and ground rails caused by these very, very strong drivers.

And the return process was very tedious and time consuming. The Chinese side sent emails calling me "friend" but always found excuses that they have to talk to the seller first, etc. I got my money back only after I threatened them with a claw back via the credit card company. If I put a price on my hourly rate above U.S. minimum wage, I certainly lost more money in terms of my time than what the whole mechandize was worth.

Your experience may differ. I think that if you buy small quantities of cheap parts, then they typically  rather refund quickly and without undue delay, because it's not worth their time to slow down or sabotage the refund process. But buyer beware, if real money is involved, and not only "peanuts" you may have a rude awakening to the crafty ways of these Chinese swindlers. They may agree to a refund, and then refuse acceptance of the return parcel, and somehow delay everything (bribing the Chinese postman ?) that the parcel bounces back to you after several months, and then it may be difficult to initiate a clawback by the credit card company. This did not happen to me, but to Armin who told me the story. He bought Apple-1 parts in huge quantitites from China, and got burned all too often. Which of course drives up the prices of his ready made, wave soldered Apple-1. Other then me he does not do this as a hobby, he has a family to feed, so he needs to make a profit. Unlike me, I've so far been able to avoid making profits from all my Apple activities (by design, it's called "going Galt").

(Please do not comment on this topic here in this thread anymore, you can instead 'wake up' one of the older threads on counterfeit Chinese ICs found in the Apple-1 forum).

- Uncle Bernie

Hi Fans -

even more questions on obscure Apple II hardware.

I've now tested most of the software I have on the Replica IIe, some from original floppy disks, some as WOZ files from the BMOW Floppy Emu, and so far I have found only a few titles which don't work. These don't work on a PC-48 equipped with 64k RAM (aka 'language card') neither, so it's probably not the fault of the Replica IIe. I have to follow up on this later and post a list of the suspect titles, none of which require an Apple IIe.

Discovery of the "Joyport"

During these tests I've encountered some games which give you a choice for game controllers, among which the "joyport". But as far as I can tell, the wikipedia page on the joyport does not have any links to a reverse engineered schematic for it. Which I would need to add it to the Replica IIe motherboard.

Maybe one of the readers of this post can help. I do have a schematic of the "Wico Joystick Adapter", though, which could be a knockoff of the "joyport".

Motivation for use of digital joysticks on the Apple II

Original (analog) Apple II joysticks generally suck. They are terrible and most games are almost unplayable with them. Digital (Atari style) joysticks are much more accurate and faster, so a good port for digital joysticks is a must have. Alas, my current hand wired adapter is rejected by "Burger Time", it just claims that my (digital) joystick is out of range. So any joystick adapter must be put under scrutiny.

Substituting keyboard controls ?

Yet another topic is those games which suck because they only offer keyboard controls. Alas, the different games have different key command conventions. I'm working on a solution for that, too, so you could play any game with a joystick, even if the game accepts only keyboard commands.

Project scope is growing and growing ...

So you see the Replica IIe project is growing and growing in scope. But I will do only one PCB layout, and so it must be a complete solution addressing all the issues, and not a half baked one to which additional hardware "warts" must be attached. The Apple II mouse being another such issue. Hard to find. I'm looking into Atari ST mice with are more abundant and like the Apple II mouse are "dumb", no microcontroller inside, just the switches and the chopper wheels. It also might be possible to remove the microcontroller IC from typical PC mice, PS/2 or USB, and rewire them with a new cable to mimic an Apple II mouse. Since I have *lots* of discarded PC mice in my basement (I use the trackball "Marble Mouse" exclusively since they came out) it should be possible to find one where the chopper wheels are correctly aligned for use with the Apple II.

What a can of worms did I open with this project. The scope is expanding and expanding ... now also looking into the Liron floppy disk controller, what it is and what it does. Work on a cheesy / stripped down IWM is ongoing. Hope I can avoid the 8 MHz mode. This would help a lot to get it done in a useful amount of time. You see, all what is needed for a IWM substitute in the Replica IIe is that its Apple IIc mode *thinks* that a real IWM is present. Not more. Not less. Just enough to mimic an Apple IIc. AFAIK, the IWM 8 MHz mode was for early Macs. (You may wisen me up if you know more).

Comments invited !

- Uncle Bernie