• Please review our updated Terms and Rules here

Saving ROM data from Tek 4052

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
 
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
 
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
 
Oh, and thanks for confirming my ancient logic analyser actually works, Dave. I can now probe with confidence. ;)
 
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
 
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
 
daver2 said:
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.
Click to expand...
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)?
Click to expand...
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.
Click to expand...
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!
Click to expand...
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.
Click to expand...
The 4K blocks makes sense, since each chip holds 2K which are then paired for 16-bit words.

Regards,

--Roland
 
>>> 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
 
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.
 
jdreesen said:
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.
Click to expand...

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
 
daver2 said:
My suggestion would be to remove the socketed option chips first and see what happens...
In the meantime I will think how to test the RAM out in a more structured manner...
Click to expand...

Hi Dave,

thanks for clarifying the RAM organisation. What do we do if the non-socketed NEC µPDs are faulty? I can unsolder one with a some patience, but several... :|

I've gone over your firmware disassembly, and I agree with your annotations. While we now know what the firmware is doing, we don't know why it's doing it. The RAM test and following loop really makes no sense to me at all, and throws up a lot of questions:

  • Why is memory only checked up to FEEA, when RAM ends at FEFF (with FF00-FFFF mapping to I/O)?
  • Why are the loops starting at 7A42 always executed, regardless of where the preceding RAM test ended?
  • Why is the top of memory (or first failed address) written to RAM at 0x003F if it's retained in the X register? For external diagnostix?
  • Why do both loops at 7A46 and 7A4C test a condition (BNE) that never changes? If the RAM test successfully (?) ended at FEEA (actually FEEB, since it's post-incremented), the first loop will already hang! As such, we don't know for sure if the RAM is infact faulty...
  • Why isn't a fault condition asserted within the loops? The parity error LED is triggered by hardware, and it's off in this case.
  • What were the Teks smoking when they designed this thing?

My head hurts, I think I'm gonna go lie down. ;)

--Roland
 
>>> I agree with your annotations.

Excellent, so the first hurdle over with!

>>> Why is memory only checked up to FEEA, when RAM ends at FEFF (with FF00-FFFF mapping to I/O)?

Don't forget that with a full complement of RAM (32K+24K=56K) the RAM will end at 0xDFFF. The CONSTANT ROM (starting at 0xE000) will terminate the memory test anyway...

>>> Why are the loops starting at 7A42 always executed, regardless of where the preceding RAM test ended?

I am not too sure what you are asking. The code at 7A42 just seems to be where everything ends up when the test has 'run out' of what appears to be valid RAM.

>>> Why is the top of memory (or first failed address) written to RAM at 0x003F if it's retained in the X register? For external diagnostic?

I assume it is written to 0x3F (and 0x40) from the X register as there is no direct means of performing logical testing on the 16-bit X register directly itself. The 16-bit X register appears to be stored into memory as two 8-bit bytes and then logically tested for being a multiple of 4K.

>>> Why do both loops at 7A46 and 7A4C test a condition (BNE) that never changes? If the RAM test successfully (?) ended at FEEA (actually FEEB, since it's post-incremented), the first loop will already hang! As such, we don't know for sure if the RAM is infact faulty...

Using a BNE this way is an easy way of saving ROM bytes I suspect. You perform a test and 'jump to yourself' if the test fails. Neat - but poor error reporting to the poor user. But, there again, these devices ended up in laboratories etc. anyway - so you just called in the repair company and they diagnosed the problem and fixed it. At least Tektronix did produce diagnostic aids etc. for their repair people. I don't think anyone did that with the micros. of the time... As I have identified above, I don't think the error should the RAM test ever succeeded be triggered! You could try reporting the error to Tektronix and see how they respond :)!

>>> Why isn't a fault condition asserted within the loops? The parity error LED is triggered by hardware, and it's off in this case.

Good question. I will have a look at the schematics and see if I can come up with an answer for this.

>>> What were the Teks smoking when they designed this thing?

I couldn't possibly comment...

>>> My head hurts, I think I'm gonna go lie down.

Back to the Asprin again!

With regard to replacing the lower bank of RAMS. Let's not be too worried about that for now. Let's identify the problem first and see where that leads us.

Dave
 
I have done a bit of disassembly on what I think are the interrupt handler routines.

I haven't got time to write up my hand-written notes just yet (I am heading out for an airport shortly) but I will when I get back.

I have disassembled what I think is the NMI routine - and it does something weird with the parity error latch - like clear it AND HOLD IT CLEARED when a parity error occurs. If this is the case, you may not actually see the PARITY LED light during startup!

Dave
 
daver2 said:
I have disassembled what I think is the NMI routine - and it does something weird with the parity error latch - like clear it AND HOLD IT CLEARED when a parity error occurs. If this is the case, you may not actually see the PARITY LED light during startup!
Click to expand...
Hi Dave,

thanks for the update. I suppose then it's a parity error only lasts 1µsec or so. ;)

Quick update from my side: I met up with Jos at VCFE in Zürich and he checked the µROMs I brought along after socketing the ones with broken pins: their checksums agreed with his, and they did so consistently. I think we can conclude that at least their content is ok, though mechanically they're very fragile indeed. Many thanks, Jos! :thumbsup:

Unfortunately, Jos' 4052 started to act up while on exhibit with what appears to be a thermal fault. His 4014 terminal, on the other hand, was rock solid and drew crowds. The keyboard on that thing is awesome! Thanks again, Jos, for putting these on exhibit!

Meanwhile, I'll figure out how to determine the address where the RAM testing routine bails out. I'll also take a look at the diagnostic ROMpack schematics and parts in anticipation of building one. I took a look at Jos' module, and we discussed the possibility of him etching several PCBs if there is sufficient demand. After all, there are quite a few defunct 4050's out there that need testing. Laying these out (something I have no experience with) will take some time.

Best regards,

--Roland
 
A 'suppliers' diagnostic!

Error, what error? I never saw an error!

Before I loose it:

Code: 
79B2:

86 41    ; LDAA 41 - IMMEDIATE
97 4B    ; STAA 4B - DIRECT
B6 FF 2A ; LDAA FF2A - KEYBOARD PIA PORT B DATA.
84 EF    ; ANDA EF - Clear PB4 of keyboard PIA.
B7 FF 2A ; STA FF2A - KEYBOARD PIA PORT B DATA.
B6 FF 2A ; LDAA FF2A - KEYBOARD PIA PORT B DATA.
8A 10    ; ORAA 10 - Set PB4 of keyboard PIA.
B7 FF 2A ; STA FF2A - KEYBOARD PIA PORT B DATA.
3B       ; RTI

Interestingly, accumulator 'A' is modified by this action and never appears to be stored across (what I think is) the NMI handler...

Dave
 
Last edited:
Hi Dave,

thanks for the disassembly. That does indeed assert CLRPER, which clears the parity error latch. I would assume this NMI handler is triggered by the HDWFAIL signal, which is in turn asserted by a parity error. But what's the point of clearing (ignoring?) a fatal error and continuing as if nothing happened? If it's fatal, the system should just halt, in which case saving/restoring registers is indeed irrelevant.

Btw, I don't think I ever saw 79B2 show up on my analyser, but I'll check my notes.

--Roland
 
Anyone followin this that would also like a copy of the diagnostic rompack should give a shout. I cannot yet promise to make them, but a rough idea of how many to make would be helpfull.

Jos
 
Starting using my diagnostic rompack and it became immediatly clear why my 4052 was misbehaving : two bad ramchips.....
A wonder that it actually did execute some basic programs.
The diagnostic manual also reveals that the 4052 contains selftest-microcode that is executed at startup. The system will hang if that fails.\
I wonder if that is what you guys are running into.

And now dismanteling yet again the whole shebang to replace the DRAM chips....


Jos
 
Hi Jos.

I don't think so. Roland did see what seems to be self-test microcode executing - but then we see the microcode starting to execute 'real' 6800 instructions - and it is this code that 'bombs'. I suspect the self-test microcode tests the hardware cards out internally but perhaps not the memory itself - that is left to the 6800 program.

Dave
 
Hi Jos,

thanks for the update. Good to know the diag ROM does its job (yeah, I want one). ;)

I suppose the fault was sporadic enough to still execute those basic demos up to a point. Are those two bad ramchips by any chance in the socketed base mem (NEC µPD in my case)? Also, did your MAS parity error LED light up? Would be good to have confirmation that a hardware fault is infact detected on-board.

According to the manual (tech. data p. 6-10), the µcode selftest halts at specified (µROM) addresses; none of these show up in the pipeline register when I probe it. The manual also states the µcode tests the MAS board for "RAM space memory read, write,
and addressing". It's not clear if that actually constitutes a full memory check, tho.

Btw, I have socket soldered the µROMs with missing pins and will drop them back into the ALU board at home over Xmas break, now that we have confirmed they're ok -- thanks again, Jos! At this point I'm now almost convinced it's the RAM. Hope I can figure out where that RAM test ends.

--Roland
 
You must log in or register to reply here.
Back
Top