• Please review our updated Terms and Rules here

Burroughs TD830 (Firmware ROM Type)

that directory and the list were made from the pictures you posted
are the parts in Burroughs ROMS.zip from another board? none of the part numbers match what was in the first three boards
also, am9233 is a 4k rom
 
Same CRCs, so it wouldn't be the conversion process.
Hi,

I could read the 8 ROMS on this CPU board REV F. Also: Here is another ROM I found in my collection. It actually is a BASIC 1 ROM chip on Motorola IC (ROM A). I have no idea where this came from.
 

Attachments

  • 26389841 REV F.zip
    12.1 KB · Views: 12
  • IMG_20230601_094536.jpg
    IMG_20230601_094536.jpg
    4.7 MB · Views: 10
  • BASIC 1 Motorola ROM A.zip
    1.9 KB · Views: 8
Here is another ROM I found in my collection. It actually is a BASIC 1 ROM chip on Motorola IC (ROM A). I have no idea where this came from.
It's a Z80 tiny basic. But your other dump has valid pointers at the start of all the chips, so I need to take some time with it. Your P1 chip has the same CRC as b1.dat, but the rest are different.
ROM dumps, etc here
That seems to be the source of the dumps we've been having troubles with. B3.TXT at 2400 has "11 96" when it should be "Bx xx" pointing into the rom data, and its 3700 page is all 3F, starting in the middle of a code flow. I also tried swapping around the two halves in case the weird chip select thing could have swapped the halves, but it still makes an inconsistent traced disassembly and B008 is too early in the ROM to be valid.
 
Aaah I see. Would have been good to have a link back to me from bitsavers, so that y'all could ping me instead of me accidentally finding this thread :)

No worries, I still have the 831, so I can re-look at the problem.

For the record, the TXT files is what I did first, dump the thing as big ROM with address lines to the chip select. I rewrote the code to make the BIN files on my website (which has been down for a couple weeks because our government can't make electricity properly any more and I was in Slovenia) and I started running the whole thing through IDA and the reset vector points to BA66 (NOP, SEI, CLRI -- looks sane) so go have a look again maybe?
 
It's nothing to do with the vectors, specifically B3 and B5 have internally inconsistent code flow. Jumps/branches go to the middle of instructions, and short branches out go of the rom and into the 3F block at the end of B3. My disassembler is a sort of "IDA lite", so these problems stick out. But the biggest problem with B3 is that all the other roms start with a 2-byte pointer to the "end" of its contents, where there is another 2 bytes that are probably a checksum for self-tests. The first byte of B3 should be in the range B0..B7 and it's way off.
 
The TXT files was a first attempt. The BIN files are much better. Not saying they're correct, but please throw the TXT files away. Seriously.

With the info from this thread I can get a better idea of where the ROMs map in memory, I see the ones I thought mapped at 0x8000 - 0x9000 should map to 0xA000 - 0xBFFF.

My server is flaky, Jason to the rescue: https://web.archive.org/web/20210722082008/http://retro.co.za/ccc/BurroughsTD831/ROMs/
 
I could read the 8 ROMS on this CPU board REV F.
And good news, your Rev F dump is completely consistent. No jumping out of the roms, no running into the middle of an instruction. That only the first one is identical to the 830 dump is interesting. I think it would be worth trying to figure out what the other roms have in common.

The TXT files was a first attempt. The BIN files are much better. Not saying they're correct, but please throw the TXT files away. Seriously.
The format is irrelevant. Anyone who understands how that dumper works (and it's pretty clever) can figure it out easily and extract the data in a few minutes. When in doubt go to the original files, which I did, and it didn't help. What matters is that B3 (and maybe B5 too) is clearly a bad dump, maybe the chip was bad, who knows. It just took this long for anyone to look closely enough to confirm it. It certainly explains why people had trouble getting it to work on an emulator. But even as a bad dump, it is still something that other chips can be compared with.
 
The format is irrelevant.
I made the TXT files first. I then changed the code I used to make them. I then made the BIN files. Somewhere in the middle, someone scraped my website and put the TXT files on bitsavers. The BIN files are _different_. It's not the format. It's stuff I _learned_, and fixed.

Please delete files B1.TXT to B8.TXT. OK?
 
And good news, your Rev F dump is completely consistent. No jumping out of the roms, no running into the middle of an instruction. That only the first one is identical to the 830 dump is interesting. I think it would be worth trying to figure out what the other roms have in common.


The format is irrelevant. Anyone who understands how that dumper works (and it's pretty clever) can figure it out easily and extract the data in a few minutes. When in doubt go to the original files, which I did, and it didn't help. What matters is that B3 (and maybe B5 too) is clearly a bad dump, maybe the chip was bad, who knows. It just took this long for anyone to look closely enough to confirm it. It certainly explains why people had trouble getting it to work on an emulator. But even as a bad dump, it is still something that other chips can be compared with.
Hi Bruce,

I actually made a crude harness to read those ROMS and it looks like it worked, or works better at least. I will repeat this method on the other two CPU board. About the B1, yes is was identical. I verified the ROM with the B1 image and no differences.
 

Attachments

  • IMG_20230613_151414.jpg
    IMG_20230613_151414.jpg
    3.5 MB · Views: 6
Hi all

I have now re-dumped my ROMs, with the following results, compared to cliff@swissbay.net's 26389841 REV F.zip file:
9316B-4220 at 0xA000 : similar but also different. Idunno,maybe its different code, maybe my ROM has something strange wrong with it.
9316B-5221 at 0xA800 : identical
2639-4254A at 0xB000 : Definitely faulty, looks like D5 is stuck high
2889-4262 at 0xB800 : identical
9316B-4226 at 0xE000 : identical
2639-4304 at 0xE800 : identical
9316B-6228 at 0xF000 : identical
9316B-7230 at 0xF800 : identical

ROMs here -> http://retro.co.za/ccc/BurroughsTD831/ROMs/

I will ask someone to delete my crappy old dumps off of bitsavers.
 
Hi all

I have now re-dumped my ROMs, with the following results, compared to cliff@swissbay.net's 26389841 REV F.zip file:
9316B-4220 at 0xA000 : similar but also different. Idunno,maybe its different code, maybe my ROM has something strange wrong with it.
9316B-5221 at 0xA800 : identical
2639-4254A at 0xB000 : Definitely faulty, looks like D5 is stuck high
2889-4262 at 0xB800 : identical
9316B-4226 at 0xE000 : identical
2639-4304 at 0xE800 : identical
9316B-6228 at 0xF000 : identical
9316B-7230 at 0xF800 : identical

ROMs here -> http://retro.co.za/ccc/BurroughsTD831/ROMs/

I will ask someone to delete my crappy old dumps off of bitsavers.
Hello,

I checked my 3 CPU Boards Prom and all are the same as your 82S123-CPU.BIN
 
Good day everyone. I found a TD832 at a local electronics recycler that has been living in a tote outside for some time. I brought it home and was able to get it to power on and plan on mapping out the cpu board as much as I can. Its a rev f board.

I'll share what I come up with here but figured I would ask if there is anything specific I can check or trace out that you would like to see.
 

Attachments

  • 20240412_150643.jpg
    20240412_150643.jpg
    3.4 MB · Views: 8
  • 20240412_150758.jpg
    20240412_150758.jpg
    2.5 MB · Views: 7
  • 20240412_153621.jpg
    20240412_153621.jpg
    2.6 MB · Views: 6
  • 20240412_153624.jpg
    20240412_153624.jpg
    2.5 MB · Views: 7
  • 20240412_153628.jpg
    20240412_153628.jpg
    2.4 MB · Views: 8
  • 20240412_151005.jpg
    20240412_151005.jpg
    1.8 MB · Views: 7
Back
Top