• Please review our updated Terms and Rules here

Best way to go about emulating micro-ODT

RetroNewbie

RetroNewbie

Experienced Member
Joined
Dec 13, 2023
Messages
72
Location
Italy
I'm trying to write a PDP-11 emulator that emulates a KDF11-BA cpu board.
The problem is that I dont know what's the best way to go about emulating the micro-ODT interface. I assume that there are no 'dumps' of the microcode and even if they were they wouldnt be standard opcode instructions so that wouldnt really be helpful. Any suggestion on how to approach this?
 
It's just a little state machine that accepts addresses, simple commands and/or values - if the cpu is halted, it is active - if it is running it is not...

basically maintain a state variable and valid input chrs for that state, most invalid inputs return "?" and a new "@" prompt

the 11/03 CPU (T-11) actually supported more features - like backspace. You can pretty much ignore the "manufacturing test" option.

It's also a handy place to add extra things like a keystroke to dump a program (like a bootstrap or test code) into the emulated RAM to save re-typing it all the time...

At start up, test the halt switch input and branch to cpu emulation or ODT, depending on the setting, loop on CPU emulation until it halts and drop out to ODT, P or G resumes CPU emulation
 
Radix said:
It's just a little state machine that accepts addresses, simple commands and/or values - if the cpu is halted, it is active - if it is running it is not...

basically maintain a state variable and valid input chrs for that state, most invalid inputs return "?" and a new "@" prompt

the 11/03 CPU (T-11) actually supported more features - like backspace. You can pretty much ignore the "manufacturing test" option.

It's also a handy place to add extra things like a keystroke to dump a program (like a bootstrap or test code) into the emulated RAM to save re-typing it all the time...

At start up, test the halt switch input and branch to cpu emulation or ODT, depending on the setting, loop on CPU emulation until it halts and drop out to ODT, P or G resumes CPU emulation
Click to expand...
Thank you, I guess I'll go about implementing it in high level code then.
I was hoping that there would have been a way to abstract the cpu to just an instruction executer and the microcode as just some code in memory space.
 
As Radix stated the ODT functionality can be seen as and is easiest implemented as a statemachine. Table 3-2 (Console ODT States and Valid Input Characters) in paragraph 3.7 of the KDJ11-A CPU Module User's Guide can be seen as a state event matrix which can form the basis of a state transition diagram. For the implementation in my simulator I created the following diagram.

ODT sm.jpg

Note that this is based on the KDJ11 implementation, but my guess is that the functionality is the same for the KDF11-A.
 
Jos Fries said:
As Radix stated the ODT functionality can be seen as and is easiest implemented as a statemachine. Table 3-2 (Console ODT States and Valid Input Characters) in paragraph 3.7 of the KDJ11-A CPU Module User's Guide can be seen as a state event matrix which can form the basis of a state transition diagram. For the implementation in my simulator I created the following diagram.

View attachment 1277935

Note that this is based on the KDJ11 implementation, but my guess is that the functionality is the same for the KDF11-A.
Click to expand...
Thank you, this is really helpful, I'll probably take this approach.
 
It works well to make the ODT state machine the top-most level function (after whatever initialisation stuff you need!) - then you can call the actual emulator if in "RUN" and return to ODT when it exits, again calling the emulator on "P" or "G" instructions, and returning to ODT on halt instruction or switch - or crash...
 
Radix said:
It works well to make the ODT state machine the top-most level function (after whatever initialisation stuff you need!) - then you can call the actual emulator if in "RUN" and return to ODT when it exits, again calling the emulator on "P" or "G" instructions, and returning to ODT on halt instruction or switch - or crash...
Click to expand...
That could be an appropriate design. On every entry from "RUN" the state machine starts at the initial state.
 
Actually the KDF11 microcode is dumped, at least the russian clone of the KDF11, but one can assume that it is identical. Here is a verilog model of the KDF11:

11/23 in verilog

It should be possible to convert it into software and then run the microcode if one wish.
 
MattisLind said:
Actually the KDF11 microcode is dumped, at least the russian clone of the KDF11, but one can assume that it is identical. Here is a verilog model of the KDF11:

11/23 in verilog

It should be possible to convert it into software and then run the microcode if one wish.
Click to expand...
Thank you! If it's normal instructions I should be able to run it. Not sure about converting verilog to software since I'm working with rust with webassembly.
 
Radix said:
It works well to make the ODT state machine the top-most level function (after whatever initialisation stuff you need!) - then you can call the actual emulator if in "RUN" and return to ODT when it exits, again calling the emulator on "P" or "G" instructions, and returning to ODT on halt instruction or switch - or crash...
Click to expand...
That's a good idea but unfortunately I dont think that's an option for me. I'm planning on using the emulator in an environment where 'realistic' execution time should have somewhat of a meaning. So having micro ODT as a normal memory mapped program would make that generalization that much easier.
 
You must log in or register to reply here.
Back
Top