X68000 Expert + SCSI + SCSI2SD = Borderline insanity

[mikkohoo]

So, I'm hoping someone can help me out in the Sharp twilight zone.

I have an X68000 Expert that I've owned for a good number of years now but haven't done much with aside from play some floppy games (and even this was 5+ years ago). Last week, I got the 0661 X68000 SCSI BOARD from a friend and decided to do the SCSI2SD thing. I followed the instructions in the wiki and, much to my surprise, everything worked first go: I had a blast playing the games on the HDD image. After a few hours, I shut down the machine and put it to one side.

The next evening, I wanted to show my son what a great system the X68k is, now that I had a good selection of games easily accessible. So, just to hook everything up, switch on and... the floppy prompt appears. Confused, I put in the Master Disk and checked that the SCSI device is there. Yes, it was, and it showed a bootable partition, but the machine would not even consider booting from it. However, I also noticed that my SRAM settings were a mess and decided that the battery had given up the ghost.

So I replaced the battery with a Ni-MH one and SRAM settings are now preserved fine. However, I cannot change the boot priority setting; if I set it to, say, SCSI1, save and immediately restart switch.x, the setting is back to "STD". This may or may not be a concern based on what I have heard. The system will not display the boot screen from the SCSI board, but the drive is always there if I start up SCSIFORMAT.

Other things I have tried:

- Replacing caps on the bottom board. I don't know if they have been changed before, but they were Nichicon caps and each one I took out measured to within +-10% of the nominal value. I did not have all of them so I did not complete this exercise, but there were absolutely no signs of damage and replacing some 20 caps had no effect.
- Switching the board to the second I/O slot.
- Cleaning the contacts on the board and the I/O slot using isopropyl alcohol.
- Checking the SCSI board for cold solder joints.

...any ideas?

[Max]

did you set everything well on switch.x?....just to make sure that all operations have been done so far...

[mikkohoo]

Depends on what you mean by "well" - I'm not very knowledgeable on this machine. I have RAM set to 2048K, "SCSI ID" set to 7 (I understood that this should be left as is. The SCSI2SD is at ID 4, which I heard is the most compatible, but there's a lot of conflicting information here). Is there something wrong with this and/or should I be looking at something else? I did not set much else when the system decided to work last time, but have reset SRAM since just to be safe.

[Max]

try setting it  differently if it does not work properly and please refer to the switch.x set you may find here somewhere on nfg, I'm pretty sure you'll work it out!!!

[mikkohoo]

If you are referring to setting different SCSI IDs for the SD card, I have done that: tested 0,1,3 and 4 at least. The only two I can imagine having something to do with the matter at hand, HD_MAX and SCSI_ID, should not be changed according to the Wiki.

[mikkohoo]

I did a complete recap of the system (mainboard + all sub boards) as there were some suspect caps on the video board at least. This improved RGB out but did not solve my original problem. If I boot from floppy and go to C:, I can see the partition there, but it still will not boot from it.

[SuperDeadite]

The Master Disk is used for when connecting a SCSI device to a SASI port.  If you want to use a true SCSI card then the Master Disk is not needed and will only screw things up.  What you do need is a driver for the SCSI card which came on the SCSI tools disk that came with the card itself originally.

If you don't have this available, it may simply be easier to just remove your SCSI card completely, plug into the SASI port and load up SxSI from the Master Disk like normal.

[mikkohoo]

Yes, however - the card is supposed to be able to boot without a driver, and it did do just that before it decided to stop out of nowhere. This is the problem I have been chasing ever since. I would get a splash screen from System Sacom and it would load the OS from the SD card. Now, I do not.

[Jehuty]

Has the System Sacom SCSI Board any Bios to Change some Settings ?

[mikkohoo]

There's not that much documentation available. It seems to contain mostly LS logic and a couple of ROMs.

https://gamesx.com/wiki/doku.php?id=x68000:0661_-_scsi_board

[SuperDeadite]

The official Sharp SCSI boards all require a driver.
If this SACOM board truly does not need one, then those ROM chips must be bootable.
So logically, you would have to tell the X68K to boot from those chips.
Have you tried setting switch to boot from ROM?  Or any of the weird memory locations you can choose from?
Due to how the machine normally functions I find it hard to believe that you just stick the board in and it will just
work on it's own.

[mikkohoo]

I've tried booting from "STD" and the different "SCSI" options. I will try the "ROM" options next.

What you are saying is completely logical and makes a lot of sense. It would make even more sense if the machine hadn't worked out of the box (empty SRAM, been sitting for years) without me having to do anything. I plugged the board in, booted from the Master Disk to see if the partitions are there (they were), rebooted and it would... just work. I wouldn't be half as surprised about all of this if this wasn't the case.

[Jehuty]

I have the System Sacom Board in my X68000 too.
Under Switch.x i can select Boot - SCSI X (X is the Unit of my Aztec Monster) and it will boot from CF, but not from Floppy.
If i select STD the X68000 Boots from Floppy if one is inserted, otherwise it will boot from CF.

But i in the past i had some Trouble and under STD it won´t boot from CF so the Splash Screen Comes up.
I tried SCSI X and it worked. Switched again to STD and it worked too.
Don´t know why it won´t work that one time.

[mikkohoo]

I made some experiments again.

I tried every ROM and RAM area available on switch.x - no help. I set the SCSI ID to 0 and 3 and tried setting SCSI0 and SCSI3 respectively. The machine does not boot, and when I come back to switch, it has restored the previous value I had (STD or, say RAM $ED0100).

It seems to be refusing to save a SCSI ID as the boot medium. Every other value will be saved across reboots.

[SuperDeadite]

Considering you already have a working Master Disk, why not just use SxSI and the normal SASI port?
True SCSI has advantages for sure, but there are a few games such as V'Ball and New Zealand Story which will only run off HDD on a SASI machine.  On true SCSI they load too fast and freeze.  Also considering you have an Expert, if you want to add say RAM and MIDI, then you will need both those I/O slots.

[Jehuty]

Switch.x has resotred the previous value ?  Sure you saved the settings on exit ? Ohterwise theres a problem with the sram or the battery.
You could try to clear the Sram.

[mikkohoo]

Switch.x has resotred the previous value ?  Sure you saved the settings on exit ? Ohterwise theres a problem with the sram or the battery.
You could try to clear the Sram.

I did, because every other value is saved (tested by messing around with Eject etc.). I have replaced the battery as it was completely flat, the new battery holds a charge. I have run sramclr and disconnected the battery overnight, same results.

@SuperDeadite: This is what I will probably end up doing in the end, I already ordered the parts to build a SASI to SCSI cable. However, I've always liked to understand what's happening with my systems. It makes no sense that the setup worked fine and then stopped working altogether without any sign of trouble.

[leonk]

Did you see the guide I wrote a while back?

https://gamesx.com/wiki/doku.php?id=x68000:installing_scsi2sd_on_x68000_externally

I assume the expert is pretty much the same as my launch original x68000 so you just need to keep the following in mind:

- the external port on the system is SCSI. Not SASI. So just use it. No need for. SCSI card. I got mine connected externally and device sits in a nice 3D printed case.
- you need to install the SASI boot loader into SRAM (I like it! You can see the SCSI devices found st bootup)
- the SCSI2SD needs external power. SCSI-1 does not provide 5V in the cable

[mikkohoo]

I did see this, but it is no more of a silver bullet in this case. I'll need to look for an external SCSI cable and the setup becomes more complicated; installing the SCSI2SD inside the case would be optimal, as I intend to have the machine on display.

Anyway, I know there are different solutions available that would work, and I'll end up trying one of them this week. The original point of my post was to see how I could make something work again that did work, was convenient, and then stopped working out of the blue.

[leonk]

If things work, and then stop it's due to changes in the system.

At this point, I don't turn on an X68K unless the caps have been replaced. Bad caps can cause ICs and other components to fail .. no one should take the chance.

Do you know if your system had a full cap kit done?  Can you also confirm the SRAM has 3V on the Vcc line while the system is off?  My SRAM is backed by a simple CR2032 battery.  It will last for years and within spec. (OG X68K)

[mikkohoo]

The only change I initially made was turning the system off, storing it for less than 20 hours and turning it back on. This is why this makes no sense.

I did a full recap of the system myself as I was unsure whether anything had been done previously. It was already all Nichicon caps and I did not find a single one that was shorted or out of spec (measured each one with a Fluke multimeter). There was one that had clearly leaked, but it was on the video board.

I also replaced the SRAM battery. It stores settings just fine now.

[leonk]

Did you do the cap kit / SRAM battery after the issue, or before?

i.e. SRAM battery was replaced, it was working fine .. now it doesn't?  Can you provide more info on the battery you are using?

[mikkohoo]

I did all the work after the issue appeared. The SRAM battery was original and probably quite dead, when I took it out it measured 0.x volts. The new battery is a 3.6V 80 mAh NiMH, the one I took out was a NiCd with similar specifications.

[leonk]

are you able to see the SASI boot menu where it show all the scsi id it’s searching?

you need to get to that point first. the battery simply makes sure the sasi menu stays in sram.

[mikkohoo]

If I put the SASI menu in SRAM, it stays there. However, I did not need it originally with the SCSI board.

[leonk]

But given you’re using an internal solution, using flash media.. why even bother with a SCSI adapter? lots of info out there on making the custom SASI tom SCSI cable.

I know you’re set on internal. would be worthwhile to just validate that external works.

[mikkohoo]

Well, it appears that I have fixed the problem in an unlikely way.

Based on the recommendations herein, I started building the internal SASI to SCSI cable according to the wiki. This is because I had scheduled the machine to appear at an event tomorrow and would really like to forgo using floppy disks.

I got as far as where the SASI driver, upon loading, would access the SCSI2SD and hang the machine. This is probably due to my bad wiring; I had to recycle connectors as eBay was being slow and I couldn't find any locally.

As I had my homemade cable out for about the fifth time to look for missing contacts, the thought occurred to me to put the SCSI board back in while the SASI cable was completely disconnected. The System SACOM splash screen reappeared at boot, for the first time in weeks! I then booted off the Master Disk and played around in Switch. I noticed that it would not let me set SCSI ID and BOOT to the same setting, which told me that there's life in the controller. I set the internal SCSI ID to 0 and BOOT to SCSI3. The machine booted off the SCSI2SD and launched the file browser. Games would load just fine.

I don't know why I could initially have the cable connected, and now I cannot, but I also honestly don't care if it starts working permanently now. Which may or may not be the case, of course...