RC2017/10 Resumee

So, my first participation in a RetroChallenge was some kind of a failure. Apart from a very basic prototype I have not achieved my goal in building a replacement for the Apple II Mouse Card at all. Instead I got distracted by my other project, the SD based mass storage. Since I wanted to use the same CPLD based design I figured I'd get that one right first. But after having changed almost everything, it still does not work and I'm kind of out of ideas what else to do.But like the Olympics, it's all about being part of it. Maybe I'll have more luck next time.

More minor successes

I've been rearranging the VHDL code a lot and it had a positive impact on timing not only in simulation, but on the real hardware, too. The problems with the EPROM 'disappearing' in the middle of the code execution seem to have gone. Also, I rearranged the assembly code for a (hopefully) more efficient driver. I wrote a test routine that writes a 512 byte block to the card, reads it back and compares the two. The test shows that data is written correctly to the card, but is not read back correctly, sometimes. I think it may have to do with the timing (again) how data is read from the Spi bus into the CPLD. That is about the only thing from the original design, I have not touched. It would surprise me, though, if the was nothing to improve...

Minor success

The Apple Super Serial Card uses address line A11 to switch the card's ROM to always to the same page ($700), when any part of the $C000 - $C7FF space is accessed. An access to $C800 - $CEFF is mapped to $000 - $600. This takes place in the first part of the CPU cycle, when the address bus becomes valid, so the ROM has enough time to react.Why hadn't I thought of that myself? I mean, the guys at Apple only did that 40 years ago. But I am just a software engineer, to my own defense.As soon as I got home yesterday, I made the modifications necessary to support the new address decoding for the EPROM. This required only the change of one line of VHDL code and the connection of A11 to a CPLD pin. I repurposed the unused /IRQ pin for that. Now I can access all pages of the ROM again!

Operation successful ...

... patient dead. Or at least in a coma. πŸ˜’I spent all of last week fixing the timing problems I described in my last blog. I cross checked the timing constraints for the different Apple II models and combined them to form a worst case scenario. This includes the long time the II+ takes to establish a valid address and the short data hold time of the IIgs. To verify that timings were by the book, I learned how to write VHDL testbenches (how have I lived without them?). The simulation showed me some flaws but I corrected them and now everything is fine. I even wrote a driver test that writes a block of data, reads it back and checks for errors.However, one thing I did not realize was that 27xx type EPROMs are relatively slow. They take up to 450ns to output data after the address is valid. The select signals that activate the ROM and forward the address bus are valid for 500ns. With my timing redesign, the signal is cut off by about 70ns at the beginning to avoid bus fights. I think yo…


Apart from being one of the most obnoxious people I ever met, my professor for digital circuit design at university told us some things that stay in the back of the mind. πŸ‘¨πŸ»‍πŸŽ“One of those things was that, in a digital design, you should always make signals that are asynchronous to the system clock synchronously. Usually this applies to signals like pushbuttons or from other devices that are separate. In case of the Apple II peripheral bus there are both synchronous and asynchronous signals. Unfortunately, this is not really clear in the simplified bus timing diagram that appeared for example in the II+ manual.
7M, Q3, Phi0 and Phi1 are really synchronous as they are devided from the 14MHz main clock. In my CPLD design for the AppleIISd card I used 7M as clock, because it is the fastest clock that is available on all slots.
The three select signals, /DEV_SEL, /IO_SEL and /IO_STB are related to Phi0/1 but are slightly late due to propagation delays in the logic that generates them.

First contact

I managed to put a first prototype together: an Arduino nano is talking to a PS/2 mouse. The adapter on the mouse is an old AT to PS/2 keyboard adaptor. There are no electronics in it and I had the 5 pin DIN sockets here. I think I'll stick with that, because the mounting holes for DB9 connectors in the back of a IIe or IIgs are actually prepared for DIN connectors as well.
The A2 can read the XY position register values through a 6522 VIA, because the Arduino is not fast enough to read the address bus and put the information on the data bus. The A2 has to tell the VIA which data it wants to read and that tells the Arduino. That in turn outputs the data that is then latched on the VIA to be read by the A2. Easy, isn't it?
A tiny driver represents the READMOUSE routine of the original card. For now, I can read and display some values in Applesoft BASIC when the mouse is moved.
This pretty much copies the original design. I think the detour through the VIA is annoying and slows…

There are never too many Apples

Apple II europlus, ca. 1981 Apple IIe, ca. 1983 Apple IIgs ROM 01, ca. 1987
Not pictured are my nine Macs: Classic PowerBook 180
Performa 460 PowerBook 190cs PowerMac G3 266 MHz
PowerBook G4 500 MHz
PowerMac G5 dual 1.8 GHz PowerBook G4 1.33 GHz iMac 27" 3.06 GHz

I seriously doubt that you can have too many Apples! πŸ˜†