• Please review our updated Terms and Rules here

Can Tektronix 4051 Serial COMM be added to the 405x Emulator?

Yes, the ACIA just needs to be very simple - Always ready to accept a character and no received character. Anything else is just ignored (as you say).

It might be sensible to consider a TCP/IP port on the emulator to handle the ACIA? Just thinking out aloud...

Dave
Hi Dave,

I saw this email from the SWTPC Flex Group.

Michael Evenson has an SWTPC Emulator for the Motorola 6800 and has just added a SWTPC 6809 emulator.

He recently started work on adding an NE2000 emulation - that may be of use for the 4051 Emulator in adding networking by replacing the ACIA emulation in his emulator with NE2000 emulation.

I have posted his email from today to the Flex user group on his progress on that project.

The link to Michaels SWTPC Emulator website and the Flex User Group is in his message below.

Monty

------
fufu - SS30 prototype card

michael.evenson@flexusergroup.com <michael.evenson@flexusergroup.com>
Sun, Nov 26, 2023 at 6:49 AM​
Reply-To: FLEX UniFLEX User Group <fufu@flexusergroup.com>
To: FLEX UniFLEX User Group <fufu@flexusergroup.com>

Speaking of software, I am making great progress with the NE2000 emulation on the emulator. I have the modified version of FNETDRV connecting to the FLEX-OS9-Net-TCP application on the web server. The only changes I had to make to the FNETDRV.TXT file that gets run on the FLEX machine was to replace the ACIA schar, rchar and reset code with code to do the equivalent stuff with the NE2000 board emulation, and add an NE2000.TXT file to include that has the hardware port definitions. That all seems to be working just fine. I hope to have it fully operational next week some time. All of the utilities that go with FLEXNet should work as is since they use the FNETDRV driver to talk to the connection.

Michael Evenson
http://www.swtpcemu.com/swtpc/Downloads.htm
http://www.flexusergroup.com:8080 <- http link to the sftp site
 
TCP/IP networking within Javascript is somewhat easy already...

The only thing we may fall into is browser protection when running on a local machine.

Dave
 
@WaveyDipole solved my problem by adding another Flash Drive to his experimental 405x emulator build!
https://github.com/Twilight-Logic/Tek405xEmulator/blob/master/experimental/JonStanley-Mod-GPIB-03.zip

He said it was a complete redesign of how he had incorporated the Flash Drive on his branch of the 405x emulator.

Now his experimental version allows selection of these devices and their GPIB primary address with a new GPIB button next to Storage:

1702167840034.png


All I had to do to add a second Flash Drive is add another 4924 GPIB Tape Drive (that's what the Flash Drive emulates) at address 6.

Then the Storage popup panel allows you to change to any of the configured 4924 Tape Drives so you can add files:

1702168066804.png

The GPIB device selector is a pulldown menu in the upper right corner.

To test this new capability - I found a color artwork Ghostbusters 1984 movie poster that I liked and spent some time getting my bitmap dithering method to create the following image that can be displayed on any 4051/4052/4054 computer with R12/Fast Graphics ROM Pack:

Here is my 4052 displaying the image:

1702168277498.png

I love this movie and years ago bought the VHS tape 😁

I added the title and attribution to my bitmap creator program and replaced the RS-232 input with the Flash Drive @5: and used Flash Drive @6: to write the R12 BINARY image file.

This saved me LOTS of time - as I ran through 10 different iterations of the BMP input file until I got this result.

I increased the emulated 6800 CPU clock speed by 100x over the 4051 - or about 10x faster than my 4054A and used Johns' latest experimental 405x emulator to create the BINARY R12 image file.

I had spent a couple of days trying to create a Ghostbusters vector image - but didn't find anything satisfactory - so decided to try a bitmap - and found this one - loaded with the four main characters plus Sigourney Weaver sitting on the "R", Slimer, Gozer and Zuul and the ECTO-1 Ghostbusters station wagon.

Bottom line -
I no longer need an RS-232 interface or network interface to the 405x emulator.
 
Reviving my old thread...

I just received instructions from Micheal D. Cranford (4051 FAST GRAPHICS and 4051 EXTENDED FONTS ROM pack author) on patching the vintageTEK 4051 MAXIPACK/MAXIROM DDT v51.8 to echo DDT display output to the 4051 Option 01 COMM RS-232 interfaceor 4051 Option 10 RS-232 Printer Interface:

Code:
Micheal D. Cranford instructions to patch 4051 vintageTEK MAXIROM/MAXIPACK
DEBUG ROM (DDT) to echo all DDT output characters to Option 01 RS-232 COMM
or 4051 Option10 RS-232 printer interface.

When the 4051 CALL "DEBUG" gets executed, it prints the actual starting
address where it was loaded into the destination string, on the DVST,
so there is no requirement to chase the links through the BASIC symbol
table to find the actual start of the string data in memory.

If your 4051 does not have Option 1 installed then a Printer Interface
ROMPACK could be used, but the ACIA port addresses shown below will need
to be modified.

The relevant steps for an Option 1 equipped 4051 follow below:
==============================================================

0.  Set up your PC to be in terminal mode at 2400 BAUD, 8 data bits,
    1 stop bit, and to save received characters into a text file.
 
    You will likely need to append <LF> to send and received text since
    the 4051 only uses <CR> and not <LF>.
 
    I also set up the PC terminal mode to echo what I type on the PC
    keyboard.
 
    Since this step is so PC and terminal software dependent,
    I will not go into details about how to do those steps.
 
    All further steps shown below are on the 4051.
 
1.  DEL ALL                <== Clear memory and all previous 4051 setup
 
2.  If you have a RAMPACK installed do:
     FIND@51:141 
     OLD@51:
     RUN
    to do the Option 1 setup.
 
    Otherwise do the below steps:
     CALL "RATE",2400,1,2   <== Set up Option 1 serial port
     CALL "BREAK",5,"Ctrl-S","Ctrl-Q"
     CALL "MARGIN",1,0,0
     CALL "TERMIN"
  
    Verify that the PC and 4051 are communicating with each other by typing
    on each keyboard are seeing the other end echo what you type.
 
    If you cant get past this step, revisit the above steps.

    To return to 4051 BASIC push UDF Key 5.
 
3.   DIM A$(5632)           <== Reserve string memory for DDT code
 
4.   CALL "DEBUG", A$       <== The DDT loading address is displayed = LA
 
5.  Verify the DDT loading address with <LA>;2/
    After this step, you should see the below, but if you don't, you messed up:
     LDA A #$15             <== This pushes a return address tag onto the stack
     PSH A         CALLs, JSRs, BSRs must do this for memory compression safety
 
6.  Enter the following 6800 instructions at 7000H:
     7000'  LDA B 87C6      <== Wait for transmit register done
         '  AND B #02
         '  BEQ 7000
         '  STA A 87C5      <== Send next character
         '  JMP CBEE
 
7.  Enter the following 6800 instructions at 7010H:
     7010'  LDA B 87C6      <== Wait for transmit register done
         '  AND B #02
         '  BEQ 7010
         '  LDA A #0D       <== Special case control codes like <CR>
         '  STA A 87C5
         '  JMP C6EF
 
8.  Add 5BAH to the LA saved in #4 above (add offline) and disassemble:
     <LA+05BAH>;16'
     JMP CBEE               <== Change
     TST 21A7
     BPL 06
     LDA A #01
     LDA B #F8
     BRA 02
     CLR A
     CLR B
     STA A AA
     ORA A #FC
     STA A 8794
     STA B AB
     STA B 8796
     LDA A #19
     JMP FEB0
     JSR C6EF               <== Change
 
9.  Change JMP CBEE to JMP 7000
     7000' JMP 7000

10. Change JSR C6EF to JSR 7010
     7010' JSR 7010

    After these 2 last steps every character printed on the DVST will also
    be echoed out the RS-232 serial port.
 
    The 4051 MUST have Option 1 installed. It is at this point that I set up
    the PC received text to go into a file.
 
    You can elect to do that at the beginning, it just means that you will
    need to edit out more junk in the disassembly text file.

11. Now disassemble whatever you want starting at the appropriate address:
     <Starting Address>;1000/
    or whatever length you want disassembled.

12. Repeat as required with ;1000/
    or whatever length you want disassembled.
    Paging the screen will generally be required unless "screen Full" (flashing write
    thru "F") has been disabled.

13. Note that one or more idiots might have embedded local variable storage
    within the code stream of any routines that specifically run in DRAM,
    and as a result, the disassembly will get out of sync with the code
    (i.e. mistaking a data byte as 2 or 3 byte instruction, etc.).
 
    So you'll need to examine the resulting disassembly and go back to
    disassemble starting at the proper addresses and then edit in the changes
    to the saved text file.

    This is similar to:
     BRA 01
     <DATA BYTE>
     CLR A

    Where <DATA> was mistaken for a 2 or 3 byte instruction, so the actual
    instruction after <DATA> was not decoded correctly. Whenever that happens,
    the disassembly can remain out of sync for many instructions, so beware.
 
    DDT works this way, with idiot data storage embedded within the code,
    making the disassembly more difficult. I doubt the difficulty was
    intentional, but rather due to not ever thinking ahead, and ignoring
    good programming practices.

14. When the disassembly has finished, close the text file on the PC,
    and perform any required edits with your favorite text editor.

    To disassemble a block of data, see the DDT instruction manual.

He describes how to load DDT twice into the 4051 RAM and patch one of the two instances to copy all DDT output characters to the display to the COMM interface, and use a PC to receive the COMM output and echo the PC keyboard input to a PC file.

I still have NOT figured out how to create a 4051 assembly language program to access my GPIB Flash Drive - as the Flash Drive requires not only a GPIB primary address but also a GPIB secondary address to be configured.

@daver2 how difficult is it to add an ACIA to the 4051 EMULATOR?

If you can tell me how you would add it to your original 405x EMULATOR, I think I can figure out how to add it to the latest 4051 EMULATOR.
 
Last edited:
Since the 4051 BASIC ROM will do memory cleanup if you add variables after a program is loaded, here is my 4050 BASIC program running on the 4051 EMULATOR which has MAXIROMs installed with the DEBUG ROM:

Two 4051 DEBUG ROMs loaded in 4051 Emulator.png

You can see in this 4051 EMULATOR screenshot that DDT was first loaded in A$ at 1EB0 (immediately after the BASIC program).

I pressed F5 (UDK 5) and exited back to BASIC without typing any commands into DDT instance 1.

The BASIC program then launched DDT instance 2 into B$ at address 34B5 (5 bytes passed the end of A$).

I then typed the commands in MDC's DDT patch step 5 using the DDT instance 2 reported loading address (LA) and got the desired response.

Next I pressed F5 for the second time which exited DDT instance 2 and returned to BASIC which then printed "DONE!" and ended the program.

I wanted to see if I could then use BASIC immediate mode to return to DDT instance 2 and typed CALL"DEBUG",B$ and was returned to DDT instance 2 and repeated my test of step 5 successfully.

So this tiny BASIC program will allow me to use DDT instance 2 to disassemble DDT instance 1 manually - skipping RAM bytes within DDT and without disturbing the DDT instance 1 state.

I only need to figure out how to either add serial ACIA - output characters to a simple ASCII file, or figure out how to send the ASCII character output to an open Flash Drive file.
 
In the meantime, I have a previous attempt to disassemble DDT itself 4051 EMULATOR screendump that I OCRed and edited into a disassembly listing.

I decided to try my two DDT instance program on DDT instance 1 disassembly and immediately find DDT barfing a weird character on the illegal opcode 1Eh.

So the DDT disassembly of subsequent opcodes is messed up until 1EBD: STS

screen - 2026-02-14T081636.364.png

So I started over at 1EB0 but only disassembled the first 3 instructions, then did an assembly starting at 1EB7, the jump destination of the third instruction:

screen - 2026-02-14T081910.387.png

No more garbage characters reported and the disassembly opcodes match what I had done in Jan 2025 (although the DDT LA was 0717h in that trace), although the ADDRESSES in B5xx8 are in ROM which doesn't make any sense.

I was concerned about having the second DDT loaded, possibly using it for the two instruction disassembly modified some low memory addresses that were in the DDT instance 1 code?

I pressed the RESET button in the 4051 EMULATOR GUI which restarts BASIC ROM which clears RAM.

I then typed in immediate mode DIM A$(5632), followed by CALL "DEBUG",A$ which gave me the following screen:

screen - 2026-02-14T084836.682.png

DDT was now loaded immediately after BASIC low RAM variables - since there was no BASIC program.

I typed <LA>;5/ to disassemble the first five instructions of DDT and now I did not get a weird character and the two bytes that should be skipped are not the same as before - but have disturbed the disassembly of the instruction at the destination of the third instruction branch destination.

I then typed 062B;30/ to get 30 instructions disassembled that now have RAM addresses past DDT (0624h - 1C24h). Obviously DDT is initialized when I get the prompt to enter a command.
These RAM addresses past the end of DDT make more sense than the addresses in my previous capture which were on top of DDT code. I need to check out what the first DDT subroutine JSR 0CE7 does.
 
Last edited:
MDC just emailed me an update to the first instruction in step 8 - change the ' to / which is the DDT command for disassemble.

<LA+05BAH>;16/
 
Back
Top