MDOS.C Line 194 test and convert causes problems for EMCOPY sourced files

[crestr1]

Sorry for the brevity, just to kick this off:

MDOS.C line 194 etc test and convert text: at times makes empty from files that are created as * .ED files by MDOS EMCOPY utility. Maybe UNIX not needed nowadays or a switch is needed, maybe could harm other text files preventing RAW "as is" output.

Yes, there are still EDOS files around from Motorola's first Exorciser floppy disk system that came before MDOS in the 70's. all EMCOPY output is classed as text its binary is S records only. EDOS made,loaded and kept executables using S Records.

[crestr1]

A sample EDOS2 disk image: EDOS2 DISK Image.zip MDOS EMCOPY disk utility will extract all files on here to MDOS *.ED files on drive 0

[jhallen]

Do you have an EDOS boot disk? (does it work like this?) Do you have any EDOS documentation? I'm very curious about this OS, but I've never seen any documentation for it. Maybe you could write down some hints if you know it..

I started down the path of making raw versions of "cat" and "get".. but looking at the code reminded me that ASCII files are complex in MDOS- it has the space compression things (where multiple spaces are run-length encoded). So I'm wondering if there is just a bug in the code instead.

I ran EMCOPY on the EDOS2 disk- some of the files are text files, but some are something else- they do not look like S19 records. For example,

LIST DP0O2.ED

shows:

D%2PAGE0 OB D*3%%%%%

Is this correct? What is it?

[jhallen]

OK, I think I see what's going on. "EMCOPY ;E" treats all files as ASCII files and this is messing up the binary files. I think you should use "EMCOPY ;RE". This will treat all files as binary files, so the MDOS file type will be incorrect for ASCII files, but this is not so bad. The consequence is that EDOS ASCII files will have CR-LF line endings (instead of the MDOS native of having just CRs), will not have space compression, and will have junk at the end (a bunch of NULs and possibly other stuff).

I've add "acat" and "aget" commands to "mdos"- these will force the file to be treated as an ASCII file even if the MDOS file type is binary. If you see an EDOS ASCII file with junk at the end, try acat instead of cat.

[A secondary issue is that "mdos" always converts ASCII files to the UNIX standard (LF only at line ends). Maybe this is not good on Windows.. but I think recent versions don't really care.]

I would love to have some documentation for EDOS... please upload it. Maybe you can upload to bitsavers.org.

It reminds me of early OSs for Altair and SWTPC, "deramp" has recent videos about these on YouTube.

[jhallen]

I've also added "rawcat" and "rawget" if you want to see how MDOS ASCII files are encoded.

[jhallen]

I see that EDOS is tied up with the original EXORdisk (not the more common EXORdisk-II). The EXORdisk brochure has a short command listing. How do you boot EDOS? Did you have to manually enter a bootloader, or was there a ROM like EXORdisk-IIs "E800;G"?

The end of this brochure talks about the original EXORdisk:

http://www.bitsavers.org/components/motorola/6800/exorciser/EXORcisor_Brochure_Jul76.pdf

It mentions EDOS-II... I guess there was an EDOS-I?

[crestr1]

EDOS Manual: EDOS ExorDisk.pdf

EDOS2 came only months after the original

[crestr1]

Good Morning Joe,

Thanks for finding some interest in this ancient stuff. MDOS.c has been a godsend for recovering the Hundreds of 8" floppies in my archives of many years of work for Motorola in Australia. Being able to recover EDOS files has given me access to many archives I'd given up on. Exorsim has helped with all this, it is just al lot easier than using the Exorciser i still have.

My observations of the *.ED files was that regardless of the EMCOPY options I used they always had the text attribute and got nabbed by line 194 and sometime got converted to having a name still but no data content.. (Size 0 bytes )

I posted the EDOS manual in the git, it is too big for here

booted with E800;G but we also had autoboot Roms for our stuff

Booted using S Records and that was its only loadable image form. (code in manual)

That was the origin of the LX output from the assemblers that never went away as a default.

best regards. Tony Furse

At 06:37 AM 7/07/2023, you wrote:

OK, I think I see what's going on. "EMCOPY ;E" treats all files as ASCII files and this is messing up the binary files. I think you should use "EMCOPY ;RE". This will treat all files as binary files, so the MDOS file type will be incorrect for ASCII files, but this is not so bad. The consequence is that EDOS ASCII files will have CR-LF line endings (instead of the MDOS native of having just CRs), will not have space compression, and will have junk at the end (a bunch of NULs and possibly other stuff).

I've add "acat" and "aget" commands to "mdos"- these will force the file to be treated as an ASCII file even if the MDOS file type is binary. If you see an EDOS ASCII file with junk at the end, try acat instead of cat.

"mdos" always converts ASCII file to the UNIX standard (LF only at line ends). Maybe this is not good on Windows.. but I think recent versions don't really care.

I would love to have some documentation for EDOS... please upload it. Maybe you can upload to bitsavers.org.

It reminds my of early OSs for Altair and SWTPC, "deramp" has recent videos about these on YouTube.

­ Reply to this email directly, https://github.com/jhallen/exorsim/issues/5#issuecomment-1624279626view it on GitHub, or https://github.com/notifications/unsubscribe-auth/A7AXA6FEOGIKS6GI5C7PTSDXO4OZRANCNFSM6AAAAAAZ6NCQIYunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[jhallen]

Hi Tony,

I wrote "edos.c"- it's like "mdos.c" but for EDOS-II disk images.

I'm guessing a little bit about the disk structure... the EDOS image you sent me had the maximum number of files I think, so I'm not sure what a partially full disk looks like. Can you upload a different one?

There are some bytes in each directory that I don't understand. Do you have the EDOS-II manual?

Anyway I see three types of files: Text files, either 6800 source code or S-records. Text files as above, but with LF-CR instead of CR-LF line endings.. Some kind of binary file that begins with D, I think these are custom for your synthesizer?

"edos.c" deletes trailing NULs from the last sector of each file, but otherwise leaves them unchanged.

Let me know if this works for you..

Also there is an "x" (extract) command to just read all of the files into the current directory.

Thanks, Joe

[jhallen]

Also- thanks for the EXORdisk / EDOS-I manual, that's awesome. I used EXORciser when I was young, but always with EXORdisk-II (but we did have some very cheap version of the EXORciser with a flat front panel, not the nicely designed one you see in all the manuals).

I can probably modify exorsim to boot these disks, thinking about it.

[jhallen]

Also, type "edos --help" after compiling for the command list.

[crestr1]

Some more EDOS2 disk images as an assortment of types. Includes my "windows" (pages) source code many years before Microsoft's windows EDOS2 Disk Images.zip

This 1970's source code made this possible way back then - even before computer graphics .

[GregSchiemer]

Hi Joe,

I wrote the shell script for Tony to recover Fairlight files from floppy disk images. I’m now writing a new one to address problems with early files written under EDOS. Under Issues you mentioned adding "acat" and "aget" commands to "mdos" and also added "rawcat" and "rawget”. But the help for mdos.c looks unchanged and the help in edos.c lines 317-334 only refers to “acat” and “aget”.

    {
                help:
                printf("\nEXORciser EDOS-II diskette access\n");
                printf("\n");
                printf("Syntax: edos path-to-diskette command args\n");
                printf("\n");
                printf("  Commands:\n");
                printf("      ls [-la1A]                    Directory listing\n");
                printf("                  -l for long\n");
                printf("                  -1 to show a single name per line\n");
                printf("      cat mdos-name                 Type file to console\n");
                printf("      acat mdos-name                Type file to console, force ASCII conv\n");
                printf("      get mdos-name [local-name]    Copy file from diskette to local-name\n");
                printf("      aget mdos-name [local-name]   Copy file from disk, force ASCII conv\n");
                printf("      x                             Extract all files into current directory\n");
                printf("\n");
                return -1;
    }

My questions: do I use aget and acat ? or rawget and rawcat ? will the new script be based on mdos.c or edos.c ?

[GregSchiemer]

BTW,

the current version of my script uses get to copy the file from the floppy disk image to the local hard drive

      `echo -e "\t salvage: ${file}\t$( "$MDOS" "$FLOPPY" get "$file" "$LOCAL/$file" 2>&1 )"`

and put to restore the local copy back to the disk image

      `echo -e "\t $( "$MDOS" "$FLOPPY" put "$LOCAL/$file" "$file" )"`

[jallennk]

Hi Greg,

I'm glad there is somewhere local there working with Tony!

For archiving I would give priority to the source files and their listings (need to run them through the assembler) and the binary (S19) files. I would not worry so much about the object file (but ask Tony...). You want the listings because the source files are difficult to read directly- this is because in the mid 70s the editors were terrible so people made no attempt to make the source files with any nice formatting- the assembler did it for you.

There are two paths:

First:

Use EMCOPY in MDOS (in my emulator) to convert EDOS-II files to .ED files in MDOS. Use it like this:

=EMCOPY ;RE      Copy all EDOS files on drive :1 to MDOS on drive :0

The 'R' option assumes that all files are object files, and will mess up ASCII files (source files and binary image S19 files). MDOS needs to know the file type, but EDOS has no such concept.

So now use my "mdos" to fix the ASCII files (it looks at each .ED file and guesses the file type from its contents- but it can only change object to ASCII, not the reverse, so you need the ;R option). Exit the emulator and fix the entire disk with:

mdos mdos.dsk -F

You can test if these conversions worked with:

 =COPY file.ED,#CN     (MDOS copy a file to the console)

Object files should look like this:

=COPY DP0S2.RO,#CN
D0B32005041474530204F42C5
D2A3300000000000100000200000300000401E724504147453020000030534D455353203055434DC
DFF3400040000000300000801D7080200000A008020000003101038000001010008000180200000D
D2B35C1000401C000001400060000240007CF003401C08E01C08E01C08E01C08E01C08E01C08E018
DF63400040000F8202035203A50414745202036203A50414745202037203A50414745202038203A9
D0536000000C5

They are not on the disk in this format, MDOS COPY is converting the file to a hex dump as part of its operation.

ASCII files should show as-is. Without the fix, ASCII should print an error message instead (checksum error) when you try COPY #CN.

Now that they are converted properly, you could use "mdos" to extract the files:

./mdos mdos.dsk x      Extract all files into current directory (same as "get" or "cat").

The source files and binary files (S19) will be plain ASCII. The object files will be in their binary format, not the hex format above.

The advantage of this path is that the source files are in MDOS, so you can then use the MDOS assembler to generate a nice listing:

RASM sourcefile.SA;L       L option for listing

(use --lpt option on exor to save listing to a text file, use new "lpf" program to convert it to PostScript, then use ps2pdf to convert listing to .PDF)

Also you can print the object files in a readable format with:

=COPY objectfile,#LP

(anyway, so don't worry about acat and aget- these are to be used if the MDOS file type is incorrect).

Second

This way is much easier, just extract the files with my new "edos" command:

./edos edos_disk_image.imd x     Extract all files into current directory (same as get or cat)

The source files and binary S19 files will be plain ASCII. As above, the object files will in their binary format, not the hex format shown above.

But now the source files are not in MDOS, so no way to run RASM. Possibly you could use an open source M6800 assembler for them, but it's unlikely that a non-Motorola assembler will have exactly the same syntax for assembler directives and options.

Also no way to get the hex-dump format of the object files.

[jallennk]

Another thought for archiving: archive the ImageDisk disk images themselves in addition to the above. Reading all of the floppies and saving their images should be done first.

[GregSchiemer]

Hi Joe,

This is gold! I haven’t used exorsim so far but it’s clear your recent improvements have simplified the recovery of Fairlight CMI files. Tony and I were thinking about converting my Cygwin scripts into Powershell scripts. I think you may have just saved us the trouble. These recent additions to exorsim with mdos.c and edos.c probably give us everything we need. And if we ever find the disks with historic works created by Tony's earliest musical collaborators in 1976 and 1978 on the Qasar M8 (several years before any musician started using a Fairlight) then we now have tools for that. I have no regrets about writing scripts for your previous version of mdos.c because it has allowed us to salvage early work created by my colleagues at the Sydney Con. I look forward to using exorsim when I revisit early work I did on the M6802 and HC11 between 1984 and 1994. Thanks a million. I'll be in touch.

Greg S