Hey all!
I was poked by
@Kai Robinson and
@bakkus to do a bit more of a write up/explanation of what the hell I managed to do! [Wow I rambled for a bit]
Bottom line is - we are able to make new CUDAs and EGRETs using 68HC705e1s.
I'm lead to believe in the vast majority of the cases the CUDA and EGRET as used on quite a few macintoshes is in reality a 68HC05e1 - and not any other variant of the 68HC05.
I'm lead to believe that due to two factors:
> The first is that the pinouts of the 68HC05e1 (hence referred to as the 'e1, as I'm probably going to strain my wrists typing "68HC05e1" every time) match the pinout of the EGRET/CUDA whenever they appear on schematics. The 68HC05e1 Datasheet is
here.
> The second smoking gun is that all of the dumps of the EGRET/CUDA ROM are specifically 4352 bytes in size. These dumps can be accessed from the internet archive
here.
The reason why 4352 is a bit of a magic number is because this is the total of the program data (4096 bytes) plus the user ROM vectors (16 bytes, also why the ROM size is sometimes counted as 4112 bytes), plus 240 bytes for the Bootloader.
As such, if the pinout matches, and the ROM dump matches - I would say with some confidence that both the EGRET and CUDA are both* 68HC05e1s.
EDIT
> Third reason, the pinouts are described in this
Google Doc, they are all 68HC05e1s! This project tackles the parts that are listed in that directory, which pretty much describes most of the EGRETs/CUDAs.
*in most cases. As I found out, the CUDA Lite on the 4400 and Tanzania clones (umax, motorola etc), used in some cases a 68HC[7]05e5. The main difference between an 'e1 and a 'e5 is that the 'e5 has a bit more EPROM space. EPROM total is 5120 bytes instead of 4112. I have asked
@Mac84 to dump any CUDA Lites he can, so we can compare the two. The program that was used to dump all of the EGRET/CUDA ROMs is
this one from Mini vMac. Damn useful!
So we know that the EGRET/CUDA is likely a 68hc05e1 - which is slightly problematic as the program ROM and all accompanying data is stored in a Mask ROM - I.E, burnt by Motorola during manufacturing.
However, the 68HC05e1 has a relative - the 68HC705e1.
This is basically the exact same chip (same pinout, memory map and so on), except that the program ROM isn't a Mask ROM - it's an EPROM. We can program it!
Better yet, the datasheet included a full schematic and explanation of how to build a programmer to actually program them! (which uses an external 8k EPROM. Don't ask) There are two datasheets available for the 68HC705e1 - the first is from NXP (
here), and it's a bit terrible as the programmer schematic isn't complete. The original Motorola one is a bit more accurate (
here).
So we have a pretty good idea of what the original chip is, a good idea of what could be a drop in replacement, a programmer schematic as well as a good chunk of all of the ROMs we need to start programming EGRETs!
There is however, a few snags.
The first - and it's a biggy - is the Mask Option Register (MOR). The MOR is a single byte at location 0x1F00 which is only present on the '705e1, and it's basically a few settings that would be programmed into the Mask itself during manufacturing. The '05e1 uses that region for a self test ROM, and as such, the MOR settings wouldn't be present in any of the dumps.
The MOR handles three things:
1) internal interrupt (0.25s, 0.5s or 1s)
2) whether the watchdog is enabled
3) whether an external IRQ is used.
Thankfully by checking Macintosh schematics we can clearly see that the external interrupt isn't used (it's pin 1, and it's always brought high - so as the IRQ is active low, we can tell that it's never used. So this can be set to 0.
The wonderful
PhilPem was able to do a bit of a disassembly on the EGRET code, and at least for the 341S0851 (which is apparently the most compatible of the EGRETs), the watchdog isn't used - so that can be set to 0.
The final question was around the internal interrupt - which is always set to
something. However, as the EGRET is used as an RTC - we guessed that a 1s internal interrupt is probably correct.
This meant that the MOR is set to... 0x00. It's cleared. In my own implementation I wrote 0x04 (it does the same thing as 0x00) just to make sure I had definitely set the MOR to *something*.
With the MOR out of the way, came the problem of getting the dumps in the right format.
Now this does sound a bit odd, but stay with me.
The dumps that are found online - as far as I can tell - start dumping from the internal memory of the CUDA/EGRET and keeps going until it reaches 0x1FFF. This means that it will happily pick up the data for the Bootloader/Self Test ROM as it goes along. It also means that the data is offset by 3072 bytes, as the programmer expects the program data to start at 0x0F00, whereas the dumps always start off at 0x00.
The easiest solution is just to add 3072 bytes of clear data at the start of the dump, which will get you a mostly valid ROM file. This will give you exactly 8k (8192 bytes) of data to be flashed to the external EPROM.
It's also good practise to clear out 0x1F01 through to 0x1FEF, so you don't accidentally wipe the bootloader (I don't think that can happen, but it might?). Then you can set the MOR byte at 0x1F00 (if it's anything different to 0x00), and check that there is data from 0x1FF0 through to 0x1FFF. These 16 bytes describe the before mentioned user vector EPROM bytes.
You might begin to notice that this method of formatting the ROM file looks very similar to the actual memory map of the 68HC705e1, and that's because.... yes. The external EPROM basically needs to match the actual memory map of the 68HC705e1. Which is fair play, it probably made writing the bootloader easier!
The final change to the ROM file before it can be flashed is to duplicate a single byte from 0x1000 to 0x000. This is because some of the. 68HC705e1s (including the batch I bought) have a minor issue with timings during programming. This is described in the errata sheet
here.
After all that, we have a good EPROM image to be programmed for the programmer.
Granted, I know it's a bit frustrating that you have to program an EPROM just to then program the 68HC705e1 - but my mantra is to always at first make as few changes to a reference design as possible. If something goes wrong, it's more likely there is an issue with the reference design than your own work.
I'm also aware that it's a bit of a confusing mess. If you need clarification - please let me know!
After all that, thankfully building the programmer is the easy bit.
It's a relatively straightforward design using the aforementioned 8k EPROM of your choice, with an external 12 bit counter to handle the EPROM address lines.
I also intentionally kept the entire thing as Through Hole rather than SMD - keeps it nice and easy for other people if they want to build their own!
The current design is VDEV2 of the Raven Programmer (VDEV1 had issues introduced by the NXP datasheet. Basically the NXP datasheet missed out what you do with PB1, PB6 and PB7. These have been corrected in VDEV2. All of the parts are relatively easy to find, even the 68HC705e1s can be purchased on ebay for relatively cheap - although I'll imagine stocks of them are probably in short supply, so no hoarding. Please!
After that, it's just a case of flicking the switches to program (on, on) - giving it 5v to begin with, then giving it 16v for the programming voltage - and hitting reset!
As mentioned,
@max1zzz graciously accepted my request to test these first batches of EGRETs.
It was their request for the 341S0851, as it is one of the more compatible EGRETs. If I remember correctly it can at the very least be dropped into the LC line, as well as the IIsi.
His testing happily confirmed that the EGRET is working. I know the video only shows that the system chimes, however, we have had full confirmation that the ADB ports work, the RTC also increments at the correct rate (so my MOR settings are correct!), the PRAM settings are stored, and as far as we can tell the interrupts to the CPU are working as expected. A Techstep tester also indicates that the EGRET is happy!
Admittedly, we do still need to check that the soft power works by dropping it into a iisi, however, I feel that as the soft power is just another IO pin on the EGRET, and as all other functionality is working as expected - it's likely the new EGRET is happy and healthy.
So where to go from here?
The next steps is to start testing more and more EGRET/CUDA replacements.
I started this entire journey off because I purchased a horribly overpriced colour classic that I was lead to believe was fully alive - but it turned up dead, mostly due to a dead EGRET, likely due to other cap leak related failures. Unfortunately as I have other commitments (work, life, retrofest, other sad and dead computers) it may be some time before I can test all of the EGRET/CUDA replacements.
My long term goal is to have all of the dumped EGRET/CUDAs (or at least enough dumped ones for the entire Macintosh line) in the correct format for the programmer, programmed to actual 68hc705s and tested. However this may take some time!
In the meantime, I have acquired a CUDA lite from a Tanzania Macintosh clone (same as the Power Mac 4400), and I've successfully transferred it to my own 4400. This is important as this CUDA Lite used a 68HC705e5 part (as mentioned), so that the MOR for the CUDA should be present and able to be read - meaning that at least the MOR setting would be accurate for the CUDAs. (They appear to use the IRQ line, so the CUDA should theoretically have a different MOR) - but currently the data appears to be inconclusive, as the MOR byte is again 0x00!
Either way - as mentioned, as all of the dumps present for the CUDAs and EGRETs are all 4352 bytes, they should all be theoretically compatible with the 68HC705e1. Therefore, all of the CUDAs and EGRETs should be able to be reproduced using this process, with the Raven Programmer.
TLDR; New EGRETs and CUDAs can be made with this (
here) programmer and 68HC705e1 ICs, so long as the ROM is in the right format. 341S0851 EGRETs have been flashed and tested. CUDAs are a work in progress.
Also If you have any questions, either reply to me on here, I'm also on the Tinker Different Discord, as well as on Mastodon as DosFox (
https://tech.lgbt/@DosFox). I'm aware this is a very long and complex subject, and I am atrocious at explaining things. If anyone needs any help (maybe a new EGRET or CUDA?) I'll be happy to help!
Also - Raven Programmer. This was a project for the spooky month of October. As an Egret is a bird, what's a spooky bird? Yep. A Raven. Gettit?
github.com
