Hi fans -
today I made some progress with substituting the timing HAL of the Apple IIe and IIc.
Here is what happened so far:
Weeks ago I took the equations from Jim Sather's book and plugged them into my PLD design software.
I then turned loose my proprietary PLD test and analysis tools on the JEDEC, and got lots of automatically generated test vectors.
Alas, when I took that JEDEC file to a programmer, and ran its test vectors against a real HAL (Apple part #341-0710-A date code 8429) plugged into it, I got hundreds of vector fails.
This does not necessary mean that Jim's equations would lead to a PAL that doesn't work in an Apple IIe, but it proves that his equations are not the same as the (unknown) equations in the original Apple part.
So I did not pursue this any further and decided to do my IOU substitute development without modelling the video pipeline in the Apple IIe in the high level simulations. This "hole" in the simulations then led to a few iterations of the WNDW signal equation until it was right. Had I modelled the video pipeline, then I would have seen the discrepancies already in the simulations. But this was impossible to do, having no proven HAL equations. If you are interested in my IOU substitution work, see post #14 and below of this thread:
https://www.applefritter.com/content/uncle-bernies-iou-and-mmu-substitutes-plds
OK, it was not a big loss of time. Writing about the pitfalls and design iterations with WNDW took me far more time than actually diagnosing and fixing it. But I thought that I should give an accurate account on how the work was done, and what went wrong. (Other people tend to show only the finished product and pretend they got it right the first time, because they are much smarter than the rest of us. Yeah, sure.)
After the IOU work was done (some further testing required, need an NTSC Apple IIe for that, which I hope to get soon) I reverse engineered the HAL. It took me a whole day until my RTL yielded a JEDEC file which, when ATVG vectors were generated for it, would run these vectors on the real HAL without fault. It turned out that the master timing state machine (PHI0, PHI1, Q3, RAS, AX) in the real HAL is far more tricky than you would expect. There are numerous detours in the state transition graph (STG) where it waits for certain conditions. This looks as if they added these exceptions to enable their state machine to recover from losing track with the M7 and COLREF signals. In normal operations, these exceptions are never taken.
After the ATVG vectors ran fine on the real HAL I had a > 95% chance that my version indeed is a faithful reproduction of the original HAL. This essentially is the test vector fault coverage. If there were some side branches in the STG of the HAL but not in my STG, then it is highly likely these would have been uncovered by these test vectors. But this is not a full state machine equivalence proof yet. This requires more work, and I first need to repair the machine I once built for this purpose, more than 30 years ago.
I did program a GAL16V8 with my JEDEC file and put it into my Apple IIe. It seems to work, but I can't check if all the colors are right before I got a NTSC Apple IIe. Here is a photo of the GAL running my Apple IIe:
In the background you can see part of the IOU and MMU PLD substitute slot card.
In the next days I will repair my PLD compare machine and if I can bring it back to life, I can let it compare the GAL to the HAL. This again is a fully automatic process. Just put the PLDs in and push a button. Seconds later you have a green light (match) or red light (difference). I'm a lazy guy so I always try to automate all mundane tasks as much as possible ;-)
Stay tuned !
Here is a question I have on the HALs which some more experienced Apple II aficionados my be able to answer:
In my NTSC Apple IIc, I found two different HAL part numbers:
341-0170-A date code 8441 (same Apple part# as the HAL from my PAL Apple IIe)
342-0170-A date code 8512 (note the "342" instead of the "341")
Unfortunately, the HALs in these Apple IIc are soldered in and before I know I indeed have a valid substitute, I don't want to take the risk to desolder the 342-0170-A).
Maybe somebody on this list knows about the difference (if any) between these two HAL versions.
Comments invited !
- Uncle Bernie
When it is validated are you going to publish the .pld and/or .jed file for that 22V10? I understand if you don't want to but it sure would be nice to have it out there in case people need to replace a bad HAL.
I need to pull out those two NTSC motherboards I have and see what state they are in. I know one of them is for sure missing the MMU.
In post #2, softwarejanitor wrote:
" When it is validated are you going to publish the .pld and/or .jed file for that 22V10 ? "
Uncle Bernie answers:
Yes. I will publish the JEDEC file (including test vectors) here on Applefritter when it has been validated 100% to contain the same logic as the original Apple HAL. I will publish two JEDEC files, one for the PAL16R8 (bipolar) and one for the GAL16V8 (CMOS). So people can grab the JEDEC file and program HAL substitutes.
Once I have the 100% validation of the 341-0170-A I will desolder the 342-0170-A from my Apple IIc and see what the difference might be. If there is a difference, I suppose they fixed a bug, and then I will make these JEDEC files available, too.
Thanks you very much, softwarejanitor, for your offering of the NTSC Apple IIe motherboard. The Apple II aficionados worldwide have an eye on us. It's an important mission - once the JEDEC files for the HAL are available, we can build Apple IIe replicas. 'frozen signal's work on drop-in IOU and MMU substitutes seen here:
https://www.applefritter.com/content/question-about-weird-thing-mmu-schematics
are the remaining two missing pieces (I know, my own PLD based IOU and MMU substitutes also do work, but these don't drop into the same DIL-40 sockets, so I'd need to design a new, different, motherboard, while 'frozen signal's solution could use a 1:1 clone of the original Apple IIe motherboard.)
I think that a smaller, cheaper, Apple IIe replica motherboard might also be attractive for those on a budget, much the same situation with the "clones" of the Apple-1 vs. the "replicas" such as the "Replica 1" designed by Vince Briel. You can't build an Apple-1 clone for less than, say, $500. But you can build the "Replica 1" for less than $100. Enclosure, power supply, keyboard and video monitor add to these basic costs. (Just to make this clear once and for all: a "clone" is a 1:1 copy having the same "genetic code", that is, the same PCB layout, the same circuit, the same type of ICs, the same "looks" --- whereas a "replica" is a functional substitute which uses different PCBs, circuits, ICs, and has different "looks" - most people are sloppy with their wording, and this often leads to confusion and misunderstandings in discussions, which can easily be avoided when using the right terms).
I have some early sketches for such an Apple IIe replica, on a small PCB, which probably could be built for less than $100, too. It only has two slots but you could dial in the slot numbers. I don't think that any slots would be needed to play games and run other standard Apple II software, as the 'Woz Machine' and the 'Language card' would be integrated on this PCB. For for those who want to experiment with slot cards, or to put a Z80 card in to run CP/M, two physical slots should be enough. But I'm not sure if I ever will design such a PCB. I will make a wire wrap version, though, just to test the concept.
Maybe some readers have suggestions / comments on their own "dream Apple IIe replica (not a clone !)". Because it's getting into reach now, with all the work by various designers on the IOU, MMU, and timing HAL getting closer and closer to the finish line (we are almost there).
Commens invited !
- Uncle Bernie
P.S.:
The one missing piece for a commercially viable Apple IIe replica kit (that can be sold by a small business) is how to dodge the deadly copyright bullet involving the firmware ROMs. Which are (c) Copyrighted by both Apple (the corporation) and Microsoft (the corporation). The issue is, you can't just burn an EPROM with the Apple IIe firmware and sell it in a kit, without inviting hostile legal action against you. However, a hobbyist could grab the binaries from the web and just burn an EPROM, and call it good. This, however, limits the pool of hobbyists who could build such a kit, as not everybody has an EPROM burner. These are cheap to buy, but still, why buy a 'thing' that is used only once. It's a waste of money if used only once to build a $100 Apple IIe replica kit.
I think I do have an innovative solution to the 'Copyright Problem'. Which involves a code morphing trick I'm still working on. This trick would allow to sell a complete kit with the whole firmware and not violate any copyright. Still, it can't guarantee if that foul trick would stand up in a court of law. It's based on my own (limited) understanding of the U.S. Copyright Law as a layman. I'm not a lawyer, and all I know about it is based on a book from the 1980s. The DMCA changed a lot of things to the worse (among other evil effects, it destroyed the 'Right to Repair').
Oh, I missed that it is a 16V8, that's good because those are more readily availabel, cheaper and easier to program than 22V10.
It is really awesome that we're so close to being able to build new //e from scratch.
Hi Uncle Bernie,
I'm very intersted in your HAL decoding ! I'm currently trying to figure out Jim Sather's equations and like you, I came to the conclusion they are strange. In particular, I believe they don't correspond to the figure 3.10 (Timing HAL Layout)... So I hope you'll publish the results of ryour your research quickly !
Stéphane
For anyone interested in these equations but unaware of this document, these have been published here: http://www.applelogic.org/files/3410170A%20(ABEL).txt
In post #6, 'frozen signal' wrote:
" For anyone interested in these equations but unaware of this document, these have been published here ... "
Uncle Bernie comments:
Ouch ! These guys screwed up the format of the Apple part #, so I could not find it with my web search. Again, it's just another case of the old adage:
" Six months in the lab can save you six hours in the library !"
Anyways, even if I had found them, they would have been (almost) useless for me, as I needed the RTL, meaning: a high level description of the state machine within that HAL. Because I want to change a few things to give my version of the Apple IIe some extra features.
These equations appear to be correct but they are in an awkward format which is not ABEL syntax, but look like PALASM syntax to me. I had to waste 15 minutes of my time to do "search and replace" with VI to arrive at equations which ABEL would accept. Then I had a JEDEC file. Which I ran trough my proprietary software to generate ATVG vectors. These then were run against the real HAL. And lo and behold, all the vectors did pass:
PDRM4462C.jpg
One interesting find is that these equations have a 99% fault coverage, while my equations, which are functionally the same as far I can tell at this point of the work, only have ~95% fault coverage. The state machine analysis phase of my software reports the same number of states, however.
This is strong evidence that the designers at APPLE either used hand optimization of their logic equations, or, that they had a very sophisticated logic synthesis tool which did not exist yet in Y1982. If I would remove the untestable factors from my synthesized equations, the functionality is still the same, but testability goes up. This has to do with stuck-at-1 faults in the product terms which cannot be tested since the state needed to excite these faults does not exist. Since that state does not exist / is not reachable, that factor in the product term can be set to "1" which is just the stuck-at-1 condition that can't be tested. So in the end, that factor goes away, and the functionality is still the same. More sophisticated logic synthesis tools put the unreachable states of each state machine into the "don't care set" for the logic minimizer (such as ESPRESSO). But there is a catch doing that: the minimized equations might generate a loop of unreachable states which cannot be left. This would mean that the system could hang forever. Of course, a humble RESET pin can solve that, but who has the luxury of a RESET pin on these small PLD devices ? The HAL has none. Neither has the 74S109 clock divider. I think this is the reason why the designers of the HAL put in so many complications in their master timing state machine STG, to make it able to synchronize itself to said clock divider, for any system "wakeup" condition. The feature of the Apple IIe that a slot card in the AUX slot could enable and disable the 14 MHz master clock for the whole system and substitute it with its own clock may have contributed to all this fear and loathing and mitigation efforts. If the HAL would make the M7 and COLREF clocks by itself, then none of these concerns would apply.
Further work to do
If I can remove factors to reach 100% fault coverage from both sets of equations, then the resulting JEDEC files would be state machine equivalent despite the equations might have small differences. Until this is done we still don't know 100% for certain that these equations describe the real thing (the real HAL). But 99% means we are very, very close to be certain.
I've attached the JEDEC file generated by my software. Don't you think it's a cracked version because it has a weird user ID. This is serial number #1 which I had reserved for me as the author of this software suite.
If you have a GAL programmer able to program GAL16V8 with a 16R8 pattern (the professional ones can do this) you could try it out and plug the resulting GAL into your Apple IIe. Run color test programs to see if the colors (especially in HIRES and DBLHIRES modes) still are right, and post your findings here.
- Uncle Bernie
The JEDEC file based on the 'anonymous' equations seen on: http://www.applelogic.org/files/3410170A%20(ABEL).txt
(Most programmers demand that the ending is .jed but Applefritter does not allow this ending, so rename this file after download)
When I have to upload a .jed or other file AppleFritter doesn't allow I usually just zip it since AppleFritter will happily let you upload all the .zip files you want.