• Please review our updated Terms and Rules here

Tek 405x web-browser emulator

Thanks for the links Monty.

The first link wasn't much help (unfortunately). It did test out the instructions - but it was all manually done. I was looking for something much more automated (as a test suite) to run. I am a lazy 'so and so' in my old age - so I just expect it to say "I tested everything and it is fine" or "I have tested this instruction and it didn't give me what I was looking for and here is the fault information for you to work out what is going wrong".

Anyhow, I am writing my own test manager since I can't find one (perhaps not so lazy after all!). I implemented the INC instruction test - and that was fine. I then implemented the DEC instruction test - and that failed... I have just added some diagnostic printout tonight and found that there was a bug in my test manager :-(. The DEC instruction worked OK after all :)!

So, need to crack on with the other instruction test cases now and then I might be able to see what is happening with the shift and rotate instructions and see if anything else similar is failing.

Dave
 
First stab at my test suite...

Code: 
MC6800 Test Suite - Version 0.1 Copyright (C) DER 2020.

Addressing mode tests...

TODO:

Instruction tests...

INC - Pass.
DEC - Pass.
ASL 09 FE 7B92 01 - Fail!
ASR 04 00 7C0E 05 - Fail!
LSR 03 3F 7C63 01 - Fail!
ROL - Pass.
ROR 04 00 7D59 05 - Fail!
NEG 05 00 7DD0 04 - Fail!
COM - Pass.
CLR - Pass.
ADD - Pass.
ADC - Pass.
SUB - Pass.
SBC - Pass.
CMP - Pass.
TST - Pass.
BIT - Pass.

Failed the MC6800 Test Suite!!!

Interestingly, the 'difficult' instructions work - whereas the 'simple' instructions don't...

All of them fall into the category of flag errors - and mainly to do with either Carry (C) or Overflow (V) bits.

I know what tomorrow brings :)...

I am also working on a version of SWTBUG to include at the end of the test suite. Why not?

I am finding the split code and data space takes some getting used to... All of my test tables are in ROM (as are my messages) - so you need to perform an SDB/SDA around the ROM tables and text to access them. Easy in a standard 6800 - have to think about it in the 4052!

Dave
 
Last edited:
Dave,

Sounds like more progress!

Yes, the two 64KB address spaces take some getting used to with 4052 assembly code programming. In addition, the ability to execute code or do write operations from either memory space is yet another difference.

Plus the 4052 option ROM bank switch area is twice as big (16KB) in the 4052/54 compared to the 4051.

Monty
 
Monty,

>>> Sounds like more progress!

Every day seems to be positive progress...

Just about to have a quick look at the dreaded carry flag and see if I can formulate a plan to track the bug down. That should fix all but one of the identified errors I think.

Dave
 
daver2 said:
First stab at my test suite...

Code: 
MC6800 Test Suite - Version 0.1 Copyright (C) DER 2020.

Addressing mode tests...

TODO:

Instruction tests...

INC - Pass.
DEC - Pass.
ASL 09 FE 7B92 01 - Fail!
ASR 04 00 7C0E 05 - Fail!
LSR 03 3F 7C63 01 - Fail!
ROL - Pass.
ROR 04 00 7D59 05 - Fail!
NEG 05 00 7DD0 04 - Fail!
COM - Pass.
CLR - Pass.
ADD - Pass.
ADC - Pass.
SUB - Pass.
SBC - Pass.
CMP - Pass.
TST - Pass.
BIT - Pass.

Failed the MC6800 Test Suite!!!

Interestingly, the 'difficult' instructions work - whereas the 'simple' instructions don't...

All of them fall into the category of flag errors - and mainly to do with either Carry (C) or Overflow (V) bits.

I know what tomorrow brings :)...

I am also working on a version of SWTBUG to include at the end of the test suite. Why not?

I am finding the split code and data space takes some getting used to... All of my test tables are in ROM (as are my messages) - so you need to perform an SDB/SDA around the ROM tables and text to access them. Easy in a standard 6800 - have to think about it in the 4052!

Dave
Click to expand...

Dave,

It might be interesting to look at the Tektronix 4052/4054 Diagnostic ROM pack test of the microcode and DRAM. They may have interesting microcode tests you can use.

See Jos Dreesen's post on his remake of that board, and download the tekdiag.bin ROM file:

http://www.vcfed.org/forum/Tektronix-4052-54-diagnostic-ROM-pack-remade
 
Who's the man?!

Code: 
MC6800 Test Suite - Version 0.1 Copyright (C) DER 2020.

Addressing mode tests...


Instruction tests...

INC - Pass.
DEC - Pass.
ASL - Pass.
ASR - Pass.
LSR - Pass.
ROL - Pass.
ROR - Pass.
NEG - Pass.
COM - Pass.
CLR - Pass.
ADD - Pass.
ADC - Pass.
SUB - Pass.
SBC - Pass.
CMP - Pass.
TST - Pass.
BIT - Pass.

Passed the MC6800 Test Suite...

I had multiple issues...

1. The original test code was written for a 6809.
2. There was a bit of code commented out for one instruction test in the original 6809 that I included. The tables that were in the original instruction didn't work! I had to fix the test tables for this instruction.
3. The 6809 works subtly different (with the OVERFLOW flag usage) for the same instructions running on a 6800. The 6809 test cases therefore didn't fully test the same instructions running on the 6800. I had to modify these test cases.
4. The NEG instruction on the 4052 works differently to that on the 6800 for the CARRY flag. This has had me baffled for 2 days now! Eventually I went back to the 4052 instruction set and spotted the WARNING in the Tektronix manual! I fixed the NEG test cases and we now have a slightly less rudimentary 4052 instruction test running properly :)!

I have also let the emulator loose on the 4052 ROMS - and they even try to do something sensible would you believe.

I now need to re-implement the I/O sub-system to see how far we now get.

Dave
 
I should have quit when I was ahead shouldn't I...

Anyhow, I am now running the firmware with some dummy I/O. However, I have a funny...

With V5 ALU microcode and V5.1 MAS firmware I seem to see the firmware accessing the 4054 special display registers rather than the on-board PIAs for the display drive signals.

It is as though the firmware has been written for both a 4052 and a 4054 but needs a configuration link somewhere to set it up for one or the other machine.

I know there are two types of I/O board - so I wonder if there is a 'design feature' on one I/O board or the other to tell the firmware which type is loaded - and therefore how the firmware should behave?

Anyone any ideas before I start looking tomorrow?

Dave
 
daver2 said:
I should have quit when I was ahead shouldn't I...

Anyhow, I am now running the firmware with some dummy I/O. However, I have a funny...

With V5 ALU microcode and V5.1 MAS firmware I seem to see the firmware accessing the 4054 special display registers rather than the on-board PIAs for the display drive signals.

It is as though the firmware has been written for both a 4052 and a 4054 but needs a configuration link somewhere to set it up for one or the other machine.

I know there are two types of I/O board - so I wonder if there is a 'design feature' on one I/O board or the other to tell the firmware which type is loaded - and therefore how the firmware should behave?

Anyone any ideas before I start looking tomorrow?

Dave
Click to expand...

Dave,

I do believe that the ROM is shared between the 4052 and 4054 (same for 4052A and 4054A code).

And I believe the firmware figures out which platform - and reports the version through the RND(0) output value (for use in BASIC programs to detect the differences) as documented in the manual and quick reference guide (see table below from the quick ref guide):

Code: 
RND(0) returns the following value:

4051     0.1 ...
4052     0.70 ...
4054     0.88 ...
4054 /w Opt 30 Refresh Graphics   0.50 ...
4052A    0.79 ...
4054A    0.89 ...
4054A /w Opt 30 Refresh Graphics  0.59 ...

Of course, the RND(0) is not how the firmware detects the hardware differences.

I would think the 4051 firmware has no such check and just reports its value for RND(0).

The 4052/4054 firmware would likely use a hardware I/O register difference, in particular the 4054 has 4096x3072 D to A resolution so the display registers are different.
See the screenshot of the register list in the 4052/4054 service manual page 6-3 below.
I'll bet they look for the Display status register contents at FF10.
The 4052 doesn't have such a register - so the firmware may try to access either the 4052 display or 4054 display registers to detect which display is present.

On a detected 4054 - they would then try to detect the Refresh Graphics option board to comprehend the Opt 30 difference.

The 4054 has separate display controller board from a vector generator board - as it does vectors for text and graphics and the vectors are much faster than the 4051/4052 vectors.

4052 vs 4054 IO differences.png

Here is the full table of RND(0) return values - from the Tektronix CYCLE factory test BASIC program I posted several months ago:

Code: 
210 DATA "4051  ",217,0.196324846518
220 DATA "4052  ",1805,0.706280095237,"4052A ",1516,0.796364876486
230 DATA "4054  ",1805,0.88093139039,"4054A ",1516,0.894514130768
240 DATA "4054  ",1805,0.505007490939,"4054A ",1516,0.590965583259
250 READ I$,S9,T1

The first integer in each 'set' is the FOR/NEXT timing loop delay of about one second, used in this program.
Second value is the RND(0) returned for that computer model.

The text string was written to a test tape as the test output was logged and the test included reading and writing to the tape during burn-in of each computer.

Monty
 
Last edited:
That was exactly my thought as well.

Unfortunately, with the 'null register set' at I have at the moment, and a dummy ReadIO routine returning $00, the firmware 'thinks' it is running on a 4054 and 'hangs' reading I/O port $FF10.

I will add some slightly 'less dumb' I/O routines later and see what is happening early on with the firmware 'probing'...

Good progress though.

I am looking to enhance my test program to checkout the other (missing) instructions and addressing mode tests - just to make sure there is nothing lurking in there that we can smoke out. Just thinking about making this into a cartridge ROM for use with Jos's generic ROM board? Perhaps add some other diagnostic features that we may need? Thoughts?

Dave
 
Three more instructions added to the test - AND, ORA and EOR...

I have added some I/O diagnostic messages to see what ports are being written to (with the value) and read from.

I also modified the default return value read from a port that doesn't exist from $00 to $FF and that fixed it thinking it was a 4054...

The firmware now appears to be looping reading the X-AXIS PIA for what I assume is either the DRBUSY or VPULSE (that is not generated yet).

I will have to analyse the dump sometime to see what the firmware is up to. After scrutinising the schematics I see the 4054 has an OPTION set of links that can be switched in instead of the MAGTAPE read data. I wonder if that is the key piece of knowledge I need?

Dave
 
jdreesen said:
If you buy it I can help out with key caps and digital electronics, have some spare CPU / MAS boards.
No cover plate I am afraid....

Jos
Click to expand...

Jos,

Dave bought the 4052 and I just finished repairs and got it completely operational last night.

The keyboard is missing the "2" key cap from the top row and the wide "0" key cap from the numeric keypad.

The "3" key cap from the top row is broken - but the key cap is ok.

Have you had any success with gluing broken key switches - or do you have any replacement key switches?

Both my 4054 had broken key switches and I tried super-glue, but it didn't hold. I found a couple of the right Cherry key switches online and replaced the key switches and those keys are now fine, but I can't find anymore of those Cherry M61-0120 switches.

attachment.php


I was able to type on all three of the broken key switches as the plunger broke off all three right at the bottom of the "T" part of the key switch, leaving the thicker part of the plunger above the body of the key switch - so you can still press the plunger and get the key code.
 
Last edited:
daver2 said:
Three more instructions added to the test - AND, ORA and EOR...

I have added some I/O diagnostic messages to see what ports are being written to (with the value) and read from.

I also modified the default return value read from a port that doesn't exist from $00 to $FF and that fixed it thinking it was a 4054...

The firmware now appears to be looping reading the X-AXIS PIA for what I assume is either the DRBUSY or VPULSE (that is not generated yet).

I will have to analyse the dump sometime to see what the firmware is up to. After scrutinising the schematics I see the 4054 has an OPTION set of links that can be switched in instead of the MAGTAPE read data. I wonder if that is the key piece of knowledge I need?

Dave
Click to expand...

Dave,

Any progress on your 4052 Emulator?

Monty
 
Hi Monty,

Yes and no...

I keep having a go. I get a bit further and then hit a problem and get distracted by real paying work!

I then go back to it. Find out what the problem is, move on a bit further and then hit another problem and get distracted by real paying work again!

And so forth...

I have now got most of the I/O subsystem for the screen and keyboard etc. bolted into the emulation.

Just 'fallen over' the problem that I haven't included the interrupt processing logic of the microcode into the emulation yet! A comment currently states "BODGE - Ignore interrupts for now.". Unfortunately, now is now and I need them for the keyboard to work!

The main reason for the stop/start is that (unlike the 4051) I don't have the listings of the BASIC firmware and executive available to study. It was much easier to follow the listing file to see where I was getting stuck at and how to 'unstick' the program with the 4051. I don't have that luxury with the 4052 - so it is a bit 'suck it and see' at times!

I am also having to 'invent' new ways of debugging the microcode and firmware when it gets stuck in a loop or halts.

I am finding a few of my 'sanity checks' getting triggered (e.g. writing to ROM or example). Not sure why this is happening - unless there is some strange logic I haven't accounted for somewhere? ROM space 0xFF2A and 0xFF2B are written to? I need to enable a debug message to see whether it is microcode or firmware writing to these addresses next.

I am also getting the 'sanity check' "Why are we reading from ROM (bank switched or PATCH) at address $001A?" triggered. I am guessing the firmware is looking for additional ROM packs?

EDIT: Just answered some fo my own questions:

READ from ROM space at address $000C occurs in the microcode.

WRTE to ROM space at addresses $FF2A and $FF2B occurs in the microcode just before it starts to execute 'real' firmware instructions.

READ from ROM space at address $001A occurs within firmware.

Dave
 
Last edited:
I thought my upload of the 4052 microcode source (starting on page 13 - pdf page 17) from the 4052/4054 system text fixture docs would be helpful?

https://github.com/mmcgraw74/Tektro...-0942-99_System_Test_Fixture_instructions.pdf

page 14 of the doc (pdf page 18 ) shows the microcode handling of interrupts

top of page 21 of the doc (pdf page 25 ) shows "Initialize the PIA used for the 4052/4054 identity determination" comment
 
Last edited:
Hi Monty,

Yep, I have that document.

This is a listing of the microcode not the firmware itself.

It passes the 4052/4054 determination OK (yes, I did have a screw-up here as well - but resolved that when it started addressing I/O devices that only existed on a 4054).

However, just below that is a check at ROM address $000C for 'DB52' to determine if there is a diagnostic ROMPACK or not loaded. That answers my "Why are we reading from ROM (bank switched or PATCH) at address $000C?" question - the microcode is looking for the DIAGNOSTIC ROM. I am just considering adding the DIAGNOSTIC ROM code to the emulator in preference to the main BASIC now... The less code I have to debug - the better!

The handling of interrupts is not a MICROCODE fault. It is a DAVE fault - I put a dummy function into the microcode emulator that doesn't call the higher-level IRQ handler. I did this for debugging the microcode issues - and forgot to add it back in. However, I left the emulator running while I had a cup of coffee this morning - and found that it carried on from where I thought it was in a loop. I suspect now it was doing a memory test! Anyhow, it gets stuck in a loop further on now - but it is PEEKing at I/O ports...

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