Author Topic: After a crash, X68000 XVI will no longer boot  (Read 770 times)

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
After a crash, X68000 XVI will no longer boot
« on: August 07, 2017, 12:55:50 AM »
Hi, I am seeking advice about what I can do about my XVI...

Before we start, I want to note that I have had this machine for about 3 months and it has been fully functional during that time (used maybe 1-2 times a week).  Got it off Yahoo Japan, and the seller stated that the system and PSU were fully recapped and the battery replaced with a CR2032 holder.  As far as I can tell from examining the machine, that is all true.

Yesterday I was just running MMDSP when the X68000 randomly hung.  After resetting it, I receive the message shown on the SRAM Issues wiki page. ("Error. Please reset the computer.")  So of course I go and check the battery... yep, it's on the borderline between alive and dead, with a low voltage.  It's conceivable it just happened to die right now.  So I swapped in a new battery and reset the SRAM by holding CLR while booting.

However... the error persists.  And unlike the page states, I cannot bypass it in any way.  Resetting with a disk in the drive either brings the same message instantaneously, or the system will access the floppy for a second or two and then stop on a black screen.  If I boot without a floppy, I can get the normal "please insert a disk" message.  Inserting a disk at this point has the same result: either a black screen or the error message.  Last night I got a few disks to do something different-- they asked for human.sys instead, basically saying the disk wasn't bootable... but they were bootable disks so I dunno what the deal is there.  After resetting a few times it went back to the usual error message and I haven't seen it again.

Repeated SRAM clears also do not help-- in fact, sometimes the error message is overlaid on the SRAM clear dialog and the system locks up, keeping me from doing a reset!  That sounds really bad to me...

Also of note is that 16mhz mode is now completely broke.  Booting at 16mhz causes the error to be printed on the left side of the screen, split across several lines.  Same with the SRAM clear dialog.  I've tried a lot of things now, and I am completely stuck at this point, and absolutely livid that so much money is down the drain if I can't fix this.  :(  What the heck happened!?

Here is everything I have tried:
-Replaced SRAM battery
-Cleared SRAM multiple times
-Attempted to boot the C Complier disk mentioned on the wiki page and reset SRAM that way (obviously, can't even get the disk to boot...)
-Removed SRAM battery, unplugged machine, left overnight in case the SRAM was badly corrupted
-Re-seated the expansion card riser based on some advice I received
-Re-seated all cables
-Swapped floppy drives

Does anyone have some insight, or do I now have a giant doorstop?

Offline Pinwizkid

  • BigMember
  • ***
  • Posts: 86
    • BrendanBailey.net
Re: After a crash, X68000 XVI will no longer boot
« Reply #1 on: August 08, 2017, 12:05:29 AM »
Has the rest of the unit been capped? There are a few caps on the motherboard and a whole bunch on the interconnect board in the base. I'm not sure if your issue is directly related, but it's a good idea to do them as those caps are hitting the age where they will die and possibly leak. I just capped mine recently, it's a bit time consuming, but they are all gonna need to get done sooner or later.

Good luck and don't give up!

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
Re: After a crash, X68000 XVI will no longer boot
« Reply #2 on: August 08, 2017, 07:20:06 AM »
Crap.  Good thing I saved the translated version of the auction text... turns out my memory was wrong, JUST the power supply was recapped.  Bottom board was cleaned and the battery holder added but not recapped.  So that leaves everything else needing some attention then.  A quick inspection of the boards didn't show anything obviously leaking, but I know that means nothing in the whole scheme of things.  Unfortunately, I don't trust myself enough with a soldering iron to try recapping this guy, considering I can barely solder wires to battery terminals on the old 486s I've done without making a mess, so I'll have to find someone to help me out.

I'm hoping that isn't the immediate issue though, considering that it was fully functional 60 seconds beforehand.  I find it hard to believe that there would be a catastrophic failure like this due to caps, it's usually a more gradual issue.

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
Re: After a crash, X68000 XVI will no longer boot
« Reply #3 on: July 05, 2018, 11:14:46 AM »
I'm bumping this topic with an update.

Today I finally recapped the entire XVI, every cap I found.  On the plus side, no signs of leakage anywhere.  Unfortunately, the recap has resulted in absolutely zero improvement to the problem.  Not even a slight change in the behavior.  At this point I am inclined to believe it is beyond saving.  Probably an actual chip somewhere is no longer working, but I have no idea how to possibly troubleshoot it any further.

If anyone has any additional ideas, I'd love to hear them, but otherwise I'm probably going to throw up a want ad for a new system unit or something, maybe use the PSU from this one as a donor since it's recapped.  Not sure I'm ready to deal with Yahoo Auctions again.

Offline Pinwizkid

  • BigMember
  • ***
  • Posts: 86
    • BrendanBailey.net
Re: After a crash, X68000 XVI will no longer boot
« Reply #4 on: July 06, 2018, 12:34:48 AM »
I'm bumping this topic with an update.

Today I finally recapped the entire XVI, every cap I found.  On the plus side, no signs of leakage anywhere.  Unfortunately, the recap has resulted in absolutely zero improvement to the problem.  Not even a slight change in the behavior.  At this point I am inclined to believe it is beyond saving.  Probably an actual chip somewhere is no longer working, but I have no idea how to possibly troubleshoot it any further.

If anyone has any additional ideas, I'd love to hear them, but otherwise I'm probably going to throw up a want ad for a new system unit or something, maybe use the PSU from this one as a donor since it's recapped.  Not sure I'm ready to deal with Yahoo Auctions again.

That's a bummer :( I went through a similar situation when my audio died. I figured it was a cap somewhere and rather than just diagnosing which one and replacing just one, I decided to just do all of them since it would need to be done eventually anyway. When I had everything back together, my audio was still dead and it turned out to just be a flaky connection between the power supply and bottom board. In the end, I'm glad I recapped the board, but what a frustrating moment it was when I first reinstalled the re-capped board to see no improvement.

Hopefully you will be able to get this working eventually or find a replacement. Good luck!

Offline DMR

  • SmallMember
  • **
  • Posts: 5
Re: After a crash, X68000 XVI will no longer boot
« Reply #5 on: July 06, 2018, 12:42:52 PM »
Did you end up teaching yourself soldering skills to recap? Or did you outsource it? In any regard, that's awesome,
because after you fix the real issue, you won't have to worry about the caps for another 20 years.

Though don't give up just yet on this computer. It'd be a shame if you did given that they're so rare!

I'm not that knowledgeable on the x68k yet,
but I wonder if one could find a dumped XVI IPL (Initial Program Loader) that's been disassembled or one could disassemble it.

The error message "エラーが発生しました。リセットしてください。" probably exists in there in another encoding,
and you could see the logic that results in the error and work from that angle.

Another angle might be to try to find a custom one that prints out better error info.

In fact, this lead me to this thread where someone has already disassembled and made their own version:
https://nfggames.com/forum2/index.php?topic=5503.0

And in the same thread someone posts similar issues to yours,
and lydux's advice seems to be:

"I'm strongly suspecting a bad (corroded) trace or cable around IOSC chip on I/O board."

But that doesn't seem to be the case for the person in the thread,
though looks like the custom IPL solution would have been the winner to diagnosing a bunch of x68k issues.

Though it looks like there's been no word from lydux since 2015... I hope they're alright.
But it also doesn't look like they open sourced their work, which means anyone new has to start from scratch. Bummer.


« Last Edit: July 06, 2018, 12:46:01 PM by DMR »

Offline Spitko

  • SmallMember
  • **
  • Posts: 32
Re: After a crash, X68000 XVI will no longer boot
« Reply #6 on: July 06, 2018, 05:57:35 PM »
You might want to spend some quality time with a meter checking all of the traces around the damaged part of the PCB.

Powering a circuit with corrosion damage can accelerate the process, destroying traces that had previously worked. Cleaning the PCB helps prevent this, but we don't know how well the cleaning was done,and how badly the board was originally damaged.

Check every trace that goes near or through the affected area. Also look for other affected parts of the PCB; any place a cap is (was) should be considered suspect. You might even get lucky and just find a corroded solder joint that can simply be reflowed.

If you've done all that and still no dice, time to start probing.

The SRAM chip in an xvi should be a pair of Panasonic MN4464S. It's surprisingly hard to find datasheets on these old things, but we have schematics for the 68k, which is good enough.

Check that Pin 28 is connected to vbatt (ie, the positive terminal of your battery holder), and pins 14 and 20 are grounded. Then inspect the remaining traces to ensure none are corroded.

If the chip legs have corrosion on them, it's possible the SRAM itself bit the dust. Unfortunately, there's no easy way to manually clear the SRAM on these chips, the 68k itself needs to do it. Pin 1 is the reset pin for a few variants of this chip, but the panasonic models were not of that persuasion, and left it unconnected.

Unfortunately, past that it starts getting into logic analyzer territory, so hopefully it's either a simple broken trace, or someone else chimes in.

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
Re: After a crash, X68000 XVI will no longer boot
« Reply #7 on: July 07, 2018, 10:43:06 AM »
Dunno where you got the idea that there's PCB damage.  All the boards are in good shape!  However, I think I am going to start going at it with the ol' multimeter and see if there is anywhere that might have a corroded trace.  I think it may be possible, as the metal shielding at the bottom of the right-side tower arrived with some rust on it.  I didn't see any damage on the board, but it could be something less obvious.  I think I might also reflow the solder joints just to be sure there aren't any cold joints.

Reading that older thread it did give me the idea to try accessing the serial debugger.  Booting up the system with OPT2 held down did allow me to see serial output!  I am not really sure what the expected behavior is, though.  Loading the serial console with no disk inserted gets me to this:

Code: [Select]
ROM debugger Ver 1.0
Copyright Hudson soft 1987

        NMI break at 00FF0010
PC=00FF0010 USP=FFFFFFF7 SSP=00002000 SR=2000 X:0  N:0  Z:0  V:0  C:0
D  003A0010 00000024 00000000 00000400  00000000 FFFFDFFF 0000FFFF FFFFFFFF
A  00ED0100 00FF08E8 10FE3BD8 00FC006C  00001120 FFFDFEFF 00001FFC 00002000
move    #$2700,SR
+

There is a message on the screen different than usual.  Translating it with the Google Translate app on my phone it says roughly "Cannot boot disk, terminal should be closed".  I think this is normal as I didn't give it a boot device.

However, booting it WITH a disk inserted, the disk does its normal reading sound ("click", "thud", whatever you want to call it) four times before this appears in the console:

Code: [Select]
ROM debugger Ver 1.0
Copyright Hudson soft 1987

Exceptional Abort By undefined instruction at 000068A8
PC=000068A8 USP=FFFFFFF7 SSP=10006800 SR=2019 X:1  N:1  Z:0  V:0  C:1
D  00000000 FFFFFFFF 0000DC7A FFFFFCBA  BBFF00BF FFFFDFFF F7F7EFFB 00009070
A  0000DC7A 00006800 0001447A FFFFFFFF  00002136 00002128 000021FC 10006800
 undefined instruction $71CA
+

I should note, the four reading "clicks" before displaying the error message is the exact same behavior I have been describing up to this point without the console.  So I think this is an equivalent to the generic error message I've been getting, as it occurs at the exact same spot in the loading process.  I did try to see if I could step past it via the debugger, but I could not.  If I run the system at 16mhz instead of 10mhz, I get the ROM debugger's copyright message, but no further lines appear unless I press the interrupt button.  The system ends up at some random RAM address further up (00FF9D42 last time I tried) and after a while of poking around it starts receiving random letters instead of what I type.  Possibly an issue with the timings?  Do the oscillators on these systems go bad?

I can't make heads or tails of this, as I don't know enough about the X68000's architecture, let alone 68K assembly, but maybe someone more knowledgeable can use this information to help identify the problem.  In the mean time I am going to try what I described above to see if a bad trace or cold solder joint might be confusing the system and making it receive a bad instruction like this.

Did you end up teaching yourself soldering skills to recap? Or did you outsource it? In any regard, that's awesome,
because after you fix the real issue, you won't have to worry about the caps for another 20 years.

I did it myself!  I practiced on some old motherboards that needed done, and while I'm not going to say I'm a professional at it, I've really improved to the point that it doesn't feel like I'm going to damage anything when I try.  And considering this XVI still turns on, I can't be doing too poorly!

EDIT:  Just got this one while trying to boot from disk.  Bus error this time.  Still sounded the same hardware wise, but a different message.  Just adding it here for informational purposes.

Code: [Select]
ROM debugger Ver 1.0
Copyright Hudson soft 1987

Exceptional Abort By bus error
 By Memory Access of FFFF9598
 at   00007924  move.w  #$0000,$9598.w

system status =  I/N=I R/W=W FC=5
PC=00007924 USP=FFFFFFF7 SSP=000067FC SR=2014 X:1  N:0  Z:1  V:0  C:0
D  000000AF FFFFFFFF 0000DC7A FFFFFCBA  BBFF00BF FFFFDFFF F7F7EFFB 00009070
A  00002000 00006C00 0001447A FFFFFFFF  00002136 00002128 000021FC 000067FC
move.w  #$0000,$9598.w
+

Also going to include the "help screen" in case someone has an idea of commands to try.  I am at least trying to read out some memory locations using the wiki's memory map as a guide.  I may also try clearing the SRAM space this way instead of the CLR key just to see if it's severe corruption.

Code: [Select]
A                :assemble                R address,drive,sector,length
B                :display breakpoint                            :read device
B[bp][address]   :set breakpoint          S[size]<range> data   :search memory
BC[<bp>]         :clear breakpoint        T[=address][count]    :trace
BE[<bp>]         :enable breakpoint       U[=address][count]    :untrace
BD[<bp>]         :disable breakpoint      W address,drive,sector,length
BR               :reset break count                             :write device
D[size][<range>]        :dump memory      X        :display register
E[size][address]        :edit memory      X[reg]   :register change
F[size] <range> data    :fill memory      Y/N      :yes no ask
G[=address][adress]     :go               Z[num=exp]  :system variable
H                       :display this     ?[exp]   :print expression(hex)
HI                      :trace history    ??[exp]  :print expression(dec)
L[<range>]              :list             \        :loop command line
M <rang> address        :move memory
« Last Edit: July 07, 2018, 10:54:43 AM by MrKsoft »

Offline neko68k

  • MassiveMember
  • ****
  • Posts: 359
Re: After a crash, X68000 XVI will no longer boot
« Reply #8 on: July 08, 2018, 12:22:46 AM »
Maybe your floppy drives or your RAM. The first boot is pretty normal looking. The second one with the error suggests it either got the wrong data back from the floppy drive or it is corrupted in RAM. Since it's booting the debug monitor I'd guess it's your floppy drives or cables. Did you recap the floppy drives? Some of them need it. I've heard some people have re-greased the drive and re-aligned the heads but I don't know the details.

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
Re: After a crash, X68000 XVI will no longer boot
« Reply #9 on: July 08, 2018, 07:39:51 AM »
I don't think it's the floppy drives as the same issue occurs if I try to boot an external SCSI2SD which has X68000_V4.HDS written to it.  (Although I get the translated version "Error.  So reset please.")

RAM is a possibility though.  I did check around all the chips and they do not appear to have any damage or corrosion.  I also found that using the debugger I couldn't actually overwrite the memory addresses for the SRAM with 0's as I wanted to try-- nothing would happen.  I compared the values that were in memory to an SRAM file from an emulator and they looked okay for the first few bytes and then the rest appeared to be garbage.

However I found a couple interesting areas of the main board that appear to be bodged in various ways...

https://i.imgur.com/e1RKw4V.jpg - The ALS373 latch at IC90 has pins 6 and 7 ("3Q" and "3D" signals according to the datasheet) detached from the chip and soldered together.

https://i.imgur.com/ff7MhNW.jpg - Two ceramic caps/resistors? (not sure, they are only marked with "47") on the backside of the board.  One is soldered from C150 to pin 6 on IC16 (which is a SN74AS1004AN hex inverting driver... the signal on that pin is labelled 3Y).  The other one is soldered from pin 4 of that same SN74AS1004AN (signal labelled 2Y) to pin 10 of IC19 (which is a SN74AS245N octal bus transceiver... and pin 10 is ground).

Anyone know if those are normal?  I know there are often fixes done to PCBs at the factory, but these don't look quite as professional to me.  According to the schematics they also seem to be within the paths that, to me, might relate to the issues (namely the ALS373 is hooked up to a few more ALS373s which are connected to the DMA controller, and the bodges on the bottom side to a bus driver which is connected to the main RAM, VRAM, etc).

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
Re: After a crash, X68000 XVI will no longer boot
« Reply #10 on: July 13, 2018, 12:16:25 PM »
Updating again with further findings.

Screwing around with the ROM debugger I went back to the Exceptional Abort at 68A8 and compared it to a boot from the same image in XM6 Pro-68k, setting up a break when the PC register hit that address.  The instruction it SHOULD be loading is $61CA but on the XVI it is reading $71CA.  Comparing the binary values of this, I found that the difference was a single bit... so it looks like the bit is flipped.  (0110 0001 1100 1010 for the correct instruction vs 0111 0001 1100 1010 for what the XVI loads into memory)  So great... looks like a memory problem.

So I downloaded memtest68k since I noticed that it did not rely on Human68k to boot.  I figured as a small program it might be able to get past this spot okay.  It didn't boot though, however it seems to have confirmed my suspicions regardless.  The system halts and gives the message "Checksum failed; program is corrupt or didn't load properly".  Except that it actually said: "Checksum fqiled; program is corrupt or@did~'t load properly".  That seems to point very strongly towards a memory problem, or at least something that is messing up the data from the drive as it gets put into memory.  I'll be double checking the drives (same thing happens with both drives which both previously worked, so I assume it is not the drives themselves, but possibly the cable is damaged?) and also looking back at that thread DMR linked and investigating the IOSC chip more closely as was suggested in that case.

I think I'm leaning towards an I/O related problem as if I change memory addresses using the debugger, they do seem to stick even at the problematic addresses.  I suspect if I were really patient I could probably use the debugger to overwrite the entire memory with a snapshot from an already booted system and it would work, but until I think of a good way to automate that I'm not going to try.   :P

Offline DMR

  • SmallMember
  • **
  • Posts: 5
Re: After a crash, X68000 XVI will no longer boot
« Reply #11 on: July 13, 2018, 01:16:48 PM »
Awesome progress! It’s likely others will run into a similar issue and your findings will be very helpful!

I was wondering if there might be any alignment in the errornous bits (like the error repeats every x bits).
From a quick glance it looks like no, but it might be that the bit only corrupts if one of the neighbors is 1.

If it was a floppy cable issue, I’d expect to see alignment.

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
Re: After a crash, X68000 XVI will no longer boot
« Reply #12 on: July 14, 2018, 05:00:30 PM »
Well, I found the pattern.  Looks like we have a completely stuck bit.  Using the breakpoint at 68A8 I further compared the memory from the XVI versus XM6 Pro-68k. 

Using $68A8 as a start point, I found that every 8th word (or every 128 bits), the 4th bit of that word is stuck as a 1.  An example in the code block below illustrates this (note it only shows those specific words to keep things brief)

Code: [Select]
bad x68000
71ca (0111 0001 1100 1010)
15b8 (0001 0101 1011 1000)
d139 (1101 0001 0011 1001)
1304 (0001 0011 0000 0100)
1254 (0001 0010 0101 0100)
1ec8 (0001 1110 1100 1000)
3f3c (0011 1111 0011 1100)
7100 (0111 0001 0000 0000)
5ff9 (0101 1111 1111 1001)
7021 (0111 0000 0010 0001)
70f6 (0111 0000 1111 0110)
7100 (0111 0001 0000 0000)
1219 (0001 0010 0001 1001)
101d (0001 0000 0001 1101)
1c15 (0001 1100 0001 0101)
1018 (0001 0000 0001 1000)
1018 (0001 0000 0001 1000)
325f (0011 0010 0101 1111)
10c0 (0001 0000 1100 0000)
7220 (0111 0010 0010 0000)

emulator
61ca (0110 0001 1100 1010)
15b8 (0001 0101 1011 1000)
d139 (1101 0001 0011 1001)
0304 (0000 0011 0000 0100)
0254 (0000 0010 0101 0100)
0ec8 (0000 1110 1100 1000)
3f3c (0011 1111 0011 1100)
6100 (0110 0001 0000 0000)
4ff9 (0100 1111 1111 1001)
7021 (0111 0000 0010 0001)
60f6 (0110 0000 1111 0110)
6100 (0110 0001 0000 0000)
1219 (0001 0010 0001 1001)
101d (0001 0000 0001 1101)
0c15 (0000 1100 0001 0101)
1018 (0001 0000 0001 1000)
1018 (0001 0000 0001 1000)
225f (0010 0010 0101 1111)
10c0 (0001 0000 1100 0000)
7220 (0111 0010 0010 0000)

And well, I guess that's that.  I am not sure what is causing the stuck bit, as I see various differences across the memory space.  Manually editing the memory in the debugger to match the emulator, I can get the "wrong" data starting at $68A8 to correct itself.  Then setting the PC register back to $68A8 I can actually get it to move a bit further.  Unfortunately it hits more bad instructions later on in the $78B4 range, and these ones are not on the same word boundary that I had identified earlier.  It's still the same 4th bit that's stuck though.  And on these ones editing the memory in the debugger does not change that bit.  I can change the value but that 4th bit sticks to a 1.  So I can't patch the memory over and over and force it to boot.

So I guess the next question is what to do next.  It could be as "simple" as bad RAM, but there isn't really much I can do about that (I doubt I can get a new compatible chip and the RAM chips are surface mounted which I don't have the kit to handle).  If we want to look at other causes, I was thinking it could be something with the PEDEC (XVI equivalent of IOSC) garbling data that is sent through it, but I am not sure as the schematic is complicated for me to read and I can't tell if the SCSI signals pass through it or go around it (which is important as this affects both floppy and SCSI booting).  I did try testing the continuity of the pins between the PEDEC and the cable where its signals leave the I/O board but they all checked out fine.  It doesn't look like the weird bodge on IC90 is the problem either - it's wired up to the VICON and CYNTHIA chips which worked completely fine when the system was functioning.  I also checked the continuity on all the cables from the I/O board to the main board, floppy drives, SCSI, etc... and none of this explains why the 16mhz mode is all glitched up.

Whatever the cause, it's definitely something deep down in the hardware, and it's probably not something I can repair.  I think I've exhausted just about everything I can do with my current experience and equipment.
« Last Edit: July 14, 2018, 05:07:35 PM by MrKsoft »

Offline DMR

  • SmallMember
  • **
  • Posts: 5
Re: After a crash, X68000 XVI will no longer boot
« Reply #13 on: July 15, 2018, 01:14:08 AM »
Awesome!

Type of fault you're looking at is something along the lines of:
OUT_D_3=(!A_6 & !A_5 & !A_4 & !A_3 & !A_2 & !A_1 & !A_0) | MEM_D_3(A_ALL)

The RAM chips (HM514402) are 1024 "words" x 4bits each, and there's only 4 of them.
Each 16-bit word request hits each RAM chip.

Given the pattern is every 128bits... it might not be the RAM chip, but it's possible the address decoder inside the RAM chip is busted...
If there is a fault, it'd be IC24 (if I'm reading the schematics right), since it's the 4th bit.

Can you put a scope on its I/O4 pin (there's got to be a data sheet for it somewhere), and just keep reading every 16th word?
See if it stays a solid 1.

Also have you tried reading unassigned memory areas? To see if they return a 1?
How about if you read the SRAM?
« Last Edit: July 15, 2018, 01:33:53 AM by DMR »

Offline MrKsoft

  • SmallMember
  • **
  • Posts: 9
Re: After a crash, X68000 XVI will no longer boot
« Reply #14 on: July 15, 2018, 10:43:02 PM »
I don't have a scope unfortunately, despite knowing the basics I have basically never dug this deep into electronics troubleshooting.  For now I'll have to make do with what I have...

I started testing random areas of RAM and I am getting inconsistent results.  I used a RAM dump from XM6 Pro-68k to find areas that should be unassigned and started trying to write F's to the area and then overwriting those with 0's using the debugger.  I have yet to find a working range, but what is really illuminating here is that there are different areas with different issues.  They all revolve around the 4th bit, but it's often different words with the problems.  And some of them are stuck to 0 instead of 1!!

Examples:
$112000-$1120ff:
every 8 words, 4th bit stuck as 0 on 1st and 7th words

$1c0000-$1c00ff:
every 8 words, 4th bit stuck as 1 on 3rd and 5th words

$1f0000-$1f00ff:
Crazy inconsistent, but revolving around 4th bit stuck as 0 instead of 1.  Might as well just lay it out every 8 words:
$1f0000: 1st and 7th word, 4th bit stuck as 0.
$1f0010: GOOD
$1f0020:1st word, 4th bit stuck as 0.
$1f0030: 1st word, 4th bit stuck as 0.
$1f0040: GOOD
$1f0050: 1st word, 4th bit stuck as 0.
$1f0060: GOOD
$1f0070: GOOD
$1f0080: 7th word, 4th bit stuck as 0.
$1f0090: 7th word, 4th bit stuck as 0.
$1f00a0: 1st and 7th word, 4th bit stuck as 0.
$1f00b0: 7th word, 4th bit stuck as 0.
$1f00c0: GOOD
$1f00d0:1st word, 4th bit stuck as 0.
$1f00e0: GOOD
$1f00f0: GOOD

Actually, I just dumped that range again after typing this up and it's changed with additional 7th word, 4th bit errors.  Then I dumped it again and it changed again, with some of those disappearing.  It seems the memory is not staying stable either.  What a mess!

I should note, I have yet to see any issues on even numbered words.  That seems very important.

Regarding the SRAM, I am able to read out portions of it and they appear OK with all 0's.  I cannot edit them to check whether any bits are stuck -- not sure if I should be able to via the debugger or not.  I can do the command (for instance e ed0000 ffff ffff ffff ffff ffff ffff ffff ffff) and it takes it but dumping the same address brings back exactly what it was before.

Offline JulBS0

  • SmallMember
  • **
  • Posts: 12
Re: After a crash, X68000 XVI will no longer boot
« Reply #15 on: Today at 07:07:11 AM »
Hi,

About the SRAM, the behavior you are experiencing is normal.

The system controller write-protects the SRAM most of the time (probably to prevent nasty things that might happen when the computer is unplugged).

To enable writes, write 0x31 as a byte at 0xe8e00d.