Using Apple's hidden "Test Mode" to fix a dead SE/30
ฝัง
- เผยแพร่เมื่อ 4 ก.พ. 2025
- In my last SE/30 repair video, I was totally stuck with what to do next because the machine crashed as soon as I turned it on. That led me on a path to discover the internal ROM based Macintosh diagnostics which we can leverage to figure out what exactly is wrong with these broken SE/30 motherboards!
Part 0: • 0089 Troubleshooting M...
Part 1: • I severely damaged my ...
Part 2: This part!
Part 3: Coming soon
-- Links
Using internal Mac diagnostic modes:
docs.google.co...
Original document on the Diagnostic protocol:
web.archive.or...
Replicated Schematics of the SE/30:
github.com/mis...
Mac SE and SE/30 PicoATX PSU adapter:
github.com/dek...
www.tindie.com...
RGB2HDMI:
github.com/Ian...
TechStep Photos:
appletothecore...
TechStep Replica:
ko-fi.com/s/aa...
Adrian's Digital Basement Merch store:
my-store-c82bd...
Adrian's Digital Basement ][ (Second Channel)
/ @adriansdigitalbasement2
Support the channel on Patreon:
/ adriansdigitalbasement
My GitHub repository:
github.com/mis...
-- Tools
Deoxit D5:
amzn.to/2VvOKy1
store.caig.com/...
O-Ring Pick Set: (I use these to lift chips off boards)
amzn.to/3a9x54J
Elenco Electronics LP-560 Logic Probe:
amzn.to/2VrT5lW
Hakko FR301 Desoldering Iron:
amzn.to/2ye6xC0
Rigol DS1054Z Four Channel Oscilloscope:
www.rigolna.co...
Head Worn Magnifying Goggles / Dual Lens Flip-In Head Magnifier:
amzn.to/3adRbuy
TL866II Plus Chip Tester and EPROM Programmer: (The MiniPro)
amzn.to/2wG4tlP
www.aliexpress...
TS100 Soldering Iron:
amzn.to/2K36dJ5
www.ebay.com/i...
EEVBlog 121GW Multimeter:
www.eevblog.co...
DSLogic Basic Logic Analyzer:
amzn.to/2RDSDQw
www.ebay.com/i...
Magnetic Screw Holder:
amzn.to/3b8LOhG
www.harborfrei...
Universal ZIP sockets: (clones, used on my ZIF-64 test machine)
www.ebay.com/i...
RetroTink 2X Upconverter: (to hook up something like a C64 to HDMI)
www.retrotink.com/
Plato (Clone) Side Cutters: (Order Five)
www.ebay.com/i...
Heat Sinks:
www.aliexpress...
Little squeezy bottles: (available elsewhere too)
amzn.to/3b8LOOI
--- Instructional videos
My video on chip removal without damage:
• How to remove chips wi...
--- Music
Intro music and other tracks by:
Nathan Divino
@itsnathandivino
This is by far one of your most revolutionary videos for Mac II/SE diagnostics thus far. Kudos to you Adrian for this investigation!
Those "TechStep Replica Guys" will be pissed... but, they're out of stock anyway 😎
@@mwk1 lmao
Hello Adrian. It gave me much pleasure watching this SE/30 saga. My conclusion is that you took the right step, making this your full time job. You do it with an abundant amount of pleasure. You face tells it all. Not even mentioning your smart way of working. It freaking works.
love these types of moments when you just happen to stumble across an old txt file that unlocks forgotten knowledge
Given Apple's tendencies, this is more like forbidden knowledge.
Sure beats stumbling across an old txt file that unlocks an infohazard
@@HaveYouTriedGuillotineswell it is the forbidden fruit: the poor soul who took that bite did not live to regret it
used to use a techstep back in the days of being a certified mac tech, however, our board-level repair techs could spot problems faster than the tool could expose them so rarely used the thing. You helped bring back a lot of fond memories of those years. it was the dawn of the PPC and the clone wars; we we had a lot of interesting hardware rolling through the shop. i loved apple's toolless industrial design back in those days, everything was so easy to work on.
I'd love to know more about Mac board level repair happening back then. Who was doing this work and where did the spare parts come from? All I ever knew is Apple didn't allow the certified dealers to do this kind of work, or was this a bad assumption?
@@adriansdigitalbasement It's true that Apple discouraged board-level repairs. By then, it was a matter of how quickly you could get each broken Mac back out in the field working. So, if an analog board was the main problem, just swap it out for a new one. Quite a costly fix, at around $260 USD back then, unless covered under AppleCare. Although, there were some repair techs (or shops) who might have quietly stolen the bad parts or "borrowed" them to try and fix the problem.
We can thank individuals like Larry Pina and his book "The Dead Mac Scrolls" for narrowing down specific symptoms and what is likely causing it. Sure, you can do the noble thing of getting your Mac repaired through an Apple Authorized Repair Technician. But for those of us looking to better understand or maybe save some money (especially when the AppleCare is long expired), it seems to be the better route to fix it yourself in some cases.
It's wild to me that people knew it was a serial protocol for 30 years and nobody actually tried to use it (except that one guy who wrote the document) until now.
Raise your hand if you wouldn’t mind a 2+ hour video from Adrian…. ✋
Will for sure make me non-active at work, but I love every second of it
Or a live video, no cut scenes, uncensored.
I'll just watch it in multiple chunks, so bring it on!
✋🏼
I made an audible "Noooo!" sound when Adrian cut the video.
Great find. I absolutely love complicated obscure inbuilt test modes like this. Thanks for exploring this and showing us. I hope the archive comes back up soon.
I"m glad for you and all the Mac mavens out there that you captured this before the Archive went down. They're still down as I type, and this is an excellent example of they kind of stuff we'll be missing without it.
Yeah and I even saved the archived page locally which is something I've learned to do from experience. You just can't always rely on things to be up when you need them.
@@adriansdigitalbasement Archive of an archive, truly the way of the archivist!
Enjoyed watching this video even though I do not own a MAC.
Your detective work and internet researching skills are top notch. This video teaches your viewers how to problem solve.
Two thumbs up!
It's "Mac", short for "Macintosh", and not "MAC" - it's not an acronym :)
This “test mode” is called the Serial Test Manager (STM), and the source code to a later version of it is included in the SuperMario sources (OS/StartMgr/UST*.a). So it should be possible to figure out exactly how all these tests work. 😉
SuperMario sources?
It took me months to get a loan Techstep recreation to try and diagnose my Colour Classic - then comes Adrian Black with some serial commands I can run! Amazing! This will open so many doors. I still haven't diagnosed the CC, I suppose if the TechStep will come up with some unhelpful errors like the Bus Error, I might be able to dig a bit more into it. Thanks for that Sir! I'll mention your work in my video of course.
As a former systems admin/network admin, you made me nostalgic for null modem cables. When I was young using those to transfer files and even play Doom with another person was possible. As an admin, we used Serial all the time to configure devices, and these days you use usb to serial adapters. I still have a frankencable similar to your laplink cable, but it allows me to turn "null modem" off and on, and has both male and female adapters on both sides, so I have a 1-cable solution for any serial ports I come across. I even have an RJ45 adapter for all the networking equipment that uses serial over an RJ45 port.
16:19 glad you got to IA before they went down. I guess this video might not have happened without it, goes to show how critical of a service it is
What is interesting -- is I never take for granted that documentation I use in a repair will be available in the future, so I always save a local copy and file it away. I really hope the Internet Archive comes back online soon.
@@adriansdigitalbasementI really hope IA is put on Hyphanet, or Pirate Bay torrents.
@@adriansdigitalbasement yeah, it's almost crazy to see the internet archive down
that's one place everyone took for granted will always be there
The Archive got hit by a DDOS attack. They're currently offline while they upgrade their security. According to their Twitter channel, they expect this to take a few days to get everything right
@@adriansdigitalbasement I do that too. I also save docs from Retroweb.
This series is excellent and confirms many of the frustrations I have encountered over the years when working on these boards. Thank you Adrian, you are an incredible resource to the community!
So much
Well, who knew!! What an incredible discovery. I can see a future full of Raspberry Pi Mac diagnostic tools. Let the revolution begin!
Sir, never dissapointed by your videos. Good stuff. Appreciate the content. I have a working VIC-20 now (just passed to my youngest son,) because of the motivation your videos gave me.
Absolutely amazing video! I never knew about the built-in diagnostic mode in the Mac SE/30, and your detailed explanation was super engaging. It’s like a treasure trove of knowledge for vintage Mac enthusiasts. Keep up the great work!
Thanks!
You say it would make this video 2 hours long like that's a bad thing, it wouldn't be. Lucky for me I got a bit behind watching your videos so I could straight on to part 3, but now I need to wait for part 4... Excellent videos.
I gotta say Thank You for explaining yourself so well in your videos. I admit I probably only understand half of it as I have 0 engineering or electrical experience but I still learn so much with every one posted
I remember in the last video you mentioned in passing that there was some activity on the serial controller as if you could attach a serial debugger, and I wondered what would happen if you tried-I never imagined it would be this sophisticated though! Amazing work!
Great work Adrian! I had tried similar reverse engineering of the boot diagnostic sequence a couple years ago, but you actually got it done and figured out. Congrats!
What an amazing discovery! How great that you were able to find it and share with the rest of us! Also, that pattern is called Simasimac, and it's frequently associated with screwed up capacitors.
Hey dude! Very nice meeting you at PRGE. You seem like a super cool dude and I love your videos. 🤘
Thanks! Same! I just watched your PRGE wrap up last night. I forgot to really take any pictures of the whole event. (Typical of me, LOL)
Nooooo… “To be continued”. Nice diagnosis, skills, and storytelling Adrian - can’t wait for episode III!
I passed on a complete Apple TechStep at a flea market for $40 about 15 years ago. Still kicking myself to this day for that one.
I sent my Quadra 840AV to Salvation Army about 15 years ago
This is Adrian working at a whole new level! Excellent forensic work!
OMG, Adrian! This is awesome! It's extremely deep troubleshooting. I couldn't stop watching it and learned a lot. I mean, seriously, fantastic! Thank you.
Dear Adrian,
this video was like a good crime thriller!!!
You really are the Sherlock Holmes of computer hardware errors.
Great - and many thanks from Germany!
Georg
Loving this series. Was hoping for a quick bodge wire and a test at the end but I can't wait for the conclusion.
One of the reasons Apple implemented board level swaps was because of guys like me! I was harvesting the original Mac and Mac Plus ROMs for use in the Magic Sac and Spectre cartridges for the Atari ST. It was a really cool device which would give you a faster Mac with a larger screen, all for far less money than a Mac (a LOT less!). Floppy support was a problem at first, but by the time the Spectre GCR cart came out, the ST, which used a slight variation of MS-DOS's FAT format, could now read and write to Apple's GCR format.
A similar device came out for the Amiga, but I feel like the Atari implementation was better, if not cheaper overall.
I had another device that was an internal mod that had an NEC V20 (Intel 8086 and 8080 compatible) so my ST could run Mac, CP/M, MS-DOS, Windows 2 and GeoWorks). I was a pretty happy young man!
Maybe someone could loan Adrian a Spectre GCR so he could explore it in a future episode?
This. THIS is why we watch ADB. Fabulous stuff, Adrian!
Watched from beginning to send, great work sir! I feel you are on the road to a booting system. Looking forward to the next installment
This is some brilliant work Adrian. What a result for the community. Cliffhanger is brutal though, a 2 hour video would definitely be ok by me!
This will definitely save people hundreds of dollars! Great diagnostics and investigation as usual from you.
Hi, Adrian. Thankyou for a nice video. I loved it. Stay safe to you and your loved ones.👍🏻
I loved the troubleshooting process that you used here - the way that you narrowed-down the fault. Very useful information is all this, and although I'm not a Mac guy, the 68000 architecture info is useful for my 'fleet' of Amiga computers.
You might want to turn local echo on in your terminal program. It makes life easier when the remote machine doesn't echo.
This is really a fascinating video and some of your best work yet! Well done and thanks ever so much for sharing with the rest of us.
I have no particular interest or love for old macs, but I do appreciate your walk through of the troubleshooting process. Thanks.
This video not just for the SE/30, but for all those early 90s Mac machines...
Even the freakin printers.
I am pretty amazed those early LaserWriter printers might have this too. The Machine Identifier is there but I'm not sure the diagnostics actually work.
@@adriansdigitalbasement I’m not surprised at all. The early LaserWriters had a 12 MHz 68000 (and the IIf/g were 030s), and if I were a hardware engineer building one, I sure as heck would reuse this external diagnostics protocol given that there was all this hardware support to drive it.
@@adriansdigitalbasement I would love to see a vid experimenting on all the various 90s apple stuff! =P
@@adriansdigitalbasement maybe it would at least let you be able to check the RAM. the LW IInt runs off a 68000 and only has 1 SIMM slot, for 2MB total, while the IIntx runs off a 68020 and has *12* SIMM slots for a whopping 12MB total (like mine).
That's a great find, some enterprising soul could write a piece of software that would communicate directly with the serial port on a PC or a Mac, and be able to decode the error messages and present them in a graphical format, such as showing what bank and specific SIMM module of memory is bad.
I’m fine with 2 hour videos! Looking forward to the next part. Great work!
I have my own opinions of Apple's whole repair/warranty system, but that's neither here nor there. But I always did have a huge fondness for their early and mid-life designs. They were pricey, but once you got into something and started farting around in there, you could see where a lot of the money went. Some of the case designs really were top notch. The old Power Macs I just adored. I had one I kept going long after it was useful just because I found it such a cool thing. I can't tell you how many times I had to repair that motherboard, which I did purely for the fun of it. At one point it did get to be past the point of being repairable, and I set it aside eventually tossing it when I finally sold my other home.
But that's just babbling. It's incredibly cool that you were able to poke around and put this together to get out there. I'm sure it was a fair bit of work trying to figure out all that you did even with the help of that older document. But it's really fantastic that you were able to. I'm sure that's going to make a lot of hobbyist's lives MUCH easier being able to do some of the things that you would otherwise have use that ancient, insanely rare and expensive diag system to do. I always find this stuff incredible interesting, especially in the case of a company like Apple who has always kept their ecosystem played very close to the chest. That's why I really enjoyed the episodes on that dual processor Unix system. That whole thing of just happening to unknowingly acquire one of the company's internal systems that just happened to have one little typo somewhere in the past that accidently preserved so much information about everything on the hard drive was just an awesome thing to watch and learn about, even if the system is largely irrelevant in the grand scheme of things. So digging this diag stuff up is super fascinating to me. Plus, it's a huge win for everyone out there still tinkering with these machines.
Outstanding video and analysis. Kudos, Adrian! What a cliffhanger though! 😆
Really fascinating process. Love it. Looking forward to part 2
I'm fine with two hours. Can't wait for part 3! Awesome video!
Can confirm. The school I was attending in 92-93 had an SE/30 that broke a lot. Like, in the two years I was there and using it, it broke three times and needed a motherboard swap. They asked the dealer what happened to the old boards and the dealer said they had to send them to Apple for credit.
Apple still works the same way. An analogy would be the core charge that car part suppliers use, which gets refunded when you return the old part (core). The biggest difference is that Apple doesn't charge you the full replacement part price, unless you don't send the bad part back in their return window.
Very fun stuff. I love your patience and persistence. Would love to hear how you plan your repairs. I’m a hope for the best expect the worst type.
One of your better Videos I was spel bound to the end.
That was some awesome investigations. Kudos! Really looking forward to then next episode.
biting my nails in anticipation..will be worn down to nubs,
lol
always like your videos
Very impressive diagnostic work! I wish I had your level of knowledge and understanding for how to diagnose stuff, but for C64 and 1541 diagnostics.
Thanks Adrian for putting this video together. I have a Mac classic that starts with zigzag line across screen. Hopefully I can find out more with a working pc running terminal software using null modem cable. Thanks again🥂
.....better than an episode of Columbo!......to be continued....cant wait!
Best ADB in a while, bravo
56:11 Learning that BERR is externally generated is not obvious, but an important thing to know about the 68K hardware.
Normally the 68K waits until it is told that memory is ready. This is done by asserting DTACK after whatever wait state time that the memory needs to respond. Since some memory is slow, and I/O ports even slower, the CPU only has to wait as long as is necessary for a particular address. But if the address is in some wasteland that has nothing there, and the chipset doesn't handle it, the 68K will wait forever for either a DTACK or a BERR. In order for BERR to happen, something external to the CPU either has to know all the invalid memory ranges, or count a bunch of idle clocks with no DTACK.
For instance, on the Sega Genesis, there is no circuitry at all to generate BERR. If you try to access certain invalid memory ranges, the system locks up waiting for DTACK. In the case of the Sega, it could probably be bodged in with one or two chips, but is only necessary for a development system. Real games don't have a problem with this because they've already been debugged to not access invalid addresses.
Conversely, there is a meme of "DTACK grounded", where the DTACK pin is hardwired to always be asserted. This causes the 68K to run as fast as possible. For the original 8MHz 68000, if you use good fast SRAM and fast I/O chips, you can get away with this.
Thanks, great insight there. And the Genesis analogy is perfect -- it's not like it printing a BUS ERROR crash message on a production system would be useful, so I can see why they didn't even bother with it.
The 68k really did bring some cool advancements. I hardly ever work on any system based on them, so I'm just not familiar with the system design but indeed, it is kind of essential to learn about these signals.
Reading Apple docs on the Mac II line (which the SE/30 is) it introduces wait states for particular regions of the memory map, so I guess the GLUE does this by holding back the DTACK and counting cycles. Awesome!
Came here to basically say this. And on 32 bit systems _DTACK got split into _DSACK0 and _DSACK1, to acknowledge the various transfer sizes that could be initiated. RAM itself does not generate any kind of acknowledge signal, so it was up to the DRAM controller to do this. With static RAM and ROM it was pretty much up to the address decoding hardware to guess based on the part timing used. Quick and dirty is to just OR (active-low) your _CS and _AS together and bump it through an inverter a couple times for the propagation delay. SRAM at least will likely have data ready long before the bus cycle is complete. For a bus error on a machine like this, the first place I'd look is the address decoding.
I always take a little bit of you on all my repairs , thanks John (uk)
I would imagine that someone probably could create an inexpensive good enough TechStep using a Raspberry Pi that could send the appropriate commands to the Mac via a touchscreen GUI. It just needs to be good enough for basic troubleshooting like you are doing here. Plus it wouldn't be stuck to only Macs as you could have Boot select as part of turning the device on. Just a thought for more talented people.
Eric (of the Bluescsi project) already hit me up regarding about this. :-) There is still a ton of work to get done before this could be automated since it appears what you can do varies from Mac to Mac, but once all of this is understood and documented then something open source could easily be developed. For now, I'm just happy to know how to do this myself so I won't be sitting around guessing. Guessing is no way to fix something! :-)
@adriansdigitalbasement documenting the input strings like you are seems to be the best first step, and then someone can create scripts for each task.
Yup, it's super simple using Python to access the serial port of a Pi, and from there to send the proper commands over to the Mac, and then read and translate the various responses into something more human readable. You could also run the same Python code, with a GUI for the desktop, compiled into an .exe for any Linux, Windows or Mac. It could also be adapted for the Amiga since the DiagROM the Amiga has can also work over serial.
Actually, even a esp8266/32 can handle this and you can do this via WiFi
@@VitorFMyou beat me to it A Pi is massive overkill for this project….
Am I the only one that would be fine with a 2 hour video?
Brilliant!
I knew it existed but did not have an idea how it worked & did not have access to a Mac for long so it was board swapping only!
Detecting an error but not giving any indication of what it could be, thus requiring an expensive trip to Apple, is such an Apple thing to do.
LOL, you've not seen a lot of vintage Apple machines. Or pc clones of the same era.
This is Magic - I'm using it right now to diagnose!
I see no problem with a two hour Adrian repair video 😊
I had a friend that was an Apple dealer in a fairly small market, and what you are describing about warranty repair work, , is the exact reason he got fed up, closed his business, and went to work for Home Depot.
Its particularly fascinating that Apple bothered shipping the techstep and diagnostic mode at all, because they were indeed basically useless outside of Apple’s own engineering departments because nobody was authorized to do board level repair anyway, and if they did some anyway they couldnt get parts and thus were limited to fixing solder joints and adding bodge wires (or replacing the occasional commodity chip).
They had to build them for internal engineering purposes, but leaving them
In the ROM is pretty fascinating.
I'm supe rexcited about this and I don't even have a compatible machine lol
The whole community is going to have a field day with this!
I love his videos everyday and I wish my school is like that back in my day-Laure paine Tesla
"and on that cliffhanger..."
NOOOOOOOOOOOOOOOoooooooooooooooooooooooooo!!!!
;-)
This is an awesome vid and I love the serial diagnostic discovery/work! This is super interesting!!!
Ooh!! I think my brother might have a Techstep! I’ve seen one in his boxes. He’s sold Macs since the 80s. Imma gonna see if I can find it :)
Very good and comprehensive video
Adrian for the Win!!!
You need what?!! An Unoptanium ridiculously expensive piece of diagnostics equipment.
Adrian: "One sec. Hold my Beer"
That tool probably cost the dealer as much as a Macintosh II back then.
Just imagine the number of boards thats gone to the great e-waste in the sky before this info became more public 😮
I'm hoping that people can dust off their broken boards they have hopefully held onto to try poking around at again.
37:58 as for the 24-32 bits being used for 8 bit devices comes straight from the processor being big-endian. It will store its MMSB in the 1st byte and its LLSB in the 4th. So an ldr.b instruction thus reads a byte from the 1st byte adressed and has thus to be on the bus as bits 24-31 as this is mapped to the LLSB.
One consequence is that if you read a 8 bits from a 16 bits stored value you get the MSB where for little endian machines this would still give you the LSB part.
Fascinating video. Once you get your teeth into a problem like this, you don't let go.
Inside Macintosh IS ONLY a programmers reference. It illustrated the applicable Macintosh OS APIs to support software development on the early generations of the Macintosh. Once Apple moved to N.E.X.T object oriented OS as the foundation of the newer Macintosh OS, Inside Macintosh was effectively obsolete. And you are correct, you had to send Macintosh hardware back to Apple, and they destroyed what they could not repair. Worked for Apple for a few years in the mid to late 80s at the high tide of Apple's hardware inventory control methods.
Awesome news. Although I never had Macs, I can imagine some being saved from the scrap heap.
64KB of dual ported VRAM, providing a monochrome 512x342 display, in 1989, for $4369.. lol. What a racket.
i shall call you Sherlock! that's some good investigation work.
As it happens my SE/30 just got sick (literally while running) and this will be very useful… once I get the whole DIN8 USB chain working.
That analogy of someone asking what's wrong with their car without having seen it, that actually happened a lot when I repaired PCs for a living, someone called the shop and asked if I could tell them what was wrong with their computer over the phone without having seen it, and of course, I couldn't, had to explain to them that without having the computer in front of me to diagnose any faults with it that I couldn't tell them what was wrong as it could be anything from a bad OS install to failed hardware which I couldn't guide them through over the phone...
The one I remember most was a phone call that began with "I can't print!"
It was caused by a full hard drive.
@@mikebarushok5361 for me it was a complaint of a key not working. After fighting the keyboard case and plate, eventually locating the pins, I find it was fine! Turned out to be a locale issue in the OS.
You ARE making a living repairing computers.
Something that came to mind when you started talking about the 24 bad vs 8 good bits, and didn't go away but instead just got further reinforced with the more details you revealed:
Might the memory management chip be sticking in 8-bit mode, AND only reporting 1MB available, because something's stopping it from accessing those other three SIMMs? Maybe a RAS or CAS line that gets as far as the first socket but is broken after that (would prevent the strobe signals needed to select row and column addresses from getting through), or a set of chip/module select lines where three have been damaged but the fourth one is still OK?
Because of the way that the 680x0 is signalled to use different data bus widths, it may then also be chucking data out to memory, and reading it back, over what is effectively an 8-bit bus instead of a 32-bit one. It's doing it slowly, but successfully, and seeing each chunk in turn building up to a full 32-bit width, so as far as it's concerned all the bits are good. And as you're doing an extremely simple, yet unfamiliar thing, over a slow serial connection, you're never going to discern any actual difference in speed. So it completes in 16 milliseconds instead of 4... you'll neither notice nor care about that. What will be a problem is any complex memory-bound operation taking 4x as long, and running out of RAM so much faster.
(the processor doesn't have any "permanent" idea of what width bus it's on, or that it's "supposed" to be on, only what it's currently seeing an assertion signal to use. 68k's are basically bus width agnostic for 8, 16, and later 32 bits. The 68008 only differs from the 68000 by losing some legs and having the bus width tied internally to "8-bit" permanently, and there's no reason you couldn't do the same with an 020, 030, 040... certainly there are enough examples of systems using an 020 or 030 on a 16-bit bus with only limited or even no 32-bit transfers ever happening. Plus, all of the I/O is memory mapped - it has no idea if a commanded write is going to a peripheral, or to RAM, and same for reads. So long as there's something at the given address that can accept data, the data will be sent there, at the width it's been told to. Thus if all you can see is an 8-bit wide strip of 1MB of memory, that's what you're going to write into, then later read back out of with no trouble at all. It doesn't mean the memory, or sockets, are all working...)
Like I guess you can test by removing the other three SIMMs and seeing what happens (if that happened in the video, my apologies, my memory is bad), or certainly two of them. Switch them around musical chairs style just to be sure. Write a routine that writes some known block of data across the 1MB boundary and see if it succeeds, and whether all that can be read back again properly. Maybe it'll get to 1MB plus 1 byte and die. Start the processes at or just before different megabyte breakpoints. Etc etc.
Also have you tried putting the memory in the second set of banks and seeing if it then boots? Gives better diagnostic results? You could / can do that with a lot of computers these days, so long as it's present somewhere it's usable and can be logically reassigned in a sensible order.
Gripping, looking forward to the next video.
Lots of usb equipment on PCs uses serial Protocols. I often have to snoop the starting sequence and commands with 2 teensys and the arduino serial monitor.( I m talking about controllers for stepper motors or spectrum analyzers and stuff.)
9:58 Commandant Eric Lassard joined the chat(many many many)
Funny sidenote when you say star-r that reminds me of the boss in first resident evil that goes STARS.
Also gives flashbacks from airplanes in a real airplane they have a delay. So it says Stall-All kind of like a echo effect. If you pull fuse 17 or 19 I think in the fuse box of the 747 it doesn't chime several warnings and stall sounds normal. Not like standard stall-all
Loving your videos. Your brilliant.
Yay for the great diagnostic mode. Boo for the "to be continued...". Won't be able to sleep for a while.
1:00:40 I like the transition to Adrian the Grey, full diagnostic wizard at the end
It looks a lot like the debugger you invoke by pressing the Programmer's Key. I never knew you could reach it from the serial port. Nice find, Adrian!
On a healthy Mac, you can force the Mac in to this mode by pressing the programmer’s key (NMI) during POST, so not a coincidence at all.
Absolutely bonkers!! Just amazing
I used the diagnostic mode using ZTerm on a IIci connected to a faulty SE/30 motherboard by serial cable. It had the same slow chimes and the same 00FFFFFF error that Adrian's board had. It turned out that the very same pin on the Glue chip, as shown in the next video, was broken due to a corroded trace.
Also remember that if you're loading and running a tiny 18 byte program, you're likely just running from the 030's cache. It will be writing to RAM, and incorrectly if the SIZ* signals are bad, but read and execute won't actually hit RAM unless the cache is flushed. A RAM test writes/reads too many addresses to hold in cache.
There is a CDIS input to the 030 to disable the cache, and the GLUE asserts it for I/O ranges, but you can also ground it to force reads to go to the bus.
You could script this very easily and do some really cool tests.
More thrilling than a true crime story
FYI I wanted to try this on my SE/30 but it boots normally. I couldn't get the interrupt switch to work. Putting some DeoxIT on my programmer's switch fixed it and now I can explore this!
I like the concept of keeping the repairs relatively simply with off the shelf equipment. That being said, I would also be interested in advance repairs, using reverse engineered test setups or 'test jigs' that were originally used by Apple.
I've found that manufacturers have deployed some interesting methods for troubleshooting, that can be used to our advantage, when servicing legacy equipment.
Motorola had Lab Tools, while challenging to get, was very handy when servicing some of their radio equipment.
It sure is a cliffhanger. Damn it Adrian :XD
This is really useful information, thank you!