the entropy bites on a ROM emulator - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: July 11, 2019, 10:03:46 am
content: A dude on eBay has recently sold me a Softec ROM emulator, which I am using to emulate a 27C010 (128Kbyte, 8bit) ROM on an SBC board. The CPU panics immediately, and after two days of digging around, I figured out that the emulated image is not equal to the file I pass to the ROM emulator but rather, and, still worse, it has not a random corruption which can be addressed to the cable, or to the socket, but rather something that always happens at the same address locationsemulated ROMCode:00900200 56 8A 10 12 48 80 02 80 00 00 00 01 66 04 4E BA V...H.......f.N.00900210 00 08 4C DF 0C 00 4E 75 48 E7 38 00 28 3C AA AA ..L...NuH.8.(<..00900220 AA AA 26 3C 55 55 55 55 0C 84 AA AA AA AA 67 04 ..&<UUUU......g.00900230 4E BA FF 18 0C 83 55 55 55 55 67 04 4E BA FF 0C N.....UUUUg.N...00900240 13 FC 00 AA 00 4FF0 13 FC 00 55 00 5FF0 .....O.....U._..00900250 0C 39 00 55 00 4FF0 66 04 74 05 60 16 13 FC .9.U.O..f.t.`...00900260 00 08 00 1F FF F0 13 FC 00 02 00 7F FF F0 14 39 ...............900900270 00 1FF0 10 02 48 80 48 C0 72 05 B0 41 67 0E ......H.H.r..Ag.image passed to the ROM emulatorCode:00000200 56 8A 10 12 48 80 02 80 00 00 00 01 66 04 4E BA V...H.......f.N.00000210 00 08 4C DF 0C 00 4E 75 48 E7 38 00 28 3C AA AA ..L...NuH.8.(<..00000220 AA AA 26 3C 55 55 55 55 0C 84 AA AA AA AA 67 04 ..&<UUUU......g.00000230 4E BA FF 18 0C 83 55 55 55 55 67 04 4E BA FF 0C N.....UUUUg.N...00000240 13 FC 00 AA 00 4FF0 13 FC 00 55 00 5FF0 .....O.....U._..00000250 0C 39 00 55 00 4FF0 66 04 74 05 60 16 13 FC .9.U.O..f.t.`...00000260 00 08 00 1F FF F0 13 FC 00 02 00 7F FF F0 14 39 ...............900000270 00 1FF0 10 02 48 80 48 C0 72 05 B0 41 67 0E ......H.H.r..Ag.(differences are marked within "[", "]" )Why does it happen? ... This is the big question. This device is a MultiROM device made by Softec Microsystem, and their software comes with a diagnostic, which says "no problem found", but it says lies since we have a serious problem here.Probably, in my opinion, the diagnostic just tests the cable, or the interface, rather the internal RAM used to store the emulated ROM.

author: CJay
author_rank: Super Contributor
timestamp: July 11, 2019, 10:09:42 am
content: Upload a ROM image with just $00 in it and see if the corruption re-occurs.Then try $AA and then $55

author: capt bullshot
author_rank: Super Contributor
timestamp: July 11, 2019, 10:11:10 am
content: This is a systematic failure -> the emulator is borked, get a replacement from the vendor. If the new one shows the same systematic failure, it's either a bad design or something strange that happens at your target only.Good point of CJay, try to do some systematic tests.

author: legacy
author_rank: Super Contributor
timestamp: July 11, 2019, 10:38:09 am
content: Quote from: CJay on July 11, 2019, 10:09:42 amwith just 0x00, it reports corruption at addresses: 00900240, 00900250, 00900270I still have to test with 0xAA and 0x55, but it seems the damage is regarding the internal RAM used for emulating.

author: CJay
author_rank: Super Contributor
timestamp: July 11, 2019, 10:43:52 am
content: I think you're right, I think it's the RAM in the emulator causing the problem.$AA and $55 are binary 01010101 and 10101010 respectively so can show up stuck bits/address lines and allow you to diagnose the problem but if you've only just bought it, get a replacement.

author: legacy
author_rank: Super Contributor
timestamp: July 11, 2019, 10:47:09 am
content: I have just emailed to Softec Microsystem signaling the problem, I am waiting for their reply if someone will care about an EOL product. I bought it on eBay and the seller doesn't have more in stock, he can only refund.Quote from: CJay on July 11, 2019, 10:43:52 amI have also tested the SBC with a Moates Ostrich2 ROM emulator and it works perfectly, so I am starting to think that the Softec Microsystem is seriously damaged, and I wonder if it's possible to repair it because it would be a pity to trash it.

author: amyk
author_rank: Super Contributor
timestamp: July 11, 2019, 12:14:40 pm
content: Are they all FFs becoming something other than FF ?I notice that around those addresses the surrounding values also have lots of 1 bits set. It could be a bad decoupling capacitor.

author: capt bullshot
author_rank: Super Contributor
timestamp: July 11, 2019, 12:58:56 pm
content: Quote from: amyk on July 11, 2019, 12:14:40 pmDidn't know it was an EOL device. So fixing it on your own is a valid option, most probably I'd take that turn under these circumstances.Yes, bad decoupling can cause all kinds of flipped bits, most prone when many address / data lines change their state from "0" to "1" (or vice versa) at the same time. So the transition from "data FF @ address 1FFFF" to "00 @ 20000" is more vulnerable than e.g. "55 @ 1A653" to "AA @ 1A654" (since there are lesser bits changing, and changing adjacent data lines to opposite states might compensate to some extent).

author: legacy
author_rank: Super Contributor
timestamp: July 11, 2019, 02:38:50 pm
content: I will post logs with the suggested tests with 0x55 and 0xaaI have just got an email back with the response: the Italian partner "Veratim" has just said thatwww.softecmicro.itis dead and about their EOL products .. well all the engineers assigned to the MultiROM are retired.

author: duak
author_rank: Super Contributor
timestamp: July 12, 2019, 01:07:44 am
content: I'm not familiar with this device. Is a cable used between the emulator and the SBC or does the emulator plug directly into the SBC? If the package is a DIP, extension with only one GND and one power pin is marginal. Are there any extra ground or power connections available on the emulator to improve connectivity with the SBC?

author: CJay
author_rank: Super Contributor
timestamp: July 12, 2019, 07:46:03 am
content: Quote from: legacy on July 11, 2019, 02:38:50 pmWell if you do get to keep it and want to repair, post up pics of the internals here, even if we can't help, it's always nice to have a reference, sometimes it helps others in the future.

author: TerraHertz
author_rank: Super Contributor
timestamp: July 12, 2019, 08:18:13 am
content: Presumably it will have one or more static RAM chips. Have you opened it up? Are they through hole?If so, desolder them, put in sockets, and swap them around. Do the bad locations stick with one of the RAMs?Is it one of these?https://www.esis.com.au/Programmers/Multirom_flyer.pdf

author: CJay
author_rank: Super Contributor
timestamp: July 12, 2019, 08:24:12 am
content: Quote from: TerraHertz on July 12, 2019, 08:18:13 amOoh, that's nice, I like that.

author: legacy
author_rank: Super Contributor
timestamp: July 12, 2019, 09:44:39 am
content: I have to emulate one of these. It's equal to 27C010.It's 128Kbyte, 8bit, and it's supported by Softec MultiROM.

author: capt bullshot
author_rank: Super Contributor
timestamp: July 12, 2019, 10:22:28 am
content: Check the electrolytic capacitors for ESR and capacity or check the supply rail (I guess there's 5V only in this box) for excessive ripple.The chips made by Alliance are the RAM chips - I remember FLASH chips by that make that were very unreliable.On the right hand side, there's a galore of protection resistors, check these for value and cracked solder joints.

author: MadTux
author_rank: Frequent Contributor
timestamp: July 12, 2019, 10:39:51 am
content: Soldering a new SRAM chip shouldn't be that difficult, IMO the most probable cause of failure.512Kx8, 3.3V SRAM also shouldn't be too hard to find, I even might have some.Worst case scenario would be some flipped bits in the Altera CPLD/FPGA chips, since these are flash/EEPROM based.

author: legacy
author_rank: Super Contributor
timestamp: July 12, 2019, 01:09:03 pm
content: Quote from: MadTux on July 12, 2019, 10:39:51 amFrom Alliancememory,thisis the datasheet for the AS7c34096.AS7C4096 is the 5V versionAS7C34096 is the 3.3V versionI wonder if a cell of a static ram can die this way ... and for which reason ...Quote from: MadTux on July 12, 2019, 10:39:51 amAnd the assigned engeears are all retired, so there is no way to get the bistream for re-programming.

author: joeqsmith
author_rank: Super Contributor
timestamp: July 12, 2019, 05:33:24 pm
content: Have you tried using the upper data bits? If you only need 8 you may be alright for now.

author: legacy
author_rank: Super Contributor
timestamp: July 12, 2019, 06:30:41 pm
content: Quote from: joeqsmith on July 12, 2019, 05:33:24 pmNoThe upper data bits (which has a second cable) iss for emulating a bigger (>1MByte) ROM, or a 16bit bus one. In my case, I need to emulate a 27C010, which is 8bit data bus, and 128Kbyte of size.The diagnostic-cable, anyway, uses both the connectors. I don't know what tha diagnostic software does, it requires to plug a special cable, and does some test. It says "all tests passed", but it doesn't seem accurate.

author: ebastler
author_rank: Super Contributor
timestamp: July 12, 2019, 06:36:51 pm
content: Quote from: legacy on July 12, 2019, 06:30:41 pmSure, 16-bit systems are what the upper bits were meant for. But you could still connect those 8 upper bits to your 27C010 data lines, right? It would entail making a custom cable, but if those bits work, I think Joe's idea has merit.

author: legacy
author_rank: Super Contributor
timestamp: July 12, 2019, 06:41:06 pm
content: looking at errors ... it seems there is a common repeated pattern4FF0 -> 4FF05FF0 -> 5FF04FF0 -> 4FF01FF0 -> 1FF0cells preceded by something that ends with "0x*F" and followed by something that begins with "0xF*" seem to be affected.Maybe it means something

author: capt bullshot
author_rank: Super Contributor
timestamp: July 12, 2019, 07:09:07 pm
content: This thing is connected through the printer port (LPT)?One way to transfer 8-Bit data and other control stuff through an 8-Bit port is to encode part of the available data range into a sequence of multiple bytes, having the goal to embed control codes.random example:data transferred0xFD 0xFD0xFE 0xFE 0x000xFF 0xFE 0x01so 0xFF never appears in the normal data stream,now one can embed control codes by preceding them with 0xFFMaybe this is some kind of a control sequence that isn't properly encoded or decoded.Just a wild guess.

author: legacy
author_rank: Super Contributor
timestamp: July 12, 2019, 07:47:16 pm
content: Quote from: capt bullshot on July 12, 2019, 07:09:07 pmYes! The manual requires to the the LPT in bidirectional-mode.I did it in the PC-BIOS. I will try a better cable, and on a different PC.

author: amyk
author_rank: Super Contributor
timestamp: July 13, 2019, 01:28:13 am
content: Quote from: legacy on July 12, 2019, 06:41:06 pmAs mentioned above, there are a lot of "1" bits in those corrupted patterns, so they do represent extremes in power draw and bad signal integrity is likely to show up there. It could even be something like a bad connection leading to an IC being powered through its signal pins, something that Dave has even made a video on:https://www.eevblog.com/forum/blog/eevblog-831-power-a-micro-with-no-power-pin!/