Saving ROM data from Tek 4052

[daver2]

I shall have a look tomorrow. I am unable to access file sharing websites from work and my wife has an 'evening activity out' planned for me tonight!

Dave

 

[GanjaTron]

I shall have a look tomorrow. I am unable to access file sharing websites from work and my wife has an 'evening activity out' planned for me tonight!

Hi Dave,

no rush -- enjoy the evening activity out!

--GT

 

[fastcare]

All the binary files are named as Tektronix part numbers. They all appear to differ from those in my service manual, but the LABELS.TXT documentation on the locations seems to suggest that all the binary files are there. Huge relief for me not having to carry the burden of trying to extract the ROM contents and now I have insurance if my only good set of ROMs go bad.
face it guys
THAY MÀN HÌNH SAMSUNG J7 PRIME

 

[GanjaTron]

All the binary files are named as Tektronix part numbers. They all appear to differ from those in my service manual, but the LABELS.TXT documentation on the locations seems to suggest that all the binary files are there. Huge relief for me not having to carry the burden of trying to extract the ROM contents and now I have insurance if my only good set of ROMs go bad.
face it guys
THAY MÀN HÌNH SAMSUNG J7 PRIME

Hi Fastcare,

which version of the MAS board and ROMs have you got? If you have a 4052A, the rev04 and rev09 ROMs will very likely NOT help you if yours go bad. Mind you, at this point it's still not entirely clear my ROMs are infact flaky.

I'm hoping that Dave might come back with something on the entry points. Dave, did you get round to checking them?

Btw, why are you advertising a smartphone on a vintage computing forum?

Regards,

--GT

 

[jdreesen]

For the upcoming VCFe in Zurich / Switzerland (18/19 Nov ) I repaired my TEK4052, which is now up and running ( no usable tapes yet...)

I took the opportunity to read all the programmable devices from the machine, you find these at ftp.dreesen.ch/ftp/TEK4052

They are release V5 for the ALU-(microcode), and release V5.1 for the MAS-(firmware) board.
They do not use patch-pla's, I believe them to be the latest revision for the 4052.
These are for the 4052, not the 4052A which is a different beast. (differnt IO and MAS board, different microcode and firmware )

As a reference, the romdump's at Al's site are for the 4052A, the romdumps at the Stuttgart museum site are the earlier release V4.x for the 4052

Take note : a 4052 does not boot without the tapedrive attached...

I also dumped the contents of both 2716's onboard the diagnostic rom pack. ( also containg a 6810 )

I have (untested) spare boards if anyone in the neighboorhood wants to try some boardswapping...


Jos

 

[jdreesen]

I put up the dumps from the ROMs from my functional Tek 4052 on my FTP server.
( V5 for the ALU, V5.1 for the MAS board)
These are for the TEK4052, not the 4052A

Note that the 4052 will not boot wothout the tape drive connected....

I will demonstrate this 4052 at VCFe in Zurich on 18/19 Nov

Jos

 

[daver2]

Hi GT,

Many apologies...

Having re-read the posts - I have suddenly realised that I failed to pick up the new set of ROM images that you had posted!

I have just downloaded them now and will see if I can make some sense of them when I load them into my emulator. I converted the last lot I had to Javascript for my emulator - but I just confused myself with them (easily done!)

So, enjoy doing other things for the time being I am afraid...

Dave

 

[GanjaTron]

Hi Dave, hi Jos,

thanks for the info and the new ROM dumps, may try these out on my later MAS board. Just to clarify: are the ROMs labelled 160-026x-05? Are these mask programmed Mmy6000Ps or SCM92000Ps, or EPROMs as in the 4052A? I have the former on my 4052 MAS boards, with the latter revision (rev9) lacking the patch PLAs.

I got back to the 4052 last night and checked the AEA lines on the backpack connector (J5), which also address the internal PIAs on the I/O board. On reset there are indeed addresses within the I/O space (FF00-FFFF) with asserted PIAE, which indicates internal and external PIAs (e.g. communications cartridge) are probably initialised. These addresses no longer show up once the firmware winds up in its infinite loop, tho.

I think I once tested the unit with the tape drive connected, with the same results -- total inactivity. I would have to remove the drive from the case and check again ex-situ (it's a b*tch to probe the boards in the case). I suspect the tape drive may be dead too, which would explain why BOTH sets of boards I have for testing exhibit the same behaviour -- unfortunately I don't have a spare drive.

Even if the tape doesn't respond (because it's missing or failed), I would expect a timeout and a message to that effect on the console, but there's no video; neither of the X/Y analog video outputs is active, and the keyboard doesn't generate interrupts either. I think I'll have to check the address decoding logic on the I/O board that generates the /CS lines for the PIAs, since the relevant I/O addresses do show up on the bus coming from the MAS (and going to the backpack as well).

I hope I can make it to Zürich and see a working 4052 in action. Not sure yet!

Btw, I have the original PLOT50 tapes and documentation, including a 2nd (backup) set. I also have a few tapes with user programs, but I haven't been able to read these in a QIC tape drive under Linux. I suspect they are either no longer readable, or the 4052 uses a proprietary low-level format. Any ideas how to dump them?

Thanks and stay tuned,

--Roland

 

[jdreesen]

Hi Roland,

These firmware are mask-programmed. But are you are sure that the microcode PROMS are OK ?
W.r.t. to failure rate : out of three spare MAS boards, thus 24 ROMs, 9 were dead.....
Be carefull with the original tapes : the (white) drive belts on these are sticky and will destroy your tape if you just try them. I also have lots of original systemtapes for these, all of them have the dreaded drive belt problem.
The format, according to cctalk wisdom, is not compatible with anything else. Still have to organize some good tapes.

 

[GanjaTron]

For the upcoming VCFe in Zurich / Switzerland (18/19 Nov ) I repaired my TEK4052, which is now up and running ( no usable tapes yet...)

Hi Jos,

just to clarify: no usable tapes means you have tapes, but they're unreadable?

I also dumped the contents of both 2716's onboard the diagnostic rom pack. ( also containg a 6810 )

I wonder if that helps with a comatose system...

I have (untested) spare boards if anyone in the neighboorhood wants to try some boardswapping...

Too bad I can't lug my 4052 across the border...

--Roland

 

[GanjaTron]

Anyone else have these?

 

[jdreesen]

I have those and more. But you will destroy them the moment you move the tape, as the tape oxide is now melted to the drive belt.......
Literally all the TEK-supplied tapes I have were bad to start with, I need to bake the few better tapes I have. But then those are emtpty.
Why could you not bring your TEK to CH ?
And yes that diagnostic rom pack could be handy, should not be difficult to duplicate.
Jos

 

[GanjaTron]

Hi Roland,
These firmware are mask-programmed. But are you are sure that the microcode PROMS are OK ?

Hi Jos,

I assume both of the MAS firmware revisions I have (rev4 and rev9) are probably dodgy. I compared the rev4 with those from Christian Corti at Stuttgart Uni/Museum (also rev4), and they differ. But after burning them on EPROMs and installing them via socket adaptors, I still got the same hung loop behaviour, so apparently something is fundamentally wrong. I suspect the missing/dead tape hangs all firmware, good or bad.

Be carefull with the original tapes : the (white) drive belts on these are sticky and will destroy your tape if you just try them.

Yeah, I'm aware of that from tapes in general. The smaller cartridges used in the HP-85 are particularly bad. I do move them by hand from time to time and then retension them in a generic QIC drive (which can't read them), but I have observed residue on the tape surface which is probably the result of the 30+ years of storage before I got them. I think I tried replacing the belts with ones from newer cartridges, but that didn't help, because the tape itself is sticky, probably from hydrolysis (a nasty problem that particularly renders videotape unplayable).

The format, according to cctalk wisdom, is not compatible with anything else. Still have to organize some good tapes.

That's what I figured; Tek apparently did its own thing whenver it can. Look at all the custom chips in their scopes. On the other hand, apart from the ROMs and PLAs, most of the components in the 4050 line are fortunately off-the-shelf.

I probed the 4052 last night with the tape drive attached, but forgot to hook up the +/-20V supply and the motor drive transistors, which are actually mounted outboard on a heatsink shared with the display board! Anyway, the firmware completely locked up then. The PC was random and no longer clocked. The microcode simply stopped at address 000. Having said that, the HDWFAIL signal isn't asserted. Dunno what's going on there. I'll connect and check the tape drive's supplies and the signals on the ribbon connectors to see for any spurios behaviour that could potentially hang the firmware.

On another note, I noticed in the schematics a DRBUSY line coming from the (currently disconnected) display board. This is asserted low, and may inhibit the display output if the board isn't connected. Could try pulling this high to see if the X/Y vector lines are enabled.

--Roland

 

[GanjaTron]

Quick update: the tape drive actually pulled RESTART low when connected, thereby locking everything up. Obviously the logic on the tape drive is shot. The tape drive status signals look ok, at least when unloaded. I severed the RESTART line on the tape board for testing, and the Tek fell back to the previous behaviour; it chugs along and winds up in the exact same infinite loop again.

I'll try Jos' new firmware dumps on EPROMs via adapters. I'll have to check what I can burn the microcode on, and if my old Data I/O can handle it.

 

[GanjaTron]

Micro-update: Jos' V5.1 firmware dumps are actually identical to those from my rev9 MAS ROMs. So either the ROMs are ok after all, or I'm just too stupid to figure this out...

 

[jdreesen]

Micro-update: Jos' V5.1 firmware dumps are actually identical to those from my rev9 MAS ROMs. (

That would rule out the MAS roms. Are you sure that both boardsets you have are for the 4052, and not the 4052A ?
Have you also checked the microcode proms from the ALU boards ? They also go bad, as I have seen.
Also check out the smaller proms (74s288's) that are used..

I'll see in due course if can build up a complete set of functional boards, alas I do not have a spare powersupply or analog board for the CRT.


Jos

 

[GanjaTron]

Jos, I can't P.M. you -- it says your inbox is full...

 

[daver2]

OK - I'm back on the case (for a short while at least)...

I have 'reassembled' the ROMS and dumped them out in both HEX and ASCII.

Note that I have 'moved' the CONSTANT ROMS (that normally appear in the RAM memory map) into addresses 0x0000 upwards so I can dump them out...

I am assuming that the restart vector of 0x79F3 appears at address 0x79F3 in my 'dumped' ROM image. If so, the restart address makes no sense as the instructions are:

79F3 5F    ; CLRB
79F4 20 ED ; BRA 0xED (relative = backwards).

I am assuming the following:

U820 (EVEN) "160-0261" and U870 (ODD) "160-0264" start at address 0x4800.
U825 (EVEN) "160-0262" and U880 (ODD) "160-0265" start at address 0x8800.
U835 (EVEN) "160-0263" and U885 (ODD) "160-0266" start at address 0xC800.

For this addressing to work - the end of U835/U885 will be 'missing' as it will be at an address > 0xFFFF.

Thoughts?

You will find my ROM memory dump at https://drive.google.com/drive/folders/1K1QpcmUidtI6hEWcbqbTSEZvyKqi0i04?usp=sharing.

Dave

 

[daver2]

I have been having a look at the address decoding in a bit more depth.

This is what I have deduced (which may require me to change my memory dump utility a bit).

The PATCH ROM is at 4400...47FF in ROM space (not RAM as you originally annotated).

I believe the 1st block of ROM (U820/U870 is actually addressed starting at 0x4000.
I believe the 2nd block of ROM (U825/U88) is actually addressed starting at 0x8000.
I believe the 3rd block of ROM (U835/U885) is actually addressed starting at 0xC000.

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)?

Thoughts?

I will modify my program along these lines... See romdump2.txt on my shared google drive.

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!

EDIT: If I read your PM a bit more closely I would have realised that you told me about the ROMS starting at 0x4000!

I have uploaded the start-up disassembly to my google drive https://drive.google.com/drive/folders/1K1QpcmUidtI6hEWcbqbTSEZvyKqi0i04 as file "startup disassembly.txt".

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.

EDIT: Started to add some comments regarding the PIA initialisation. It seems to initialise the keyboard PIA (port B) and set the BUSY light active whilst it performs its start-up. It's getting late in the UK - so over to you tomorrow.

Dave

 

[daver2]

I was perusing my ROM dump this morning and found - almost at the end of the CONSTANT ROM - a couple of references to 79F3 (what we think is the startup vector). This was at:

3EF0 and 3EFE in my dump (where the constant ROM starts at 0000 because that was a convenient place to temporarily put it),

3EC0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3ED0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3EE0 : FF FF FF FF FF FF FF FF FF FF DF FF 86 FF 12 7E => .........._....~
3EF0 : 79 F3 79 B2 79 C7 97 ED 5B A2 BB F4 F1 F6 79 F3 => ysy2yG.m[";tqvys
3F00 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F10 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F20 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F30 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F40 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F50 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F60 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F70 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F80 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3F90 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3FA0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3FB0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3FC0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3FD0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3FE0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................
3FF0 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF => ................

I see starting at 3EF0 what looks to be potentially 3 vectors fairly close to each other 79F3, 79B2 and 79C7. I might have a little look at disassembling those later too see if they are the RESET, NMI and IRQ vectors (or something like them)...

EDIT: My 3EF0 to 3EFF are the last of the 16 bytes of the CONSTANT ROM area from E000 to FEFF when the I/O space is taken into account. I deduce, therefore, that some of this area contains the CPU vectors as I suspected.

EDIT: I disassembled from 79B2 onwards and that seems to toggle the keyboard PIA (Port PB4 = CLRPER-0) to '0' and then to '1' and then return from interrupt (RTI). It does this without saving registers etc. so I suspect this is a semi-fatal memory Parity error occurring. The other entry point I disassembled was 79C7 and that also looks to me to be the beginnings of an interrupt handler - so I think I am heading in the right direction by assuming the last bytes of the CONSTANT ROM is the vector area for the microcoded CPU.

I probably now need to read the technical manual ...

EDIT: I went back and looked at the Rev04 ROM images (especially the CONSTANT ROM) and found the two identical reset start-up vector addresses in there matching your logic analyser traces at 7D0F. They appear twice in the CONSTANT ROM fairly close together - so not sure which one is exactly the reset vector.

Dave