Jump to content

Recommended Posts



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 Long-Word Operand Write on 8 bit port and /DBEN is changing states too. /RMC stays high so that is not Read Modify Write cycle.


Edited by mmx01
Link to post
Share on other sites
On 10/9/2020 at 10:41 AM, mmx01 said:

/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.

Link to post
Share on other sites

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.






Link to post
Share on other sites

Machine is macintosh LC III and MMU is mentioned .


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


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.

Link to post
Share on other sites

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 User Data Space  &  User Program Space


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.


Link to post
Share on other sites

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.




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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.




Link to post
Share on other sites

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. 

Edited by techknight
Link to post
Share on other sites

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...



Link to post
Share on other sites

Reading this other ROM boot process reaches


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?


Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

is it possible the Sonora is bad? woudl take a donor board to figure out though. 


Is it possible to invoke the 68K trace and see where its hanging up? which opcodes, etc. 


Im going to go with my gut and say its some sort of initialization fault. 

Edited by techknight
Link to post
Share on other sites
  • 3 weeks later...

Slow progress due parts and covid shipping delays... got myself two boards in the mean time so have now access to some parts. This project is now driving few other projects and got out of proportions ;)


> Still waiting for more LA probes to be able to handle 64+ channels and do address/data decoding

> Got inverse assembler software for TLA714 and started building adapter it requires to run TMS203

> Got addons for my hot air station to heat only IC pins, not etire chips to avoid heat damage. Gives more confidence with touching these oldies - so far successfully

> As expected RAMDAC is just a stupid chip, with it removed good board chimes as normal. Chip from bad board produces image in the working one

> I am about to do same trick to SCSI controller


Next is to get TMS205 working and decode what the board is doing. With CPU, buffers and RAM + VRAM replaced not much options I see but still curious to see if it fails at RAM test as part of rom boot or elswhere. Provided it fails with RAM this would mean indeed Sonora doing mem mgmt. is bad.

Edited by mmx01
Link to post
Share on other sites

Interesting, with SCSI chip removed (U8) good board chimes good as well. So neither RAMDAC nor SCSI are really queried for chime of death. Removal of on board VRAM or RAM results in chime being distorted.


Soldered both RAMDAC and SCSI from bad board into a good one and both are okay.


In the mean time fixed old 10Base2 Ethernet card from Asante which had -9v inverter faulty resulting in loopback transmission test failure and no connectivity. Newer ones have DC-109 which is obvious but of course mine was custom padded with no markings. Not repairable but with minor power supply wiring tweak a modern one with full isolation works like a charm: RO1209S



Link to post
Share on other sites

Finally some progress! Lifted, cleaned up and re-soldered QFP 208 fine pitch Sonora chip. Not funny and impossible without a microscope as shorts are tiny even when soldering with soldering paste.


Chime of death is gone and I was able to boot MacOS, keyboard and mouse are fully functional. Another wire was needed for SCSI controller next to the corroded battery holder.


Still some work needed as colours are distorted but otherwise the board is pretty functional. Seems like on an LCIII board chime of death is nothing related to RAMDAC, SCSI or PRAM. When chime is distorted there are issues on the bus related to VRAM/RAM contacts/presence. Low level ROM boot test appears to be limited to BUS/RAM/MMU as lack of other ICs don't change behavior.




Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...