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.

[jhallen]

A faster way to exit "exor": hit Ctrl-C twice.

Also I fixed Ctrl-Z suspend. You can type "fg" at the shell to resume it.

[johnsonjh]

Just wanted to say I've been quietly following all this recent work you guys have been doing and it's excellent.

[crestr1]

G'day Joe
What you have made here is just so fast and terrific to use, many thanks

Just looking at the all the PDFs I've made from EDOS files
i think a problem with CR/LF giving a double spaced end result PDF

Making ps from. MDOS lp.zip

Tool Chain is:
bhfs1.sa comes from EDOS recovery edited to BACH.sa, MDOS put to mdos.dsk
RASM to listing.lp, lpf to listing .ps, converted to PDF on net freebie converter.

i think in transfer by MDOS PUT the 0As become 0Ds
A useful fix may be in conversion to .ps to allow both CR/LF formats
however listing.lp could use more width if possible but is usually needed DOS formatted

[jhallen]

Hi Tony,

OK, I've modified edos and mdos to use MS-DOS line endings instead of UNIX. mdos will now accept either format when "putting", so this should fix the problem where you get double-spacing when "putting" an ASCII file onto an mdos disk image.

I'm not sure I understand what you are saying about the .pdf file: the one in the .zip file looks OK to me- no double-spacing. Is there a problem with it that I'm missing? The only case I can think where you would see double spacing if you had "put" an MS-DOS file on an mdos disk image and then printed it.

The listing.lp file should be in MS-DOS format: mdos (the operating system) prints with CR-LF.

"lpf" does not care what the format is, MS-DOS or UNIX will work.

BTW, in Linux (WSL) there should be a command "hd filename" to print a hex-dump of a file.

I can just imagine younger-you tediously entering a Bach Fugue in assembly language using EDOS "edit" :-)

Thanks!
Joe

[crestr1]

Thanks Joe, I really appreciate this help,

Sorry my comments on the pdf double spacing is wrong, it is the line spacing that appears unusual,must be an artifact of the typeface chosen.

About to can using WSL and go back to using Cygwin you cannot find where the WSL filesystem backups are in Acronis backups. I often need to get files out of old backups. Ms has carefully hidden the windows pseudo net port that gets you into WSL. It works a bit better if you install the linux in a WSL2 Docker container but that brings lots of CPU resource gobblers with it. Cygwin is just so much easier to live with it has a firm footing in both worlds and i've been running it in another computer shadowing the work under Ubuntu and WSL in a new AMD w10

Only the days of invention bought hard work in entering music this way, this resolved in several ways as the M8 morphed into the CMI after I ported MDOS to the Qasar dual CPU to make QDOS, but the direct descendant of this was CMI MCL (music composition language) which linked to the timing requirements of film and advertising media production. MCL allowed a composer to also add studio staff directions on applying the sounds and music in real time to the end media the composer was commissioned for but without his presence,. It could also apply sounds and silences under control of standardized clock tracks

[crestr1]

What i really found useful in Cygwin was being able to quickly process the EDOS extractions to useful collections and file names.
I used the WIN GUI to isolate the source text files with a ???s search that i could cut and paste to a source folder within the extraction folder and then i could "bulk rename" all to have .sa suffixes all this done in a folder tree rooted in the Cygwin exorsim base folder
i found it very useful to be able to create folders amenable to ../edos actions that also had a foot in the windows world

[crestr1]

G'day Joe,
i think there is a problem in mdos.c it seems to corrupt the destination mdos.dsk if the 'put' path fails.
the following zip contains some info and an example corrupted disk it is not a very recent problem.

Mdos put problem.zip

the disk was the default mdos.dsk image exor uses

[jhallen]

This should be fixed now, 'put' was not dealing with names in paths correctly.
Also now it will complain for invalid MDOS names: they must start with a letter and be composed of only letters and numbers.

You can give a separate mdos name with put: ./mdos disk.dsk some/long/path/myfile file.sa <-
myfile will be called file.sa on the disk.

[crestr1]

Thanks Joe it works far more predictably now
sometime i needed to put the path list in quotes "..." even for paths that cat will accept.

[crestr1]

Sorry Joe, Using more of your great stuff for even more - some problems with EDIT.CM and E.CM
EDIT.CM
has lost mapping of the esc key so no user $ control to even exit "(@+E$$)"
will not open an existing file you get ** 06 DUPLICATE FILE NAME (mdos OPEN function error ?)
will create a new file directory entry of an empty file if the file name is new and you cntrl+C exit to close
files need no user supplied suffix .SA is assumed and/or automatically appended

E.CM
data entry cursor does not track entry line arrow on the screen left. (>)
you can move the line pointer arrow up and down but the data entry cursor remains on the bottom line and the left and right arrows move the entry cursor only on that line

[jhallen]

I've fixed the ESC key problem (but have not tried it on Cygwin). The problem was that the ANSI to EXORTerm translation was eating them because it has to look for sequences like ESC [ A (up arrow). If this fix ends up not working in Cygwin, you can try "./exor --no_exorterm". This should definitely work, but E will not work in screen mode with this option.

I don't get the existing file error except when the output file already exists, as in: EDIT TEST.SA,BOB.SA If BOB.SA exists, it complains. If this is not normal, please let me know.

Yeah, if you hit Ctrl-C you get files in weird states. I'm not sure what to do about this. I remember the same thing would happen on the real EXORciser if you hit reset while in the editor (or you get SCRATCH1.SA and SCRATCH2.SA in E).

For the E problem, I'm still looking at it. If you start a new empty file, it seems to start out doing the right thing. But once you enter command mode (where the > is at the bottom), I don't know how to get back to edit/insert mode. I thought you used the I command (Insert command), but it's not working. But my readme file from years ago says that it should work, so I will try older revisions.

[jhallen]

So for E, I figured one thing out: The "I" (insert) command does not work if there are line numbers. So I don't know how to get back to insert/edit mode once you hit F1 for command mode. But if you use "RESE N" to remove the line numbers, then the I command does bring you back to insert/edit mode where the cursor works correctly.

[jhallen]

I figured out how to get back to edit/insert mode when there are line numbers: it's the "N" command, like "N 50" and you start editing line 50.

This works in scroll mode also: If you N an existing line, it shows you the old line and asks for the new one.

One more thing, the window needs to have 25 lines. My Cygwin window starts with 24 lines, so I have to expand it vertically by one. Otherwise weird things happen- the last gets scrolled off the screen.

[crestr1]

My goodness Joe, don't you sleep :-)

the editing i need to do lately is generally trivial just to change options for assembly and include equates
attached page shows it should not complain about an existing file.

MDOS EDIT CM.pdf

[crestr1]

Will download again after you have considered the problem of existing names for EDIT. just in case it is a an MDOS OS open mode problem. EDIT.CM working would be fine for the moment. Could not live without exortem

[jhallen]

crash RASM09 XCOM:1,TCOM:1,DOSEQU:1,SCRDRV:1;L=#LP

Can I have these files? Or maybe you already gave them to me, I'll take a look..

Never mind, yes, I have them.

[jhallen]

Actually I think I only have the TEXTPC in Crashes.textpc.cm.zip. I looked at the sector on the disk image, It starts with 32 0s. If I modify exorsim to treat these as NOPs, then it seems to run (although the textproc.cf seems to get into an infinite loop- it prints the same thing over and over).

If I treat the 0s as NOPs, it picks up running with the 7E 20 A8 (JMP $20A8):

% d 2000
2000: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
2010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
2020: 00 7E 20 A8 8D 05 7F 22  46 20 3F A6 0A 85 40 26 .~ ...."F ?...@&
2030: 05 C6 23 7E 20 EC A6 01  85 10 27 05 C6 25 7E 20 ..#~ .....'..%~ 
2040: EC 39 B6 22 4A F6 22 49  B0 22 48 B7 22 4C F2 22 .9."J."I."H."L."
2050: 47 F7 22 4B 39 B6 22 47  A7 04 B6 22 48 A7 05 B6 G."K9."G..."H...
2060: 22 49 A7 06 B6 22 4A A7  07 39 7D 22 46 26 21 8D "I..."J..9}"F&!.
2070: E4 3F 04 27 09 C1 09 27  02 20 70 7C 22 46 FF 22 .?.'...'. p|"F."

[jhallen]

Can you DUMP textpc on the real EXORciser? Maybe the 0s don't bother the 6800..

[crestr1]

Ran it from this disk a few moments ago. Dump is same Made a fresh copy of disk
TEXTPRO.zip

if started without a input file name it just complains about this and returns to OS

[crestr1]

Thanks for your helpful thoughtfulness in the install makefile, : should clicking the Cygwin terminal on the desktop get me to home or to the working exorsim directory ? It presently gets me to /home/w10pman need to go /home/w10pman/work/exorsimA03 i think.
would it be possible to get "ls" and perhaps "pwd" on the exorsim folder in the "ctrlC" commands menu would like to use big filenames for disks and copy/paste is good to have

[jhallen]

I've added cd, pwd and ls.

[crestr1]

6809 cross assemblers for 68000 and 6800
6809 Cross asses.zip
MACS.cm is the 68000 assembler it has two overlays which don't seem to be in the right path to work

[crestr1]

Some recovered disks from the 1970s for those interested in adventure in cross land and the early fortran for 6800:-

On a 6800 disk a 6809 suite for 68000 pascal compiler, transfer the few pascal files only to 6809 environment to use
09_68K_PASCAL_00-dsk.zip

some more EDOS recoveries of 6800 Fortran recovered ones on MDOS disks others on EDOS disks needing EMCOPY or edos.cm to practice recovery on
EDOS FORTRAN.zip

[crestr1]

Question for Joe
what is the best way to keep my exorsim in synch with the git updates you make ?. I there some background checking going on, I got a flash of a message from something complaining that an update came from the wrong source or something

[jhallen]

what is the best way to keep my exorsim in synch with the git updates you make ?

It's best to use "git" command: you may have to run Cygwin Setup to install it.

    git clone https://github.com/jhallen/exorsim.git
    cd exorsim
    make install   (you need "run as administrator" the Cygwin terminal for this)

If you want to pick up latest changes:

    cd exorsim
    git pull
    make clean
    make install

I got a flash of a message from something complaining that an update came from the wrong source or something

I'm not sure what this is- there are no background tasks associated with git or exorsim.

[jhallen]

MACS

Cool, I tried it. Yeah it wants the overlays on drive 0. Do you think there was a 6800 version of macs? I remember a coworker making a 68000-based product, but it was either on the 6800 EXORciser or possibly on a PDP-11/34... I don't remember. I know we never had a 6809-EXORciser.

[crestr1]

Thanks for git clone and git update info
pulled a new folder and made it all OK
Did the update pull to test the process:

$ git pull
Already up to date.

Bloody Marvelous , this will save lot of time and uncertainty

[crestr1]

This will interest some For our real time OS version of MDOS (ADOS) we made a load and go system for 6800 and 6809 object code, the 6809 one was the difficulty. its loader would grab a chunk of memory anywhere on $100 (hex) page boundary and follow the rules in this opcode table of all opcode pages and perform the direct loading translations. If the 6809 code has been DMA loaded the translator would do a sweep thru the loaded image to convert it

listing-2.pdf

the 6800 one was initially a two part system the external first part recompiled the loader images. Then in the application computer the loader task just grabbed the memory on the start page it was allocated and the just plugged in the high byte of all the long addresses by simple one byte unsigned add as it loaded the code.

[crestr1]

exor -1 dblankAD.dsk crash
does not assemble to end statement
MDOS 3.05
=DIR :1
DRIVE : 1 DISK I.D. : ADOS
MAPS09 .SA
MAPS09 .LO
TOTAL DIRECTORY ENTRIES SHOWN : 002/$02
=DEL MAPS09.LO:1
MAPS09 .LO:1 DELETED
=RASM09 MAPS09.SA:1 ;L=#LP
M6809 MACROASSEMBLER 3.04
COPYRIGHT BY MOTOROLA 1978

** 21 END OF FILE

dblank09 disk folder.zip

[jallennk]

It worked with RASM09 3.03..

=RASM09 MAPS09.SA:1;L
M6809 MACROASSEMBLER 3.03
COPYRIGHT BY MOTOROLA 1978

=

[jallennk]

Sorry, I mean it worked with the 6809 version of rasm09. I'm able to duplicate the issue with the 6800 version of rasm09.

[jallennk]

Ok so:

RASM09 version 02.00 size 18784 for 6800: works, I put it on mdos.dsk

RASM09 version 3.04 size 18992 for 6800: does not work, I'm not sure where I got this from anymore (was on mdos.dsk, now removed)

RASM version 3.01 size 16084 for 6800: works (on mdos.dsk)

RASM09 version 3.03 size 19304 for 6809: works (on mdos09.dsk)

RASM version 3.01 size 16608 for 6809: works (now on mdos09.dsk)

RASM09 version '!3.04' size 19304 for 6809: works (bitsavers disk17- I guess we could upgrade to it, but not sure what the exclamation mark means in the version number)

[jallennk]

68000 pascal compiler

RLOAD on this disk:

=RLOAD:1
M6809 Linking Loader - 3.10
Copyrighted 1981 by Motorola, Inc.
? EXIT
=

Lowercase copyright notice!

[crestr1]

$ git pull
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 4 (delta 3), reused 4 (delta 3), pack-reused 0
Unpacking objects: 100% (4/4), 38.81 KiB | 1.39 MiB/s, done.
From https://github.com/jhallen/exorsim
793f376..bb38d82 master -> origin/master
Updating 793f376..bb38d82
Fast-forward
mdos.dsk | Bin 512512 -> 512512 bytes
mdos09.dsk | Bin 512512 -> 512512 bytes
2 files changed, 0 insertions(+), 0 deletions(-)

This is just fantastic at no stage do the fingers leave the hand

[crestr1]

Motorola Document Processor. On 6809 disk but with 6800 executable included
DOC09.zip
manual page 13 for cmd options. Manual was made by running this attached disk as drive 1. So it works
The version I'm having trouble with was derived from this. Ours uses + instead of ^ as command flag
if it does not complete ^OS shroud go back to the OS

[crestr1]

G'day Joe
Need a few hints on getting control of the toolchain parts thru lpf to get documents from the motorola 6809 DOC.cm properly centered and not loosing footers etc
Listing Printing .zip
I must say exorsim has grown into a most amazing creation, it is just great to work with.
Thanks for all the creativity and hard yards you have put into this wonderful product

[crestr1]

DOC.cm for 09 or 00 (both versions)
patch loc $20 to change the command flag from the default ^ to + In my stuff (use the MDOS DUMP.cm)
other things you can change are in manual last page

[crestr1]

Things are working out beautifully. I think lpf.c may need another command option
Vertical Centering weakness in lpf.c
lpf Centering problem.zip
need to loose the first 7 lines of listing.lp from DOC.cm to get this to get the entire document in synch with the settings for top and bottom

[crestr1]

Found ORIGINAL EDOS MANUAL (1975)
where MAID E800;G all started
EDOs_Original_manual.pdf

[jhallen]

It looks correct with botskip=0 and topskip=6: but you have to manually delete the first line from listing.lp before running lpf. I think there is one extra line on the first page for some reason. One way to delete the first line: tail --lines=+2 <listing.lp >newlisting.lp (I've been busy with other things, have not been able to look at this recently..)

…

On Sun, Aug 27, 2023 at 11:15 PM crestr1 ***@***.***> wrote: Things are working out beautifully. I think lpf.c may need another command option Vertical Centering weakness in lpf.c lpf Centering problem.zip <https://github.com/jhallen/exorsim/files/12449830/lpf.Centering.problem.zip> need to loose the first 7 lines of listing.lp from DOC.cm to get this to get the entire document in synch with the settings for top and bottom — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFR2NVJPR76ALEFJ3XL2ATXXQEO5ANCNFSM6AAAAAA2CVQLOE> . You are receiving this because you commented.Message ID: ***@***.***>

[jallennk]

I've added an option to lpf to do this "lpshift"- shift entire document up (positive) or down (negative):

lpf listing.lp listing.ps --fontsize 10 --font Courier-Bold --lpbotskip 0 --lptopskip 6 --lpshift 1

[crestr1]

Thanks Joe, Much appreciated, This shift option makes it capable of doing a lot more with oddball paper synchs

[crestr1]

TSC 6800 Exorciser debugger and user guide.
a really powerful debugger with disassembly and other helpful stuff for M6800 Exorciser

TSCDEBUG00.zip

[jallennk]

Happy new year Tony! Just checking in, how goes your recovery project?

[crestr1]

A happy and prosperous 2024 to you Joe, may there be green lights and straight roads for all your 2024 adventures. It's all working extremely well, still got hundreds more disk to do. Being able to get great listings as PDF's really adds to the recovery quality and ability to add explanatory comment pages This monumental effort is greatly appreciated by Greg and I and we are about to train some museum bods on using it. Kindest regards Tony Furse At 02:21 PM 8/01/2024, you wrote:

…

Happy new year Tony! Just checking in, how goes your recovery project? ­ Reply to this email directly, <#6 (comment)>view it on GitHub, or <https://github.com/notifications/unsubscribe-auth/A7AXA6EOHS7MF6OLXS7LADLYNNQ5HAVCNFSM6AAAAAA2CVQLOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGMZTGNZXGY>unsubscribe. You are receiving this because you modified the open/close state.Message ID: ***@***.***>