Tek 405x web-browser emulator

[nikola-wan]

The only ROM info I can find is the 4052A/4054A ROM entry point table starting on page 85 of the 4052A Assembler doc:

Tektronix 4052A-4054A-Assembler/4052A-Assembler-TECO-OCR.pdf

The Example note at the bottom of page 7 may indicate that the ROM Jump Table listing in this doc may be the same as the 4052/4054 ROM Jump Table, particularly as all the 4052 ROM Packs work in my 4054A, with the exception of the GPIB Enhancement ROM Pack that takes advantage of the A-Series TI 9914 GPIB integrated circuit.

 

[daver2]

It looks like the write to ROM from the microcode is intentional (unless I have misunderstood the I/D logic somewhere - which wouldn't surprise me of course).

I have found the microcode:

Write to byte address $FF2B with $00.
Write to word address $FF2A with $F004.
Write to byte address $FF2A with $60.

If these are truly writes to ROM then they should achieve nothing of course (or trap out if such a thing exists).

If they write to RAM - then this is in I/O space and there doesn't appear to be anything there to write to?

Jos, out of interest, what addresses are the switches and LEDs on the diagnostic card located at?

The microcode comments specifically mentions LEDs (PC) which (I assume) are the top 4 bits of the PC which are on the MAS board.

However, I don't think these have anything to do with the MAS I/D tests?

It may just be that these LEDa are used to indicate a test failure and not associated with the specific writes themselves.

Dave

 

[daver2]

I think -)) I have put all of the infrastructure back in for interrupts now...

I had to remove all of my diagnostic code within the I/O reads and writes - because otherwise the emulation was just filling up the log file. I have just commented it out for now of course.

Now I have to 'bolt in' the bit of logic into the microcode emulator that tests the interrupt flag(s) (IRQ and NMI) and vectors accordingly.

I think I will have a break and go and do the hoovering in the house. That will let me concentrate on that part of the delicate operation in peace !

I can then see what I will be left with will be another mammoth debugging task :-(! But I will have moved forwards...

Dave

 

[jdreesen]

It looks like the write to ROM from the microcode is intentional (unless I have misunderstood the I/D logic somewhere - which wouldn't surprise me of course).

I have found the microcode:

Write to byte address $FF2B with $00.
Write to word address $FF2A with $F004.
Write to byte address $FF2A with $60.

If these are truly writes to ROM then they should achieve nothing of course (or trap out if such a thing exists).

Jos, out of interest, what addresses are the switches and LEDs on the diagnostic card located at?

Dave

These are just I/O devices at cartridge address 41 . Equations, from the Diag Pack PAL, are :

; WLED write to status LEDs
/WLED = /BSR * /XPC2 * PHI2 * /RWN

; RSWI Read Dipswitch
/RSWI = /BSR * /XPC2 * PHI2 * RWN


Jos

 

[daver2]

Thanks Jos,

I will add some of my microcode logic diagnostic code to the specific addresses around where it is playing with these locations to see what is happening...

I don't (therefore) expect this microcode to be interacting with the diagnostic cartridge LEDs - especially since it has just 'probed' the cartridge and found it NOT to be present!

Dave

 

[nikola-wan]

Dave,

Any progress on your Tektronix 4052 Emulator? You should be able to use your 4052 to see what the microcode is actually doing in the hardware.

 

[daver2]

Hi Monty,

Actually, I was doing some debugging the other week.

The microcode is working 'well' now. Focus has now turned to debugging the instruction path in the ROMs.

I have added the code for all of the I/O (including the screen code) and the interrupts.

The ROMs seem to initialise the hardware (as I would have expected them to have done) - but then I 'loose track' of the code as it is executing the firmware itself.

With the 4051 I had the BASIC ROM listings to view - so I could put 'traps' at various parts of the code. With the 4052, we don't seem to have found these listings. As a result, I am having to think about being 'creative'...

See http://bitsavers.trailing-edge.com/pdf/tektronix/405x/fiche/4051_Firmware/ from the 4051 for what I could do with for the 4052 (ideal for Version 5.1 firmware).

I do get an interrupt received from the keyboard - but this is where it appears to go belly up...

I am trying to think of ways of tracing this down. The other week I added some diagnostic code on the first interrupt to be detected. However, the microcode appears to respond to my keyboard interrupt without triggering the debug code!

Just working on that inconsistency at the moment!

Work has been absolutely hectic over the last four weeks. Starting to ease off (for me) - but I am piling the pressure on our Contract Partners who are falling behind schedule. Well (to be honest) they haven't even got a schedule - so they don't even know whether they are going to meet the deadlines or not. I am assuming not - so I am pushing them hard...

Dave

 

[nikola-wan]

Hi Dave!

Sounds like great progress!

I asked vintagetek.org if they could find DDT for the 4052, but no response.

Since we have a DDT file for the 4051 - the 4051 Assembler program uses DDT, could we try to disassemble the 4051 DDT code into 6800 source? I should then be able to try to assemble DDT for the 4052A global ROM entry points published in the documentation. Then I could try using the 6800 DDT code to disassemble a section of interest - like the keyboard interrupt?

I guess we have all the 4052 ROMs captured for version v5.1 and my 4054A v1.5 ROMs are posted on bitsavers - have you tried disassembling those ROMs?

Jos' 4052 Diagnostic ROM Pack works in both my 4052 and 4054A, so some of the entry points may be the same.

My 4052 / 4054 Architecture document in the 4052 Assembler directory indicates a couple of entry points for keyboard that I extracted from the 4052A Assembler document:

4021 CIDLE  Routine that displays cursor while waiting for keyboard I/O to come to logical end
4099 GENCUR Generate a blinking cursor
409C GETCHR Get next character from input buffer (for FP input conversion?)
409F GETKEY Handle keyboard interrupt
4105 KBQOUT Fetch a key from the type-ahead queue
4108 KEYIN  Input from keyboard
4312 KBNTCP Entry to Kb int so ROMpacks can intercept keyboard interrupts

 

[daver2]

I have added a bit more debug code this afternoon - and it is not responding to an interrupt at all...

I left the firmware 'run' whilst I had a cup of coffee - and it produced the same output regardless of whether I poked a key or not!

The firmware must have gone into a software loop checking something, and when I poked a key my brain's 'cause and effect' kicked in - but this was a mistake on my behalf!

I also noted that I had the state of the I flag the wrong way round. The I flag is a '1' to mask the interrupts out. However, changing it round had no effect whatsoever either...

I am now left with the signal LSAVEC not being set from U185 for some reason.

I keep finding out what it isn't. Eventually, I will be left with the only thing that it can be!

Some of those entry points may be useful.

Dave

 

[daver2]

I may have just found the stupidity (on my behalf).

I have copied the code from the 4051 into the 4052 to start with (to be used as a template for the 'common' functions) and then copied and pasted the code and edited it for the 4052 functionality.

It looks like the keyboard code interface that I had that worked with the 4051 doesn't work in the same way with the 4052 hardware/firmware.

I haven't included the 4051 I/O debug code in the 4052 (to save time in the copy process) but - in doing so - I now have to debug the 4052 I/O subsystem (so I am going to have to put it in). Obviously a false economy with time!

Let me see what I can do...

Dave

 

[daver2]

He, he, he...

I have found why the interrupts weren't being generated (blush)! In order to prevent me getting confused by the system generating erroneous interrupts and messing up my microcode emulation and debug work; I commented out a key piece of code buried deep within the emulator. I also forgot to enable it again now I want interrupts :-(!

Anyhow, now I am getting interrupts generated when I press a key . Unfortunately, they don't go away again :-(.

The code is in the emulated keyboard PIA (U320) to clear the IRQA1 status bit - but it stays SET for some reason.

The ROM must read the keyboard PIA to determine the key that has been pressed - and it is this read that I think should clear the pending interrupt. I will have to add a bit more debug code to see why the IRQA1 status bit is not being cleared.

That will have to be a problem for another time now. But a bit further this afternoon than I was this morning.

Dave

 

[daver2]

I have managed to persuade the emulator to dump out a reasonably short execution path from the keyboard interrupt through to the return from interrupt.

The code appears to look at everything EXCEPT the keyboard PIA!

It looks at the GPIB interface (that I am not simulating), then has a look at the COMMUNICATIONS ACIA then the COMMUNICATIONS PIA then finally performs an RTI instruction - whereupon the interrupt handler is re-entered (because the KEYBOARD PIA has not been processed, so the interrupt is still standing).

I am just wondering whether the state of some of the other devices is confusing the code into thinking they generated an interrupt when they aren't?

I will look at the disassembly that was generated when I have a little more time.

The code does make sense though - so it hasn't disappeared off to 'la la' land...

Dave

 

[daver2]

I had a bit of a 'slow day' at work today - so I felt like doing a bit of vintage computing again at home for a change...

Got a bit further with the 4052 emulator. I now know what it isn't!

I worked out how the GPIB interface hardware worked from the schematics. It turned out that the default value I returned if I haven't implemented some I/O device ($FF) was partially confusing the interrupt handler into thinking that the GPIB interface had generated the interrupt from the keyboard.

I have fixed that now - and fixed some further issues with the ACIA emulation (in receive).

What I am left with now is the keyboard PIA generating an interrupt when I poke a key on the keyboard - but it looks like the keyboard PIA is not being cleared - so the interrupt is standing. The interrupt service routine (ISR) is entered, it does some processing, exits via an RTI instruction and is promptly re-entered again because of the standing keyboard interrupt from the keyboard PIA. Repeat for infinity...

I have now gone back to basics and started to look (in detail) at all of the PIA inputs and outputs - checking the default values for signals thet I am not currently emulating to see if those are causing a problem.

I am also re-reading how the keyboard handler is supposed to work...

I have a disassembly of the ISR, so I will look at that in a bit more detail as well. It is just possible that I am not printing out some debug information when the keyboard PIA is being accessed - so I may be misleading myself into thinking that the keyboard PIA is not being accessed when (in fact) it is...

I know more now than a few hours ago!

Dave

 

[daver2]

I think I have found a significant (aka stupid) fault in my 6821 emulation of the PIA devices.

It is too late to fix anything now - so I will give it a go tomorrow.

Dave

 

[daver2]

Hmmm...

My PIA 'fix' had no effect whatsoever :-(!

I had put a previous comment in there as to why the code was there though. However, when I commented it out - the emulation didn't work at all! I have found out that the code I copied and pasted into there was wrong (I copied the wrong line of code from my 4051 emulation).

Even though it still doesn't work - I have squashed one bug that would have bitten me later anyhow. So progress...

I get the interrupt from the keyboard PIA. The microcode emulator enters the Interrupt Service Routine. The ISR checks the GPIB and ACIA for an interrupt - but ignores the keyboard! Whilst the firmware is in a 'waiting loop' - it is polling the keyboard PIA input register B. Once the keyboard interrupt is generated (and never acknowledged) we just loop around the ISR continually. All of the keyboard interrupt stuff is related to CA1 and CA2 - and not the 'B' side of the PIA.

More thinking...

Just one thing Monty (since I still haven't had time to setup my 4052) - it ended up in storage (as my wife refused to have any more **** in the house until I fixed some of them and put them into storage); what do you observe on the 4052 screen when it is first booted - but you don't touch the machine? Is it like the 4051 - and you get a completely blank screen apart from the cursor in the upper left-hand side of the screen? Or does it announce something at power-up?

I keep finding what it isn't... Eventually, I will 'stumble' across what it actually is !

Cheers,

Dave

 

[nikola-wan]

Just one thing Monty (since I still haven't had time to setup my 4052) - it ended up in storage (as my wife refused to have any more **** in the house until I fixed some of them and put them into storage); what do you observe on the 4052 screen when it is first booted - but you don't touch the machine? Is it like the 4051 - and you get a completely blank screen apart from the cursor in the upper left-hand side of the screen? Or does it announce something at power-up?

I keep finding what it isn't... Eventually, I will 'stumble' across what it actually is !

Cheers,

Dave

All the Tektronix 4050 computers on power up have a "glow" on the screen like WaveyDipole's photo with a blinking cursor. I typically wait ten seconds or so for the high voltages on the CRT to 'warm up' (the monster 19" storage tube on the 4054 is the slowest to 'warm up'), then press the PAGE key to clear any residual text from the last power on. Sometimes press it twice as I don't want any residual marks on the screen.

If a tape is inserted when the system is powered on - that tape will be rewound.

All the lamps on the right turn on and after power up is complete only the Power lamp is illuminated.

No sound, no text, just a blinking cursor on the top left of the screen like the 405x web emulator.

 

[daver2]

Cheers Monty,

That's what I assumed - but I thought I had better check with 'the authority'...

I have done my gardening job for the afternoon that I promised myself. Still nursing yesterday's blister from the gardening!

I will have another look at the 4052 emulator again...

Dave

 

[nikola-wan]

Dave,

I think you should check out the instructions in the 4052 System Test Fixture manual I converted from microfilm posted on TekWiki to a PDF
:
https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/blob/master/4052-4054_SystemTest/Tek_067-0942-99_System_Test_Fixture_instructions.pdf

Page 2 says there is a jumper needed on J239 (slow ALU) when using the System Test Fixture as the microcode is designed to run full speed or some functions don't work (your emulator in debug may be running into this issue):



Another interesting page is this one on power on system errors:




And this page has a table of the front panel Lamp states with power on error conditions:



Monty

 

[daver2]

I suspect the jumper is just for the benefit of the physical hardware etc. It should not affect my microcode emulation.

I have avoided implementing the diagnostic ROMPACK - but I may have to implement it to track this issue down.

I get the following lamp status information presented. I can see all of the transitions on my diagnostic dump - but some of the states may be so short on the physical hardware that you may miss them. The interesting will be the last state where the ROMs are waiting for an interrupt:

BUSY I/O BREAK
ON   OFF OFF
ON   ON  ON
OFF  OFF OFF
OFF  OFF ON
OFF  ON  ON
OFF  OFF OFF

Waiting for a keypress / interrupt here.

Do you observe the same lamp status (at least for the last state) on a physical machine?

EDIT: The above table was rubbish! I found an error in my diagnostic dump routine (printing things out before I had assigned the value to them). Table above corrected now - which does make sense - it it not BUSY and there is no I/O or BREAK in progress.

I am going to modify my emulation dump to see if I can identify where the ROM 'idle loop' is. EDIT: PC=$E212 and PC=$E251 is where the ROM code loops reading IRB/ORB of the keyboard PIA.

Dave

 

[WaveyDipole]

I have downloaded this emulator in addition to obtaining Brad's (Aurelian Design) emulator for Windows. Had a little play with both of them, but ran into several issues with this JavaScript based version and unfortunately could not do very much with it. Firstly can I thank the developers for making the emulator available. Secondly, can I contribute? I have done some javascript work and would be willing to help. Who is actually leading the project? I generally don't work on Windows so I haven't tried Exploder or Edge, but here is what I ran into using both Chrome and Firefox:

1. Chrome/Firefox: which starting point to launch from? jsTEKTRONIX4051.html, jsTEKTRONIX4051_universal.html or index.html?

2. Chrome/Firefox: when launching from jsTEXTRONIX4051_universal.html, then power button doesn't do anything to the emulator does not start

3. Chrome/Firefox: with either version, caps lock does not work. The only way to enter capitals is using the shift key

4. Chrome/Firefox: The = key does not work. Tried to enter a short program but my efforts were thwarted when I got something like FOR X=10..... which appeared as FOR X10.... Checked cap lock status but that did not appear to be the issue

5. Chrome/Firefox: Can't load a program from file. I selected a file and the filename shows next to the Choose button, LIST shows nothing. I even tried the --allow-file-access-from-files trick in Chrome. perhaps it needs to run on a server?

6. Firefox: none of the keys work for input. Only when I selected a file did the emulator suddenly start accepting input from the keyboard.

I expect that some of these issues might be cross-browser (in)compatibility or simply because this is a work in progress. Since I haven't got as far as running a program I can't comment on how well the programs execute or graphics rendering, however I am willing to have a go at helping to fix some of these niggles.