SBC6120 - IOB6120 FLASH trouble

[thunter0512]

I bought a fully assembled SBC6120 with FP6120 and IOB6120.
The IOB6120 has the "Battery Backup Fix Version 1".
The system is partially functional, but I cannot download a new FLASH image using the FL command.

On startup it says:

---
SBC6120 ROM Monitor V266 Checksum 1254 5023 6317 03-JUL-03 08:01:32
Copyright (C) 1983-2003 Spare Time Gizmos. All rights reserved.

ROM: Error 2
NVR: 2048KB
IDE: Not detected
---

When doing the "FL" download it aborts when it writes the first block.

---
:0000.360/ 300 244 257 325 277 256 205 376
:0000.370/ 274 201 036 174 375 014 162 326
:1363
?I/O Error 3000
---

Reading the code (BTS6120.plx) I believe the "Error 3000" means that it has written the FLASH block, but the verify fails at offset zero.

There was a bad solder joint (disconnected) on one of the FETs used in the "Battery Backup Fix Version 1" which I fixed. Since then it reports the "NVR: 2048KB".

I also carefully reflowed the FLASH chips solder joints because at least two looked marginal.

The FLASH appears to be somewhat functional because reading the code it looks like it check first that the FLASH chip is actually there by switching into "read ID" mode and back into "array read" mode which seems to succeed because only after that will it ask "Overwrite flash?" otherwise there would be an error message.

Any ideas how I could find the cause of this problem?

Thanks and best regards
Tom Hunter

[kb811]

Assuming there isn't a hardware problem... then one possible cause is:

There is no flow control and the actual flash programming is somewhat slow to commit each section, both of which result in it missing characters if they are sent "too fast", which then results in an error being reported.

When I FLed the IOB6120, I found the best way to, quickly, deal with the problem was to run things at the slowest baud rate with a delay (it might have been 1 or 2 seconds) after each line has been sent, and let it run overnight!

I almost wrote a program to do this in a better way; but resorted to using code from the net which I modified and used from a command prompt on Windows 10. It was bit of a lash-up/Heath Robinson thing; but I was only expecting to do it the once "for now" and wanted to get things underway!
I assume I have saved this somewhere, so I can probably dig out more details if you need them.

I am using the SBC6120-RBC: which also has a slightly newer ROM (but I don't think it matters for the particular issue I am describing):

SBC6120 ROM Monitor V320 Checksum 3752 6072 3515 09-APR-10 21:15:39
Copyright (C) 1983-2010 by Spare Time Gizmos.  All rights reserved.

NVR: 2048KB
IDE: Not detected
CFC: 961MB - SQF-P10S1-1G-EC6
IOB: ROM V0114, FPGA V0111
C/C: 06/03/21 17:06:31

>

[thunter0512]

Thanks for the suggestion.

I have already slowed down to 1200 bps and used c-kermit's "set transmit pause 50" to add a 50 ms delay after each character sent.
I actually don't believe the Windows version of c-kermit I am using is implementing this properly as the "transmit" speed seems unchanged depsite the pause.
Anyway 1200 bps is pretty slow and if I read the code right an entire block is buffered in RAM and then written to FLASH.

It always reports "Error 3000" where the last thre digits are the offset where the compare after write has failed.
So it always fails on the first byte of FLASH.

It would be nice to be able to dump FLASH to see what it has actually written - if anything.

The SMD FLASH part has such a fine lead pitch that it would be impossible to hook up a logic analyser to see what is happening.

It is a lot easier to debug the LAB-8/E - everything is nice an visible and through-hole.

Thanks
Tom Hunter

[kb811]

Okay.

I checked what I did though: I also ran it at 1200, but "crucially" there was a 1 second delay after each line (which seemed to be the thing that was needed to prevent it erroring out). There does not seem to have been a need for a delay between individual character on a line.

[thunter0512]

Okay.

I checked what I did though: I also ran it at 1200, but "crucially" there was a 1 second delay after each line (which seemed to be the thing that was needed to prevent it erroring out). There does not seem to have been a need for a delay between individual character on a line.

I tried the 1 second delay after each line using TeraTerm and even tried 2 seconds but the symptom remains the same. It fails on the first byte of the first block.
The file FLASH.DL uses CR/LF Windows line terminators. I tried converting to Unix style LF only line terminators and that made no difference.

I suspect this is a hardware issue. Is there some way to write/read the NVRAM using the SBC6120 monitor commands?
The NVRAM shares most signals with the FLASH chip so I could check for shorted address or data lines if I figure out how to exercise the NVRAM.

Thanks for your help.
Best regards
Tom Hunter

[kb811]

I tried the 1 second delay after each line using TeraTerm and even tried 2 seconds but the symptom remains the same. It fails on the first byte of the first block.
The file FLASH.DL uses CR/LF Windows line terminators. I tried converting to Unix style LF only line terminators and that made no difference.

1 second delay: I am sure the 1 second delay is more than long enough; as my "load process" was only needed (probably) the once I didn't try to analyze how large a delay it needed as it would take a very long time anyway - so 1 second it was.

If "TeraTerm" allows a "prompt", then the prompt character is ":". That should eliminate the need for a delay... but it likely still needs to loaded at 1200 baud. If one were doing this a frequently then there is a better way (but it requires effort to implement).

I used CRs. I don't think it minds which is used; but it breaks if the file data are sent using CRLF.

I suspect this is a hardware issue. Is there some way to write/read the NVRAM using the SBC6120 monitor commands?
The NVRAM shares most signals with the FLASH chip so I could check for shorted address or data lines if I figure out how to exercise the NVRAM.

It think it could be worth double checking the mezzanine connectors and that the boards are not shorting (the crystals on my SBC6120-RBC are in sockets and stick up quite a way).

Remove any Compact Flash card just in case...

Did you verify the system memory is okay?

A quick NVRAM test might be to use the RAM disk commands... Note that the following is based on an SBC6120-RBC with ROM version "SBC6120 ROM Monitor V320 Checksum 3752 6072 3515 09-APR-10 21:15:39" and a fully a functional (as far as I know) IOB6120 (in case that matters; ROM extensions).

Zero out the first block of the first RAM disk partition (enter the command "RL 0" and then the data lines as shown, end it with a carriage return on the line after the checksum, which is "0000" for this first example).

>RL 0
0000.000/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.010/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.020/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.030/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.040/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.050/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.060/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.070/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.100/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.110/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.120/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.130/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.140/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.150/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.160/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.170/ 0000 0000 0000 0000 0000 0000 0000 0000
0000
<CR>
??

Note: <CR> means entering return to "exit" the RL command.

If you dump the block it should hopefully contain zeroes:

>RD 0 0000 0001
0000.000/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.010/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.020/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.030/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.040/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.050/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.060/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.070/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.100/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.110/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.120/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.130/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.140/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.150/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.160/ 0000 0000 0000 0000 0000 0000 0000 0000
0000.170/ 0000 0000 0000 0000 0000 0000 0000 0000
0000
>

Set all the bits in the first block:

>RL 0
0000.000/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.010/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.020/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.030/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.040/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.050/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.060/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.070/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.100/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.110/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.120/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.130/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.140/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.150/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.160/ 7777 7777 7777 7777 7777 7777 7777 7777 
0000.170/ 7777 7777 7777 7777 7777 7777 7777 7777 
7600
<CR>
??

Dump that out to check:

>RD 0 0000 0001
0000.000/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.010/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.020/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.030/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.040/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.050/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.060/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.070/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.100/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.110/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.120/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.130/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.140/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.150/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.160/ 7777 7777 7777 7777 7777 7777 7777 7777
0000.170/ 7777 7777 7777 7777 7777 7777 7777 7777
7600
>

"Format" the first RAM disk partition with a test pattern (which it reads back to check):

>RF 0
Format unit/partition 0000 ?Y
Writing .................... Verifying .................... Done
>

Dumping the first block should "probably" then give:

>RD 0 0000 0001
0000.000/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.010/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.020/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.030/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.040/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.050/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.060/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.070/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.100/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.110/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.120/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.130/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.140/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.150/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.160/ 2600 5177 2600 5177 2600 5177 2600 5177
0000.170/ 2600 5177 2600 5177 2600 5177 2600 5177
7700

An additional hardware test might be to see if you can boot off of a Compact Flash card in the CF slot:

>PM 0 7700
>B
-IDA0

SBC6120 OS/8 -- RETROBREWCOMPUTERS.ORG
BASED ON PIDP-8/I PKG:1 - OS/8 V3D - KBM V3Q - CCL V1F
PREPARED BY WILL SOWERBUTTS <WILL@SOWERBUTTS.COM> 2017-12-28

Restart address = 07600

Type:
    .DIR                -  TO GET A LIST OF FILES ON DSK: (IDA1:)
    .DIR SYS:           -  to get a list of files on SYS:
    .DIR IDA2:          -  TO GET A LIST OF FILES ON IDA2:
    .R PROGNAME         -  to run a system program
    .HELP FILENAME      -  to type a help file

.

To map at least the first 4 "IDA" partitions to the CF card (which is probably "normal usage"):

PM 0 7700
PM 1 7701
PM 2 7702
PM 3 7703

If you don't have a [digital] microscope or jeweler's loupe: the macro mode on your phone camera might be sufficient to get a good shot of the fine pitched devices if you want to look for shorts or similar issues...

I bought a fully assembled SBC6120 with FP6120 and IOB6120.

If it was shipped as working, then hopefully it will be something simple to sort. Is it an "original" set?

[thunter0512]

If it was shipped as working, then hopefully it will be something simple to sort. Is it an "original" set?

Thanks for all the info.

This original SBC6120 was sold as known faulty. I am happy to have it despite the IOB6120 problem and will fix it.
Having said that, for me this is a new and relatively complex device and I am grateful for any help or suggestions to debug the problem.

Thanks and best regards
Tom Hunter

[thunter0512]

Previously my workbench was full with a LAB-8/E I have been repairing so I took a break from the IOB6120 debugging.

Last night and today I connected up my logic analyzer and got a complete trace of the FLASH programming trouble – except no address bus.
The logic analyzer has only 16 channels so I can’t trace it all.

Here is what I see.

After the FL command it does the following:
• writes “reset to read array mode” - 0xFF;
• two reads – 0x08, 0xA3 ( actual FLASH data);
• writes “Read ID” 0x90;
• correctly reads back the Sharp LH28F400BVHE ID of - 0xB0, 0x5A;
• repeats the 4 items above one more time.


After starting the serial download no further FLASH transactions occur until the last byte + checksum of the first block have been sent over the serial port. It then does the following to write the first block to FLASH:
• writes “Clear Status Register” 0x50;
• writes “reset to read array mode” 0xFF;
• reads 0xE2 (actual FLASH data);
• writes “Block Erase” – 0x20, 0xD0;
• polls for “Block Erase” completion looking for MSB bit set (i.e. 0x80) ;
• writes “Byte Write” – 0x40;
• writes first data byte – 0xE2 (octal 342);
• polls for “Byte Write” completion looking for MSB bit set (i.e.0x80);
• repeats the 3 lines above for all bytes sent in the first block of the “FLASH.DL” payload except for the checksum;

Now that the first FLASH block has been written in tries to verify that the write has succeeded:
• writes “reset to read array mode” - 0xFF;
• reads what is meant to be the first byte written (i.e. 0xE2 or octal 342), but in reality it reads 0xFF – note that during the write the FLASH chip returned 0x80 to indicate that the write has successfully completed.

So basically the entire FLASH ID, erase and write machinery works exactly as expected, but the actual data read back after the entire block has been written indicates that the first byte is fully erased (oxFF) rather than the written 0xE2.

At this point the SBC6120 just reports “?I/O Error 3000” – saying the verify failed on the first byte.

I have hooked up my logic analyser to following signals:
• CPUDX[11..4];
• LOAD_DAR_H;
• FLASH_L;
• WRITE_L;
• READ_L.

All of them on the 50 pin SBC header except the FLASH_L signal which is on pin 14 of the 74ACT138D (1 out of 8 decoder) which decodes EMA[2..0].

My logic analyzer is limited to 16 signals so I cannot capture the MA[11..0] signals as well.

Clearly FLASH is working but when you try to verify data that has been successfully written (the status poll returned 0x80) the data appears to be still erased.

My LOAD_DAR_H capture is not quite complete and I didn’t manage to reconcile that fully with the other transactions, but it looks like the following:
• after the FL command it sets address latch to: 0x8F and possibly other values and then ends up at 0x86;
• when serial data starts arriving it sets the address latch to 0xF5 and then ends up at 0x86;
• after the last byte has been written and FLASH has been set back to “read array mode” (0xFF), it sets the address latch to 0xC6.

Now the address latch setting of 0xC6 just before the verify is obviously different from the value 0x86 just before the write of the first byte, so this would explain why it is reading 0xFF rather than 0xE2 during the first verify read. But why would it set the address latch wrong (only for the verify)?

Any ideas how to debug/analyze this further?

Thanks and best regards
Tom Hunter

[kb811]

Any ideas how to debug/analyze this further?

I don't own a logic analyzer; so cannot verify what you might expect to see.

Because you are trying to program the flash on the IOB6120 and also stated that "this original SBC6120 was sold as known faulty", I am wondering if they ever worked together and if the IOB6120 was ever working? If not,

• Is the SBC6120 fault fixed/a possible cause?
• It might be worth checking the IOT1 GAL; this device needs updated programming for the SBC6120 to work correctly with the IOB6120. I have not tried running mine with the old IOT1 programming, so I don’t know what the symptoms of using the old programming actually are.

[thunter0512]

I don't own a logic analyzer; so cannot verify what you might expect to see.

Because you are trying to program the flash on the IOB6120 and also stated that "this original SBC6120 was sold as known faulty", I am wondering if they ever worked together and if the IOB6120 was ever working? If not,

• Is the SBC6120 fault fixed/a possible cause?
• It might be worth checking the IOT1 GAL; this device needs updated programming for the SBC6120 to work correctly with the IOB6120. I have not tried running mine with the old IOT1 programming, so I don’t know what the symptoms of using the old programming actually are.

If I understood the seller correctly the systems was working many years ago, but when he tried it just before he sold it, the terminal & keyboard emulation wasn't working. He then tried to reload FLASH and then hit the problem where he could no longer program FLASH. There was a broken solder joint on one of the FETs used in the "Battery Backup Fix Version 1" patch, but fixing this did not fix the problem. The system was not in a box so the broken solder joint was the result of some mechanical strain presumably by laying the system (and consequently the IOB6120) flat on its back which would have strained the fragile patch circuitry.

I know the seller for about 20 years and don't doubt what he told me. Of course we all get older so memory may play tricks on us.

I will see if I can reprogram the IOT1 GAL with my EPROM programmer. I seem to remember that it would do Lattice GALs.

My PDP-8 programming skills are almost non-existing but I try to read the BTS6120.PLX ROM source. There is a LDAR IOT which is loading the address latch. I don't yet understand what exactly is getting done there. I wonder if the LDAR IOT is working. It almost looks like random stuff gets latched. The "FL" download starts at address zero, yet I see it latching values like 0x86, 0xF5 and 0xC6. This doesn't make sense. From the code the LDAR IOT seems to latch the value in ACC. From the code (if I read it right) that should be zero for the first block.

Thanks and best regards
Tom Hunter