Logic Board - Macintosh SE Reloaded

[retr01]

@JDW,

The error code -192 is when the Mac cannot find the resource. I suspect that the resource manager could not find the resource as instructed by the program's parameters to use that specific resource.

My question for you @JDW, have you used this disk (or disk image) before on the SE without any errors? Try it on the regular SE logic board? Mac Plus? And what was the program trying to do for that instruction set to use what resource? What about the Macintosh SE Tour disk?

Interestingly, back in 1984, a contributor author to InfoWorld, John R. Nichols, mentioned in the eighth paragraph on page 7 of the April 16, 1984 issue:

MacPaint and MacWrite seem to be bug-free. I have a surprising talent for bringing out the worst of software, and so far nothing's even burped. Though the Guided Tour tutorial disks displayed system errors while I was running them, I recovered on my feet. I suspect the Tour disks were rushed a bit to get them out of the door on time.​

He was not sure if it was that or the logic board in the 1984 Mac 128k.

 

[retr01]

@JDW,

Related to the software errors you ran into for SCSI, have you tried using the programmer's switch to interrupt and snoop to see where the problem is? I know SCSI Director Pro 4.0 and 2.1.7 should work fine with Mac SE and BlueSCSI. It would be nice to snoop and see what is causing the system error.

A dab of hope and add a bit of patience. Cheers!

 

[rikerjoe]

I left my stock, working SE board (donated to me by Marcus Hesse) at the office., and I am here at home now testing my SE Reloaded board. My SE Reloaded board checks out fine with my TechStep and basically every other test I've conducted, but SCSI Director Pro puzzles me. It throws an Address Error every time I click the "Test" button. That is true of SCSI Director Pro 4.0, regardless of whether I boot from System 6.0.8 or 7.1 (operating systems it is compatible with). It also happens when I try SCSI Director Pro 2.1.7 and boot off the 800K floppy image on my FloppyEMU. The screenshot below is version 2.1.7 booted off my FloppyEMU.

View attachment 6352

In all cases, the app loads just fine, but the bomb occurs when I click a SCSI drive I want to test and then click the "Test" button within the app.

Those of you with a Mac SE (must have old ROMs and IWM, compatible with 800K disks but not 1.44MB disks -- not the SE FDHD model), have you experienced the same problem?

I really want to get SCSI Director Pro to work because I've used it to graph out BlueSCSI & MacSD performance on my SE/30 machines and Color Classic Mystic, so I'd like to get it to work on my SE too. Nothing I read in the files on Macintosh Garden indicate it is incompatible with the SE.

James, I fired up my SE with 4 MB RAM this afternoon, booted it into System 7.1.1 from an external BlueSCSI with the DB 25 connector, and was able to run SCSI Director Pro 4.0 just fine. I ran a successful test on the original spinning rust 40 MB SCSI drive. My SE is the Rev A board with an 800k floppy. I wonder if it is a strange FloppyEMU problem you are encountering, perhaps? At least my data point indicates success using an external BlueSCSI, perhaps that is worth a try?

 

[retr01]

I wonder if it is a strange FloppyEMU problem you are encountering, perhaps?

Maybe.

That leads me to wonder, does SCSI Director require at least one SCSI media device mounted from an ID number beside the SCSI controller at ID 7? Did the SCSI Director see the BlueSCSI HDD image while booted into System 7.1 off the Floppy Emu? Suppose the SCSI Director could not see anything, including the SCSI controller at ID 7, which identifies as Macintosh SE. Would it throw an exception error, causing the bomb dialog to show up?

I understand there are no hardware-level issues since @JDW tested with TechStep and APD (Apple Personal Diagnostics), and the SE reloaded logic board passed with flying colors. So, there must be some strange trigger causing the expectation errors at the program or OS level. However, @JDW did mention not having loop-back cabling.

Could DIY SCSI loop-back cabling be made relatively easy and implemented in further testing?

 

[JDW]

My question for you @JDW, have you used this disk (or disk image) before on the SE without any errors? Try it on the regular SE logic board? Mac Plus? And what was the program trying to do for that instruction set to use what resource? What about the Macintosh SE Tour disk?

I cannot test the stock SE board (donated to me by Marcus Hesse) until after work tonight. I've only tested the 128K Tour on my SE Reloaded board as of right now.

One kind person on FaceBook indicates it happens for him on his stock SE board though... (he has the old ROMs, just like my SE Reloaded board)

have you tried using the programmer's switch to interrupt and snoop to see where the problem is? I know SCSI Director Pro 4.0 and 2.1.7 should work fine with Mac SE and BlueSCSI. It would be nice to snoop and see what is causing the system error.

No because I do not know the exact snooping process. I know "G FINDER" and how to trigger the Easter Eggs, but I'm not savvy with the Programmer's Switch. And since we're on that topic, when I boot and invoke the programmer's switch, is there a command I can type to tell the Mac to Restart or Shutdown? I've long wanted to know that.

Anyway... On Facebook, the same kind person confirmed it works on his stock SE board...

The fact that the SCSI Director Pro 2.1.7 boot disk can run that one test which I cannot indicates a difference on his stock SE board versus my SE Reloaded board. When I run the same test on my Marcus Hesse stock SE board tonight, if I am able to run 2.1.7 without issue, then that confirms a problem on the SE Reloaded board.

James, I fired up my SE with 4 MB RAM this afternoon, booted it into System 7.1.1 from an external BlueSCSI with the DB 25 connector, and was able to run SCSI Director Pro 4.0 just fine. I ran a successful test on the original spinning rust 40 MB SCSI drive. My SE is the Rev A board with an 800k floppy. I wonder if it is a strange FloppyEMU problem you are encountering, perhaps? At least my data point indicates success using an external BlueSCSI, perhaps that is worth a try?

That provides more evidence of a problem on my SE Reloaded board. :-(

It cannot be the FloppyEMU because I tested SCSI Director Pro 4 while booted from my BlueSCSI and also my MacSD. It throws the same error.

@JDW did mention not having loop-back cabling.
Could DIY SCSI loop-back cabling be made relatively easy and implemented in further testing?

I don't have such cabling outside the cabling that comes with the Apple TechStep, which I guess is it's own version of official loopback cabling.

@Kai Robinson, if you are able to test SCSI Director Pro (old and new versions) on your own SE Reloaded board, that would be useful and worthwhile, especially if you use a FloppyEMU and BlueSCSI like I am.

Again, I will test on my stock SE board later tonight.

 

[Kai Robinson]

I had a thought - the SCSI chip in your board, what brand is it?

All original machines were the NCR 53C80, I'm wondering if there was errata specific to that chip that was not present with ones from Logic or AMD - nothing that would stop SCSI from actually working, as you've seen but something that was hard coded into the scsi driver in ROM or certain software.

Secondly, the SE Reloaded has never been tested with anything less than System 6. I'm very surprised to see it booted with anything less than that!

 

[retr01]

I reviewed @JDW's SE Reloaded Part II video, and it appears the NCR 53C80-40 was installed, right?

Since the original Apple Hi and Low ROM chips on the SE logic board cannot be modified, could replacement reprogrammable Hi and Low ROM chips be introduced with modified code to work with a greater variety of SCSI chips, if needed?

 

[JDW]

I had a thought - the SCSI chip in your board, what brand is it?

NCR as shown in the still from my video...

Purchased from this UT Source page.

 

[retr01]

That is a much clearer picture, @JDW! I see that you used sharpen mask.

So, @Kai Robinson says NCR 53C80. Does the "-40" make any difference?

 

[JDW]

NCR 53C80. Does the "-40" make any difference?

I don't know if the -40 makes a difference, but here's the description and datasheet from NCR...

http://datasheet.datasheetarchive.com/originals/distributors/Datasheets-111/DSAP0032062.pdf

And the stock SE board kindly donated to me by Marcus Hesse uses this chip...

 

[retr01]

I don't know if the -40 makes a difference, but here's the description and datasheet from NCR...

"The 53C80-40 is a CMOS part designed at a higher performance CMOS replacement for the NMOS 5380." CMOS stands for Complimentary Metal Oxide Semiconductor, a RAM chip that stores information about processes. NMOS is a metal oxide semiconductor. Both are different designs serving the same function.

I only am wondering if "higher performance" is too much for the SE's logic board design because of timing differences? Pages 30 through 39 have various timing tables that can be reviewed and see if the -40 is compatible.

And the stock SE board kindly donated to me by Marcus Hesse uses this chip...

That is the 5380 which the 53C80 is functionally equivalent.

 

[retr01]

If TechStep did not see anything wrong with the SE Reloaded logic board, including the SCSI chip, I find it puzzling that some SCSI software throws exception errors and that the SCSI chip is a higher performance version that is checked out fine by TechStep?

@JDW, can you pull up the testing logs from the TechStep console?

 

[JDW]

@JDW, can you pull up the testing logs from the TechStep console?

Yes, but they aren't highly technical. The log simply shows what basic tests were run, and that they all passed.

 

[retr01]

Ah. Running the same programs using the "control" standard SE board will help. I look forward to your further findings, @JDW. Hopefully, we tinkerers can nail down the culprit.

 

[JDW]

I've made time to test the stock SE motherboard from Marcus Hesse, which has the same old version ROMs and IWM as my SE Reloaded board. I am getting the same results on it. But I need to clarify one important thing. This is address error problem in SCSI Director Pro is happening only when I have my MacSD connected. It doesn't happen with BlueSCSI. I am in contact with the developer of MacSD to find out why.

Now, to test the SE Reloaded board further, I desoldered the 5380 chip from the stock board that @Kai Robinson kindly shipped to me (defective) and then socketed it into my SE Reloaded board (after cleaning it, of course). That chip is this one...

Same address error in SCSI Director Pro, but again, that is when I am testing my MacSD, not BlueSCSI.

So we can rule out the 5380 chip type from being an issue at this time.

I must also say that I sometimes get the address error and sometimes not when using the stock motherboard and MacSD, when booted from the SCSI Director 2.1.7 floppy via FloppyEMU. I have no idea why that is. But I get the address error most of the time.

Also, there are times when I will boot off MacSD into System 7.1 (the version for the SE), and then launch SCSI Director Pro 4.0, and the test will start and complete the top 4 tests, but then it displays a large dialog box filled with text explaining some kind of anomaly, and after that it never completes the graphs. In other words, it doesn't throw an address error, but it never completes the graphs (when using MacSD only).

I cannot say anything further until I hear back from the developer of MacSD.

Please also don't take that the wrong way. I've never had any issue with my MacSD until now. It's a great product that I think highly of. It's just curious that BlueSCSI doesn't respond in the same way (address error) with SCSI Director Pro.

— — —

I also used my FloppyEMU on the stock motherboard to test the 128K Guided Tour. Same problem as the SE Reloaded board. However, the 512Ke Tour floppy works fine. I also tested the System 0.85 floppy (the same OS as is used by the 128K Tour), and that throws an error -- the same error on both the stock board and SE Reloaded board.

— — —

Now, returning to what I wrote in this post, I re-tested the following on the stock (Marcus Hesse) SE motherboard...

1. When launching Speedometer 4, I don't get an "unimplemented trap" error like I do on the SE Reloaded board, but when I quit the app, I get an address error.

2. When I launch FWB Hard Disk Toolkit 2.0.6, I don't get an "unimplemented trap" error like I do on the SE Reloaded board, but it throws a strange error dialog that complains I need to use System 7.0.1 or higher -- but I am booted into System 7.1!

So while I cannot explain why SE Reloaded throws an "unimplemented trap" error, the fact remains that even the stock SE board has trouble with those two apps.

That's all for now.

 

[Kai Robinson]

In a way i'm glad that the wierdness isn't solely occurring on the SE Reloaded board, but the stock SE board as well. I was worried there was something wrong with the board revision that i'd need to change.

Have you tried with a DIP28 SWIM /SWIM adapter i sent you and the more modern FDHD ROM set?

 

[Kai Robinson]

@YMK any thoughts on the way the MacSD is behaving?

 

[retr01]

This is address error problem in SCSI Director Pro is happening only when I have my MacSD connected. It doesn't happen with BlueSCSI. I am in contact with the developer of MacSD to find out why.

Good! I am curious.

So we can rule out the 5380 chip type from being an issue at this time.

Whew! That is GREAT news!

I must also say that I sometimes get the address error and sometimes not when using the stock motherboard and MacSD, when booted from the SCSI Director 2.1.7 floppy via FloppyEMU. I have no idea why that is. But I get the address error most of the time.

Maybe contact Steve at BMOW about the error on FloppyEMU? I find it odd. One thing, have you tried putting a new fresh image of SCSI Director 2.1.7 on a separate SD formatted and set up again?

Also, there are times when I will boot off MacSD into System 7.1 (the version for the SE), and then launch SCSI Director Pro 4.0, and the test will start and complete the top 4 tests, but then it displays a large dialog box filled with text explaining some kind of anomaly, and after that it never completes the graphs. In other words, it doesn't throw an address error, but it never completes the graphs (when using MacSD only).

Screenshot, please?

I cannot say anything further until I hear back from the developer of MacSD.

Please also don't take that the wrong way. I've never had any issue with my MacSD until now. It's a great product that I think highly of. It's just curious that BlueSCSI doesn't respond in the same way (address error) with SCSI Director Pro.

Understandable.

I also used my FloppyEMU on the stock motherboard to test the 128K Guided Tour. Same problem as the SE Reloaded board. However, the 512Ke Tour floppy works fine. I also tested the System 0.85 floppy (the same OS as is used by the 128K Tour), and that throws an error -- the same error on both the stock board and SE Reloaded board.

Yeah. System 0.85 and the first tour program were intended for the Mac 128k. Those programs were frankly buggy. I think System 0.85 and the tour program were used to introduce the Mac in 1984 at the presentation and the Apple campus in Cupertino.

If you could get the 128k ROM file and try it on the Mini vMac emulator?

Or if anyone here on TD has a Mac 128k to try it?

So while I cannot explain why SE Reloaded throws an "unimplemented trap" error, the fact remains that even the stock SE board has trouble with those two apps.

Do those apps work fine with the SE/30 and other Macs? I agree that it is odd.

That's all for now.

Rest! Sip some lemonade or tea and relax.

 

[YMK]

@YMK any thoughts on the way the MacSD is behaving?

I'll be looking into this soon.

 

[JDW]

Have you tried with a DIP28 SWIM /SWIM adapter i sent you and the more modern FDHD ROM set?

No because I still haven't gotten around to buying the required programmer, and I also don't have the required chips for the ROM replacement PCBs yet either. This is what I have right now (what you kindly shipped to me, Kai)...

In the above photo, from left to right, the chips are: PLCC28, PLCC44 & PLCC32. Which means if you have a programmer, you need all those socket adapters.

Kai, you soldered that IC onto the SWIM PCB, so I assume you programmed that, correct? If you did program it, then all I need to do to test it is just resolder the chip (several pins aren't fully soldered), then add a couple headers for the DIP legs, then add 4pcs of 0.1uF SMD ceramic capacitors (I purchased those) to finish it.

However, even when that SWIM replacement completed, as I said, I still don't yet have the programmer or chips necessary for the SE ROM HI & LO Replacement, so adding only that SWIM chip replacement alongside the old ROMs would merely be a test that shows if that SWIM replacement works or not.

You told me the SWIM should work with both old and new ROMs, but of course, adding the SWIM alone will not enable 1.4MB functionality. So again, testing only the SWIM replacement with my existing old version ROMs would merely be to see if the machine crashes (proving something is wrong with the SWIM replacement PCB) or show if the board seems to work normally. However, if there is any oddness that occurs when a SWIM is used with old ROMs, that would come out in my testing of that combo, and since I am already experiencing oddness right now, as mentioned in my testing recently, it would be another series of long tests to do.

At this point, I've filmed next to nothing for SE Reloaded Part IV because I am just so busy at work and the rest of my free time (every waking moment) has been spent on testing (the results of which I have been sharing in this thread). At some point, I am going to need to freeze testing and start filming so I can finish the finale. I haven't done that yet because I want to tell everyone, "It's 100% error free, folks! I've verified it." But there is just so much to test. It is incredibly time consuming. I realize I can't test every software combination possible, so I am just trying to cover the basics of what could be wrong with ports mostly, and most of my time has centered on SCSI because of the aforementioned issues.

If I can remember today (and I probably won't), I will order the programmer and required socket modules. Separately ordering the 2 chips from Mouser will cost me $16 in shipping fees alone, in addition to the cost of the $1.70 x 2pcs cost of the chips, I will need to spend time seeking out a cheaper alternative source for those, since I have nothing else I need to order from Mouser at this time.

@max1zzz sent me a PM reply in the past to clarify which chips are compatible with his ROM replacement PCBs...

The IC's I use are either AM29F010's or SST39SF010's though pretty much any 1Mbit PLCC32 EEPROM will work as they all use a standard pinout

Mouser doesn't have the AM29F010's that I can see, but they do have multiple variations of the SST29SF010's like this:

https://www.mouser.jp/ProductDetail/Microchip-Technology/SST39SF010A-70-4I-NHE-T?qs=Ot24P6tC%2FQ4cBkaU2PnYqg%3D%3D

---

@retr01
I need to get to work now, so no time to answer your questions, but I will test more on my lunch break and try to answer a few at that time.

Thanks.