Tektronix 4052 Emulator

[daver2]

Yes, the 4051 INTSRV and the 4052 IRQ handler (which probably has the same name in the source code) is structured very similar.

I have disassembled the IRQ handler and (apart from the odd improvement - for example, 6 off INX instructions are not present but a new fangled 4052 instruction "ADXI +6" to add immediately +6 to the X register) they are very, very similar. There appears to be a bit of code in the 4052 version to check the GPIB chip for interrupts.

In the 4052, the PIATBL is located at $050E. I have found various (sensible) references to $050E within the ROM code. However, when my keyboard interrupt occurs, the only thing in the table is the ACIA.

I am, therefore, trying to locate the ROM code sets up the PIATBL in RAM.

I have trapped the memory writes to this table (or round about it) and the only thing that is actually set up in it is the ACIA. I surmise, therefore, that I am searching for a bit of ROM code that is not currently executed...

Yes, I have worked out the microcode for the RETI (and the corresponding microcode for the interrupt processing itself) is slightly different to a 'real' 6800. Again, that is the beauty of using the microcode itself - you get the microcode behaviour for free!

I will check the constant ROM though now...

EDIT: My invocation of loadROM takes care of the half-filled $E000 to $FFFF constant ROM. It only loads half of the ROM image ($1000 bytes) and I use an offset of $1000 to access the last half of the ROM image.

Dave

 

[daver2]

I had a brief thought...

I disabled most of the 4052 firmware memory testing (to save time during development). I was just wondering what the memory test actually did...

It writes $CC into a memory byte (indexed by X) and checks that it is $CC.

It then writes $55 into the same memory byte and checks that it is $55.

It then sets the same memory byte to $00.

It then bumps X and loops around until most of the memory ($0000 to $FEEA) has been initialised.

I double-checked, and my 4052 emulator clears both the ROM and RAM areas to $00 before loading the relevant ROM code and starting the emulation. So, the 'untested' RAM is already $00.

So that is a red herring...

Going back to the Keyboard PIA (address $FF28) the only place that I see any reference to 'FF 28' within the ROM code (in the context of a 6-byte PIATBL structure) is at address $3CDD. However, I never find any references to $3CDD within the ROM code?

Strange.

I might go and lookup my 4051 source code listings and see how the 4051 does it...

Dave

 

[nikola-wan]

the 4051 PIATBL format is on this microfiche page:

 

[daver2]

Yep.

The PIATBL 'magic' is done within the listing of MTCTL-RAMMAP.pdf within the listing for PWRUP.LST.

Interestingly, there are two (different) tables. PIATAB and PIATBL. I think (although my brain is a bit 'mush' at the moment and I need to go and do some washing up) these tables have two (2) different formats and one (I assume the RAM version) is created from the other (ROM version) by some code within the PWRUP listing.

I suspect I am going to have to disassemble the 4052 ROM code from the entry point to where it enters the IDLE loop.

I was hoping not to have to do this - but it is quite simple to do with the emulator, I just have to wade though the disassembly output afterwards...

Dave

 

[nikola-wan]

I just did a disassembly of the 4052 v5.1 ROMs 4000, 8000, C000 after adding FF's into 0000-3FFF to properly locate the concatenated ROMs.

The 4052 Assembly documentation I posted indicates the 4000-4314 addresses are a table of JMP addresses in the ROM - starting on pdf page 85-90:
4052A-Assembler-TECO-OCR.pdf



I see the JMP table in my attached 4052 v5.1 f9dasm disassembly starting at 4000 - after editing the first couple of JMPs at 4000 to sync the listing:

./f9dasm.exe -6800 "4000-8000-C000-ROMs-64KB.BIN" > "4000-8000-C000-ROMs-64KB-dis.lst"

        STX     hdlr_RST                 ;3FF6: FF FF FF       '...'
        STX     hdlr_RST                 ;3FF9: FF FF FF       '...'
        STX     hdlr_RST                 ;3FFC: FF FF FF       '...'
        STX     M7E5C                    ;3FFF: FF             '.'
        JMP     Z5C27                    ;4000: 7E 5C 27       '.~\'
        JMP     Z5E61                    ;4003: 7E 5E 61       ''~'
        JMP     Z63F8                    ;4006: 7E 63 F8       '~c.'
        JMP     Z942F                    ;4009: 7E 94 2F       '~./'
        JMP     ZEB7C                    ;400C: 7E EB 7C       '~.|'
        JMP     ZEB9C                    ;400F: 7E EB 9C       '~..'
        JMP     Z8F62                    ;4012: 7E 8F 62       '~.b'
        JMP     ZF2CF                    ;4015: 7E F2 CF       '~..'
        JMP     ZE099                    ;4018: 7E E0 99       '~..'
        JMP     Z5CCC                    ;401B: 7E 5C CC       '~\.'
        JMP     Z63B3                    ;401E: 7E 63 B3       '~c.'
        JMP     Z6320                    ;4021: 7E 63 20       '~c '
        JMP     Z8CE7                    ;4024: 7E 8C E7       '~..'
        JMP     ZBB0E                    ;4027: 7E BB 0E       '~..'
        JMP     Z6CC0                    ;402A: 7E 6C C0       '~l.'
        JMP     Z6CBE                    ;402D: 7E 6C BE       '~l.'
        JMP     ZDFE1                    ;4030: 7E DF E1       '~..'
        JMP     Z50DA                    ;4033: 7E 50 DA       '~P.'
        JMP     Z46E3                    ;4036: 7E 46 E3       '~F.'
        JMP     Z6F09                    ;4039: 7E 6F 09       '~o.'
        JMP     ZF317                    ;403C: 7E F3 17       '~..'
        JMP     Z8729                    ;403F: 7E 87 29       '~.)'
        JMP     ZF2FE                    ;4042: 7E F2 FE       '~..'
        JMP     ZF300                    ;4045: 7E F3 00       '~..'
        JMP     Z8A37                    ;4048: 7E 8A 37       '~.7'
        JMP     ZBAD2                    ;404B: 7E BA D2       '~..'
        JMP     ZBBD5                    ;404E: 7E BB D5       '~..'
        JMP     Z84EB                    ;4051: 7E 84 EB       '~..'
        JMP     ZDFBD                    ;4054: 7E DF BD       '~..'
        JMP     Z52EC                    ;4057: 7E 52 EC       '~R.'
        JMP     ZE005                    ;405A: 7E E0 05       '~..'
        JMP     Z52E6                    ;405D: 7E 52 E6       '~R.'
        JMP     ZE3E2                    ;4060: 7E E3 E2       '~..'
        JMP     Z5187                    ;4063: 7E 51 87       '~Q.'
        JMP     Z526C                    ;4066: 7E 52 6C       '~Rl'
        JMP     Z5202                    ;4069: 7E 52 02       '~R.'
        JMP     ZB3ED                    ;406C: 7E B3 ED       '~..'
        JMP     ZB421                    ;406F: 7E B4 21       '~.!'
        JMP     ZBA8D                    ;4072: 7E BA 8D       '~..'
        JMP     ZEB84                    ;4075: 7E EB 84       '~..'
        JMP     ZEB80                    ;4078: 7E EB 80       '~..'
        JMP     Z937E                    ;407B: 7E 93 7E       '~.~'
        JMP     Z5E8B                    ;407E: 7E 5E 8B       '~^.'
        JMP     Z93BF                    ;4081: 7E 93 BF       '~..'
        JMP     Z6EFE                    ;4084: 7E 6E FE       '~n.'
        JMP     Z5E20                    ;4087: 7E 5E 20       '~^ '
        JMP     Z81E9                    ;408A: 7E 81 E9       '~..'
        JMP     Z9667                    ;408D: 7E 96 67       '~.g'
        JMP     Z7F62                    ;4090: 7E 7F 62       '~.b'
        JMP     Z51A3                    ;4093: 7E 51 A3       '~Q.'
        JMP     Z962C                    ;4096: 7E 96 2C       '~.,'
        JMP     Z5298                    ;4099: 7E 52 98       '~R.'
        JMP     Z5AB0                    ;409C: 7E 5A B0       '~Z.'
        JMP     ZED9E                    ;409F: 7E ED 9E       '~..'
        JMP     Z9846                    ;40A2: 7E 98 46       '~.F'
        JMP     Z8ED7                    ;40A5: 7E 8E D7       '~..'
        JMP     Z8ED3                    ;40A8: 7E 8E D3       '~..'
        JMP     Z9838                    ;40AB: 7E 98 38       '~.8'
        JMP     Z5791                    ;40AE: 7E 57 91       '~W.'
        JMP     Z58E6                    ;40B1: 7E 58 E6       '~X.'
        JMP     Z544A                    ;40B4: 7E 54 4A       '~TJ'
        JMP     Z8F89                    ;40B7: 7E 8F 89       '~..'
        JMP     Z8F82                    ;40BA: 7E 8F 82       '~..'
        JMP     Z626B                    ;40BD: 7E 62 6B       '~bk'
        JMP     ZEC2D                    ;40C0: 7E EC 2D       '~.-'
        JMP     ZEC56                    ;40C3: 7E EC 56       '~.V'
        JMP     ZEBDA                    ;40C6: 7E EB DA       '~..'

 

[nikola-wan]

My disassembly listing shows the IDLE loop is at 626B since the 4052A Assembly doc indicates:

40BD Idle ; Main basic idle loop entry point

40BD: 7E 62 6B

 

[nikola-wan]

You can use the latest 4051 Emulator which includes DDT and the Extended BASIC ROM PEEK and POKE commands to examine the 4051 RAM to see those tables.

Micheal D Cranford's 4051 Assembler doc indicates on page 9:

PIATABLEBEG .EQU 0H0050C ; 4051 PIA TABLE STARTING ADDRESS
PIATABLEEND .EQU 0H0058A ; 4051 PIA TABLE ENDING ADDRESS

 

[daver2]

I think I have found an (the) anomaly...

Funnily enough, the 4052 emulator has been telling me all along that something was wrong! I have just been ignoring it...

I can now see the code that is trying to set-up the PIA table for use by the interrupt service routine. However, the SDA instruction (Set Data space A) appears to be working sometimes and not others. As a result, the data that should be written into the table is being written into somewhere else... I can see the code writing the PIA addresses FF14 and FF16 (X-AXIS PIA) and FF28 and FF2A (keyboard PIA) but to the wrong locations. The problem is actually reading the X register that it has previously stored into RAM at address $1A. It writes into RAM at $1A and $1B but then reads from non-existent ROM at $1A and $1B - reading a default value of $0000.

The subsequent data writes do actually write into RAM, but now at the wrong address (because X was rubbish).

OK, having found that, I need to go looking after I have now done the washing up. I keep getting a funny look from the wife because I promised to do it a while ago!

The PIA table in the 4052 starts at $050E.

Dave

 

[nikola-wan]

 

[daver2]

I may have found the culprit...

The 'D' flag is being changed just after the instruction that uses the new value has executed!

I assume the same issue will be applicable to the 'F' bit.

It appears to be a microcode state machine timing issue.

The reason I incorporated this into the code (as it is) is that the microcode 'health check' was being confused by the flag register changing instantaneously if I did not. So, I don't want to fix one problem and create an old one again!

I will call it a day now, have a look at the schematics again, and formulate a plan whilst watching Dr. Who and having my tea...

Dave

 

[nikola-wan]

I just updated my 4051-4052-4054 Address Map for the following changes:

I found that ALL the BASIC ROMs for 4052/4054 and 4052A/4054A have a table of all the BASIC ROM assembler CALL entry points at 4000-43FF, from the 4052A Assembler document that I posted in my repository - and from examining my 6800 disassembly listing in my previous post in this thread of the 4052/4054 v5.1 ROMs that Dave is using in his 4052 Emulator.

Therefore the ENTIRE 4000-FFFF range of the BASIC ROMs in ROM space is used in ALL the 4052/4054 and 4052A/4054A models - including the 4052/4054 ROMs with earlier firmware than v5.1 with Patch ROMs.

The 4052 and 4054 models including A-Series have the same set of ROMs - and the specific model is auto-detected by the ROM code.

There is BASIC ROM code in the 8KB CONSTANTS ROM at E000 in the RAM space, so I updated the description of that ROM, so the 4052/4054 have 56KB of BASIC ROM.

The 4052/4054 BASIC ROMs are much larger than the 4051 BASIC ROMs for several reasons:

• 4051R01 Matrix Functions option ROM Pack is included
• 4051R05 Binary Program Loader option ROM Pack is included
• 4054 differences for 4054 Display and Vector Generator
• 4052 Option 1 RS-232 COMM ROM support is included (there is NO ROM on the 4052/4054 Option 1 schematic, these CALLs are in the 4000 ROMs)
• 4054 Option 30 Dynamic Graphics ROM support is included (since the Option 30 board has no access to the option ROM bus)
• 4907 Floppy Drive system or 4052 Expanded Memory CALLs in the E000 ROM (at least these are in the 4052 v5.1 ROMs I have disassembled)

The 4052A/4054A added an additional 16KB BASIC ROM at 0000 containing the new 4052A/4054A ROM CALLs for structured BASIC and other new A-Series BASIC commands that can be bank switched out of the ROM space for a total of 72KB of BASIC ROM!

I also posted this updated Address Map in my repository.

 

[daver2]

That is a very useful piece of reference material...

I have added copious amounts of debug code into the 4052 emulator this afternoon and found that the emulator is both working and not at the same time (in a superposition of states)!

I think that the sequencing of operations is not 100% correct (well, I have a bug) so I suspect I am going to have to re-write the microcode emulator section itself. Well, not re-write it, just make sure that the sequencing of everything is correct.

I will make a backup of everything - on the off chance (99.99% probability) that I mess things up in the process...

This is a job for the week now - but I need a good think...

Dave

 

[nikola-wan]

Dave,

The 4052/4054 boot from the ROM space, and I wonder if the BASIC ROM power up code moves the Interrupt handler addresses into 16 bytes of RAM (taken from the RAM decode) at addresses FFF0-FFFF at the top of the RAM space above the I/O Peripheral addresses?

So if the Emulator is not handling ROM to RAM switching properly - the interrupt vectors in RAM would NOT be properly set up?

I haven't seen your disassembly of the 4052 power up sequence, nor looked carefully at the RAM decode logic - so that theory may be easily dismissed.

A more plausible explanation might be that your emulator bug is keeping the PIATBL in RAM from being correctly updated by the ROM code.

 

[daver2]

Please ignore my post #32. It was a load of rubbish (except, of course, for the part about your very useful document update! That was true).

I know it doesn't look like much, but here are some of my diagnostic messages where the PIA table is setup in RAM...



You can see the FF14, FF16, and FF28 entries being created.

And the IRQ handler even responds with some more of my diagnostic messages when I type a key on the keyboard:



I can even type multiple keys, and the IRQ still responds!

I even get the following displayed occasionally on the emulated screen!



It doesn't look like much - but I have been waiting for this event for a while - type a key and get a vague response! To have the correct character displayed that I typed is a bonus! OK, the emulator is a bit shaky yet...

I had been a bit of a silly bug*er!

I had attributed an emulator diagnostic message to this fault when it was nothing of the kind...

It was the firmware probing the optional bank switched ROMs that was causing my diagnostic messages to be produced.

I moved the code that updated the CPU status flags (latch U385 on the ALU board) a bit further up my code - so that the latched flags had been updated before the next instruction (including the operand - a very important step) had been fetched and partially executed. I had updated latch U385 after the instruction's operand had been fetched - but not before. The 'fix' caused the PIA table to be correctly constructed in RAM, but I was fixated on the emulator diagnostic message that had nothing to do with this fault. I (basically) confused myself into thinking the fix had not worked when, in fact, it had!

It was a good job I thought a bit more before doing anything wasn't it...

Anyhow, I am going to call it a day now and will get back to this next weekend... I will, however, have the occasional 'play' and see what I need to look at next.

I have found a small error when the F status bit is updated. It should only take effect after a BRANCH has occurred. This could have an effect sooner or later - so I had better have a look at fixing it first.

Dave

 

[nikola-wan]

I just posted an update to the 4052/4054 Extended Memory File Manager on this forum and since it contains a "Mini-Toaster" board with the ROMs for that Option 27 or 28, I want to reword by last bullet in my previous post in this thread on why the 4052/4054 ROMs are so much larger than the 4051 ROMs.

• 4907 File Manager - system factory test? in the E000 ROM

The 4052 v5.1 ROM contains text strings like I see in the 4907 File Manager ROMs - but not the File Manager CALL names, so this E000 ROM code may only support Tektronix simple factory testing of the GPIB interface of the 4052 and 4054 computers - without requiring the 4907 ROM Pack to be installed.

 

[daver2]

I managed to enter a very simple program - then the 4052 bit me!




I'll take that for now!

It's plotting points OK though...

Any idea what 0200 00 is?

Dave

 

[nikola-wan]

Here is a Tekniques article on decoding 4052/4054 System Error Messages:



Although your error message is much shorter - I think you only have the last three HEX bytes 0200 00

And it is interesting that the characters all have an extra SPACE.

The article says convert 0200 hex to integer BASIC line number = 512 - which you don't have in your BASIC program.
The 00 means System ROM error - not Option ROM.

Since your program was 10 PRINT 10 - the error was caused in the PRINT routine.

I think you need to look at RAM in the emulator and see if you can find your program.
I would try 100 PRINT "HELLO" so you should be able to find the HELLO text.

The PRINT statement will be tokenized.

I did a test with 4051 Emulator DDT - my 100 PRINT "HELLO" was stored in RAM starting at 0613 as BASIC uses 16-bit unsigned integers for line numbers:



DDT got loaded into RAM with my immediate commands - after my BASIC program - you can see the DDT message string at 06C0

0064 is the 100 line number in HEX
B5 is the PRINT token
0005 is the string length (a second attempt with 100 PRINT "HELLO WORLD" got 0B for the byte in front of the H)
94 is the end of line token

Hope that helps!

You have made LOTS of progress!

 

[daver2]

>>> You have made LOTS of progress!

Yep, that is what I am thinking too!

Sometimes it is just good to go away and forget and come back with a fresh perspective!

I tried LIST on its own, and got a more comprehensive system error this time...


This looks more like the error in the Tekniques article.

We are (however) getting into the IDLE loop. I added a diagnostic message when we first hit address $626B:



I will have a look at the X and Y spacing tomorrow also.

Dave

 

[nikola-wan]

My decode of the last set of HEX digits: 00 0848 08 indicates:

Nonsensical Line number 2120
00 is the Bank Switch ID of the System ROM

And since your just typed LIST - it says the error occurred in the LIST command

 

[daver2]

The CCRF flag is latched by U661A on the MCP board when the PC is loaded from the ALU output. I may need to implement this bit of logic, otherwise (when I change the F bit in the condition code register) the change will take place instantaneously rather than waiting for a BRAnch to occur. If I get it wrong, the CPU will start fetching instructions from the wrong space, and will end up invariably crashing the machine. This looks a relatively simple modification to implement.

Right, it is getting too late now - so time for a bit of TV and bed...

Dave