• Please review our updated Terms and Rules here

Tektronix 4052/4054 Multifunction modules available.

Jos,

I have some good news - I think I found a combination of components that work in both your first MFM board and my assembly with different RTC, and both work in my 4052 and 4054A!

The components that made the difference are:
  • GAL: Lattice 22V10D-25
  • ROM: AMD AM27C010-70DC
My tests with your first MFM were:
  • No SLOW logic components installed
  • Your 0903 JED file
  • My MFM15.BIN ROM image:
My MFM assembly was tested with same JED and ROM image, with SLOW logic installed.

Since both MFM ran the same tests, in both slots of my 4052 and 4054A and passed all the tests - I think the SLOW logic is not needed.

ROM Pack image Expansion ROM slot#Hex address range
Blank100000-03FFF
Blank204000-07FFF
RS-232 Printer Interface308000-0BFFF
741RTC TransEra Real Time Clock40C000-0FFFF
750SPU TransEra Super Utilities510000-13FFF
Graphics Enhancement R12614000-17FFF
Character & Symbol R11718000-1BFFF
Blank81C000-1FFFF
[tr]

The only ROM image that has issues in the MFM is the 4907 File Manager, but my workaround was removing the 4907 File Manager from the MFM and installing the 4907 ROM pack in the left slot and MFM in the right slot.
This could be a software problem due to the order of the ROM images in the MFM - but it doesn't have to be solved right now.

Here is a table of what I tested:


ROM Pack tested Test ProgramResultComments
RS-232LIST @43: (MFM in 4052 right slot) LIST @53: (MFM in 4054 right slot)Passed with bluewire from IFC1 pin 5 to pin 7 (DTR to DCD)DTR/DCD hardware handshake needed or the bluewire. Slot is wrong in 4052 - I think BSX signals in slots are swapped in 4052, see text for more info.
741RTCRTCTEST.TXT programPassedincluding reboot with the small program stored in RTC CMOS
750SPUCALL "750SPU"PassedI need to do more testing of other CALLS
GraphEnhR2D2 programPassedlots of fast graphics calls
Chr&Symbolcouple of simple CALLsPassedneed to create a test program for this
[tr]

There are a couple of issues - but I don't think they should block other folks from enjoying your Multifunction ROM Pack for the 4052
  1. Opposite slot number for RS-232 in 4052, but right slot number in 4054
  2. 4907 File Manager didn't work in MFM, but needs to be separate ROM slot
  3. Diagnostic ROM image in slot 1 works to show the BASIC ROM CRCs, but not MFM ROMs

I would also recommend you provide the right GAL and EPROM, pre-programmed and tested, as I spent weeks ordering different ones that didn't work.
Example ones that don't work:
  • Atmel AF22V10C15PU and Atmel ATF22LV10CQZ-30PU both did not work in this design
  • Lattice 22V10D - I got on EBAY must have been clones, could not be programmed
  • Atmel AT27C010-70PU EPROM was one-time-programmable - only worked once :(

4052 ROM images that I did not test:
  • EDITOR ROM - I don't think this is needed, I use Notepad++
  • 4909 Advanced File Manager - I don't have a 4909 hard disk system
  • GPIB Enhancement for 4052 or A-series - I haven't used these ROM Packs
  • TransEra 735-SIF RS-232 interface, not needed, particularly if the Tek RS-232 can replace the backpack RS-232 you get full support from the internal BASIC including TERMIN
  • TransEra 764 Auxiliary Memory - I don't have the memory box, but wonder if the ROMs would work on a big static RAM - future Jos project :)

There was one other oddity during my testing, I was able to get your Diagnostic ROM Pack in the left slot to dump the CRCs for your MFM ROM pack in the right slot only in my 4054A.
Since all the reported CRCs matched CRC-16 calculated by HxD for each of the images in my MFM15.BIN, I think this is the best confirmation that your MFM is working.
The oddity is neither your original MFM nor my assembled MFM report any checksums when installed in the right slot of my 4052 with the Diagnostic ROM pack in the left slot.
I thought it might be due to the same issue as the RS-232 slot number (crossed BSX signals between left and right slots?), so I changed my test program to address the MFM as if it was in the left slot and that hung the 4052.
I don't think this should keep anyone from using the MFM, in particular I think the folks would find adding the Diagnostic ROM to slot 1 in the MFM valuable to tell them what BASIC firmware version they have by running my CRCDUMP program that does not attempt to access the ROM Expander slots.

Thanks for all your hard work on this 4052/4054 ROM Pack Jos!

The ROMs in the MFM15.BIN image I tested provide support for all the programs I have uploaded to github - and the programs that run on floppy will work by plugging in a 4907 ROM Pack plus your MFM, so total success!

Monty
 
Thanks for your feedback Monty.

I did not expect the PAL speed to be that critical, I'll look into that. In view of the issues you have had it will probably be better if I supplied fully tested modules.

I'll digest your post in detail tomorrow, and will let it it influence my upcoming V2 of the design, which should have a proper place for the CR2032, and 16 instead of 8 ROM images. All in the same size of course.....

Jos
 
Jos,

I agree, a fully tested module would be better.

I don't know if any more ROM images are needed - the six I put in my test image will run all the software programs I have posted on github.

It would be interesting to see if the TransEra Aux Memory ROMs could be used with static RAM. This module emulated a disk drive with 128K expandable to 1MB!
Here is the Aux Memory doc link on bitsavers:
http://www.bitsavers.org/pdf/transEra/070-6400-03_6400_Auxiliary_Memory_Nov83.pdf

Monty
 
Without either schematics or a clear picture of the Transera 6400 Box PCB that will be a difficult thing to replicate. Would be very usefull indeed...

At the moment the only option I see is to duplicate, slightly modernized, the 4907.

Alternatively we could look at the stuff that was done in Stuttgart, they managed to interface a Commodore 8050 floppy unit to a Tek4051......

Jos
 
I can't duplicate my previous result on the RS-232 Printer Interface on the MFM :(

Here is a photo from last week (when I had it working) of successfully printing with Jos' prototype MFM (hardware handshake jumper on pin 5 to 7 on RS232 IFC1) on my 4054a to a laptop running Realterm:

attachment.php


Here is the 4054a screenshot for this test:

attachment.php


The Printer Interface manual indicates that a Form Feed will be issued for every LIST command to the Printer Interface, and you see that "FF" in Realterm prior to PRINT "Hello"

I had the RS232 port speed jumper set to 9600 baud, note the Realterm settings 9600 7E1, also note CTS is asserted.

The MFM uses DTR/DCD for hardware handshake. This is very unusual and not supported by Realterm.

I had my laptop to 4052 Opt1 serial cable, a laplink serial crossover cable and my laptop to DataIO programmer serial cable near my 4054a - but I did not take a photo of which cable was connected for the test :(

I think we need to rewire the MFM RS232 hardware handshake to either RTS/CTS (my preference) or DTR/DSR (not as well supported in OSes like linux).

I used a DB9 connector I found on a PC option card with ribbon cable for motherboards without DB9 faceplate connector - on my assembly of the MFM.

And I changed the DTR/CD hardware handshake to RTS/CTS, but I couldn't find a combination of my serial cables to get the interface to work :(

Here is my MFM assembly with DB9 mounted on the bracket:
(I trimmed the bracket with my Dremel to fit the MFM mounting slots and put a floppy disk write protect metal label over the PC printer connector hole that was on the bracket, and trimmed a notch in the 3D printed MFM case to clear the DB9 cable housing):

attachment.php


I need Jos and Roland to try my MFM15.BIN file and try to reproduce the success formula for the RS232 printer interface.

My files posted on my Tektronix 4050 repository in a new Jos MFM folder:

https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/tree/master/Jos MFM test files

MFM16.BIN is the same files as MFM15.BIN with Jos 4052 Diagnostic ROM pack image added in slot 1.

So MFM16 can also be used for the RS232 Printer Interface testing.
And you can run my original 4052/4054 CRC test program CRCDUMP6.TXT - also posted in that folder to see the CRC versions of your 4052 or 4054 ROMs.

To run the CRC test program make sure the MFM is in the left slot.

My latest version of the CRC program CRCDUMP7.TXT only works with Jos' Diagnostic ROM pack in the left slot and the MFM with MFM15.ROM in the right slot (the 4052/4054 does not support multiples of the same ROM pack installed).
My hypothesis is the Diag ROM image expects to run in the left slot, not the bankswitched ROM expander slot which is a different bankswitch address.
 
Last edited:
Now the good news, I have been running the MFM in the right slot with MFM15 image and a 4907 File Manager ROM Pack installed in the left slot.

I have successfully mounted a 4907 8 inch floppy disk, loaded and run the menu and all the games I had put on that floppy including my floppy Adventure port, Star Trek, and my R2D2 display program which uses fast graphics calls in the MFM R12 Graphics Enhancement image.

I believe I had found that the 4907 ROM had worked better outside of the 4050E01 ROM Expander, or maybe there was a particular order to install it, but I leave that for another day.

I wonder whether a slight modification of Jos' Multifunction ROM Pack could add support to use the space in larger ROMs by bank switching 256 byte blocks of those ROMs into the space which would include a simple file manager ROM image like what I see in the 4041 tape drive.

I've been investigating the 4041 tape drive format - which is a little different than the 4050 tape format in that a directory is stored at the beginning of the tape with additional information like six character filename, file type, and starting and ending tape block numbers. If we would like to run some of the 4050 programs (Adventure, Star Trek, etc), that would easily fit in the 384KB space left in a 27C040 (subtracting the 128KB of MFM ROM Space), then we might be able to write the file manager code to fit within one of the 16KB MFM slots - leaving a small 256 byte space in that slot to "file block" bank switch in one of the 1536 256 byte blocks in the 384KB file system.

This file manager would have unique CALLs, but if it was only emulating a read-only file system similar to the 4041 tape drive file format with CALL "MOPEN","Filename", MREAD, etc, I could modify the programs we want to store in that tape emulator to use these calls instead of the FIND filenumber, OLD or READ calls in the 4050.
 
nikola-wan said:
I've been investigating the 4041 tape drive format - which is a little different than the 4050 tape format in that a directory is stored at the beginning of the tape with additional information like six character filename, file type, and starting and ending tape block numbers. If we would like to run some of the 4050 programs (Adventure, Star Trek, etc), that would easily fit in the 384KB space left in a 27C040 (subtracting the 128KB of MFM ROM Space), then we might be able to write the file manager code to fit within one of the 16KB MFM slots - leaving a small 256 byte space in that slot to "file block" bank switch in one of the 1536 256 byte blocks in the 384KB file system.
.
Click to expand...

Isn't that exactly what the Transera RAM cartridge does ? It has firmware that implements a filesystem in RAM. And it definitly looks like it is not much more than a few presettable counters with some DRAM.

The way I see it it should be possible to have both a static RAM and a ROM inside a RAM-cartridge, with the firmware residing in the MFM rom, and thus have a 1 MB RAM disk with an additional 1MB readonly ROM disk. Adding a CR2032 and some circuitry could easily implement a "continous memory" 1MB space. That would be sufficient "diskspace" needs. And why not make multiple RAM/ROM cartridges if you need more ?

If you have the PAL contents of that Transera module I should be able to reverse engineer it into logic equations.

The MFM RS232 is an exact copy of the Tektronix implementation, bar the selectable baudrate. There might be better ways of implementing things, I'll check your ROM image.

Jos
 
jdreesen said:
Isn't that exactly what the Transera RAM cartridge does ? It has firmware that implements a filesystem in RAM. And it definitly looks like it is not much more than a few presettable counters with some DRAM.

The way I see it it should be possible to have both a static RAM and a ROM inside a RAM-cartridge, with the firmware residing in the MFM rom, and thus have a 1 MB RAM disk with an additional 1MB readonly ROM disk. Adding a CR2032 and some circuitry could easily implement a "continous memory" 1MB space. That would be sufficient "diskspace" needs. And why not make multiple RAM/ROM cartridges if you need more ?

If you have the PAL contents of that Transera module I should be able to reverse engineer it into logic equations.

Jos
Click to expand...

I'll see if I can read the PAL on the TransEra Auxiliary Memory ROM Pack.

Monty
 
TransEra 764-RAM Tektronix 4052/4054 ROM Pack 12L6 PAL

TransEra 764-RAM Tektronix 4052/4054 ROM Pack 12L6 PAL

Jos,

Here is my capture of the TransEra Auxiliary Memory ROM Pack 12L6 PAL:

Code: 
TransEra 764-RAM 4052/4054 Auxiliary Memory ROM PACK

National DMPAL12L6NC read with DataIO 29B with 303A-011A adapter
****************************************************************

                         DATA I/O CORPORATION
                - Programmable Logic Development System - 

      - GENERAL COMMANDS -                    - I/O COMMANDS - 
0 - Display menu                        B - Receive JEDEC data 
1 - Enter Family/pinout code            C - Transmit JEDEC data 
5 - Enter reject count option
6 - Enter verify option
7 - Enter security fuse option
8 - Enter functional test data 
F - Configuration number 
G - Select attributes
H - Select continuity test 

    - DEVICE RELATED  COMMANDS -              - FUSE MAP COMMANDS - 
2 - Load device                         A - Display fuse pattern
3 - Verify device                       D - Display fuse sumcheck
4 - Program device                      E - Edit fuse pattern

NOTE - Always transmit an "ESC" before removing adapter 

 Command :  A - Display fuse pattern

      00          10          20          
0000  -X-XX--XX-  ---X------  ---X
0024  -X-X-X-X--  ----------  --X-
0048  -XX-X--X-X  ---X------  ---X
0072  XXXXXXXXXX  XXXXXXXXXX  XXXX
0096  ---------X  ----------  --X-
0120  --------X-  ----------  ---X
0144  X--X-X-X--  ----------  --X-
0168  XXXXXXXXXX  XXXXXXXXXX  XXXX
0192  -------X--  -X----X---  -X--
0216  ----------  -X----X---  X---
0240  -------X--  -X--X-X---  -X--
0264  ----------  -X--X-X---  X---
0288  -XX-X--XX-  ---X------  ---X
0312  -XX--X-X--  ----------  --X-
0336  X--XX--X-X  ---X------  ---X
0360  XXXXXXXXXX  XXXXXXXXXX  XXXX
Sumcheck 1C74

 Command :  D - Display fuse sumcheck

Sumcheck 1C74

 Command :  C - Transmit JEDEC data 
*
QP20*
QF0384*
L0000 
101001100111101111111110
101010101111111111111101
100101101011101111111110
000000000000000000000000
111111111011111111111101
111111110111111111111110
011010101111111111111101
000000000000000000000000
111111101110111101111011
111111111110111101110111*
L0240 
111111101110110101111011
111111111110110101110111
100101100111101111111110
100110101111111111111101
011001101011101111111110
000000000000000000000000*
C1C74*
51DD
 Command : 
 
****************************************************
12L6
PIN	764-RAM Signal
---     --------------
1	A12
2	A13
3	A15
4	A11
5	EPIA
6       SLOW
7	PIAE (and PIAE also goes to Pin 16 74LS373 near the cable)
8	A4
9	A3
10	GND
11	4.7K resistor to +5V
12	connected to PAL pin 11
13	Pin 20 EPROM II  (PD and /EN to read)
14	Pin 19 74LS245   (OE) near the cable, this signal is then connected to 74LS373 pin 11 (Latch Enable)
15	Pin 4  74LS373 near the cable (maybe data ready from aux memory box?)
16	Pin 20 EPROM III (PD and /EN to read)
17	Pin 18 all three EPROMs
18	Pin 20 EPROM I   (PD and /EN to read)
19	BS
20	+5V
 
Last edited:
Jos and Roland,

I figured out my issue with getting the MFM RS-232 printer interface to work again - my rewiring of my DB-9 connector had only changed one of the two handshake signals, now my MFM RS-232 printer interface works.

My DB-9 connector rewiring disconnects the connector from DB-9 pin 1 and wires the board signal to DB-9 pin 7. DB-9 pin 4 is disconnected from the board and that signal is wired to DB-9 pin 8.

This changes the DB-9 pinout to match the PC DB-9 pinout with RTS on pin 7 and CTS on pin 8.

Now - connect the PC to the RS-232 printer interface with a DB-9 to DB-9 crossover cable - like the old "Laplink" red serial cable.

Configure Realterm for RTS/CTS hardware handshake and the baud rate to match the baud rate jumper on the MFM board.

I have listed a long program from the 4052 to the PC - and had no issue, other than the 4050 converted the control characters in the program to Character BS _.

Roland - you should be able to cut the connections from the RS-232 drivers and rewire them to the DB-9 pins 7 and 8 as above.

Since you don't have Option 1 - I think you should do the mod Jos suggested, so you get full 4052 TX/RX support including the TERMINAL mode! That will also give you XON/XOFF hardware handshake.

Monty
 
Jos,

Looking again at the Opt 1 Serial Interface in the 4052/4054 schematics, I think the RS-232 Printer Interface won't work with RTS/CTS hardware handshake - the 68B50 in Option1 doesn't connect the RTS/CTS on the ACIA, those pins are connected to a PIA, which also decodes the BSX lines for the slots.

Roland and others should still be able to use the RS-232 printer interface with XON/XOFF software handshake if they mod their ROM backpack board as you suggested.
 
Another update from testing.

I moved the 4050E01 to my 4052 computer and inserted the original ROM Packs in the same slots as my MFM17 test image.

I also modified my CRC program to CRC-16 the entire 16KB of each ROM Pack and compare against a known CRC and print the type of ROM Pack.

This worked fine with the Diag ROM Pack in the left slot of my 4052 and 4050E01 plugged into the right slot.

Here is a photo of the ROM Packs loaded into the 4050E01 in the same order as in my MFM17 image:

attachment.php


I have had ROM images in slot 8 get duplicated to slot 1 so I left both of those unused for this test.

I've uploaded my MFM CRC program - I want Jos and Roland to try it on their MFMs and 4052's with the Diag ROM Pack in left slot and MFM in right slot.

Note that my CRC program for ROM Packs does a CRC of the entire 16KB ROM Pack space - so the Diag ROM checksum is not the same as Tek published but is correct if you check 16KB.

My CRC_DUMP10MFM program link below has the original ROM checksums shown on the screenshot.

https://github.com/mmcgraw74/Tektro...b/master/Jos MFM test files/CRC_DUMP10MFM.txt

Here is what the MFM CRC output looks like in my 4052 with the 4050E01 and original ROM Packs in the right slot and Diag ROM in the left slot:

attachment.php


Note also in this photo that the 4050E01 expander slots show up as 41-48, not the expected 51-58 for the Expander plugged in the right slot.
This is why the RS-232 Printer Interface is addressed in slot 43 - NOT 53, hmmm

Now I turned off my 4052 and unplugged the 4050E01 and plugged in my MFM ROM Pack in the same slot on the right of the Diag ROM Pack.

Here is the output of the same MFM CRC program:

attachment.php


Several differences:

1 - The Diag ROM CRC is now different. This is bad news - something is colliding with this ROM when the MFM is present
2 - Only the Character & Symbol ROM Pack matches the original ROM packs in a 4050E01

On the good news side - the MFM slots also show up on the left side just like the 4050E01.
Also, I believe the CRC-16 values match what HxD calculates for the 16KB range for each ROM in the MFM image

What doesn't work is the MFM17 with 4907 File Manager image - I can mount the disk and get a directory, but the 4052 cannot "OLD" any of the programs.

I repeated these tests with MFM17 on my 4054A. Here is the CRC result screenshot:

attachment.php


Ok I cheated on this shot, I edited the CRCs to get the program to print out the ROM names.
I did not erase my MFM EPROM, I just zeroed the diag rom image - so that's why the crc for slot 1 came up zero too.

On the good side - the MFM CRCs reported on the 4054A match the report on my 4052.
Also note - the MFM ROM Packs are reported in the right slot, and the RS-232 Printer interface works in 53, not 43 like in the 4052.

Bad news - the CRC reported for the Diag ROM in the 4054A is different than the same Diag ROM CRC reported by the 4052 and different than reported with the 4050E01 :(

I can get the 4907 to work with the original ROM Pack in the left slot of my 4052 and the MFM15 image that does not have the 4907 image.

We aren't quite done with the MFM yet.
 
MFM is WORKING!!!

MFM is WORKING!!!

Jos,

I believe your MFM is NOW WORKING!!!

I figured out my 4907 issue - the 3rd ROM I uploaded had a stuck data bit - so that image was corrupted.
I re-captured the 3rd ROM in my cartridge and put the new 4907 image in the MFM18 ROM I uploaded to github:

https://github.com/mmcgraw74/Tektro...iles/blob/master/Jos MFM test files/MFM18.BIN

I also uploaded in that folder my CRC version 18 program that includes checking the backpack slots and the ROM Expander or MFM:
https://github.com/mmcgraw74/Tektro...b/master/Jos MFM test files/CRC_DUMP18MFM.txt

It took a while to figure out with my CRC program how to get an MFM image to match the CRCs in the Tektronix list - now everything matches!

Here is a photo of the the 4050E01 ROM Expander loaded with the original ROM Packs in the same order I put them in the MFM 18 image:

attachment.php


And the resulting CRCs with the 4050E01:

attachment.php


Try this on your 4052 with Diag ROM and MFM - should match the photo above.

Both my 4054A and 4052 matched the CRC report with MFM18 ROM image.

My 4907 worked with my 4052 and the MFM18 ROM - the torture test is loading Adventure and playing Adventure!

attachment.php


Your MFM should be ready to ship!

Monty
 
I forgot to describe the different CRC columns in the program.

The Tektronix CRC list for 4052/4054 is a little mysterious, and took me a while to decode how they did it.

Some of the CRC for the internal BASIC ROMs are 8KB, some 4KB, some 1KB.

Same with the ROM Packs.

In addition, the reported CRC-16 values do not match individual ROMs in some cases - like the reported value of the RS-232 Printer Interface ROM.

I guessed that I would have to narrow the address range to see if some of the ROMs were not fully decoded, and repeated within the 16KB address space - that guess was correct for both the RS-232 and TransEra 741-RTC.

Also, many of the 4052 ROM Packs with three ROMs only have two CRC values reported - with the first value labeled as "combined"

These "combined" CRC-16 use an 8KB range and the other ROM is only 4KB range for the CRC.

My current CRC program uses an 8KB range to identify which ROM Pack, then displays four 4KB CRC-16 values which typically are for each of up to four 2732 EPROMs.

CRC-16 values of 0000 indicate all zeroes in that block, 5000 and 6000 are blocks with FF.

attachment.php


The yellow labels on the screenshot above indicate which range is used for the report.

The R12 Graphics Enhancement ROM Pack image is v1.04 - newer than the v1.0 reported in the Tektronix CRC list
 
Hi Monty, good to see it has finally worked out. \
Would have been though for me to figure out what was wrong with the 4907, without having acces to such a device.
I w ill try your CRC program, after I repair my 4052 again, after another breakdown yesterday......

Jos
 
Just looked at my backpack documentation : bsx l/r are interchanged between the communications backpack and the firmware backpack. That is why the expander shows up in the wrong slots.....Clearly an implementation error from Tektronix.
 
Jos,

Hope you can easily fix your 4052.

I posted updates to my github repo:
  • Updated the 4052 File Manager-01 folder with the corrected U13 EPROM image
  • Updated the Jos MFM Test Files folder with my instructions for RS232 connector mod for RTS/CTS in the README
  • Added my photo with the CRC column labels

I would be the RS-232 interface could be used to "OLD" programs into the 4052 without modifying the backpack with my mod above - but you wouldn't get the BASIC ROM Terminal emulator feature.

I think modifying the backpack per Jos' instructions would work with software handshake selected instead of HW handshake.

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