Earliest MSXDOS1 version

Pagina 2/3
1 | | 3

Van tfh

Prophet (2942)

afbeelding van tfh

01-12-2019, 22:28

msxholder wrote:

Alright seen it give a date and time stamp.
On your msx 2 or up ?
That is strange ?

This is a screenshot from Generation-MSX Smile

Anyone has a working disk-image?

Van zeilemaker54

Champion (309)

afbeelding van zeilemaker54

02-12-2019, 07:26

zeilemaker54 wrote:
Grauw wrote:

@zeilemaker54 Do you have perhaps a different version of this kit? Since I can’t find the list you pasted in the one tfh linked to.

No, I think it is the same thing. The information is from a text file on the disk. I do not know the filename by head, but can look tomorrow if you like. I have used information about the kernel changes in my msxsyssrc project to determine the different disk kernels. I have already indetentified 5 versions.

The disk includes a brazilian MSXDOS.SYS and COMMAND.COM. The file with the version history is called SYSFILES.MEM. This is the content:

Following notes are the changes made to the the MSX-DOS system files.

COMMAND.COM (version 1.01)

Fixed the problem that file concatenation got "write error"
message and never performed.

October 12, 1984

COMMAND.COM (version 1.02)

Fixed the problem that command hanged when non-blank separators,
such as commas, semicolons etc., were used for batch command

November 14, 1984

COMMAND.COM (version 1.03)

Fixed the problem that DOS did not reboot after MACRO-80 has
been terminated.

December 15, 1984

COMMAND.COM (version 1.04)

This version was in-house review only, and was not released.

COMMAND.COM (version 1.05)

Fixed the problem that the cursor was disappeared in some of
the application.
This was because command processor did not care the cursor
status when control was returned from the application. To
fix this problem, it was changed to turn the cursor on just
before passing control to the application.

Application programs can control the cursor status
by sending following escape sequences to the console.
ESC+"y5" will turn on the cursor, and
ESC+"x5" will turn off the cursor.

The current date displayed by the "DATE" command has been
changed to fit into single line by removing "centuries" of
the year string. The change was made to the Japanese version.
Previously this message had wrapped to the next line, and was
very unreadable.

January 29, 1985

COMMAND.COM (version 1.06)

Fixed the problem of version 1.05 that the escape sequence
to turn the cursor on was also echoed to the printer.

Fixed the problem of "DIR /P" command that the first file name
was scrolled off the screen when the console width was set
to 30 columns or less. The prompt for the next page was wrapped
to the second line.

Fixed the problem of "DIR" command that columns of the printer
output was not aligned. "DIR" command bypassed output of CR-LF
when the line was automatically wrapped to the next line. When
this was echoed to the printer, consective lines were joined

February 21, 1985

COMMAND.COM (version 1.07)

Accepts codes 80h to FEh as file name characters from this
version. They are Hiragana and Katakana characters in Japanese

Fixed the problem of "DIR /W" command of version 1.05 that
the tab position was not aligned for the first line. Escape
sequences to turn on/off the cursor was also counted for tab
position management.

February 28, 1985

MSXDOS.SYS (version 1.01)

The disk error handling procedure was improved.

There was a danger that a disk being damaged, if, the disk
was a non-MSX-DOS format (such as CP/M), an disk error occurred
and "Ignore" was selected.

To handle this case, changes have been made to the MSXDOS.SYS
to display "Unsupported media type" and "Abort" the process,
If disk driver detects illegal format.

March 7, 1985

COMMAND.COM (version 1.08)

Fixed the problem of COPY command that "Write error" was
displayed while copying multiple files. The copy had been
aborted in the middle.

March 24, 1985

COMMAND.COM (version 1.09)

Fixed the COPY command problem that when you try;


old COMMAND.COM read that file and wrote the file into same
disk. This should have been detected as

File cannot be copied onto itself
0 files copied

April 30, 1985

MSXDOS.SYS (version 1.02)

Fixed the problem that disk error handler ran away when long
batch command was entered.

When invoking batch, if the batch parameter was very long (about
70 bytes), it destroyed MSXDOS disk error handler code. There
was not enough space for batch parameters.

New version will allow batch parameters even if they fill up
entire command line.

COMMAND.COM (version 1.10)

Added support for 80 columns display of MSX2.

"MODE" command parameter now allows up to 80 columns.

Fixed the problem of copying files onto itself finally.

Version 1.09 of command still could not detect the
cases like:

COPY *.*

and files were read in and written back in the same
place and sometimes got truncated.

Fixed the problem when appending binary files.

In the version 1.09 of command, appending binary files,
sometimes got incorrect data in ABC.BIN, and sometimes
got "Insufficient disk space" error message.

This problem was hidden until version 1.09 began to
handle append properly. Previous versions never did

Fixed the problem when concatenating ASCII files.

In ASCII mode copy, there were cases that source file
was not cut off at first control-Z. This occurred
when the file size was multiple of 256.

There may be no problem for copying single files, but
when the files were concatenated, this would cause
unwanted end-of-file and rest of the data after
control-Z would not read.

Fixed the problem when copying null file.

In the previous version of command, when the source
file was size was 0, destination file was not written,
though there appeared the message that file was copied.

Fixed the problem of batch files with very long line.

While processing batch, there were chances that the
command line exceeded internal buffer (after parameter
substitution, or batch file itself had longe lines)
and destroy other internal work areas.

New version will check the size of the command line
and ignore excessive characters.

If the command line with many many parameters was
entered to invoke batch file, say, full of separators
with many many "null" parameters, it will still destroy

Version 1.10 assumes MSXDOS.SYS version 1.02 or later,
and uses up all the spaces for batch parameters. When
combined with version 1.00 or 1.01 of MSXDOS.SYS, it
cause system crush, by executing BATCH command.

July 21, 1985

MSXDOS.SYS (version 1.03)

when printer does not exist and control-P is pressed, system
hangs waiting for printer ready.

Only control-stop can force BIOS to exit printer wait loop.
But any characters including control-N are thrown away while
control-STOP is depressed, and trying to echo "^C", DOS enters
wait loop again. This is a ROM BIOS problem.

This fix trys to cover this situation; this will wait enough
time for auto-repeat to occur and then echo "^C".

Recovery action should be:

(a) Hold down [CTRL] and [N].
(b) Press [STOP].
(c) Still holding [CTRL] and [N], release [STOP].

COMMAND.COM (version 1.11)

Fixed the bug of version 1.10 that it forgets to load the latter
half of the *.COM file when the file size is lager than 22k
bytes. Nothing was loaded after address 58FFH.

Fixed the bug, known in version 1.10, that caused system crash
when there were many many batch parameters. And fixed the
incompatibility of version 1.10 with the old version of
MSXDOS.SYS (1.00 or 1.01).

This is a summary of system crash possibility when
the batch command is entered. number(s) in parenthesis

1. When the command line is longer than 70 bytes.
2. When the line in batch file is longer than 128 bytes.
3. When number of batch parameters is more than 64.


1.00 or 1.01 1.02 or later
1.00 to 1.09 | maybe (1,2,3) | maybe (2,3) |
COMMAND.COM 1.10 | always | maybe (3) |
1.11 or later | maybe (1) | never |

Changed the message timing when multiple files are copied.

When dual drive simulator is active, commands like;

A>COPY *.* B:

displayed message sequences like;

FOO1 DAT (FOO1.DAT was found)
FOO2 DAT (FOO2.DAT was found)
Insert diskette for drive B:
and strike a key when ready
FOO3 DAT (FOO3.DAT was found?)
Insert diskette for drive A:
and strike a key when ready
FOO4 DAT (FOO4.DAT was found)

It looked as if FOO3.DAT was found while drive B
diskette was inserted. Though this was not true, there
was some uneasiness in this sequence.

Aug 23, 1985

COMMAND.COM (version 1.11)

Fixed the bug of version 1.10 that file(s) get mixed up when
other files are appended to it by "COPY" command with a
(default) switch "/A". Append was successful, but original data
was lost.

To fix above problem, shipment of August 23 version has been stopped
in the middle.

September 2, 1985

Van tfh

Prophet (2942)

afbeelding van tfh

02-12-2019, 08:19

Yes. That file is also on the disk I linked to earlier.
Quite some nasty bugs in the older MSX-DOS versions.

Van rderooy

Paladin (686)

afbeelding van rderooy

14-02-2020, 23:01

Just found this thread. I'm wondering if these notes were written by Tim Paterson, although it does not really match up with his timeline in his MSX-DOS history write-up where he basically said he was done by April 23, 1984 and only did a few bug fixes afterwards. But reading them it looks like they were written by an American.

I'm starting to suspect Tim may have used the wrong years in his write-up. Instead of 1983-1984 as he said, it looks like it was 1984-1985 instead, which makes more sense from when it was actually shipped by OEMs.

Van Briqunullus

Champion (392)

afbeelding van Briqunullus

07-09-2020, 19:26

Woah, this is an interesting topic. The sysfiles.mem dump above just says there have been two different versions of command.com 1.11. And one of them contains a bug.

Well, like others have noted, there is a version string at the end of command.com when viewed in a hex editor. It can either read

COMMAND version 1.11 for MSX-DOS amended by Hal-F  07/30/85


MSX-DOS version 2.2 by Tim Paterson  03/06/84

Now let's run some tests. The Hal-F version is above, the Tim Paterson version below. I wanted to add screenshots, but msx.pics is down at the moment. So you got to take my word for it.

MSX-DOS version 1.03
Copyright 1984 by Microsoft

COMMAND version 1.11

A>copy con 1.txt
       1 file copied
A>copy con 2.txt
       1 file copied
A>copy /a 1.txt+2.txt 1.txt
       1 file copied
A>type 1.txt

MSX-DOS version 1.03
Copyright 1984 by Microsoft

COMMAND version 1.11

A>copy con 1.txt
       1 file copied
A>copy con 2.txt
       1 file copied
A>copy /a 1.txt+2.txt 1.txt
       1 file copied
A>type 1.txt


Do you spot it? It's the Hal-F one that contains the bug. Exactly as described in the sysfiles.mem document. So, to settle this for once and for all, the true final version of command.com 1.11 is the one with Tim Paterson's name in it.

command.com (Hal-F) md5 0F1E2F8A6DBAFA06D04431DCC41B649D
command.com (Tim Paterson) md5 08F84127E5BAF86F659CF43ADF4DE246

Van Manuel

Ascended (18086)

afbeelding van Manuel

07-09-2020, 21:42

MSX-DOS version 0.26
Copyright 1984 by Microsoft

COMMAND version 0.12

Current date: Mon  9-07-2020
Enter new date:
Current time:  9:41:09.00p
Enter new time:

A>dir msxdos.sys
MSXDOS   SYS    3072  1-01-84
1 File    97280 bytes free
A>dir command.com
COMMAND  COM    6144  1-01-84
1 File    97280 bytes free

Van Briqunullus

Champion (392)

afbeelding van Briqunullus

07-09-2020, 22:41

Yeah, I've read about that version in other threads. It's on a Sony disk with BDS C, isn't it? So it should be an official version of some sorts. Could you send me a copy? I would love to examine it.

Van Briqunullus

Champion (392)

afbeelding van Briqunullus

13-09-2020, 14:01

I have unearthed another early MSX-DOS version. Dutch financial software suite 'WieWat' was distributed with MSX-DOS 1.00 and COMMAND 1.01. It can be found on the MSX Nostalgia website or it's mirror at kudos.be as disk 191.

This software product was made by AKG Micro Systemen and was commissioned by Philips. Apperently Philips gave them this version early in the development process and upon release nobody bothered to check for updates.

I have checked this version against the list of bugs above and there is no "Unsupported media type" error in msxdos.sys which was added in version 1.01. In command.com I have checked "the problem that command hanged when non-blank separators were used for batch command parameters". I found it hangs indeed, so COMMAND is an earlier version than 1.02.

All in all I think this really is MSX-DOS version 1.00 and COMMAND 1.01. It would be interesting to see how this one compares to 0.26/0.12.

tfh wrote:

If someone has these different MSX-DOS versions, please do not hesitate to contact me so I can add all of them.

You can download this one at the link above. I have started researching these old MSX-DOS versions. When I am done I will compile an archive with all these versions. Of course I will send that to you to put on your site. :)

Van tfh

Prophet (2942)

afbeelding van tfh

13-09-2020, 14:19

Thanks Smile I have added this version to my site! And looking forward to your final archive with all the different versions. Will this only be with the "official" versions or also the versions like "CyberDOS", etc?

Van Briqunullus

Champion (392)

afbeelding van Briqunullus

14-09-2020, 10:46

I may do those another time, for now I'm just looking at the original ones.

While searching for MSX-DOS 0.26 I found another reference to it. Apparently, UK based IS Systems developed EX-DOS for their [url=https://en.wikipedia.org/wiki/Enterprise_(computer)]Enterprise computers[/url]. They at some point tried selling EX-DOS in Japan as a future MSX-DOS 2. In preparation of the trip, they testdrived MSX-DOS 0.26.


         This   document  refers  to  MSX-DOS  version  0.26  and COMMAND.COM version 0.12 running on a SONY "HIT-BIT" computer.  It describes various limitations of this system as compared to a possible EXDOS/IS-DOS implementation on a MSX machine.  It also mentions some general bugs which have been noticed.


         With the drive supplied,  only 80 track disk formats can be read.  In particular IBM compatible 40 track disks cannot be read.  Even connecting a 40 track drive as drive "B:" will not allow IBM compatible drives to be read.  The conclusion is that to 40 track formats which are defined in the MSX-DOS specification are not in fact supported at all.

         Apricot disks also cannot be read at all and if this  is attempted then the "disk error" does not go away even if an MSX-DOS disk is put in the drive.  The only way I have discovered to make the drive work again it to totally re- boot.

         I  have no evidence of whether 5.25" drives can be used, but I would expect that 80 track formats which are identical to the MSX formats could be read, but not 40 track or other 70 or 80 track formats.

         As  far as I can tell,  MSX-DOS only supports one or two drives.  However if it only has one drive then it automatically maps both "A:" and "B:" to this drive and gives appropriate messages.  EXDOS requires a "MAPDISK" command in the "EXDOS.INI" file to achieve this. 


         As  mentioned above,  if an Apricot disk (or  presumably any other "strange" format disk) is accessed then a non- recoverable disk error occurs requiring a re-boot.  

         If  an  error such as "not ready" occurs when doing  for example a "DIR" command, then the error often has to be retried several times even after the cause of it has been corrected (ie. a disk has been inserted).  

         Also if "DIR" is done with no disk in the drive then the "IGNORE" response to the prompt does not seem to work, the "not ready" error immediately re-occurs.  EXDOS won't let you ignore this either, but at least it doesn't offer the "IGNORE" option.


         There  seems to be delay of about 2s before any  MSX-DOS command actually does anything.  The equivalent delay in EXDOS is certainly much smaller and is generally not noticable.

         Accessing  of  files by CP/M programs under  MSX-DOS  is very slow.  Clearly MSX-DOS is only able to transfer one sector (512 bytes) per disk revolution.  IS-DOS has a buffering scheme which should improve this at least by a factor of 2 or 3.  Loading of programs and copying in MSX- DOS is faster but still not as fast as with EXDOS/IS-DOS (hopefully).


         There are severel important features supported by  EXDOS and IS-DOS which MSX-DOS does not provide.  These are discussed briefly here.

      SUB DIRECTORIES:  MSX-DOS recognises them and includes them in its directory listing but they cannot be accessed at all.

      VOLUME  NAMES:    These are not supported at all, either by listing on the "DIR" command or allowing any way to change them.

      UN-DELETION:      Although  it  will  require  a  transient command to  be run, IS-DOS will allow deleted files to be recovered provided the disk has not been written to since they were deleted.  I am not aware that MXS-DOS allows this at all.

      VOLUME  IDs:      These  allow EXDOS to recognise when  the wrong disk is in the drive.  MSX-DOS has no such feature (as far as I am aware).

I'm starting to think MSX-DOS 0.26 is the version Tim Paterson delivered in April 1984. And that ASCII took over from there, making just a few changes and releasing MSX-DOS 1.00 in June to OEM's. From there, it's history is documented in the SYSFILES.MEM text.

Pagina 2/3
1 | | 3