Trying to run MDL106 on KLH10

[ZoBoRf]

The mdl105 interpreter, which comes with the KLH10 (Panda) distribution, errors out with

$ FATAL ERROR FIXUP FILE CANT BE OPENED $

when first error occurs. It seems it looks for PS:<MDL>FIXUP.FILE which is not in place. So I wanted to try the muddle on github to see if it behaves better.

To run the MDL from https://github.com/PDP-10/muddle/tree/master/<mdl.int>
I have installed KLH10 from the Panda distribution http://panda.trailing-edge.com/.
Then zipped all <mdl.int> files with an old ZIPper, transfered them to TOPS-20 with a raw tape image, tested and unpacked them and trying to start.

All I get is

?Illegal instruction 0 at 600000
?Undefined operation code

What I do not understand:
When I try to view the textfile with

type assem.all.7

I get trash only.
When I do a

cat <ASSEM.ALL.7 >ASSEM7.ALL

I can type ASSEM7.ALL and it contains no trash. What is going on here?

Is there a way to start mdl106.exe interpreter?
Does it display errors, when it is necessary?

The version of klh10 I am using is:

$info version
 ZOBORF, PANDA TOPS-20 Monitor 7.1(21733)-4
 PANDA TOPS-20 Command processor 7.1(4453)-4

Starting with:
/kn10-kl klt20.ini

the ini file:

; Define basic device config - one DTE, one disk, one tape
devdef dte0 200   dte   master
devdef rh0  540   rh20
devdef rh1  544   rh20
devdef dsk0 rh0.0 rp    type=rp07 format=dbd9
devdef mta0 rh1.0 tm03  type=tu45

; Set Ethernet address
devdef ni0 564 ni20 ipaddr=192.168.1.110 ifc=ens38 dedic=true doarp=false

; Define the idle device on 700
devdef idler 700 host

; Set switch register
set sw=254200,,147

; Set console lights I/O base register
;Uncomment the following line if you have a Panda display.
;lights 378

devmount mta0 tapes/mdlint

; Load disk bootstrap directly
load boot.sav

; Ready to GO

[larsbrinkhoff]

No one has tested the TOPS-20 EXE files from <MDL.INT>. It's quite possible not all bits have been preserved in the binary files.

As for why you can't type a text file, sorry I don't know how to transfer files to TOPS-20. Maybe try FTP instead?

[ZoBoRf]

The files are ok, both unzip -t and od -t x1 ... shows all 8 bit bytes correctly.
I am able to unzil the file, too.

Here is a transcript of what I have done after transfer:

$dir

   TOPS20:<MDL>
 MDLINT.ZIP.1

 Total of 1270 pages in 1 file
$unzip -xjq mdlint.zip
$vd assem*.*

   TOPS20:<MDL>
 ASSEM.ALL.7;P670000        1 1464(8)    30-Apr-2019 08:43:30 OPERATOR  

 Total of 1 page in 1 file
$type assem.all
&^ShtH'^H^H4`)^A.@P!Sidp^P^R)e ^]^BITH"^P*0P Qh2!^R)ex Qh2&R(@P)^Q*4(*^H	
TH"^P*0P&R(D^H)BH^T8!S*$X^P^PI^Tp/P(t^X&TI2&R(@P)^Q*4(*^H	TH"^P*0P&R(D^H)B
H^Th)Qh2!^R)ex S*48!H	TH"^BJ$()Q*B&R(D^H)BITH"^P*0P TI^U $^H^H$H'^Wh^U^P$U	
... more trash lines ...
b&R(@P)^Q*4(*^H	TH"^P*0P&R(D^H)BJE@(^U*$(^P^PI^Tp/U^K^E*THR&R(@P)^Q*4(*^H	
TH"^P*0P&R(D^H)BJU $S	^U ^P^PI^Tp/U*DH&^R*B&R(@P)^Q*4(*^H	TH"^P*0P&R(D^H)B
JU('R^D^D^P$SKu(*Si^B&R(@P
$cat <assem.all >assem7.all
$type assem7.all
LOGIN CLR^Et
CONN INT:
MIDAS
... more text lines ...
UTILIT BIN_UTILIT MID
RESET MIDAS
MIDAS
UUOH BIN_UUOH MID
$vd assem*

   TOPS20:<MDL>
 ASSEM.ALL.7;P670000        1 1464(8)    30-Apr-2019 08:43:30 OPERATOR  
 ASSEM7.ALL.1;P777700       1 1579(7)    21-Jul-2019 23:48:46 OPERATOR  

 Total of 2 pages in 2 files

cat seems to change the byte size from (8) to (7)?
However this is not the same as a

copy assem.all.7 to assem7.all,
byte 7

I am not a 36-bit expert. I installed KLH10 some days ago to run mdl. :-)

What I have learned from the "Kermit User Guide: DECSYSTEM-20 KERMIT 1.1"
Section "Text Files and Binary Files":

The DEC-20 has an unusual word size, 36 bits. It differs from most other
systems by storing text in 7-bit, rather than 8-bit, bytes. Since text is
encoded in the 7-bit ASCII character set, this allows more efficient use of
storage. However, the word size is not a multiple of the normal byte size. The
DEC-20 therefore stores five 7-bit characters per word, with one bit left over.

It is also possible to store files with other byte sizes. The common layouts of
bytes within a word are shown in Figure 1-1.

Figure 1-1: DECSYSTEM-20 Word/Byte Organization

*7: Text Files: Five 7-bit bytes per word.*

+------+------+------+------+------++
|      |      |      |      |      ||
+------+------+------+------+------++
0      7      14     21     28     35

Normally, bit 35 is unused and set to zero. 
However, in EDIT (or SOS, or OTTO) line-numbered files, bit
35 is set to 1 when the word contains a line number.


*8: "Foreign" binary files: Four 8-bit bytes per word.*

+-------+-------+-------+-------+---+
|       |       |       |       |   |
+-------+-------+-------+-------+---+
0       8       16      24      32  35

Bits 32-35 are unused.


*36: "Native" binary files: One 36-bit byte per word.*

+-----------------------------------+
|                                   |
+-----------------------------------+
0                                   35

All bits are used.

So I suppose, I have to convert from one format to the other.
The installed Unix cat makes it so. But which native TOPS-20 command is used for that?

[ZoBoRf]

When I compare the vd ouputs of the preinstalled mdl105 with the transfered mdl106 I can see the byte size difference also, but do not know how to convert from (8) to (36):

@vd mdl105.exe

   TOPS20:<GAMES>
 MDL105.EXE.1;P777752     104 53248(36)  14-Dec-86 13:10:19 MRC       
@vd *.exe

   TOPS20:<MDL>
 MDL106.EXE.5;P670000     134 273893(8)  30-Apr-2019 08:43:30 OPERATOR  
 MDLXXX.EXE.2;P670000     123 250865(8)  30-Apr-2019 08:43:30 OPERATOR  
...
$mdl106
?Illegal instruction 0 at 600000
?Undefined operation code

Starting the preinstalled mdl105 gives:

mdl105
MUDDLE 105 IN OPERATION.
LISTENING-AT-LEVEL 1 PROCESS 1
<+ 2 40>$
42

but then...

.FOO$
?:$ FATAL ERROR FIXUP FILE CANT BE OPENED $

Perhaps the byte size difference is not the problem, perhaps the mdl106.exe is incompatible?
How to check it?

[larsbrinkhoff]

There are several potential problems.

First, the .exe files stored on your host computer may not have all bits preserved. Presumably, the files came from a TOPS-20 machine and was stored to tape. However, it's unknown how they was transferred from the tape to an 8-bit file. PDP-10 text files are usually stored as 7-bit ASCII, five characters to a word, and one bit left over. Normally, those five characters are stored in five 8-bit bytes on a modern host machine. But that additional bit? It's not always treated properly.

Secondly, the zip file stores 8-bit bytes. Apparently, the TOPS-20 zip extracts those as 8-bit byte files. I don't know how TOPS-20 type works, but from your transcript I'm guessing it's not happy about those 8-bit bytes. It seems like cat reads the 8-bit characters and writes 7-bit characters which would explain why the text comes out readable. But binary files will most likely not survive this transformation.

I'm sorry, I don't know enough about TOPS-20 to suggest a way forward.

I do know MDL 106 runs on ITS. However, it's missing many important libraries, so it may not be able to run ZILCH.

[ZoBoRf]

There are several potential problems.

First, the .exe files stored on your host computer may not have all bits preserved. Presumably, the files came from a TOPS-20 machine and was stored to tape. However, it's unknown how they was transferred from the tape to an 8-bit file. PDP-10 text files are usually stored as 7-bit ASCII, five characters to a word, and one bit left over. Normally, those five characters are stored in five 8-bit bytes on a modern host machine. But that additional bit? It's not always treated properly.

Secondly, the zip file stores 8-bit bytes. Apparently, the TOPS-20 zip extracts those as 8-bit byte files. I don't know how TOPS-20 type works, but from your transcript I'm guessing it's not happy about those 8-bit bytes. It seems like cat reads the 8-bit characters and writes 7-bit characters which would explain why the text comes out readable. But binary files will most likely not survive this transformation.

I'm sorry, I don't know enough about TOPS-20 to suggest a way forward.

I do know MDL 106 runs on ITS. However, it's missing many important libraries, so it may not be able to run ZILCH.

Thanks, that makes all sense. What is the simplest way in your opinion to get ITS with a running MDL106? On ZILF and IMDL ZILCH is running without any libraries with minor changes, nevertheless both has incompatibilities, so I'd like to check it on a "real" mdl...

[larsbrinkhoff]

The simplest way should be to clone http://github.com/PDP-10/its and type make all EMULATOR=klh10 (or whichever emulator you're most comfortable with).

[ZoBoRf]

ITS (make EMULATOR=klh10) built under my Debian 8.7 jessie in a VM without problems.
Under Ubuntu 18.10 cosmic (VM on the same host) it hangs on different times. First with "The last command timed out.", then after increment all timeouts in the TCL scripts blocks up to the configured timeout.
For example:

Compressing file DSK: EMACS1; PURIFY >
Compressing file DSK: EMACS1; CCL >
 -> DSK: EMACS; [PRFY] >
Compressing file DSK: EMACS1; EINIT >
 -> DSK: EMACS; EINIT ^Q:EJ


M-X generate Library$emacs;aux$emacs1;aux
Compressing file DSK: EMACS1; AUX >
 -> DSK: EMACS; AUX ^Q:EJ

*:kill
*:delete emacs;ts 126
*:delete [prfy] <
*:delete [pure] 162
*emacs$^S
*:teco

TECO.1213

&
The last command timed out.
make: *** [Makefile:94: out/klh10/rp0.dsk] Error 1

Now back to the working ITS:

DDT really deserves it's name... :-)

MUDDLE under ITS is doing, what I was looking for!
Now I can compare it's generated ZAP code with the code generated by ZILF and MDLI!
Thanks a lot for the work on the distribution making the past coming alive.

*:muddle
MUDDLE 56 IN OPERATION.
LISTENING-AT-LEVEL 1 PROCESS 1
<FLOAD "zilch">$
"DONE"
<DEBUG>$
T
<ROUTINE GWIM (GBIT LBIT PREP "AUX" OBJ)
 #DECL ((GBIT LBIT) FIX (OBJ) OBJECT)
 <PRINTB <PREP-FIND .PREP>>>
$

Compiling routine: GWIM
Routine called: PREP-FIND

        .FUNCT  GWIM,GBIT,LBIT,PREP,OBJ
        CALL    PREP-FIND,PREP
        PRINTB  STACK
        RTRUE
Code length: 4 bytes.
Compilation time: 0.0000000 seconds.
T

As of building MDL106 under TOPS-20, there perhaps is hope. But this excercise I let for a later time, when I learned more about MIDAS, STINK and their friends...

[ZoBoRf]

Has anyone got STINK to work on TOPS-20?

I got it compiled (taken from ITS mudsys; stink.2) after changed the first lines to:

TITLE TSTINKING ODOR
.SYMTAB 10000.
ITS==0			; FLAG SAYING WHETHER FOR ITS OR 20

IFE ITS,.INSRT MUDSYS;STENEX MID

Then assembled it with midas.458 (which comes with PANDA distribution):

$midas
MIDAS.458
*stink.bin_stink.mid
TSTINKING ODOR
 DISPATCH ROOM = 223
 HIGHEST USED = 7401
 LOWEST LOCATION LOADED  = 0
 COMMAND BUFFER LENGTH = 12000
 INITIAL CORE ALLOCATION = 5
TSTINKING ODOR
LOAD1+1		1101	 0.    14-015	OUT	Undefined
DDT1+5		3632	 0.    49-007	EXIT	Undefined
Constants area inclusive
From	To
4545	4641
5406	5412
Run time = 0.34
7228 Symbols including initial ones (72% used)
$$RESET

and linked it with:

@link
*stink.bin,stink.exe/save/go
@stink

When I try to link muddle, which I try to compile, I get:

$stink
STINK.MID
MMDL105.STINK$@$$
MDL105.STINK  

and nothing more happens.
<CTRL-T> gives something like this:

14:24:40 STINK IO wait at TYI+2  Used 0:00:02.7 in 0:37:45, Load   0.01

Also assembled STINK with MIDAS.324 (which is used for ITS-Muddle) with the same negative result.

Tried linking of single file also:

$dir stink.exe

   TOPS20:<MUDSYS>
 STINK.EXE.18

 Total of 11 pages in 1 file
$stink.exe
STINK.MID
MMAIN.BIN$L

MFOO.EXE$Y$$

and nothing more happens. CTRL-Ts give:

 14:36:10 STINK Running at LKUP1+2  Used 0:00:17.0 in 0:49:15, Load   0.23
 14:36:13 STINK Running at LKUP1  Used 0:00:20.0 in 0:49:18, Load   0.29
 14:36:14 STINK Running at LKUP1+4  Used 0:00:21.7 in 0:49:20, Load   0.32
 14:36:16 STINK Running at LKUP1+2  Used 0:00:22.7 in 0:49:21, Load   0.34
...

[larsbrinkhoff]

@ZoBoRf, as far as I can see you are doing most things right.

I don't immediately see why Midas complains OUT and EXIT are undefined. They are there in STINK.2, and it's unclear why they would not be included in the output. Maybe some conditional is wrong? I suggest examining STINK.EXE in DDT to see which parts of STINK.2 is there, and which aren't.

Your commands to STINK look right to me.

Is there a STINK that comes Panda? Perhaps experiment with that first.

CC @atsampson, who did a lot of work on the Muddle STINK.

[ZoBoRf]

OUT and LINK are unused labels in STINK.2. When I remove both of them (the labels, not the instructions) I get a version without assembly warnings:

$cd <MUDSYS>
 TOPS20:<MUDSYS> 
$324
MIDAS.324
*stink.bin_stink.mid
TSTINKING ODOR
 DISPATCH ROOM = 223
 HIGHEST USED = 7401
 LOWEST LOCATION LOADED  = 0
 COMMAND BUFFER LENGTH = 12000
 INITIAL CORE ALLOCATION = 5
TSTINKING ODOR
Constants area inclusive
From	To
4545	4641
5406	5412
Run time = 0.31
2054 Symbols including initial ones

EXIT

The resulting EXE behaves the same way like the one with the assembly warnings.

Are TWENEX and TOPS-20 "uuo compatible" ?

[larsbrinkhoff]

Your error message was:

LOAD1+1		1101	 0.    14-015	OUT	Undefined
DDT1+5		3632	 0.    49-007	EXIT	Undefined

I checked the code below the LOAD1 and DDT1 labels, and it does seem to reference OUT and EXIT, respectively. I suspect there's something fishy going on here.

TWENEX is just a nickname for TOPS-20. TENEX, on the other hand, is the predecessor to TOPS-20. TOPS-20 is mostly backwards compatible with TENEX, but maybe not 100%. For one thing, TOPS-20 added subdirectories. It's unclear if this STINK.2 would work with TENEX, TOPS-20, or both.

[larsbrinkhoff]

By the way, you are welcome to #PDP-10 on irc.freenode.net if you want a more interactive communication channel.

[ZoBoRf]

I could solve the problem with OUT and EXIT undefined with a missing closing conditional bracket in lines 1842 and 2990 of https://github.com/PDP-10/muddle/blob/master/%3Cmdl.int%3E/stink.mid.1

Got this:

$324
MIDAS.324
*stink.out_stink.mid
TSTINKING ODOR
LOADTE		1141	 0.    14-049	
	OUT	Pseudo, macro or initial sym as label
PSV17+5		3714	 0.    49-077	
	EXIT	Pseudo, macro or initial sym as label
 DISPATCH ROOM = 223
HBOT+1		5350	 0.    59-001	
	INIT	Pseudo, macro or initial sym as label
 HIGHEST USED = 7400

Then I renamed OUT, EXIT and INIT to OUTX, EXITX, INITX respecively and the assembler warnings was gone.
Stink's behavior is the same.

I'll try to look out for ignored code in the listing midas creates, in the hope to see if something is missed in assembly:

$324
MIDAS.324
*stink.bin/L_stink.mid

Perhaps I should try to link muddle with the LINK-10 llinker.

[larsbrinkhoff]

I believe TOPS-20 has OUT and EXIT JSYS calls, so Midas has those symbols predefined. STINK.2 clearly uses them as labels instead. Renaming works, but another solution is to add IF1, EXPUNGE EXIT,OUT at the beginning to remove the predefined meaning.

I'm not sure about LINK. Actually, I'm not sure if TOPS-20 Midas outputs STINK or LINK relocatable files. Scripts in <mdl.in> does use STINK, so maybe LINK can't be used. I don't see any STINK in the Panda distribution, so maybe its version of Midas doesn't write the STINK, but LINK .REL format.

[larsbrinkhoff]

Another thing to consider is how to get a MDL106.EXE file safely from the host to TOPS-20. Unfortunately, the Unix read20 program can only read DUMPER tapes, not create new ones. What I have been doing is to configure KLH10 for networking and used FTP to get files back and forth. Hopefully FTP image mode should work for an .EXE file. But first, the file must be converted to work with image mode: read20 will write it in "ASCIIized" format and FTP expects a densely packed bit stream.

[ZoBoRf]

I use FTP too.
As a test program I have built pi.exe from http://web.archive.org/web/20120617125257/http://panda.com/tops-20/pi.mid.txt

First transfered it from host PC to TOPS-20:

# ftp 192.168.1.110
Verbindung mit 192.168.1.110 wurde hergestellt.
220 Site 192.168.1.110 FTP Server Process 5Z(40)-7 at Fri 14-Aug-2020 02:39-PDT
Benutzer (192.168.1.110:(none)): rob
331 User name ok. Password, please.
Kennwort:
230 User ROB logged in at Fri 14-Aug-2020 02:39-PDT, job 11.
ftp> cd TOPS20:<MUDSYS>
250 Connected to TOPS20:<MUDSYS>.
ftp> put pi.mid.1

Then compiled it on TOPS-20:

$324
MIDAS.324
*PI.REL_PI.MID
pi ram
pi ram
Constants area inclusive
From	To
1237	1247
Run time = 0.10
1192 Symbols including initial ones

EXIT
$link
*PI.REL,PI.EXE/SAVE/GO

Transfered the exe to host PC and back to TOPS-20:

ftp> bin
200 Type I ok.
ftp> get pi.exe.1
200 Port 102.254 at host 192.168.1.242 accepted.
150 IMAGE retrieve of <MUDSYS>PI.EXE.1 started.
226 Transfer completed. 2560 (36) bytes transferred.
FTP: 11520 Bytes empfangen in 0,06Sekunden 192,00KB/s
ftp> put pi.exe.1 piex.exe
200 Port 103.0 at host 192.168.1.242 accepted.
150 IMAGE Store of <MUDSYS>PIEX.EXE.1;P777700;A started.
226 Transfer completed. 2560 (36) bytes transferred.
FTP: 11520 Bytes gesendet in 4,21Sekunden 2,73KB/s

On TOPS-20 piex.exe still works, i.e. FTP preserves the binaries:

$piex
3
1415926535 8979323846 2643383279 5028841971 6939937510 5820974944 5923078164 
0628620899 8628034825 3421170679 8214808651 3282306647 0938446095 5058223172 
5359408128 4811174502 8410270193 8521105559 6446229489 5493038196 4428810975 
6659334461 2847564823 3786783165 2712019091 4564856692 3460348610 4543266482 
^C

When I try it with an exe from github (e.g. https://github.com/PDP-10/muddle/blob/master/%3Cmdl.int%3E/mdl106.exe.5) I get this:

c:> ftp 192.168.1.110
Verbindung mit 192.168.1.110 wurde hergestellt.
220 Site 192.168.1.110 FTP Server Process 5Z(40)-7 at Fri 14-Aug-2020 03:24-PDT
Benutzer (192.168.1.110:(none)): rob
331 User name ok. Password, please.
Kennwort:
230 User ROB logged in at Fri 14-Aug-2020 03:24-PDT, job 11.
ftp> bin
200 Type I ok.
ftp> put mdl106.exe.5
200 Port 104.249 at host 192.168.1.242 accepted.
150 IMAGE Store of <ROB>MDL106.EXE.5;P777700;A started.
226 Transfer completed. 60865 (36) bytes transferred.
FTP: 273893 Bytes gesendet in 155,24Sekunden 1,76KB/s
ftp> quit

and on TOPS-20:

$mdl106
?Illegal instruction 0 at 600000
?Undefined operation code

IMO the exe and othe binaries was corrupted on transfer to github or are in a different format (Core Dump(?): http://src.gnu-darwin.org/ports/emulators/klh10/work/klh10-2.0a/doc/vtape.txt).

I don't understand fully your comment about dumper and read20, because I have to RTFM...

[larsbrinkhoff]

The files from GitHub are (or should be) in what vtape.txt refers to as ANSI-ASCII format, or Tape_Ascii. FTP uses "high-density".

To make sure the .EXE from GitHub isn't corrupted, extract the tape image with the latest read20 with the -b option.

[larsbrinkhoff]

Oops, there is no tape image.

[ZoBoRf]

I have converted the exe with

wfconv -ah <mdl106.exe.5 >mdl106x.exe.5

and transferred mdl106x.exe.5 per FTP.
Now I get:

$mdl106x
?Bad .EXE file format

Near miss. :-)

Usage: wfconv -io <infile >outfile
  where 'i' and 'o' are chars specifying the input and output formats:
    c   - Core-dump  (std tape format, 4 8-bit, 1 4-bit bytes = 36 bits)
    h   - High-density (FTP 36-bit image, 9 8-bit bytes = 72 bits)
    a,7 - Ansi-Ascii (4 7-bit, 1 8-bit byte = 36 bits)
    s,6 - Sixbit     (6 6-bit bytes = 36 bits)
    u   - Unixified  (Alan Bawden format, various = 36 bits)
    t   - Text-Newline (CRLF-NL conversion; 5 7-bit bytes = 35 bits ONLY)
    d   - Debug (for output only)
  Note: EOF on input always causes zero-padding up to a PDP-10 word boundary.

[larsbrinkhoff]

I think you did the right thing. But the person who provided the MDL106.EXE file probably didn't use the fully bit preserving extraction. I will try to fix this.

[ZoBoRf]

That would be great!

Are the tape dump images available online? The github repository https://github.com/PDP-10/muddle (and the ITS mudsys folder) seems to be the only public locations containing the muddle sources.

[larsbrinkhoff]

No, the tape images are not due to privacy concerns. I have added MDL105 and 106 .EXE files to the muddle repository. They should have all original bits preserved.

[ZoBoRf]

Converted and transfered both of them:

Lets try the first one:

$TOPS20:<ROB>mdl105.exe
MUDDLE 105 IN OPERATION.
?:$ FATAL ERROR GARBAGE COLLECTOR IS MISSING $

Lets try the second one:

$TOPS20:<ROB>mdl106.exe
MUDDLE 106 IN OPERATION.
LISTENING-AT-LEVEL 1 PROCESS 1
<FLOAD "filtst.mud">$
$:$ FATAL ERROR CANT FIND SAV FILE $

I cannot find a sav file, too... :-)

$type filtst.mud
<SET CHAN <OPEN "PRINT" "FOO.BAR">>
<PRINC "Hamster was here!" .CHAN>
<CRLF .CHAN>
<PRINC "<EOF>" .CHAN>
<CRLF .CHAN>
<BUFOUT .CHAN>
<CLOSE .CHAN>

I would like to try https://github.com/PDP-10/muddle/blob/master/%3Cmdl.int%3E/stink.exe.13 with all bits preserved.

[ZoBoRf]

Without the FLOAD:

$mdl106
MUDDLE 106 IN OPERATION.
LISTENING-AT-LEVEL 1 PROCESS 1
<SET CHAN <OPEN "PRINT" "FOO.BAR">>
<PRINC "Hamster was here!" .CHAN>
<CRLF .CHAN>
<PRINC "<EOF>" .CHAN>
<CRLF .CHAN>
<BUFOUT .CHAN>
<CLOSE .CHAN>
$
#CHANNEL [2 "PRINT" "FOO" "BAR" "DSK" "ROB" "FOO" "BAR.8;P777700;A" "TOPS20" 
"ROB" -30064672768 23748405234 80 0 0 0 0 10 
""
]

"Hamster was here!"

T

"<EOF>"

T

#CHANNEL [2 "PRINT" "FOO" "BAR" "DSK" "ROB" "FOO" "BAR.8;P777700;A" "TOPS20" 
"ROB" -30064672768 23748405234 80 0 0 0 26 10 
"er was here!
<EOF>
Hamster was here!
"]OF>

#CHANNEL [0 "PRINT" "FOO" "BAR" "DSK" "ROB" "FOO" "BAR.8;P777700;A" "TOPS20" 
"ROB" -30064672768 23085705499 80 0 0 0 26 10 ""]
<QUIT>$
$type foo.bar
Hamster was here!
<EOF>

[ZoBoRf]

BTW: The same command sequence doesn't work in ITS' MUDDLE 56.
The buffer will not be flushed. You have to add something like
<PRINC <ISTRING 1000>> there to get something in the output file.

[ZoBoRf]

The other problem in ITS' MUDDLE 56 is the garbage collector.
I have managed to get https://github.com/PDP-10/zil/blob/master/zork.z/zilch.mud.188 to compile ZORK 2 from https://eblong.com/infocom/sources/zork2-mac-r22.zip ZILCH.MUD.188 creates identical (!) *.zap files like the contained in this zip. Problem is, that it is hard to get the compilation to come to a happy end, because the garbage collector fails at different places. Nevertheless I found with trial and error some settings which work.

Now my hope is the TOPS-20 MUDDLE version could be more stable to work with.

[larsbrinkhoff]

Thanks for the updates. The `?:$ FATAL ERROR GARBAGE COLLECTOR IS MISSING $` error should be fixable. I'll ping here when there are more files to try.

[larsbrinkhoff]

Have you assembled the ZILCH output with either the Muddle based ZAP, or the one written in MIDAS?

CC @36bit

[ZoBoRf]

I have assembled the *.zap output with midas ZAP (x.mid and zap.mid are in https://eblong.com/infocom/sources/minizork-r2.zip), which runs on TOPS-20. But the output generated is not compatible with the standard infocom interpreters (for example missing header information). Looks like some sort of Muddle's gc-save format. So not much fun with it for now.

But ZILF's ZAPF assembles the output without major problems.