• Please review our updated Terms and Rules here

Saving ROM data from Tek 4052

Hi Philco,

when I power up the Tek the POWER and BUSY lights stay on, while the I/O light flickers rapidly... and it just stays that way. This accompanied by a click from the speaker every 1.5 sec or so, with BUSY flickering in sync. And that's all it does. The monitor initially glows a uniform green, then darkens from the edges inward. There is absolutely no response to any keystrokes. The 4th light is BREAK, btw.

I'd burn a new ROM set, but so far I've only managed to grab one 68764 EPROM from eBay.

Regards,

--Roland
 
It sounds like your computer is stuck trying to do something, and it is probably the ROMs. Let us know your results when you get a full set of 68764's.

The monitor glowing green is the DVST warming up, at that point the HOME key would clear it up. No response from the keyboard seems to coincide with the I/O light flickering. I hope it's just the ROMs and not the I/O board.

I have two 4052s, and one of them has what I suspect is a bad I/O board. With the good set of ROMs the computer seems to boot fine and the HOME key clears the screen, but all I see is a dot in the center of the screen. I/O light didn't flicker, though. The I/O board will be very tough to fix because it just has a bunch of PIAs and DACs. Hopefully it's just a failed voltage rail or simple component.
 
Hi Philco,

I'm not ruling out the I/O board, or the PSU even. Haven't checked the supply voltages yet, mainly because I don't know where or what to look for (again, service manual urgently needed!), plus in situ measurements on the board are a real pain in the $*#& with that monitor in the way. I can only make educated guesses and poke around aimlessly inside, but my guesses tend to be pretty off... ;)

Um, anyone have a bunch of 68764/6s gathering dust? :)

See ya,

--Roland
 
Hi folks,

I'm reviving this thread after acquiring a set of 68764C's in a (probably vain) attempt at resurrecting this thing.

Looking at the datasheets, I now realise the 68764C is *much* slower than its mask programmed counterpart used in the 4052, the MK36000P-4: 450 vs. 250ns access time. I knew there was a catch. :| Apparently there was also a 68764-35 with 350ns access time, though they're probably impossible to obtain.

I take it this *is* significant, or does somebody here know how the ROM is clocked in the 4052?

Regards,

--Roland
 
Well, if it *is* significant, 2764s with <250ns access time are easily available and, as I mentioned, so are the adapters if you don't want to make your own. Granted, not quite original/authentic.

The 68766 was (is?) available in a 300ns version if you can find 'em.
 
Saving ROM data from Tek 4052

Hi everyone,

I'm reviving this thread once more after aeons to post an update on my 4052. Since I'm now working abroad I only have a few days of the year at home to get physically near the thing. Having said that, I was between jobs earlier this year and resumed my attempt at restoring it, albeit still with little progress.

In the meantime I actually managed to get a second set of 4052 boards from Canada, and they exhibit the same symptoms as the original ones. These are a slightly newer revision, as are the ROMs. This was released just before the 4052A, which differs substantially and uses EPROMs.

I finally got scans of the tech manual, without which I'd have no chance in hell of figuring out the convoluted architecture. As I understand, the 4052 emulates an enhanced (i.e. 16 bit) 6800 with custom extensions as four AMD2901 nibble-slice CPUs. The enhanced instruction set is actually documented in the manual.

All of the support logic (addressing, branch, I/O, interrupt, data buffering) is implemented from scratch using mostly standard TTL chips rather than the integrated solution AMD's 29xx family offered, presumably because the custom logic was more flexible. All in all, I find the architecture mindboggling, and it really pushes my (admittedly humble) digital electronix prowess to the limit. But I consider it a valuable lesson in learning by doing.

To recap, the basics -- RESTART signal and the PSU -- check out ok. The thing just sits there with indicator lights cycling, a *plop* coming from the speaker, and a green expanding blob on the screen. No response from the keyboard, and entering a 10 FOR..TO..NEXT loop doesn't flash BUSY. According to the manual, the firmware does rudimentary checks and stops on error; this doesn't happen. The parity and HW error LEDs don't light either.

I checked the boards with my digital logic probe (Tek 7D01 plug-in for the 7603 scope), and I discovered the 4052 gets stuck in a tight two-address loop after power-up: BNE -2. That didn't really make sense to me, and I suspected the firmware ROMs.

Since the 68764 EPROMs I had were definitely too slow to replace the mask programmed MK36000 ROMs, I actually resorted to building adaptor sockets for 2764 EPROMs. I checked the adaptors and the firmware addressing logic by programming 2764s with NOPs and checking the address lines for monotonically increasing values; each bit toggled with double the frequency of its most significant neighbour.

I then reprogrammed the 2764s with Christian Corti's dumps from ftp://ftp.informatik.uni-stuttgart.d...tronix/tek4052. These correspond to the firmware on the earlier board set I have. Lo and behold, the 2764s still executed the identical loop as the MK36000s, so apparently the firmware is intact and its supposed to do that; but what's it waiting for? There is no activity on the I/O board when I hit a key, nor is an IRQ raised. The PIAs on that board don't appear to be even addressed.

I also checked the microcode fetched for the loop on the ALU board, and decoded the signals by hand from the manual; while not all of it made sense to me, it does indeed appear to be waiting for an interrupt that never comes. Having said that, I'm not ruling out that the microcode ROMs -- which I can't read with my Data I/O -- could be dodgy on both ALU boards I have for testing.

Note that I test the boards ex situ after removing the PSU. No peripherals are attached, so if it's waiting for those, it should time out. I only briefly connected the keyboard for testing -- with no effect at all, as it doesn't appear to be even scanned.

At this point I don't know where to go from here; is there something wrong with the microcode or am I overlooking something obvious?

Thanks & best regards,

--GT
 
I got your PM. Sorry, a bit too busy at the moment with work...

Question. Are the technical manuals online somewhere detailing the hardware and firmware listings (in a similar manner to the 4051)?

I can take a look at them if I get a few minutes/hours...

Dave
 
daver2 said:
I got your PM. Sorry, a bit too busy at the moment with work...

Question. Are the technical manuals online somewhere detailing the hardware and firmware listings (in a similar manner to the 4051)?

I can take a look at them if I get a few minutes/hours...

Dave
Click to expand...

Hi Dave, no worries.

I've uploaded the manuals along with some component datasheets and Corti's ROM dumps here:
https://drive.google.com/drive/folders/0B7TyHkreF1doMk1Zc2FPdHEzaFk?usp=sharing

They're very similar to the 4051's documentation. I can't even remember where I got these from, but thought I'd make these public for the benefit of the few other 4052 owners out there. You might need more than a few minutes to digest them, tho. ;)

Have a great week,

--GT
 
Thanks. I will pick them up tonight - work won't let us look at file sharing services...

I have a business trip Tue/Wed - so I will need something to read on the 'plane... This might fit the bill!

Dave
 
So, I got home and found that I had downloaded all of your documentation from a PM that you had sent me ages ago... Dooooo!!!

Anyway, I know a lot more now than I did a few hours ago - but I am left with more questions!

The first thing that I have found out is that the 4052 instruction set is an 'enhanced' variant of the 6800's (no surprise there - that is what we thought anyhow). All of the 6800 instructions are coded for *** WITH THE EXCEPTION OF *** DAA (0x19) - Decimal Adjust Accumulator. For some reason that instruction has been 'written out' and replaced with a TRAP. All of the unused 6800 1-byte opcodes have either been re-purposed (for the extended instructions) or (for I guess unused instructions) replaced with a TRAP.

It would seem that the extended instruction set contains floating point instructions (e.g. FADD,, FSUB, FMUL, FDIV and FNORM) plus a host of other interesting stuff.

Even though the microcoded machine is 16 bits - the memory is still byte-addressable (as the 8086 is) and (all) of the OPCODES fit in 8-bits to fully decode them. They can be on an ODD or EVEN byte boundary - so the hardware (MAS board) contains byte-swapping logic.

Now the 'rub' - I don't seem to have found any documentation describing the functionality of the enhanced instructions. It must exist somewhere - I just haven't found it yet...

The other thing I am trying to piece together is the firmware ROM image. I appear to have two variants of the firmware - both seem to be different (I think there were two variants of the MAS board around). One thing I was hoping to find was the reset vector at the top of memory (FFFE/FFFF) - but in your combined ROM images - these locations don't seem to be used? I wonder if the restart vector for this magic enhanced processor is different to that of the 6800?

If I can find the answers to the above, I may be able to modify my software emulation of the 4051 to be compatible with the enhanced processor to see if it runs. A (very) quick look seems to indicate that the rest of the machine (I/O, display etc.) looks similar to a 4051.

The other thing that I can't find is the listing of the firmware build for the 4052. For the 4051 this seemed to have been present on some fiches that found their way into bitsavers. I seem to remember finding a post somewhere about someone who had the 4052 fiches. Or did I make that up?

In order to progress your problem - we will have to determine if the code is behaving correctly and is getting stuck in an 'expected' loop (as you expect waiting for an interrupt) or whether it has 'gone berserk' and the machine has followed an incorrect path.

Let me have a further think...

Regards,

Dave
 
Last edited:
Hi Dave,

thanks for racking your brain over this. Personally I enjoy the intellectual challenge, and have learned more than a thing or two about hardware design.

There are at least three different MAS revisions around: 4 and 9 (both of which I have for testing), and that of the 4052A, which has its firmware in EPROMs. The firmware on rev 4 and 9 dates from 1980 and 1982, respectively. Rev 9 has empty patch PLA sockets, so I assume the firmware is already patched. Corti's ROM dumps are from rev 4, while those on Bitsavers are from the 4052A and very likely incompatible with the earlier boards.

The top of memory maps to U885 (odd) and U835 (even), which indeed both end with FF. Then again, I wouldn't put it past Tek to reinvent the reset vector. ;)

I believe Philip Belben may have 4052 microfiches, at least according to an email I found, possibly as a followup to a post here -- I'll have to rummage around in the forum. It wasn't really clear what was actually on them, tho.

At this point I agree that an emulation, once adapted to the 4052, may provide more insight than the actual hardware to determine if the latter or its firmware is misbehaving.

Thanks and keep me posted. If it's any help, I have annotated PDFs in which I noted the logic analyser outputs plus whatever else I observed.

--GT
 
I used to work with Philip many moons ago, so it may be an opportune time for me to contact him and start a dialogue...

I will also copy my tek4051 emulator across to a tek4052 emulator and see if I can get the 'new' firmware into some sort of order. I suspect the 'best' firmware would be the definitely non patched version 9. Any comment?

It would be helpful to see if you track down where the firmware starts execution when you are able to get back to the hardware.

Dave
 
Last edited:
daver2 said:
I will also copy my tek4051 emulator across to a tek4052 emulator and see if I can get the 'new' firmware into some sort of order. I suspect the 'best' firmware would be the definitely non patched version 9. Any comment?
Click to expand...
Hi Dave,

rev. 9 would indeed be the go-to firmware... except I can't read it reliably with my Data I/O (same with rev 4, btw). I do have dumps that I can upload to my Goggle drive for you to test with. These are the most "stable" dumps based on the most frequent checksums I got for a series of reads, but I'm not sure how useful they would be. I'll drop you a link here once they're uploaded.

It would be helpful to see if you track down where the firmware starts execution when you are able to get back to the hardware.
Click to expand...

Since I'm still fairly new to this: how would I go about detecting the first valid instruction fetch with my (rather limited) logic analyser? I would have to use some kind of qualifier to trigger it, right?

I plan to take 2 weeks off at home this month, so I might have an opportunity to test this soon.

--GT
 
Thanks for the info.

I think you can use the initial trigger as the RESTART-0 signal. The power-on reset is generated by the regulator board as MRESTART-0 and is sent to the I/O board. It goes through a couple of gates on the I/O board and becomes RESTART-0 where it is sent to loads of places.

Schematic 4052_schematics_chapter_7_part_6.pdf PDF page 1 (I/O board A5-1) shows MRESTART-0 entering on P3 pin 14. My suggestion would be to pickup U80B pin 5 where it goes to the non +5V side of R501. This signal should be normally '1', go to a '0' on a power-up and then go back to a '1'. I would set your logic analyser to trigger on a '1' to '0' transition. To save powering-up every time (which is not usually good for vintage computers) I would be tempted to 'tack' a normally open pushbutton between 0V the junction of R164/R165. Connecting this point to 0V (pushing the button) should generate a RESTART-0. R164 (750 Ohms) should prevent any problems with the logic generating the MRESTART-0 signal.

I would pick-up the address bus where it enters the MAS board. I will assume you have the 4052A MAS board in my write-up here.

4052_schematics_chapter_7_part_5.pdf PDF page 1 (A4-1) shows the address lines (MB0-1 through MB15-1) entering the MAS board on P154. MB0-1 on A1, MB1-1 on A2 etc. up to MB15-1 on A16. The signal to latch the address lines into the 'odd latches' is ADDRCLK-1. This forms the ODD ADDRESS internally. The EVEN ADDRESS is formed by adding 1 to the ODD ADDRESS. But we can ignore this for now...

After a RESTART, what addresses are then accessed? We only need the first few to (hopefully).

As a double-check I would then propose that you monitor the 16-bit data bus from the MAS board to see what data bytes are actually sent out. This should (in theory) agree with the ROM contents found at those addresses. I was going to propose looking at the data pins of the ROMS - but I can't find that schematic for the 4052A MAS board!

Reverting back to the 4052 MAS schematics in 4052_schematics_chapter_7_part_4.pdf PDF page 21 of 22 (A4-5).

The ODD ROM data bus (ORB0-1 through ORB7-1) and the EVEN ROM data bus (ERB0-1 through ERB7-1) seem to go back to page 1. When I go back to page 1, we seem to end up in a 'mass' of data buffers, so the best place to pickup the data from the ROMS may be directly from the data bus of the ROMS themselves?

Hope this makes sense?

Hopefully, we should be able to either:

a) see the read of the reset vector followed by the execution of the first few instructions at the RESET VECTOR address or
b) The processor execute instructions directly from a fixed location (i.e. they have ditched the RESET VECTOR in favour of hard-codeing the start address in this bit-sliced processor).

Obviously, check out what I am saying first to see if it makes sees to you...

Dave
 
Last edited:
daver2 said:
Thanks for the info.

I think you can use the initial trigger as the RESTART-0 signal. The power-on reset is generated by the regulator board as MRESTART-0 and is sent to the I/O board. It goes through a couple of gates on the I/O board and becomes RESTART-0 where it is sent to loads of places.

I would pick-up the address bus where it enters the MAS board. I will assume you have the 4052A MAS board in my write-up here.

4052_schematics_chapter_7_part_5.pdf PDF page 1 (A4-1) shows the address lines (MB0-1 through MB15-1) entering the MAS board on P154. MB0-1 on A1, MB1-1 on A2 etc. up to MB15-1 on A16. The signal to latch the address lines into the 'odd latches' is ADDRCLK-1. This forms the ODD ADDRESS internally. The EVEN ADDRESS is formed by adding 1 to the ODD ADDRESS. But we can ignore this for now...

After a RESTART, what addresses are then accessed? We only need the first few to (hopefully).

As a double-check I would then propose that you monitor the 16-bit data bus from the MAS board to see what data bytes are actually sent out. This should (in theory) agree with the ROM contents found at those addresses. I was going to propose looking at the data pins of the ROMS - but I can't find that schematic for the 4052A MAS board!
Click to expand...

Hi Dave,

sorry for the delayed reply, RealLife[tm] stuff gets in the way.

IIRC, after MRESTART-0 went low, the address bus simply cascaded, which either suggests it wasn't valid yet or the restart vector is simply 0000, (unlikely, considering it doesn't even point to the firmware).

The MAS board is a pain to check as it's normally upside-down, with the thick (and too short) power connectors making it difficult to flip over with the PSU attached. On top of that, there are few headers provided for testing; for reasons only known to Tek, only the LSB of the odd and even address bus is accessible via J141 and J142, which seems pointless (unless I'm overlooking something).

I don't have the 4052A boards; I used the MAS 670-6030-0x schematics in 4052_schematics_chapter_7_part_4.pdf, of which I've uploaded my annotated version here: https://drive.google.com/file/d/0B7TyHkreF1doelZuWFNSRGEwV3c/view?usp=sharing

I did most of my tests on the MCP, which is mounted back-to-back with the MAS, connecting to it via 2 ribbon cables, and faces up. The headers on it are abundant and far more accessible. I tapped into the PC at J266 on page 9 (A3-4), where I managed to confirm the firmware loop. Note that I didn't use a trigger -- I just sampled the pattern of bytes I got, disregarding duplicates (still learning the ropes with the 7D01 plugin). Failing MRESTART-0, I might have to trigger from the falling edge of U421's output enable at pin 1 to get the latched PC.

I'll be home next weekend and will try and let you know...

See ya,

--GT
 
Agreed.

I understand your issues with RealLife - I have the same problem!

J266 from the MCP is probably the best place to intercept the PC - directly off the IC's.

You can use the /CLR pin of the PC registers (e.g. U425 pin 1) to indicate RESTART (as this line is connected to RESTART-0 back on MCP page 1.

And (as you say) you can use U421 pin 1 as a trigger to indicate when the PC is accessed on the bus.

The PC appears to be reset to 0 on a RESTART - but I would like to bet that the MICROCODE of the CPU sets it to a different initial value before fetching the first instruction...

I await your findings...

Dave
 
Hi Dave,

it's been a busy week, but I finally got round to checking the MAS PC startup sequence via the MRESTART pushbutton as you suggested (works like a charm). For comparison I did so with the rev 04 (+patch PLAs) and 09 firmware. I've uploaded captures of the 7D01 readout for rev09 here, along with a video of its "map" function as an overview: https://drive.google.com/drive/folders/0B7TyHkreF1doVG9KeEI5bTlWOUE?usp=sharing
I can upload captures for rev04 too if you need them.

Both firmwares cycle the bits of the PC on restart (what I referred to earlier as "cascading"), which I presume is done by the microcode as a diagnostic. In some instances this cycle repeats, so the sequence is sometimes offset by multiples of 16 (see 4052-mas09-reptcycle*, with differences highlighted).

Once the PC settles, the rev09 firmware starts at 79F3. The rev04 firmware, by contrast, starts at 7D0F. I assume the entry point is fetched from the constant ROM at E000-FEFF, which is part of the firmware.

If you can adapt your emulator you'll also need a valid firmware dump; I'm not sure mine is. Would it make sense to send you the ROMs?

Hope this helps. I'll be around the Tek for another week, so let me know if there's anything else I can check.

--GT
 
GanjaTron said:
Hi Dave,

it's been a busy week, but I finally got round to checking the MAS PC startup sequence
Click to expand...

Correction: that's the PC on the MCP, not the MAS. I used the convenient J266 header as before but this time synced the 7D01 to pin 1 (/OE) of U521 and triggered from pin 1 (/CLR) of U525. The latter is asserted when the MCP inits after MRESTART. (See piccies in the above Gdrive link).

Have a great weekend,

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