AppleIISd V1.2.2 - Silly bugfixes and an improved flasher application

 Thanks to the fact that I could (luckily) continue working through the past year, I haven't had much time at all to do work on the AppleIISd and people have been nagging me to support non-65C02 models as well. In fact, when working from home, I wasn't in the mood to do work on personal projects at all when I've been doing professional work in the same room on the same computer the whole day long.

In a brief moment of being inspired, I managed to find a bug that's been haunting me since I introduced the new SMD board design (see my last post on the AppleIISd). The problem was that despite the manufacturers claim for having a power-up write protection, the first byte of the now soldered EEPROM would be erased frequently causing the card to stop working. My manufacturing partner and I did hundreds of On/Off switching tests, monitoring power and data lines. We didn't find anything that would lead us to a solution. I reviewed the VHDL for the CPLD over and over again and made sure by simulation and measurement that the write-enable line was switched off properly after programming and was forced in a high state (meaning read-only) by a reset as well. My workaround was to include a jumper on the card to tie the write-enable pin on the EEPROM to +5V when in normal use. I was never happy with this solution because it forced you to touch the card when updating it, something I wanted to get rid off by using an EEPROM. We suspected the well-known chip maker to lie to us in their spec sheet where they claim their chips are immune to power-up conditions where the control lines may be in an indefinite state. After all, at work, I just had to deal with another well-known chip maker whose UV light sensors degraded under the influence of UV light. I know this sounds silly, but it caused us big trouble. They said the sensors didn't degrade, but we proved them wrong.

It was not until quite recently that I found the reason for the problem of the erased first byte. The EEPROM manufacturer will be pleased to read that he is not to blame, but, as usual, the fool at the keyboard (i.e. the programmer, me). The instruction LDA #$03 (yes, only this one) at the beginning of the SD card initialization was in there from literally day one. This was around June 2017, when I made the first tests with a hand-wired test board. Back then, I used the almost unaltered VHDL sources of the 65SPI/B controller by André Fachat that required the setting of SPI mode 3 (using bits 1 and 0 in the control register) to be compatible with SD cards. In October 2017, I removed a couple of (for me) unnecessary features from the VHDL to gain space on the CPLD. During this cleanup, I hard-coded mode 3 into the SPI controller as this would be the only one I needed. However, the line of code in firmware remained untouched.

Fast forward to March 2019. I had just come up with a way to replace the EPROM with an onboard programmable EEPROM and needed a way to control the write-enable line from the card. The choice was the (seemingly) unused bit 0 in the control register. By now you might see where this is going... In my mind, the card's firmware would never touch this bit, as it was not necessary. Only the flasher application (see this posting) I had created for the sole purpose of updating the card's firmware, would write it directly when performing its duties. "And I would have gotten away with it too if it weren't for you meddling kids!" Only here the "kids" was this single line of code that sat there so completely useless apart from initializing two other bits to zero. Technically there is no write access to the EEPROM in the SD card initialization sequence, but you can't be sure that when the chip is ready for being written to the odd electron or two might jump over. This is the reason why only sometimes the first byte would be erased.

Apart from finding this nasty bug, I improved the flasher application to include an erase option and made use of the write cycle check offered by the EEPROM. I hope that all of this will improve the reliability of the card.

Oh, one more thing! The "problem" with the card not working when a Z80 card is installed turned out to be not a problem with my card. It is the No-Slot-Clock driver that is on my ProDOS test image because I have one installed in my IIe! I will write about the issue (and probably a fix for it) in the future.