A0, A1, A2, and so on are the address lines. You have 32 of them.
When looking at the schematics you will see the signal name (let's take A0 for example) and the corresponding pin number (pin A2 in case of A0, pin C4 for A1, pin D13 for A2...)
When you flip pages to the video section you will see that A0 should be present at pin 4 of UD8 as well. Put your probes on pin A2 of the CPU and pin 4 of UD8 and you should get continuity between those two.
Repeat with all other address lines that are present in the video section but as said you usually have A0 or A1 broken because that's where the cap goo is getting most of the time:
The breaks usually occur where the traces enter the solder pads of the ASC or for A0 where the trace enters the solder pad of UD8.
Because you also have issues with your audio I would suspect the breaks to be where I put the little blue marker.
The big blue circle is where the cap goo usually spreads.
I couldn’t find the II switch in the other thread either.
Right now, I’m almost done with the first iteration, @jessenator do you have a picture of the flipside? Just want to make sure I get the reset/interrupt pictogram/legends correctly aligned.
Here’s the work in progress. (I’ll post a .STL as soon as have everything in place).
There are no disadvantages to implementing >4GB images. This is something 040 and PPC owners have been interested in, in addition to the CD audio and changer functions. For example, you could use fdisk to divide a 32GB card into a 20GB FAT32 partition and a 12GB hard drive image. A drive entry in the config file could point to an image file on the FAT32 partition or to the entire 12GB partition.
That is the general idea, but not a direct quote.
While my primary focus is Macs, there's no reason MacSD cannot work on other SCSI platforms. It is being tested on Amiga, SGI, Sun, RS/6000, etc by others. I will describe it as unsuitable for applications supporting human life (as are its individual components and the SD card). Nobody should be using this in a traffic light. Everything else is fair game.
I'm not concerned whether features I add to MacSD already exist in other products. Everyone benefits from the new options and capabilities.
The ini file configuration in no way limits the MacSD's capabilities. Config files run entire operating systems. In addition to convenience, it solves the problems of:
Keeping firmware and configuration utilities updated in tandem
Migrating configuration on firmware updates
On-chip configurations valid only for a particular card
If you don't want to bother with >4GB images and fdisk; if all you need is a single HDD, your config file is two lines long. Easy is not the opposite of powerful.