Some SL5 ROM-dump failures and successes

Once again logging discussion of the SL5 dongle from Facebook.  In my previous blogpost I saved "permalinks" to that discussion on Facebook, but it has proven frustratingly useless because Facebook automatically scrolls away from the linked content when a user opens a permalink.  (It's the same issue that occurs with Facebook notifications, which employ permalinks, because the platform tries to engage users by leading them to "top comments" or "relevant posts" without regard for what was requested.)

Jan 17

Card described by @jeffd as, "all of the ICs and the caps had a black coating to hide what they are. When I first started looking at the EPROM I was confused by that and thought they may have etched away the part number. I know chip markings are made to withstand harsh chemicals so that was a surprise. But lots of IPA and rubbing exposed the markings on all compents except the ceramic caps. Those markings weren't as durable as the chips. They look like power filters so exact values may not be important if anyone desides to clone the design."


Jan 20

Bootstrap EPROM listing from SL5 card as it appears in the monitor when installed in slot 4.

Plain text iconCard ROM disassembly.txt


Jan 20

Parts list from a FB comment.

  • 7404 DIP-14 Hex Inverter 
  • 7408 DIP-14 Quad 2-input NAND gate 
  • 7411 DIP-14 Triple 3-input NAND gate
  • 7420 DIP-14 Dual 4-input NAND gate
  • 7432 DIP-14 Quad 2-input OR gate
  • 7474 DIP-14 Dual D-type flip-flop
  • 7493 DIP-14 4-bit binary counter
  • 74244 DIP-20 Tri-state octal buffer line driver


Jan 20

Initial comments about artifacts in the $C400 bootstrap EPROM listing.


Jan 21

The raw contents of the 2716 EPROM appear to be scrambled by rearranging the address lines.  So it lists all the correct byte values, but the bytes are not in the correct order.


Jan 23

Commented listing of card's bootstrap ROM with additional callouts.


Jan 23

Utterly ineffective copy routine, which attempted to imitate the boot ROM's behavior of issuing a STA $C0C0 to unlock the EPROM and copy it into RAM.  The EPROM did not activate, so this routine merely copied meaningless 'vapor' bytes into RAM.


Jan 25

Byte-counting histogram shows the 2716 has exactly 172 bytes with the value $EA, which exactly matches the quantity of NOP instructions ($EA) in the $C400-$C4FF boostrap EPROM.  This suggests that the bootstrap EPROM accounts for 100% of the $EA bytes in the whole 2716, which is sufficient to esablish that bytes in the $C400-$C4FF range are all stored in addresses with 1-bits at address pins A1, A3, and A5 of the 2716.  That left us with 8 address bits to be descrambled, which leads to a lucky find: there are exactly two $C0 bytes in the 2716, which must be those two adjacent bytes in the STA $C0C0 instruction at $C427 and $C428 in the bootstrap-EPROM.  Only bit A0 differs for their bootstrap-EPROM addresses, whereas only bit A10 differs in their 2716 EPROM addresses...therefore A10 must map to A0.  We can establish the mappings for additional bits by repeating this procedure.


Jan 25

Address mapping derived from a histogram of the 2716's srambled data and mapping of individual byte values from the $C400 bootstrap ROM.

Address mapping spreadsheet derived by @jeffd tracing connections on the 2716 pin-by-pin.


Jan 25

First guess at the contents of the $C800 EPROM, derived by rearranging bytes from the scrambled EPROM dump.  With comments added.


Jan 26

The BASIC portion of the de-scramble routine counts EPROM addresses from $000 to $800.  For each address, it calls a machine code routine to rearrange the address bits to determine a different address for the byte at that location.  Then it reads a byte from the scrambled address in the scrambled EPROM and stores it at the position where it would appear in a non-scrambled address in a non-scrambled EPROM.


Jan 26

Another ineffective attempt to unlock the card's EPROM, again adapting the STA $C0C0 instruction from the card's bootstrap ROM at $C425 on the premise that there might be a particular byte that has to be passed to the card to unlock it.  The card did not unlock its EPROM even after trying all 256 possible byte values.


Jan 28

A Facebook user posted this picture of a software dongle to the Apple II Enthusiasts group on Facebook.


Jan 29

eBay seller ThatMacGuru sold a software dongle accompanied by a very sad looking floppy disk, under the auction title "Unknown mystery Apple II card w/floppy disk software - GDS".  The description says, "I have no clue what this is other than it came with an Apple II. Disk is labeled "GDS JOB SAVE PROGRAM". The serial on the floppy disk and card match. That is all I know!"


Feb 3

Discussion with Steve Brown draws attention to JSR CHRGET calls within the bootstrap EPROM and "locked" region of the EPROM.  Microsoft BASIC locates the CHRGET routine in RAM, so these callouts are vulnerable to attack by patching the RAM where CHRGET is stored.


Feb 4

Proposed diagram of commands that should allow the card to unlock itself, but with a hook at CHRGET that directs control into the monitor before the card can lock itself again.  This is just a simulation of how it should look...if it works.


Feb 17

A tentative guess at the EPROM contents with comments about its anti-tampering tests hidden in the locked EPROM, and a memory-wipe routine.


Feb 17

@jeffd successfully unlocked the EPROM using the CHRGET hook, and confirmed the contents of its $C800 EPROM matched the bytes we had obtained from de-scrambling the 2716 EPROM dump by re-mapping address lines A0-A10.