Add a hardware implementation guide

[frozen-signal]

Implementing a hardware solution with the current state of the project is not a trivial task.

[Giorgio-BE]

Hello,
I've been following your project for quite some time and I'm very excited now that the coding work is finished, tested and working. I have several Apple IIe computers (all the different versions of the motherboard) and I would like to test on all of these. Are you going to document on how to use it to create the respective chips which can be put into the sockets?
Best regards and thank you for your hard work you have already done on this.

[frozen-signal]

Hello Giorgio,
I'm really glad you have interest in this project. Yes, I plan to write a guide on how to create both the IOU and the MMU from these sources. I have been working with Henry from ReActiveMicro.com to create a replacement IOU and MMU. If you just want to test your Apple IIe units and you are not really interested in building your own IOU/MMU, the easiest solution for you would be to wait; we are in the final stages of this project and will soon release a replacement IOU/MMU using these sources.

On the other hand, if you want to create a replacement IOU/MMU, the FPGA/CPLD you plan on using will determine the complexity of your design. If you use a 5v compatible device, you just need to connect the pads for the MMU, and you need a 10K ohms pull-up on the /RESET line for the IOU.
But, most FPGAs/CPLDs nowadays are 3.3v and you will need to level-shift the Apple's 5v to 3.3v. Here'a a photo of the difference:
On the left, with all the wires, is the MMU with a 3.3v FPGA. To it's right (center), you can spot the IOU prototype that uses a 5v CPLD.

For the MMU, I used 3x 74LVC245 (on the breadboard under the wires) to level-shift the inputs to the MMU (A0-A15, PHI_0, Q3, /PRAS, R_/W, /INH, /DMA) to 3.3v
The 3.3v outputs are fortunately enough to be interpreted as logic HIGH by the Apple IIe.

For the IOU, it is more complicated. First, you will still have to level-shift the inputs (PHI_0, Q3, /PRAS, R_/W, /C0XX, VID6-7, A6, IKSTRB, IAKD)
And second, some of the pins are bi-directional (/RESET, ORA0-6). But you need to level-shift these pins and just connecting them to a 74LVC245 will break the bi-directionnality.
This means that you will need to change the sources (IOU.vhdl) to expose FORCE_RESET_N_LOW and RA_ENABLE_N.
You will then need to use these two signals with separate 74LVC245s and change the direction of the bus transceiver according to: (I haven't tested this and I can't certify that this would work)

• When FORCE_RESET_N_LOW is LOW, RESET_N should be an input; when HIGH it should be an output. I haven't checked but maybe a pull-up will be needed on both sides of the 74LVC245 for this signal.
• When RA_ENABLE_N is HIGH, ORA0-6 should be inputs; when LOW they should be outputs.

You also possibly will need to write code: The multplexed address lines need a hold delay. This project currently support ALTERA devices (with LCELL primitive), as well as iCE40 (untested) and MACHXO3D. But if you use something else you will need to write your own "hold time" component. (See CUSTOM/RAS_HOLD_TIME/readme.md for info)

As you can see, a bit a work is still needed to bring this project to a more user-friendly state.

[frozen-signal]

Oh, I am forgetting about the files you will need for each IC.
For both the IOU and MMU you will need:

• All the .vhdl files in COMMON
• An implementation of RAS_HOLD_TIME (see CUSTOM/RAS_HOLD_TIME)

For the IOU, you will also need:

• All the .vhdl files in IOU
• In TTL, the files LATCH_9334 and LS138

For the MMU:

• All the .vhdl files in MMU
• In TTL, the files LATCH_9334 and LS175

And, as you can guess, the top-level unit is "IOU" for the IOU, and "MMU" for the MMU.