68030 /BERR

[mmx01]

Hi,

Would anyone know most common reason for /BERR to be asserted for LCIII 68030 CPU? Obviously no boot, no sound, no picture but there's life on the bus. /HALT /RESET are not asserted, I see on oscilloscope activity on ROM data pins as well as CPU/DRAM R/W pin. Without logic analyser no chance to check any timing.

I see also /ECS & /AS are alive flipping states but /BR & /BG are dead. Honestly looks similar to 68000 machines with dead ram (like Atari ST). I don't have ram to swap it out but is this common fault for these machines?

Not sure how to check if (which) external device CPU is calling for that would fail to respond causing a timeout. /STERM & /DSACK0 change states while /DSACK1 stays high all the time. Which signal to check next to see what's happening? DSACK1 staying high looks like [SIZE=23.68px]Long-Word Operand [/SIZE][SIZE=23.68px]Write[/SIZE] on 8 bit port and /DBEN is changing states too. /RMC stays high so that is not Read Modify Write cycle.

 

[Bolle]

/BR & /BG are dead

That‘s normal. There is no hardware on the locigboard itself that will ever request the bus.

Only third party hardware might do this.

Is /BERR constantly asserted or is it flipping around?

There are a lot of 8-bit peripheral devices on the logicboard, so /DSACK1 staying high shouldn’t be too uncommon.

 

[mmx01]

No, /BERR is flipping too. Mind I only have two channel scope but it almost looks like it operates in 8 bit mode read (/DSACK1 high all the time) which points me to either faulty ROM or RAM - but obviously not sure if I understand init sequence well.

What I understood is that upon reset and before switching to working in 32 bit mode it pulls data from ROM in 8 bit mode and maps RAM into same address space. ROM contents is copied to RAM and ROM chips are disconnected by GAL/GLUE so user can update vector tables etc. in R/W memory which is at the same address ROM used to be.

ROMs are probably masked, tried to read them with TL866 to no success. I see activity on ROMs' pins so chips are not dead but cannot check content either.  Next I plan on replacing LS245 & RAM but that's a lucky guess.

Regards,

Mariusz

 

[techknight]

Bus Error is commonly used by the MMU/Virtual Memory so it may not be as significant as it seems. 

Depends on what model machine, and if it has an external MMU capability or not. 

 

[mmx01]

Machine is macintosh LC III and MMU is mentioned .

[SIZE=16.6667px]The Macintosh LC III [/SIZE][SIZE=16.6667px]hardware, however, always operates in 32-bit mode. The memory management unit [/SIZE][SIZE=16.6667px](MMU[/SIZE]) inside the 68030 works with Sonora’s memory controller to map 24-bit addresses [SIZE=16.6667px]to their 32-bit equivalent.[/SIZE]

What is kind of getting my attention is no flipping of DSACK1 to low, it stays high all the time. It should switch port to 32 bit mode if I read manual correctly.

I am fighting also with a dead CRT M1212 but was counting on at least chime of death. It started completely dead but with fixed reset circuit, PRAM battery etc. it is doing something... just nothing audible/visible. When I connect floppy drive it does not do anything with it. Hard drive spins up and then stops few seconds later. Bare board without anything attached or with devices attached behaves identically.

 

[mmx01]

n-th day of battle. still loosing though.

Replaced all F245 with new LS245 bus transceivers, replaced all ram chips. Switched ROM chips to good known ones, measured activity on CE and OE pins, still no progress, no dong, no image. There is activity on data & address lines but a pain without LA and just 2 channel scope. It would help very much to understand what is it waiting for... graphics chip, scsi chip in what sequence they are queried.

FC0 0 1

FC1 1 0

FC2 0 0

It is switching between [SIZE=15.2px]User [/SIZE][SIZE=15.2px]Data [/SIZE][SIZE=15.2px]Spac[/SIZE]e  &  [SIZE=15.2px]User [/SIZE][SIZE=15.2px]Program [/SIZE][SIZE=15.2px]Space [/SIZE]

IPL0 0 1

IPL1 1 1

IPL2 1 1

We are either at no interrupt or interrupt 1

SIZ0 1 0 0 0

SIZ1 0 1 1 1

DSACK0 flipping DSACK1 high all the time

STATUS is hard to track with ref to CLK but also no magic there usually ready for next instruction.

 

[mmx01]

With ROM removed there's no life on the bus at all. De-soldered ram chips again. With or without ram chips behavior does not change. Soldered in another set of 8 chips with 70ns better than 80ns originals. I also found disassembly of mac plus rom. Not the same machine as LCIII but I would expect logic in what ROMs do should be similar.

https://www.bigmessowires.com/rom-adapter/plus-rom-listing.asm

My attention goes back to RAM/Timing/bus as chime is before any query for a boot device. Check for test software, run test, test ram, initialize ram contents. In the meantime I checked all address & data lines through PDS socket. RAS/CAS is pulsing with the right shift of CAS before RAS, OE is low all the time W is pulsing. Nothing seems missing/shorted or of unusual level.

Not sure how to verify further if ram is good or not without building a board to store/read something from it.

 

[paws]

Is replacing F245s with LS245s a good idea? I thought F parts were only used where the lower propagation delay was actually needed. I've also heard that sometimes mixing F and HC/LS.parts is done specifically to make one signal travel faster than another, say an enable signal that needs to be asserted before some data is set up, or similar.

 

[mmx01]

Indeed timing could be an issue indeed. Full of hope I switched LS245 with F245D to discover nothing improved

Managed to get my hands on a working board and do some measurements. BERR behaviour is different, working board does not have continuous BERR assertion. So there is some kind of an issue here related to bus/BERR. De-soldered SCSI chip, no change. I also rechecked FC0-2 and was wrong before. It starts with 1 1 1 which is CPU address space and switch to supervisor program space flipping with supervisor data space continuously.

All signals go via Sonora which is an ASIC beauty of  208 pins handling memmory mappings, floppy drive whatnot. This limits my further troubleshooting options as to what this monster is doing/expecting to signal MCU. Having lifted BERR leg of Sonora there is no BERR on MCU pin which suggests this is external signal not triggered by MCU itself. But there is also no activity on the bus with the leg lifted.

Looks like there is no a real graphic chip on board, it is more DAC. If Sonora writes to video memory directly and DAC only reads/display perhaps there is video memory test in ROM? I did not replace video memory chips yet as have no parts. Curious what you think, could that be an option?

If Sonora would be dead ROM activity would not be initiated, with ROM chips removed there's no activity on the bus. So it initiates and start executing ROM program also suggesting MCU is working and ends in some kind of loop before chime it seems. Not sure if replacing MCU makes any sense as it would be strange fault if MCU related.

 

[techknight]

Well the constant pegging BERR means that the CPU is trying to access a memory mapped device that isnt present, or isnt being selected, as the DTACK isnt coming back. 

Lets start stupid simple. inspect thoroughly all the areas where Caps were and make sure there isnt a trace or via break somewhere to a chip that would cause the mac to constantly freak out with a bus error. 

 

[mmx01]

I equipped myself with 102 channel LA from 00s so... now just to learn the hw, sw, and wire it up all together. This one is a funny ride!

All caps were replaced at start of this fun, clock chip measured etc.

Visual inspection under microscope did not show any damage. Perhaps I have to do this hard way with probing between MCU & Sonora & Ram & Rom alltogether. 64x3 + other singals IPLx3 FCx3 DSACKx2 etc. Good for winter Does this board packs more than just 2 layers?

I replaced all F245 & ALS241 chips with the ones from the working board - no change - good board works well with parts soldered in from the bad one - bad one does not work

I replaced all video chips with the ones from a working board - no change

Graphic DAC is just a DAC that copies from VRAM, good board chimes without it

Good board chimes without VRAM although chime is dissorted

LCIII against what is said will display image without PRAM battery, will also chime good without one

For this EGRET chip I am scared to touch it... so don't know. On the bad board it releases reset and pokes with IPL states so I will assume somehow okay...

 

[techknight]

These are minimum 4 layers, probably 6 layers. 

 

[Bolle]

Most if not all Apple logicboards of that era are at least 6 layers.

SE was 4 layers, not sure about the Mac II but everything afterwards was min. 6 layers.

 

[mmx01]

btw. just replaced the MCU hoping it would be semi-dead - no change. Working out QFP without stencil is refreshing

25% of LA wiring. bad thing without socketed option is that I am unable to flip the board.

 

[mmx01]

Progress has been made! It now chimes, unfortunately just to a second later play chime of death but there is no video. 

 

[mmx01]

Reading this other ROM boot process reaches

P_mBootBeep


Plays boot sound, pokes VBLANK interrupt as CRT seems to be wanting to turn on and then it should initialize ram contents?

Without ram chips on board it plays boot sound but no video and no chime of death. With ram soldered in, it plays boot sound and then chime of death. I wonder aren't we back to ram?

 

[bigD]

I don’t have the technical knowledge to be any help, but I thought I’d mention that it’s been really interesting reading your posts as you work through this.

Good stuff! 

 

[mmx01]

Quite a pickle... these retro boards usually take me max few days but this one is stubborn.

If I had more parts progress would be much faster but I am reluctant in exposing the only other working board to damage so not touching proprietary chips I cannot source. These 20yrs old chips probably don't take re-flowing well, seen moist accumulating and then when heated doing damage and not all look fresh!

I finished measuring abt. 90% of everything for 32bit data, 32bit addresses and other vital signals to ROM, RAM and VRAM. Some go directly from CPU to transceivers while others go from CPU to Sonora and then to transceivers. You measure all that multiple times on both ends of transceivers and also bomarc schematic of LCIII seems to have an error for one of them being reversed upside down - easy to spot though.

 

[mmx01]

Measured everything 100% and no issues found.

Looks like VSYNC/VBLANK is generated by Sonora chip while RGB comes from RAMDAC. Since the machine chimes (reads rom/executes code) should be no reason for no video and all traces/discrete parts are good there. It should display error hex code and sad mac. Behavior does not change with RAMDAC removed hence I assume it is dead. With VRAM removed chime is distorted like on the working board. As for apple RAMDAC - CLUT/DAC they call it part impossible to find without another board... so I guess I will have a pause for a while looking for the parts.

Unless I am missing something big like SCSI chip initialization before video output activation (doubt it since it is just a dumb RAMDAC that converts on frame refresh) don't see anything else at play causing no video.

Ordered din plug for PDS and will play with opcodes decoding in the mean time to kill the time and learn more abt. 68030. With the connector I will be able to switch LA from one board to another and compare listings without a full day operation prone to mistakes.