Page 4 of 7

Re: DOS/65 Richard Leary

Posted: Thu Aug 06, 2015 5:39 pm
by RichLeary
It is working!

I checked the hex file contents and they were correct. What I saw were solitary noise bytes ($FF) before the "C" that starts the header. I manually removed them and added a 00 at the end of the track. I had done this before so will necessary I knew it was not sufficient.

I also saw a few solitary noise bytes (usually $FF but at least one $FE) between the "X" and "v". I did the same thing with them as I did with the noise before the "C". I had not done this before.

This was the secret solution. I used the output of HEXBIN without using CLEAN and it worked perfectly.


So....

I am going to modify my DOS/65 version of RAWDUMP to eliminate the noise before or inside the header. Since I use a constant track format with the only track to track difference being the track number it is easy to ensure the dump track header is 100% accurate with enough error checking to abort when the disk header can not be recognized.

Thanks,

Rich

Re: DOS/65 Richard Leary

Posted: Fri Aug 07, 2015 1:54 am
by MK14HAK
Thanks Danny. Just shows I cant rely on my (late night) memory any more!

43 57 01 58 NB 76 01 08 ... 65D
80 00 TK NB 1F code .... 65U

Well done Rich. Look forward to your updated version.

Re: DOS/65 Richard Leary

Posted: Mon Aug 10, 2015 3:48 am
by RichLeary
I will shortly be posting the DOS/65 version of RAWDUMP and will have comments regarding that when I do.

In the meantime I am starting to post transients that were either not part of the OSI release or that have been significantly updated since then. I all cases I will run tests to ensure the transient will operate on the baseline V2.0 OSI environment.

The first of these is the counterpart to the LOAD.COM transient that converts the DOS/65 native assembler object output file (the .KIM file) to an executable .COM file. The counterpart is HEXTOCOM.COM that will do the same thing for Intel .HEX object files. Because there is a chicken versus the egg situation here the ZIP file contains the HEXTOCOM.COM file as well as the source file, the .HEX file, and the .LST file. This transient was developed in the WDC environment.

One note on file naming conventions. During development an executable file name is established - HEXTOCOM in this case. However to prevent total chaos during development and test the files are given a name suggesting the final executable file name but with three (usually) positions at the end reserved for a version number. The this case the files are named HXCOM200.xxx where xxx is ASM, HEX, COM, or LST.

When the HXCOM200.COM file is brought into your system it should be renamed to HEXTOCOM.COM.

Thanks,

Rich

Re: DOS/65 Richard Leary

Posted: Mon Aug 10, 2015 4:06 am
by RichLeary
Here is the DOS/65 version of RAWDUMP. A comment or two is appropriate.

a. This is not really a RAW dump as the software spends time and code to eliminate the "noise" bytes before or inside the seven byte track header.

b. There is no reason to use CLEAN on the captured hex stream. If there was an unrecoverable error in the header of a track RAWDUMP.COM will abort execution.

c. Error checking in the eight pages of data is very limited.

Thanks,

Rich

Re: DOS/65 Richard Leary

Posted: Mon Aug 10, 2015 4:18 am
by RichLeary
Here is V2.02 of the C1P MONITOR ROM.

Thanks,

Rich

Re: DOS/65 Richard Leary

Posted: Tue Aug 11, 2015 4:19 am
by dave
Rich, that's awesome. Next week I will have a little time and plan to to some updates to the site, and will gather together the DOS/65 materials into their own section.

Dave

Re: DOS/65 Richard Leary

Posted: Wed Aug 12, 2015 1:34 am
by MK14HAK
Thanks Rich.

XModem-CRC OSI RAWDUMP is not far away either ! ....

Mike

Re: DOS/65 Richard Leary

Posted: Wed Aug 12, 2015 9:19 pm
by RichLeary
I think this message will be good news for all concerned. I just brought up DOS/65 V2.17 (that is the SYSGEN version) on my C1P/SBII with no changes to my BOOT and SIM other than the opening banner upon cold boot displays the SYSGEN version as well as the SIM version. Even that is just a hard coded entry in the opening message.

Given my concern about the de-blocking needed how does this work?

The de-blocking is really optional and the OSI SIMs already had a de-blocking algorithm although not as sophisticated as that provided for in V2.1X. CCM and PEM lengths are the same in V2.0x versus V2.1X so no other change was required.

I will post the V2.1x release packages, both code and documentation, and will have a special additional file with the SYSGN217.COM file as a file and as part of a disk image.

The next step is to go to V3.0x. That will take a little extra effort but even that should be simple.

Thanks,

Rich

Re: DOS/65 Richard Leary

Posted: Thu Aug 13, 2015 3:56 pm
by RichLeary
Attached is the ZIP file with the V2.1x documentation. Please read it carefully as there are several changes from V2.0 to V2.1:

a. Names have been changed to better match the function, e. g., LOAD is now named MAKECOM, COPY is now DISKCOPY.

b. Command line flow is consistent as a left to right flow. For example the built in command REN syntax was

REN <to name> <from name>

now it is the opposite

REN <from name> <to name>

c. Some transients have different purpose than before. For example MOVE is now named COPY that is now a routine that writes a copy of a file either where the source file is located but with a different name or to another drive. Syntax is now

COPY <source file name> <destination file name>

where the names are a UFN including a drive location. Destination may be just a location.

Thanks,

Rich

Whoops - the forum software has a maximum file size of 250KB so I will have to create several ZIP files as the complete documentation ZIP file is 1.9MB. Stand by please.

Re: DOS/65 Richard Leary

Posted: Thu Aug 13, 2015 4:30 pm
by RichLeary
Here is the first of 6 ZIP files. I could not get the IEEE696 guide to reduce below the 250KB limit but if someone wants that S100 bus oriented do let me know.