Quantel Paintbox & 68000 CPU Bus Errors

[CJay]

although i don't have replacements for the nvrams yet i did try removing them completely and it made no difference to the bus error.

That could either indicate that the problem is indeed with the nvram or that it occures earlier in the boot routine.

I think the NVRAM is a red herring, I'd be of the opinion that the other unit the friend has is also of similar vintage and that the NVRAM batteries would be similarly flat.

With some kind of idea where they're mapped in memory it should be possible to read them using the monitor but if not you can verify they work by reading them in an EPROM programmer that supports them (I have one if you need one)

You may be able to replace them with a plain old 6116 or similar as a temporary measure

[bktemp]

Correct me if I'm wrong, but from my understanding BERR is generated by the counter when too many wait states are inserted (DTACK not going inactiv).
For simple bus devices like SRAMs or the NVRAMs no or only a fixed number of wait states are necessary. Accessing shared memories or DRAM where a refresh cycle could be active, additional wait states are inserted until the memory is ready.
Therfore the DTACK signal is generated somewhere depending on the bus address, either by using a simple delay counter or by the accessed device itself. For simple memories the bus shouldn't even notice if the memory chips are removed from the board. I doubt the NVRAMs cause a bus error unless their content somehow affects the bus address being accessed.
There must be logic somewhere decoding the bus address and either generating the DTACK signal using a counter or selecting an external wait signal from the accessed device. Most likely one of the programable logic devices is used as a bus address decoder and for DTACK generation.

[dexters_lab]

yea, it is not the NVRAMs causing the issue, i only tried because it very easy to do. I can also read and write to the NVRAM in the monitor, it works but obviously loses it's memory after a few seconds without power.

The BERR happens very early into the boot into the ROM code where it initialises various hardware peripherals and before it checks the NVRAM to be valid.

I mentioned before the fault that stops this booting properly is a write access to 0xF96000 which is probably some of the quantel custom devices as we have mapped just about everything else.

i've attached my memory map, which is work-in-progress BTW!

You'll see there are a few regions of space that cause the BERR and why i am suspicious of A16-A19.

It's just a bit of a daunting task for a noob like me to try and do this, but i like a challenge!

[bktemp]

You'll see there are a few regions of space that cause the BERR and why i am suspicious of A16-A19.

Why do you think A19-A16 are faulty? Some regions may be unused, therefore not decoded and not acknowledged when accessed.
Do you know if the address bus decoding for all the peripherals is done on the CPU board or does each card has its own bus decoder looking at a matching address?
For decoding the region where the bus error occurs, at least A23-A16 are necessary. I am no expert in debugging computer systems, but I would start at looking for parts where A23-A16 are connected to and see if those parts generate a chip select signal when the region is being accessed (most likely the PALs).

Let's assume the region where the bus error is generated is connected to one of the quantel ascis. That means either the chip itself does not acknowlege the bus cycle or the acknowlege signal does not reach the cpu. Possible faults could be the address bus decoder/DTACK signal mux not working correctly.
But it could also be a problem with the chip itself: Maybe the accessed asic is not working correctly, because of a missing clock or a stuck reset line?
You have to identify the chip mapped to the region and start looking at its signals to see if the problem is the chip itself (or some surrounding circuit) or if there are some problems with the address bus.
Without having a schematic or block diagram it is probably hard work to trace all the address lines to each card.

[CJay]

yea, it is not the NVRAMs causing the issue, i only tried because it very easy to do. I can also read and write to the NVRAM in the monitor, it works but obviously loses it's memory after a few seconds without power.

The BERR happens very early into the boot into the ROM code where it initialises various hardware peripherals and before it checks the NVRAM to be valid.

I mentioned before the fault that stops this booting properly is a write access to 0xF96000 which is probably some of the quantel custom devices as we have mapped just about everything else.

i've attached my memory map, which is work-in-progress BTW!

You'll see there are a few regions of space that cause the BERR and why i am suspicious of A16-A19.

It's just a bit of a daunting task for a noob like me to try and do this, but i like a challenge!

I  like a challenge too, plus, 680x0, takes me back to the days when I repaired Macs and Amigas for a living.

Given the system places the peripherals at 'page' boundaries  (I may be using the term loosely) of 0xyyy000 etc. I think it confirms my theory that it's a peripheral not responding or somehow being verified as present (unable to write or read from etc.)

So, you've mapped all the identifiable devices, can you trace control lines from the decode logic to the custom devices in the same way you should be able to for the 'known' devices?

Are the customs duplicated or is there only one of each in the system?

[dexters_lab]

Why do you think A19-A16 are faulty? Some regions may be unused, therefore not decoded and not acknowledged when accessed.

i can't think of a reason why regions 080000 to 0FFFFF and EE0000 to EFFFFF should not be accessible, the physical ram is there for it

Do you know if the address bus decoding for all the peripherals is done on the CPU board or does each card has its own bus decoder looking at a matching address?.

i don't know

Let's assume the region where the bus error is generated is connected to one of the quantel ascis. That means either the chip itself does not acknowlege the bus cycle or the acknowlege signal does not reach the cpu. Possible faults could be the address bus decoder/DTACK signal mux not working correctly.
But it could also be a problem with the chip itself: Maybe the accessed asic is not working correctly, because of a missing clock or a stuck reset line?
You have to identify the chip mapped to the region and start looking at its signals to see if the problem is the chip itself (or some surrounding circuit) or if there are some problems with the address bus.

all very valid points!

Without having a schematic or block diagram it is probably hard work to trace all the address lines to each card.

indeed, i have actually slowed my efforts in the vain hope that some documentation might come to light

[dexters_lab]

I  like a challenge too, plus, 680x0, takes me back to the days when I repaired Macs and Amigas for a living.

Given the system places the peripherals at 'page' boundaries  (I may be using the term loosely) of 0xyyy000 etc. I think it confirms my theory that it's a peripheral not responding or somehow being verified as present (unable to write or read from etc.)

So, you've mapped all the identifiable devices, can you trace control lines from the decode logic to the custom devices in the same way you should be able to for the 'known' devices?

Are the customs duplicated or is there only one of each in the system?

the task of finding addresses for the peripherals so far was done through the disassembly of the ROM code, thanks to a nice guy called Nicolas in Australia who offered to help.

We have a long list of unknown 0xFxxxxx addresses that are read/written to.

on the main board there are a couple of types of PAL and some Atmel PLDs, they all appear to have individual identifiers so i'm guessing they are all unique

[mikeselectricstuff]

Could it be that it's trying to acess optional peripherals that the corrrupt NVRAM is saying should be present but actually aren't ?
 

[dexters_lab]

Could it be that it's trying to acess optional peripherals that the corrrupt NVRAM is saying should be present but actually aren't ?

hi Mike

no, NVRAM isn't read until after this access

[grumpydoc]

Could it be that it's trying to acess optional peripherals that the corrrupt NVRAM is saying should be present but actually aren't ?

hi Mike

no, NVRAM isn't read until after this access

One would hope for a better error message in that case than "bus error" 

[mikeselectricstuff]

Could it be that it's trying to acess optional peripherals that the corrrupt NVRAM is saying should be present but actually aren't ?

hi Mike

no, NVRAM isn't read until after this access

True, but this is the late 80's, and a closed system that was doubtless only ever configured in the factory and serviced by factory techs...
One would hope for a better error message in that case than "bus error" 

[TerraHertz]

I don't suppose you have access to a device programmer that does the PALs and PLDs used?
If you are lucky their configuration may be readable. In which case if you can talk your contact with the working machine into letting you read the ones in his machine, you can verify if yours are all working. Another way would be to put your suspect PALs into his working machine (if he's incredibly trusting and the machines are identical.) But I doubt he'd go for that.
If you are unlucky, they won't be readable because readback not supported or security bits set.

Verifying the PALs would be good, because almost certainly the high address decoding and bus state logic will be done in those PALs.

One caution, that I'm sure you'd be aware of without my mentioning, but I will anyway. To read the programmable chip types you'll need to remove (or partially peel) the Quantel part number labels. Don't get them mixed up, as many can be the same chip type. But of course once programmed they are different. Best way is to write the board location on the bottom of each chip as you remove it, and keep a list of board locations, chip types and Quantel part numbers on the labels.

From your description of the original 'cause' ("just opened the case to change a DIP switch, and it stopped working, honest") it could be that he static-zapped it with his gerfingerpoken. In which case it could be anything (or multiple things) that's dead.

[dexters_lab]

video update to this from a couple of weeks ago

it's not looking likely i'm going to get the service manual after several possible leads on getting it, looks like the next step might be to start tracing everything out by hand to find where the faulting address physically decodes to. Not something i really wanted to do   

[vaualbus]

So have you fine any progressi so far?

[dexters_lab]

the saga continues slowly... still no sign of service manuals. I keep still keep getting hints of being in contact with ex Quantel employees but nothing has come of that yet.

In a vain attempt to do something i'm swapping out some of the buffers/transceiver ICs for the CPU bus.

[SeanB]

Tip for those folded pin DIP devices is to simply cut all the legs flush with the board on the IC side, and simply unsolder the stub of folded leg. That saves the board a heat cycle, and then you simply solder in a turned pin socket ( or buy a whole lot of 0.1 pitch SIL turned socket strip and make your own). If you want to reuse the IC simply solder it to a socket ( place it into another so the melting and softening does not deform it too much) and plug into the new socket on the board.

Been there, done that, and as the TTL IC generally is a lot cheaper than the board, throwing them away is not too much of an issue.