SE/30 Recurring Freeze at Cold Boot

[JDW]

One of my SE/30's freezes on cold boot most of the time, sometimes freezing as the INITs display while booting and sometimes a couple minutes after booting into the Finder.  Switching power ON/OFF doesn't solve the problem UNLESS I hard power off for at least 15 seconds and then power on again -- and then the problem usually goes away for the rest of the time I have the machine turned on.  I made a video below.  The video is long because it is uncut in order to show how the problem goes away; and as you can see, except for a freeze caused by a game, the SE/30 was stable for the remaining 40 minutes of this test.  The question is, why the lockup on cold boot?  As you can see in this video, it locks up about 2 minutes into the video while I'm playing Crystal Quest.  My little round crystal-eater guy starts moving increasingly more slowly for about a second and then the lockup occurs.  Programmer's switch interrupt doesn't work in this case, although using the programmer's switch to reboot it does the reboot job properly, but it doesn't solve the problem.  Again, I have to hard power off for at least 15 seconds when the lockup roblem occurs and then power on for the problem to go away.  My question is, why?  Motherboard, Analog Board, and Sony PSU are all properly recapped.  I even replaced the flyback transformer.  This machine has the stock CRT Yoke Board installed, with no PDS cards.

Thanks.

 

[JDW]

Well, I see I've stumped the experts in this forum once again!

Not to be dissuaded, I have made yet another video (below) showing the slowdown followed by a freeze a few moments after cold boot.  The video below also shows a separate problem I've been seeing on the display whereby the display horizontally jitters on occasion.  You can see that horizontal jitter during my Tetris game play at the end of the video.  The video is rather abruptly cut off at the end because my SD card ran out of space during the shoot.

I LOOK FORWARD TO HEARING YOUR THOUGHTS.  Thanks.

 

[K Trueno]

I can't say I have experienced freezing symptoms like this.  Sorry.

As for the horizontal "jitter", I've noticed that one out of my three SE/30 on the same analog board and CRT exhibits a "widening" when I bring up menus.  I.e. When I toggle the Apple Menu it widens the display a touch, but it looks slightly different from yours.  And one of three is a lot worse than the other two.  Perhaps something on the motherboard, then?

 

[JDW]

@K Trueno

Thank you for sharing your experience.  But your question is the same as mine.  HOW DO WE FIX IT?  Seems odd it would be on the motherboard though, especially one that has been recapped like my case.  (My analog board and SONY PSU are recapped too.)

 

[BadGoldEagle]

Hi James, 

Somehow I didn't see your thread, otherwise I would have done some checks on my SE/30 as we seem to have pretty much the same setup, only my ROM image is from a IIsi and was hacked to remove the ROM and RAM checks (I think the olePigeon ROM is pretty similar...) and I only have 32 megabytes of RAM. But I too have that socketed 50MHz Powercache and no PDS cards connected (at the moment!).

I did experience a couple of crashes with mine lately. Most of them were due to the fact that I forgot to patch my system files for the new ROM. I fixed that yesterday evening. The funny thing is that after that, it once froze like yours on cold boot (but at the Welcome to Macintosh screen) and only when the Floppy EMU was attached in HD20 mode and with one specific disk image. I blamed the image and proceeded switch the thing off (reset or interrupt wouldn't do anything) and removed the Floppy EMU. It then rebooted just fine. I powered it off normally and reconnected the Floppy EMU but this time with another image and it worked fine. I didn't do any further diagnosis as the problem fixed itself.

This might be completely unrelated but this does seem strangely similar. Could it be caused by having some weird volume mounted (that image on the F-EMU in my case and your ROM image in yours)? Hummm... Could your ROM be corrupted?

I haven't watched the whole 90 minutes (sorry about that!), so excuse me if I suggest something that has been tested before.

Have you tried running this config with the stock SE/30 ROM? It seems to me that this could be the cause of our issues. 

Cheers,

Lambert

 

[Jinnai]

If it were me, I'd try swapping parts. I don't know much about complex CPU/ROM issues. If the horizontal movement is so rare, I wouldn't let it bother me, but perhaps rather consider it a possible clue about the computer's issue. The confusing thing is, one seems like an analog issue, while the other seems like a digital issue.

 

[JDW]

Thank you for the replies. 

I have another Analog Board that was recapped by me at the same time as my existing Analog Board was recapped, using the same capacitors.  I swapped it out and tested last night.  I got the cold boot freeze even with that Analog Board, but I didn't see the horizontal jitter.  Even so, I don't always see the jitter with my stock yoke board, so tonight I intend to put my Micron Xceed PDS video card and Xceed grayscale yoke adapter board back in a test if I get the jitter.  If I don't get jitter, then it was clearly the Analog Board as being the source of that problem, but then the question becomes: WHAT in particular on the Analog Board would cause horizontal jitter?  As I said before, I recapped that Analog Board AND replaced the flyback transformer too, which is a topic I presented in my Analog Board recapping video on YouTube.

 

[JDW]

I put my Micron Xceed Grayscale adapter (yoke board) and Color30HR PDS card back in using my spare Analog Board and tested for well over an hour.  No horizontal jitter.  So it's clear the jitter came from my other analog board, even though it was recapped at the same time and with the same capacitors as this other analog board which has no jitter.  I also swapped the flyback on that other analog board (the one with the jitter), so I'm curious as to what component on the board it could be causing the jitter.

As to the freezes I've been getting, those continue even with the new analog board.  I've not yet moved back to the stock ROM since it too me a while to secure my ROMinator II MEGA in this motherboard.  But since the motherboard is recapped along with the SONY PSU, it must be either the ROM or the socketed Daystar 50MHz 030 PowerCache accelerator causing the freezing.  Even so, when the freeze happens, I can then shutdown for 20 seconds, then flip power ON and it won't freeze after that, so long as I keep the machine ON.  It's a crazy problem.

 

[JDW]

I've been testing this problem over and over for the last 2 months and I've made a couple key discoveries:

1. The freeze only lasts 2 minutes.  Note that in my earlier videos I didn't wait 2 minutes and just tried to restart.  If I wait 2 minutes, then the computer suddenly starts working again and never locks up after that.  However, the 2-minute freeze is still a problem that needs to be resolved.  I made a new video showing the automatic recovery from the 2-min Freeze here.

2. I tested every variant of RAM/ROM/Motherboard/Video possible and found the 2-minute freeze is an incompatibility between the ROM-inator II MEGA and the Daystar PowerCache 50MHz 68030 socketed accelerator board.  No problems when the ROM-inator is used WITHOUT the Daystar board attached (i.e., when I remove the Daystar board, I of course put the stock CPU back into its socket and then test).  This is a fact, and after countless hours of testing and applying solder to the ROM-inator, I know for a fact it's not a ROM-inator connectivity problem in the ROM socket.  It's definitely the Daystar board and ROM-inator conflict.

I wrote to Steve C. at Big Mess o' Wires.  His reply to me was as follows:

I think this is probably a Daystar ROM patch gone wrong when applied to the ROM-inator II, but not sure why the delay appears when it does. Possibly it’s tied to the software driver to the ROM disk, so the problem appears when you try to access a new region of the ROM disk which must be loaded and decompressed. But that should only take milliseconds, not 2 minutes. Maybe 2 minutes is some kind of disk timeout? Just a wild guess. You could check if the problem still occurs if you have the ROM-inator II installed, but you boot from a floppy disk or SCSI HD. For grins you could also try Rob Braun’s much earlier iisi+romdrv0.9+nomem+nosum+img.bin ROM image from here: http://synack.net/~bbraun/macromboot.html

Background history, if you’re not already aware:

- Rob Braun designed the ROM disk driver code, for a Mac Plus ROM replacement
- Doug Brown designed a Mac II series replacement ROM SIMM
- Rob and Doug collaborated to make a Mac II version of the ROM disk driver code
- Doug sold Mac II ROMs for a while that leveraged the ROM disk code
- Doug decided to exit the business, and we made an agreement for me to use his hardware and software designs
- I made a bunch of improvements to the original software, including a compressed ROM disk, and added the new chime, icon, and splash menu
- I sold SIMMs and programmers
- I decided to exit the business due to unavailability of parts and it generally being a PITA to support
- I later reintroduced a smaller ROM-inator II Atom with no programmer

From memory, the differences from ROM-inator II vs the stock IIsi ROM are:

- RAM test is disabled
- startup chime is different
- Happy Mac icon is different
- A new software driver is installed during boot up to manage the ROM disk
- There’s a splash screen / menu that shows info about the installed RAM and ROM disk, and prompts the user to press a key to select the boot method
- Some regions of the IIsi ROM containing unused code/data have been overwritten with the code needed for the above features
- The contents of the ROM disk are present in an address range that's beyond the range of the IIsi ROM

The programmer can modify the entire ROM, including both the ROM disk and the ROM code region. But knowing where/how to modify the ROM code region is very difficult. Many of the changes are interdependent and all were created through manually disassembling, studying, and reverse-engineering the existing ROM, before applying careful byte-by-byte patches. Much of this is discussed in a long thread at mac68k.info that’s linked from the ROM-inator II page. There’s no simple way to change any of the ROM modifications without wading very, very deep into the guts. For this purpose you would also need to find and reverse engineer the patches applied by the Daystar card, to understand what they’re doing. Doug Brown mentioned some small progress towards doing this for the Daystar 040 card a while ago here: https://68kmla.org/forums/index.php?/topic/54723-my-se30-w-turbo-040-rom-inator-ethernet-and-81/. You would probably need to continue that effort yourself if you want to research this further.

I tried Steve's suggestion (colored in red above) to use Rob Braun's older ROM and found there is no 2-minute freeze at all when used with my Daystar PowerCache!  No problem! 
Specifically, I programmed and tested the following two ROMs to my ROM-inator II MEGA:
 
http://synack.net/~bbraun/macsrc/iisi+romdrv0.9+nomem+nosum+img.bin
 
http://synack.net/~bbraun/macsrc/iisi+romdrv0.9.6+nomem+nosum-8mb+chm.bin
 
My successful testing with these 2 older Dougg ROMs indicates there's something the stock "mega-simm-image.rom" has which is causing the 2-minute freeze in conjunction with the Daystar PowerCache. 
 
I don't know all the differences from ROM-inator II (MEGA?) vs Dougg's ROMs, but the differences I do know are crossed out in gray below:
 
- RAM test is disabled
- startup chime is different
- Happy Mac icon is different
- A new software driver is installed during boot up to manage the ROM disk
- There’s a splash screen / menu that shows info about the installed RAM and ROM disk, and prompts the user to press a key to select the boot method
- Some regions of the IIsi ROM containing unused code/data have been overwritten with the code needed for the above features
- The contents of the ROM disk are present in an address range that's beyond the range of the IIsi ROM
- HD20 Compatibility
 
I doubt the "startup chime" is the cause of the 2-minute freeze, so that leaves only the "splash screen" difference as a possible cause of the freeze, unless there's some other differences I'm unaware of.  

Do any of you have a ROM-inator II MEGA and use it with a Daystar accelerator?  Do you get any kind of temporary freeze like I am?

Any thoughts any of you might have would be greatly appreciated.  

Thank you.

 

[BadGoldEagle]

Interesting stuff.

So remember when I said we almost had the same setup? Well, the ROM SIMM I have is from GGlabs and has the Brown / Braun ROM (stock IIsi but no ram or rom check) on it.

Putting hardware aside, the only difference was the image. And I didn't have any issues with my Powercache. I also remember you mentioning that yours got quite hot to the touch after a few minutes. Now I'm starting to wonder if those two things weren't correlated...

In order to isolate the ROM issue, you should compare the two ROMs with a hex editor (Hex Fiend on macOS or Notepad++ on Windows). There shouldn't be more than two or possibly three differences between the two. Then you can slowly start adding back the features you want from the ROM-inator II and check if the problem reappears. There is no risk of damaging anything, so it's worth a try

I think what's happening here is that something must still be 'running' in the background (I know this isn't software but I couldn't find another word for what I meant) after the Mac finishes booting up and hang as the 'process' requires too much processing power. Once it finishes, normal operation can be resumed. That's only my take on this. For that reason, I wouldn't exclude the startup chime from the suspects list as the Powercache does some funny things to it (much faster and higher pitched IIRC) with the default SE/30 ROM. 

Edit; I can't seem to find the ROM-inator image online, otherwise I would have checked the difference with you...

 

[Jinnai]

Wow, you're a very curious fellow. Thanks for such a thorough investigation of this issue.

 

[JDW]

In order to isolate the ROM issue, you should compare the two ROMs with a hex editor (Hex Fiend on macOS). There shouldn't be more than two or possibly three differences between the two. Then you can slowly start adding back the features you want from the ROM-inator II and check if the problem reappears. There is no risk of damaging anything, so it's worth a try...

Thank you for the advice, but what is the best approach to compare the two ROMs?

You see, I downloaded Hex Fiend per your recommendation (and updated it to version 2.11.0), and then I opened my ROM-inator II MEGA's View attachment mega-simm-image.rom.zip (which has a large disk image embedded in it) and then opened Rob Braun's 8MB Version ROM (which doesn't have any disk image in it).  After that I choose File > Compare (Shift-CMD-D) and found there are 1342 differences!  Obviously, the bulk of those differences likely pertains to the disk image on the ROM-inator II MEGA's ROM which isn't present in the Braun ROM.  But how do I make it easier to spot those "two or possible three differences" you mention I need to find?

Thanks.

 

[BadGoldEagle]

The best way to go at this would be to make a copy of your custom ROMinator II image and remove the disk image portion. I don't know where it is located, but the bits should all be at the same place towards the end I would think. 

I haven't used Hex Fiend in a while but I think there's a way to highlight the differences. Then the bits have to be checked line by line. 

 

[JDW]

The best way to go at this would be to make a copy of your custom ROMinator II image and remove the disk image portion. I don't know where it is located, but the bits should all be at the same place towards the end I would think. I haven't used Hex Fiend in a while but I think there's a way to highlight the differences. Then the bits have to be checked line by line. 

Unfortunately, there is still no easy way to isolate differences intelligently.  For example...

Here's the BASE 512K ROM from Big Mess o' Wires (no disk image at all).  And here's a copy of my View attachment IIsi.rom.zip (100% stock condition Apple IIsi ROM, copied to my iMac via my ROM-inator Programmer, which of course has no disk image either).  When you open those two ROMs in Hex Fiend, you will find 1735 differences scattered all over the place.  It's literally impossible to know what to make of those 1735 differences.

Next...

If you open that same BASE 512K ROM from Big Mess o' Wires (no disk image at all) and compare in Hex Fiend to the Rob Braun ROM (with no disk image), you see 1341 differences scattered all over the place!

In other words, I really haven't the faintest idea how to properly go about moving code little-by-little from the BMOW BASE 512K ROM to either the stock IIsi ROM or the Rob Braun ROM in light of the sheer number of differences.  If some of you folks do, please advise in detail.  But please ponder it logically.  Even if I could make the time to copy each and every one of the 1000+ differences, and test after each copy, because the code is scattered all over the place, I assure you it would just lockup the vast majority of the time.  And the end result would merely be a worn out ROM and worn out ROM socket because of those 1000+ tests.

Thanks!