General Category => LisaList2 => Topic started by: sigma7 on May 10, 2022, 05:52:36 pm

Title: Troubleshooting Bus Errors
Post by: sigma7 on May 10, 2022, 05:52:36 pm
Here is a first go at troubleshooting bus errors... if it turns into something useful hopefully it will end up in the FAQ. -- corrections & suggestions requested!

Debugging Bus Errors caused by hardware issues v.2022-05-14-A

A bus error is generated if a timeout occurs when the CPU attempts to read or write to an address (memory or I/O).

There are circumstances when bus errors are expected, such as when checking to see if an expansion card is present in a slot. In these cases the software intercepts the bus error and carries on.

In the case where a bus error is not expected, it indicates a hardware or software fault, and so typically an error message is shown.

The bus timeout signal is generated by the 556 timer beside the CPU. It is re-started at the beginning of each bus cycle, so the timeout only occurs when a bus cycle does not terminate properly.

Bus cycles are terminated by an acknowledgement signal, which signifies to the CPU that the requested data is now available (for a read), or has been accepted by the hardware (for a write).

There are two acknowledgement signals, VPA and DTACK. VPA is used to provide compatibility with older 6800 peripheral timing and to do so, the CPU slows down the process of completing the bus cycle when it receives the VPA signal. DTACK is the 68000 signal that indicates the bus cycle can terminate more or less immediately.

In the Lisa hardware, VPA and DTACK are generated by different circuits depending on what hardware is accessed. ie. the I/O board generates DTACK or VPA for accesses to hardware on the I/O board, the CPU board generates DTACK or VMA for accesses to the various hardware control registers, MMU, and ROM on the CPU board as well as DTACK for slot RAM, and individual expansion slot cards generate their own DTACK or VPA.

So when a bus error occurs, the fault may be on any of these boards and so you may be in for some interesting troubleshooting.

Swapping boards with a working machine is helpful to isolate the problem board, but even having isolated a particular board, there is usually more than one source of VPA/DTACK to check.

If one knows the address that generated the bus error, that usually will narrow down the circuit substantially. While the Lisa is still operating from the CPU ROM, it will try to help provide the information needed...

Reviewing p25 of the Lisa Boot ROM Manual v1.3 Feb84, it indicates that when an exception (such as a bus error) occurs, the address is stored in the long word at $282. In the event this is not populated with the problem address that caused the bus error, one will need to use another technique to isolate the problem (see reply below).

The default memory map setup programmed into the MMU by the ROM looks like this:

Lisa addresses have 3 bytes as the 68000 is limited to 16MB of address space (68020 etc. have more). The high byte of a long word address is ignored by hardware and almost always ignored by software -- various components of Mac software use the high byte for flags eg. to indicate a locked handle. When entering an address into service mode it will pad the address with leading zeros, but if you are putting addresses into memory, likely you will need to provide the leading byte, eg. 00xx yyzz.

Once the problem board is isolated, the missing DTACK/VPA signal path can be investigated.

For example, by inspecting "Schematic System I/O Lisa" "050-4008-" page 2 of 5, we see that VPA can be generated by U10D-3 (when one of the VIAs is addressed) or U5E-8 (when the SCC is addressed).

In addition, page 3 shows that DTACK is generated by U5E-6 when the 9512 is addressed, and controlled by the 9512 "Pause" signal that will delay the termination of the bus cycle until it has finished its operation.

Once the problem device is determined, one can examine activity on the signal path at the time of the bus error to isolate where the problem lies at the chip level.

Additional addressing details that may be useful to know (but probably unnecessary) ...

Later versions of the Lisa Hardware Reference Manual have an errata page that indicates the I/O mapping in the manual proper is incorrect. However that errata assumes the I/O mapping will persist as initially set up by the ROM, which is not necessarily true. The MMU can be used to map I/O to many different places/pages in the address range of the 68000, and even to more than one page. The manual proper is written such that it doesn't assume where the I/O will be mapped and so provides offsets from the beginning of that page rather than absolute addresses. In most cases one can use the addresses provided in the errata, but there may be an operating environment where they are not correct (likely suspects are limited to LOS and the Workshop).

One simple example is the SCSI expansion card. On the Mac Plus, the SCSI port base address is $580000. For compatibility with MacPlus software, MacWorks +/II will map an alias of the expansion card slot that contains the SCSI card such that the 5380 SCSI chip also appears at $580000 (as well as in the $FCxxxx space).

The CPU and I/O board hardware addresses are not fully decoded. This means that the devices will also appear at other locations in the address space.

For example, by inspecting "Schematic System I/O Lisa" "050-4008-" page 2 of 5 we see that U7C, the Keyboard & Mouse 6522 VIA has chip select pin 23 driven by a circuit that decodes A10, A11, and A12 (as well as INTIO generate by the CPU board and asserted for eg. FCC000 - FCDFFF). Also note that A1-A4 go to U7C to select 1 of 16 addresses in the chip. As A5-A9 are not decoded, the VIA addresses will be aliased at any variation of A5-A9. eg. as well as the typical base address of FCDD81, U7C will also be found at FCDE81, FCDDC1, etc.

edit 1: 2022-05-10-A corrected VMA to VPA
edit 2: 2022-05-10-B fixed unmapped area below ROM, reference to 4MB modification
edit 3: 2022-05-11-A added SCSI port example
edit 4: 2022-05-11-B changed designation of I/O schematic as variant available on bitsavers differs (
edit 5: 2022-05-14-A Corrected that DTACK for RAM is generated by the CPU board, not on the memory board
Title: Re: Debugging Bus Errors
Post by: rayarachelian on May 10, 2022, 08:19:29 pm
Many thanks for this excellent write up!
Title: Re: Troubleshooting Bus Errors
Post by: sigma7 on May 10, 2022, 11:14:51 pm
"What if I don't know the address that is causing the bus error?"

More Difficult Bus Errors v.2022-05-15-A

There may be circumstances when you don't know the address causing the bus error. For example, you may not be able to get into service mode because the hardware isn't working well enough to get there.

In this case one has to troubleshoot solely by examining what the hardware is doing.

On startup, the ROM does not expect to encounter any Bus Errors in a working system until the point where expansion card slots are tested and found empty. Since this is the last step of the self-test, a bus error generated during the self test due to a problem with the Lisa hardware is likely to be the first bus error that occurs.


This is straightforward to troubleshoot with a logic analyzer, so assuming that one is not available...

If an oscilloscope is available, one can trigger off the Bus Timeout signal on the CPU board (eg. U15B pin 9). Then use the other channel to probe signals of interest just at/before the time the fatal bus error occurs after reset.

If an oscilloscope or logic analyzer is not available, you are likely in advanced difficulty mode and will need to be creative. Even with an oscilloscope the following may be helpful for efficient troubleshooting...

Disable the bus timeout delay
Extend the bus timeout delay
Eliminating the bus error caused by an empty expansion slot

Double Bus Faults

There is a more unusual hardware error called a "Double Bus Fault"; this is what happens when another bus error occurs while trying to handle a bus error exception (ie. what would be an endless loop of bus error exceptions). A Double Bus Fault causes the CPU to halt and stop attempting to process instructions. A Double Bus Fault caused by hardware is probably due to some problem with the core bus cycle logic on the CPU board, in which case it is likely the Lisa will not run at all. The procedure above to troubleshoot Bus Errors is probably useful in this case too.

A Double Bus Fault can also be caused by software. eg. if the bus error vector (@ $000008) points to unmapped space, or address $8 is unmapped, presumably due to an error in MMU programming, then a bus error will result in a Double Bus Fault.

edit 1: 2022-05-14-A Substantially rewritten due to erroneous thought that bus errors may occur before empty slots are encountered
edit 2: 2022-05-15-A Updated after testing ghost expansion card modification, formatting adjusted in an attempt to improve readability
Title: Re: Troubleshooting Bus Errors
Post by: sigma7 on May 14, 2022, 05:21:38 pm
Major rewrite

Note posting above: "Substantially rewritten due to erroneous thought that bus errors may occur before empty slots are encountered"

The technique described to hold a problematic bus cycle indefinitely for hardware inspection may simplify troubleshooting substantially!

It seems that the CPU board generates DTACK for all accesses that the MMU has been programmed to be RAM.

To determine the amount of RAM installed, the MMU is initially programmed to address 2MB of memory (4 MB in 3A 'square pixel' or correspondingly modified ROMs), then the ROM code tests areas of that RAM to see if it is indeed unique memory or just empty space. Once the size and physical address of RAM blocks is determined, the MMU is re-programmed to make the RAM contiguous starting at logical address $0.