Compile and execution errors

[crestr1]

Compile erriors.txt
execution errors.txt

Also had a recollection that all *.ED would "LIST" as text or copy to #CN

not sure if S record assumptions are made that involves checking check-sums after assuming they exist in the *.ED

since the type and suffix are same for all *.ED i would have thought that all would be treated as *.SA

something going on here I thought *ed was type 5 (ASCII) some I looked at are type 3 (object)

[crestr1]

Seems that files can be type 5 or 3 at the discretion of the copy options, 3 qualifies them for EXBIN use to be binary converted or linked. but unfortunately disqualifies them for some ASCII uses and listing.
normally I bring them all in as ASCII in one go, my filename system under EDOS uses no informative suffixes although o and s is used in the names to denote type. They should be easier to manage all as ASCII suffix changes should be able to entirely manage their use (if any) in MDOS

[crestr1]

I also noticed that copying from the exorsim text screen causes jumbling of the screen display, this may only be due to the compile problem warning.

[jallennk]

The compiler warnings should now be fixed. Also I added an "x" (extract all files) option to mdos.c, should help with bulk extracting.

Hmm, tomorrow I'll add a command to "mdos" to set the file type to 5 on any .ED files that don't look like they are object files (that don't begin with D).

It's sneaky that COPY converts the binary to text, I didn't know or remember that it did that. Are you trying to extract these out of the EXORciser completely (so then do you want the binary or text versions?) or are you trying to get these to actually work in MDOS (to assemble and link)?

(I need to find the manual that has the binary object file format- long ago I wrote a cross-reference tool that read a bunch of these object files and made a nice cross reference listing of all the XREFs and XDEFs between modules. We were linking many files together and the cross reference was useful to go along with printed listings).

Give the new "edos" command a try to read from the EDOS images directly. I tried extracting files from those other EDOS images you sent, it looks like it's working. I don't understand what happens to the disk layout for bootable EDOS-II disks, but at least none of the ones you sent look any different, and it looks like the maximum number of directory sectors really is 5 (so 55 files max).

It uses a simple heuristic when reading files: if the file begins with 'D' assume it's an object file and leaves it unchanged (except delete NULs at end). Otherwise treat it as an ASCII file. For ASCII files, it converts line endings to UNIX (to a single linefeed- this fixes a few cases where the file has LF-CR instead of CR-LF) and it deletes the padding NULs. At least on Linux, I found that the NULs were confusing programs into thinking that some S-record files were UTF-16 encoded.

Do you think it's a good idea to delete the padding NULs? I think it's better this way if the goal is for people to look at the files or for them to be used by modern tools. On the other hand, if they are going to be loaded in a real system, the padding NULs might be needed. I guess it should be an option.

[jallennk]

Well I added it. "mdos disk.img -F" fixes the file types.

 ./mdos mdos.dsk -F
  Changed dp0s2.ed to ASCII
  Changed wavs5.ed to ASCII
  Changed dp3sf.ed to ASCII
  Changed dp4s9.ed to ASCII
  Changed vdmsb.ed to ASCII
  Changed dp2sc.ed to ASCII
  Changed macb8.ed to ASCII
  Changed lges3.ed to ASCII

[crestr1]

Thanks Joe, The thought you are giving to this is really appreciated its a big help on identifying my potential problems.

All the source code will be re-assembled to listings in exorsim, this is seems to present more meaningfully, the external print stream will be extremely important.

exorsim has become a vital component in my work it is so fast and easy and the terminal simulation is a real treasure

[crestr1]

Really encouraging progress

a double sided mdos disk and a edos disk I tested the edos.exe on follows
New disks.zip

I made some code assemblies on this mdos disk to check all is well, all the *.ed are ASCII, not tried the type correction utility yet. only need to weed out unprintable.
This now gives me the *.ls files i think i need to work with, my initial thinking is to put them into pdf files with other explanatory paragraphs. Any tricks you know to get the *.LS pagination across into the PDF would be appreciated.

My compilers seem to be fussier than yours:-

Compile probs.txt

[jallennk]

I've included an ASCII to PostScript converter I wrote in the mid 90s, it's called "lpf" (should build when you type "make").

To use it:

./lpf listing.lp listing.ps     (listing.lp is the printer file from exorsim)

You then have to convert the PostScript file to .PDF. In Linux, I use "ps2pdf", which is a script which is part of Ghostscript:

ps2pdf listing.ps listing.pdf

You could install Ghostscript in Cygwin (I'm sure it's one of the packages), or use Adobe Acrobat Distiller.

Anyway, "lpf" has some options, try "./lpf --help". But I've set the defaults so that they will work with the 120 width, 66 line output from rasm.

"lpf" writes 60 lines on each page. The output from rasm is 66 lines, so by default "lpf" deletes the first 6 lines of each input page. You can control the margins of the output with "--lmargin" and "--tmargin". You can control the input margin skipping with "--topskip" and "--botskip".

[jallennk]

I tried this site to convert the .pdf listing into a Word document:

https://smallpdf.com/pdf-to-word

It works, but don't know how editable the result is... but at least there is one way to incorporate a listing into a modern tool.

[crestr1]

Thanks for V4 Joe.
been giving it a thrash - really impressive. Thanks for the print and PDF considerations its a big help. Though would like an lp raw option that is an infinite txt, that just gets added to if you do not delete it. Maybe would like to pipe it thru grep and/or postscript later. Having a printer all the time can be really helpful keeping track of changes

Tests discovered a Bit of a prob here:
Duplicate file name Anomoly in edos.exe: Could be both the image file and edos.exe though

edos anomoly.txt

New disks.zip
a second copy

[jhallen]

So there really are multiple directory entries with the same name. Sometime they point to the same file, but in this case the "mark" byte is different between them. Sometimes they point to different files, but then they have different values in the "unknown" byte. "Mark" and "Unknown" are two bytes of the 11 byte directory entry that I don't know what they mean... sure you don't have an EDOS-II manual anywhere? :-)

Anyway, I've modified "edos.c" so that it extracts these to different files, like this. You'll have to check the duplicates manually:

./edos  M8_ACT_s0E.img x
Extracting dp0o2
Extracting dp0s2
Extracting dp2oc
Extracting dp2sc
Extracting dp3of
Extracting dp3sf
Extracting dp4o9
Extracting dp4s9
Extracting dp5o9
Extracting dp5s9
Extracting dvro3
Extracting dvrs3
Extracting fmnoh
Extracting fmnsh
Extracting gesob
Extracting gessb
Extracting inil8
Extracting inil8
File already exists, renamed to inil8.1
Extracting inil8
File already exists, renamed to inil8.2
Extracting inio8
Extracting inio8
File already exists, renamed to inio8.1
Extracting inis2
Extracting inis3
Extracting inis4
Extracting inis4
File already exists, renamed to inis4.1
Extracting inis5
Extracting inis5
File already exists, renamed to inis5.1
Extracting inis6
Extracting inis7
Extracting inis8
Extracting inis8
File already exists, renamed to inis8.1
Extracting inpom
Extracting inpsm
Extracting kefoh
Extracting kefsh
Extracting lgeo3
Extracting lges3
Extracting lil1
Extracting lil1
File already exists, renamed to lil1.1
Extracting logo2
Extracting logs2
Extracting macb8
Extracting mpko6
Extracting mpks6
Extracting plao0
Extracting plas0
Extracting tabob
Extracting tabsb
Extracting vdmob
Extracting vdmsb
Extracting wavo5
Extracting wavs5

[jhallen]

Though would like an lp raw option that is an infinite txt, that just gets added to if you do not delete it.

OK, I've changed how this works. The default is to append any line printer output to a file called "listing.lp" (it does not get deleted).

But there are options to change the file:

--lpt file          Save listing to a file (it gets deleted first)
--append file  Append listing to a file (it does not delete, append-only)

[crestr1]

all the time printer works great thanks Joe,

problem in exor.c line 946 option parsing fails so cannot try off and on options
any option defaults to help screen:

    int x;
    int diskn = 0;
    int gotox = 0;
    mon_out = stdout;
    mon_in = stdin;
    char *facts_name = "facts";
    char *lpt_name = "listing.lp";
    int lpt_append = 1;
    for (x = 1; x != argc; ++x) {
            if (argv[x][0] == '-') {   

[jhallen]

This is working for me- can you show me what command you are trying that is not working?
For example, I try:

./exor --append fred

=LIST TEST.SA;L

And the listing ends up in file "fred".

[crestr1]

Sorry to bug you but more tests Joe,

But listing.lp should have an infinite life as an automatic default and is there and active as long as no other listing file has been nominated for creation or append. It seems to get recreated under default append and named append

documented in the attached txt file.

BAD.txt

Some ps listings also, does not exit with clean process list, this may be part of the (or my) problem

[jhallen]

Sorry, you are right, was not opening for append due to a typo. I just checked in a fix.

To exit exor, you should hit Ctrl-C to get to the monitor prompt '%', then type "quit", like this:

MDOS  3.05
=Interrupt!    (hit Ctrl-C here)
    1292643 ---- Subroutine at FA8B processed by simulator ---- RTS executed ---

>   1292644 A=00 B=00 X=0120 SP=E7E7 ------          FAA2: 84 7F    ANDA #7F                 

Type 'help'
% quit

Bye
jallen@jallen-HP-Pavilion-Laptop-15-cs2xxx:~/exorsim$ 

If you hit Ctrl-Z, it will suspend exor. The number in the square brackets is the job number.
So at the shell prompt you can get a list of background jobs with "jobs", and can kill a specific one with "kill":

MDOS  3.05
=       (hit Ctrl-Z)
[1]+  Stopped                 ./exor
jallen@jallen-HP-Pavilion-Laptop-15-cs2xxx:~/exorsim$ jobs  (list jobs)
[1]+  Stopped                 ./exor
jallen@jallen-HP-Pavilion-Laptop-15-cs2xxx:~/exorsim$ kill %1   (kill job #1)
jallen@jallen-HP-Pavilion-Laptop-15-cs2xxx:~/exorsim$   (hit Enter)
[1]+  Terminated              ./exor
jallen@jallen-HP-Pavilion-Laptop-15-cs2xxx:~/exorsim$ 

Or you can resume a suspended job with "fg" or force it to run as a background job with "bg" (which makes no sense for a job waiting for terminal input, but can be useful for long running programs). I noticed that "exor" does not resume properly because it leaves the terminal in the wrong mode, I'll work on this.

This job control stuff is a feature of the UNIX shell, comes from UC Berkeley's "BSD" UNIX.