Image Map Image Map
Page 9 of 10 FirstFirst ... 5678910 LastLast
Results 81 to 90 of 96

Thread: Saving ROM data from Tek 4052

  1. #81

    Default

    Hope this gets out as I still seem to be moderated....

    On ftp.dreesen.ch/FTP/TEK4052 they will find description, schematic, pictures and romdumps for the Diagnostic ROM pack, as used by the TEK engineers in the day.

    Also listed are the the TEK-supplied CRC's for all ROMS in the 4052/54 systems.

    No special components used, so nothing to stop you building your own Diagnostic pack. If anyone does so they can contact me if they need further info.

    Jos

  2. #82
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,455

    Default

    Your post finally escaped from the mods...

    Actually, you may be OK now from the number of posts that I see you have made.

    As you can see, I am making some headway on code disassembly.

    I suppose one big question to ask is "has anyone got a good description of the 'extra instructions' that this beast has got"? If so, I could encode them into my 4051 emulation and try to make an emulator for the 4052(A).

    Dave

  3. #83

    Default

    HI Dave, hi Jos.

    many thanks for your efforts in deciphering the firmware -- I am REALLY impressed! Yes, the ROMs logically start at 0x4800 but have a physical base address of 0x4000, and the first 0x800 bytes are apparently unused and probably (as you point out) shadowed by external firmware in the backpack, if found.

    Thanks also for the diagnostic ROM schematix, Jos!

    Regarding a potential RAM fault: I have two different MAS boards which would then have RAM faults, but maybe that's not that unlikely. Having said that, there's no parity error or hardware fault signal. Again, maybe that's not a reliable indicator. I suppose rotating RAM chips wouldn't change much?

    Regarding the front panel annunciators (BUSY, I/O, etc), I will check tonight if I get around to it. Maybe they can point us in the right direction.

    Unfortunately I have to return to Switzerland (and my job) tomorrow and won't have access to the Tek again until mid-December. In the meantime I can pore over the disassembled firmware too.

    Hope I can post another update tomorrow. Thanks again,

    --Roland
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

  4. #84

    Default

    Oh, and thanks for confirming my ancient logic analyser actually works, Dave. I can now probe with confidence.
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

  5. #85
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,455

    Default

    Thanks. It has been a pretty interesting couple of days (although my wife would have a different word for it other than interesting...)

    Sorry I didn't get around to it a bit earlier - still, we are moving forwards!

    I see they are 4116 DRAM devices. From my experience these can be pretty 'ropey' after this length of time. You just need one fault in 8 on one bank of one card and another fault in 8 on another bank on the other card - and you have two cards that don't work.

    Interestingly, the number of iterations around the loop 7A28... should indicate the number of bytes of RAM checked before a failure occurs. The X register (16-bit address of RAM being checked) is stored in addresses 0x003F and 0x0040 when a fault occurs, so by triggering the logic analyser on a write to addresses 0x003F or 0x0040 and capturing the data that is written should indicate where the fault is. Don't forget these two bytes will be written to by the memory test routine first though...

    Swapping the BANKS of RAM chips may have an effect. If they are socketed, you could consider just putting two banks of DRAM chips in at a time (for 32K DRAM) and testing. Then try swapping chips one at a time. Tedious, but what you are looking for is a couple of banks of memory chips that appear to initially work.

    If I can find some documentation on the extended instructions I may stand some chance of modifying my emulator. Until then - it is going to be a non-starter... But at least I have a set of ROMS (and a potential restart vector) that I can use.

    Safe trip back to Switzerland and I hope to hear from you in the near future. I will try and see what further documentation I can dig up in the meantime.

    I have re-read the technical manual this afternoon and learnt a few more things. From my memory dump - the CONSTANT ROM doesn't just hold constants. It seems to hide executable code as well! I now see the two additional bits in the status register that defines how the ROM/RAM banks are addressed so I can start to simulate that in my emulator. I will, however, start to add the instructions to the disassembly table and executable switch statement in my emulator in readiness for when I obtain some further details (hopefully) in the future.

    Dave

  6. #86

    Default

    Wow, thanks Dave!

    Unfortunately we don't know anything more about the extended instructions other than their mnemonics and addressing modes in the appendix. Too bad Tek themselves are oblivious (or denial) of any documentation, let alone the fact they even carried such a product!

    I just checked the front panel indicator lights again, and confirm that BUSY is constantly lit. BUSY in an endless loop, duh...

    I removed the µcode ROMs and will be taking them with me in the hope I can meet up with Jos, hopefully at VCFE in Zürich next weekend (not sure yet if I can make it). These chips are in pretty bad condition; they are badly corroded, and run hot. As a result, the pins are extremely brittle, and two or three lost a pair of pins despite my best efforts to delicately extract them (by patient symmetric levering, not pulling)!

    I suppose I'll now have to permanently mount these into sockets to bridge the missing pins, assuming they will even take solder with all that oxide. Fortunately there's ample space on the ALU board for intermediate sockets, as it's facing upward in the cabinet. I hope Jos can read and compare these ROMs, because my Data I/O just gives up on them.

    Looking forward to (somehow) probing the RAM testing routine, but that will probably have to wait until december; not going anywhere for Xmas anyway. There are two sets of RAM on the MAS; NEC µPD4160 (base memory, NOT socketed), and MOSTEK 4116 (maybe optional, socketed). It's going to be a b*tch to swap the base memory if the fault lies there.

    Will hopefully get around to studying your dis/reassembled firmware dump sometime this week.

    --Roland
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

  7. #87

    Default

    Quote Originally Posted by daver2 View Post
    I believe the 1st block of ROM (U820/U870 is actually addressed starting at 0x4000.
    I believe the 2nd block of ROM (U825/U8 is actually addressed starting at 0x8000.
    I believe the 3rd block of ROM (U835/U885) is actually addressed starting at 0xC000.
    Hi again, Dave.

    Just to clarify: from my understanding, that's how the firmware ROMs map into the address space. Each block is comprised of an (even/odd) pair as you cited.

    It may well be (internally) that the "JUMP TABLES FOR ROM PACK" and the "PATCH ROM" overlay the initial area of the first ROMS (or there is some magic which means it happens automagically)?
    It's not clear from the manual, but I think this address space may be statically reserved for external ROMs from the outset, rather than dyna-auto-magically.

    I will modify my program along these lines... See romdump2.txt on my shared google drive.
    Looks spot on, and I really appreciate the annotations. Like I said, may give you feedback in the coming days after I've soaked it up.

    Disassembling the first few instructions seem to now make sense (woo hoo)! OK, let me do a bit of hand disassembly after an apple and a cup of coffee!
    Actually, after messing about with the Tek, I could use an aspirin!

    The 'hang' seems to occur just after it has performed a memory test (0x0000 upwards) to find top-of-memory. From my disassembly, I think it wants to find top of memory matching 0xX000 (i.e. I suspect you have some form of RAM fault)... EDIT: The start-up firmware assumes that memory is in 'blocks' of 4K I think. Anything else it finds is assumed to be an error.
    The 4K blocks makes sense, since each chip holds 2K which are then paired for 16-bit words.

    Regards,

    --Roland
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

  8. #88
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,455

    Default

    >>> It's not clear from the manual, but I think this address space may be statically reserved for external ROMs from the outset, rather than dyna-auto-magically.

    I had another look and I agree with your assessment. It begs the question why the ROM image for these addresses do not contain FF's (unless the information placed in the 'master' ROM is 'overlaid' with the PATCH ROM - if fitted). I think the 'if fitted' may be the key thing here...

    >>> Actually, after messing about with the Tek, I could use an aspirin!

    Or even something stronger!!!

    >>> The 4K blocks makes sense, since each chip holds 2K which are then paired for 16-bit words.

    The 4116 device is 16 KBITS. Each device only serves 1 bit of the data path so (to make a byte) you will need 8 of them and (to make the odd/even banks) you will need two lots of these. This equates to 32KBYTES of DRAM organised as 16KBYTES*16bits. Therefore, multiples of 4K doesn't make sense in this case. However, before the MK4116 DRAM, there was an older MK4027 4K part. So it potentially makes sense if this code was developed for an earlier machine with smaller DRAM chips and not updated when larger DRAM chips came along.

    >>> Looking forward to (somehow) probing the RAM testing routine, but that will probably have to wait until december; not going anywhere for Xmas anyway. There are two sets of RAM on the MAS; NEC µPD4160 (base memory, NOT socketed), and MOSTEK 4116 (maybe optional, socketed). It's going to be a b*tch to swap the base memory if the fault lies there.

    My suggestion would be to remove the socketed option chips first and see what happens...

    >>> Looks spot on, and I really appreciate the annotations. Like I said, may give you feedback in the coming days after I've soaked it up.

    Excellent. Feedback always appreciated.

    In the meantime I will think how to test the RAM out in a more structured manner...

    Dave

  9. #89

    Default

    The Diagnostic ROMPack contains RAM & ROM tests, with output on a couple of LEDS. So you do not even need a functional display to check things out.

  10. #90

    Default

    Quote Originally Posted by jdreesen View Post
    The Diagnostic ROMPack contains RAM & ROM tests, with output on a couple of LEDS. So you do not even need a functional display to check things out.
    Hi Jos, that thing looks like just what we need; It will even identify the faulty chip! I grabbed your docs (btw, the JPGs aren't readable) and skimmed thru them. Short of building one of these modules from scratch, would you be willing to lend yours for a good cause?

    --Roland
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •