Enterprise Forever

:UK => Programming => Topic started by: BruceTanner on 2014.April.14. 10:40:33

Title: EXDOS
Post by: BruceTanner on 2014.April.14. 10:40:33

Zozo there as an interesting (to me anyway!) sounding discussion on an EXDOS bug in the Hungarian topics but google translate is a bit limited...any chance you could put an English summary here when you have a spare 5 minutes, thanks!

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.14. 10:48:01

As you say:

Quote from: BruceTanner

There is a huge amount of hand-written assembly in IS-BASIC, EXOS and EXDOS - there must be loads of bugs!

Now found another one in the EXDOS :oops:

When started testing the SD interface cartridge I noticed the written files are randomly damaged :-(
More than two weeks of debbuging I found exactly what is the bug.
When handling FAT sectors, some information copied to sector buffer header, for example the FAT size, this is will be used when calculating LBA address of specified FAT sector in the next FAT copy. Sector buffers are in the System Segment, paged to Page 2.
There is the buggy routine from 1.3 version (but all other versions have same):

Code: ZiLOG Z80 Assembler

1.   CA5F  7E           LD    A, (HL)
2.   CA60  D3 B1        OUT   (B1), A
3.   CA62  23           INC   HL
4.   CA63  5E           LD    E, (HL)
5.   CA64  23           INC   HL
6.   CA65  56           LD    D, (HL)
7.   CA66  23           INC   HL
8.   CA67  D5           PUSH  DE
9.   CA68  CB B4        RES   6, H
10.   CA6A  CB FC        SET   7, H
11.   CA6C  E5           PUSH  HL
12.   CA6D  DD E1        POP   IX
13.   CA6F  E1           POP   HL
14.   CA70  0E 01        LD    C, 01
15.   CA72  D1           POP   DE
16.   CA73  D5           PUSH  DE
17.   CA74  C5           PUSH  BC
18.   CA75  01 FF 01     LD    BC, 01FF
19.   CA78  CD B0 CA     CALL  CAB0
20.   CA7B  CD 1E CC     CALL  CC1E
21.   CA7E  C1           POP   BC
22.   CA7F  D1           POP   DE
23.   CA80  20 01        JR    NZ, CA83
24.   CA82  0C           INC   C
25.   CA83  FE BF        CP    BF
26.   CA85  20 03        JR    NZ, CA8A
27.   CA87  01 01 01     LD    BC, 0101
28.   CA8A  F5           PUSH  AF
29.   CA8B  7B           LD    A, E
30.   CA8C  DD 86 FC     ADD   A, (IX-04)
31.   CA8F  5F           LD    E, A
32.   CA90  30 01        JR    NC, CA93
33.   CA92  14           INC   D
34.   CA93  F1           POP   AF
35.   CA94  10 DD        DJNZ  CA73

It is page in to Page 1 the Unit Handler segment, this is needed for the Unit Handler call (The EXDOS paging routine will move it to Page 3, and page in the transfer segment fro C register to Page 1).
Ix will point to the transfer area (sector buffer data) it is converted to Page 1 address as the Unit Handler call (CC1Eh) need it.
After the call come the problem: using the IX addressing the sector buffer header (for the FAT size), but the IX point to the Page 1 where the Unit Handler segment paged in!!!
It is don't problem with the built in Units (floppy, Ramdisk) these are also in the System Segment then it is paged to both Page 1 and 2, the wrong IX also point to right place.
But with EXDOS extensions which are use separate segments the IX point to wrong place then using false data for calculations -> FAT2 written to the data area overwritting file data.

In the fix I only convert IX to Page 1 only for the Unit Handler call, removed the RES, SET from CA68h,CA6Ah, and the CALL CC1Eh modified to CALL this routine:

Code: ZiLOG Z80 Assembler

1.                 PUSH IX
2.                 PUSH HL
3.                 PUSH IX
4.                 POP HL
5.                 SET 6,H
6.                 RES 7,H
7.                 PUSH HL
8.                 POP IX
9.                 POP HL
10.                 CALL 0CC1EH
11.                 POP IX
12.                 RET

This is can be done only in 1.3 version, because only this have a free ROM space. It is renamed to version 1.4 because the extension programs can check the EXDOS are bug free (least this bug :oops: ).

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.15. 00:41:38

:oops: Thanks for posting zozo, impressive debugging! :bow:

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.18. 23:10:18

The EXDOS has a lot of error codes that have no error messages.
I think this is because in the original 16K versions the ROM space is very limited so the rare errors don't get messages.
The 1.4 was developed from version 1.3 which uses a 32K ROM, with lots of free space. I want to put messages for all the errors.
I hate so much when a computer displays error code xxx as an error message :twisted:

Bruce, can you help define messages for these errors? Following the original style of the Enterprise error messages.
I will write each specified error code when it has been done.

Title: Re: EXDOS
Post by: gflorez on 2014.April.19. 11:03:43

I want to help too.....

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.19. 11:45:25

Quote from: gflorez

I want to help too.....

Spanish version also will be updated! :-)

Title: Re: EXDOS
Post by: szipucsu on 2014.April.19. 12:02:22

OFF:
New error messages in the 21st centruy:

*** Internet connection error.
*** Server connection error.

Title: Re: EXDOS
Post by: lgb on 2014.April.19. 13:49:48

Quote from: szipucsu

OFF:
New error messages in the 21st centruy:

*** Internet connection error.
*** Server connection error.

*** 404 Not found, HTTP error.
:)

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.19. 20:45:35

Quote from: Zozosoft

The EXDOS has a lot of error codes that have no error messages.
I think this is because in the original 16K versions the ROM space is very limited so the rare errors don't get messages.
The 1.4 was developed from version 1.3 which uses a 32K ROM, with lots of free space. I want to put messages for all the errors.
I hate so much when a computer displays error code xxx as an error message :twisted:

Bruce, can you help define messages for these errors? Following the original style of the Enterprise error messages.
I will write each specified error code when it has been done.

Zozo I'd be glad to give that a go although it was so long ago I'm not sure I'd be any better than anyone else!

I certainly share your hate of giving the end user error code xxx as an error message although that is better than just ”an error occured” as so often happens in Windows!

I don't actually remember having to restrict the error messages in EXDOS but you may well be right about lack of ROM space. I assume they are in a compressed format in the ROM. Do you have an example of something the user can do that results in an Error xxx message?

Title: Re: EXDOS
Post by: szipucsu on 2014.April.19. 21:07:23

Quote from: BruceTanner

I assume they are in a compressed format in the ROM.

I don't know. Many years ago I used some PRINT STR$(PEEK(x)) in a FOR loop, and I got a lot of messages and basic commands printed on the screen.

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.19. 21:33:18

Quote from: BruceTanner

I assume they are in a compressed format in the ROM.

Yes it is compressed, similar as the EXOS or BASIC ROMs. But only in the original English EXDOS ROMs (16K size). When the German Enterprise company released the 1.3 two languages version (English/German) then the decompression routine and compressed data removed (at source code level), and putted both message tables (English/German) as plain text to the second segment.

For examples the error xxx message, the most frequent reason: damaged disk with FAT or Directory error.
File operation try to access more than the FFFFh Z80 address. Many original tape released programs just put a big number as lenght to EXOS 6 block read, and don't care with the final EOF error. These generated error coded messages from disk.

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.20. 23:40:44

Bruce! What do you think about this?
[attach=1]

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.20. 23:52:05

Quote from: Zozosoft

Bruce! What do you think about this?
(Attachment)

:smt023

Title: Re: EXDOS
Post by: szipucsu on 2014.April.21. 10:46:06

Quote from: Zozosoft

What do you think about this?

I would leave the colon ( : ) after "by":
"Written by Martin Lea & Bruce Tanner."
not: "Written by: Martin Lea & Bruce Tanner."

Title: Re: EXDOS
Post by: gflorez on 2014.April.21. 10:52:34

Yes, with the colon it seems it follows a crew....
--
Si, con los dos puntos parece que a continuación viene un grupo....

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.21. 11:41:39

Quote from: szipucsu

I would leave the colon ( : ) after "by":
"Written by Martin Lea & Bruce Tanner."
not: "Written by: Martin Lea & Bruce Tanner."

Ok, is it good now? :-)

[attach=1]

Note: now all commands which existed in 0.3 version but were removed later because of the lack of the ROM space, have been put back in 1.4!

Title: Re: EXDOS
Post by: szipucsu on 2014.April.21. 13:17:26

Quote from: Zozosoft

Ok, is it good now? :-)

Yes, it is!
Great!

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.21. 19:15:29

Quote from: Zozosoft

Note: now all commands which existed in 0.3 version but were removed later because of the lack of the ROM space, have been put back in 1.4!

About this I wrote in the Hungarian forum: previously somebody put back four commands (ATTR, ATDIR, ASSIGN, MAPDISK) to the modified, English-Hungarian 1.3 EXDOS. This is at the late '80s.
As I could not see the version 0.3 I always thought these command are extracted from ISDOS and put to EXDOS.
Now I disassembled these commands routines and found: the ISDOS version are totaly different. But the code is very similar to version in 0.3 EXDOS! These routines use lots of internal subroutines of the EXDOS (command line analyze, printing, etc). This means: the person who made the modifications had the source code of 0.x EXDOS! Extracted the command routines from the source, for the called routines found the same in 1.3, and then compiled the adjusted routines to free space in 1.3 ROM.

Today when I added the remaining missing commands to 1.4 I used my 1.3 disassembly for adjusting the extracted code from 0.3.

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.21. 23:16:35

Quote from: Zozosoft

This means: the person who made the modifications had the source code of 0.x EXDOS! Extracted the command routines from the source, for the called routines found the same in 1.3, and then compiled the adjusted routines to free space in 1.3 ROM.

Today when I added the remaining missing commands to 1.4 I used my 1.3 disassembly for adjusting the extracted code from 0.3.

You don't think the person who made 1.3 could have done the same as you ie. take the disassembled code from 0.3?

Where did the English/Hungarian 1.3 come from?

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.21. 23:45:27

Quote from: BruceTanner

You don't think the person who made 1.3 could have done the same as you ie. take the disassembled code from 0.3?

1) the code is similar, but not the same. I think it is from another 0.x version which still has these commands.
2) anyway have a non public early version ROM or source
3) need a least one version source, because need a lot of additional disassembly for the called subroutines. Which are parts of the command, which are general internal subroutines?
At my situation I have a "1.3 source", my very long disassembly project. Not a complete, but these routines discovered, then easy to adapt the 0.3 code for 1.3.
I'm sure who made the early modifications not have the 1.3 source, because the modifications done by binary level, not a recompile.

Quote

Where did the English/Hungarian 1.3 come from?

Very good question! :oops:
Probably every Hungarian EXDOS user has this version, but nobody knows the origin :oops:
I guess Mr. Kopácsy or other people from the Hungarian team which are connected with the English company.
Unfortunately noone from this team found the existing Enterprise community :cry:

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.22. 09:54:59

Bruce! One non technical question :-)
Why the purple color selected for paper color in EXDOS CLI? Used a monochrome monitor? :-D

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.22. 10:59:13

Quote from: Zozosoft

Bruce! One non technical question :-)
Why the purple color selected for paper color in EXDOS CLI? Used a monochrome monitor? :-D

Good question! I remember deciding to do the EXDOS CLI this way so you could copy, rename, delete etc easily without having to leave BASIC (an early form of pop up window) but I don't actually remember making it purple, and in fact I was surprised when I saw it purple after nearly 30 years! :oops: :smt021 I don't think it is a colour I would have chosen from free will, I was probably told to make it that colour. I had been looking into easy-on-the-eye colour schemes around that time (IBM had done some research for mainframe terminals) and I don't think purple featured very highly! You could probably change it fairly easily...

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.22. 11:20:30

Quote from: BruceTanner

You could probably change it fairly easily...

I have already done it :-) What do you think about dark green?
[attach=1]

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.22. 14:08:35

Quote from: Zozosoft

I have already done it :-) What do you think about dark green?
(Attachment)

Yes yellow on dark green is good. The other combination that works well is white writing on dark blue. But you are doing the work so it is your choice!

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.23. 21:38:37

Bruce! Now one technical question:
Can you remember about developing disk buffers function?
Firstly view the 0.0 version specifications (http://enterprise.iko.hu/technical/PER-5-2_EXDOS_00_System_Specifications.pdf), start at PDF page 26 talking about buffers.
The essence: buffers allocated as Channel using BUFFER: device, and the allocated channel RAM are the buffer space. maximum 30 sector buffers are possible, which are on segment (30x540 bytes).

The main change in the existing ROM versions (including the early 0.3) the buffers are allocated by user device called as "." it is added by EXOS 21 call, and the requested device RAM are the buffer space.
Device RAM only can be allocated in the System Segment, then less buffers possible.
At the FISH 27 call, which are allocate buffers, the version 0.3 accept max 30 as input parameter, as the 0.0 document wrote. But only max 15 can be allocated, with 16 the system will be very unstable, for example cold reset done after :BASIC :oops:
The 1.x versions only accept max 10 as buffers. I think because avoiding too high System segment usage.

Can you remember why changed the original idea: channel RAM to device RAM? It is too many problems with force closed channels?

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.23. 22:14:52

Quote from: Zozosoft

Can you remember why changed the original idea: channel RAM to device RAM? It is too many problems with force closed channels?

Once again my memory fails me I'm afraid zozo: I don't recall the change let alone the reasons for it! (It wasn't really my area anyway.) If I had known at the time someone was going to revisit the issues 30 years later I might have taken notes!

Good theory though...sounds very plausible

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.23. 22:32:37

Quote from: BruceTanner

If I had known at the time someone was going to revisit the issues 30 years later I might have taken notes!

Good idea! If I found a time machine will tell you :ds_icon_cheesygrin:

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.28. 16:50:13

Unfortunately the original EXDOS documentations still missing :cry: but exist a leaked Hungarian documentation: text files which are talking about FISH and DISKIO calls, FAT table, and EXDOS error codes. Unknow people see the original documentation, and translated these parts. The error table contaion the original IS identifiers of the errors. (This is the right pharse for .WPROT, .NDOS and etc?)
I wanted to use error code table from this package, cleaned up the Hungarian texts, for talking about English error messages.
Then I noticed many errors are missing from this table! Probably are come from early documentation.
Missing the:
- File exists
- RAM disk already exists
- Invalid file attributes
- Invalid MAPDISK
- Data error
- No RAM disk
But exist the: File cannot be copied onto itself
The strange thing: version 0.3 ROM have all the missing errors from the list, but don't have File cannot be copied onto itself error! (And COPY FILE1 FILE1 are working :-) )

Another strange thing the: B1h  .WDRV      - Insert disk for drive x:
In all existing version (from 0.3) these removed from the error table and putted to other messages table.
The very early 0.0 documentations what we have talking about this as error messages!

I'm totally confused about guess which version are the original of the leaked documents. At the FISH calls the RAMDISK handler function also missing, and also some other calls.


Back to the error messages... What is the right in English: filename or file name?
At the A6h  .IFNM      - Invalid filename

in version 1.3 changed to "Invalid file name".


But at ABh  .DUPF      - Duplicate file name

all existing ROM version use "Duplicate filename".


And the story of B1h error very interesting: it is removed from error messages table, but the error code still used. In the "ask user when error occured" routine (Retry or Abort and etc) added a exception handler for B1h error: if B1h code then print message from messages table, else select right message from error messages table.
Why added this extra routines for B1h? Just for can't see "Insert disk..." message with EXOS 28 (Explain error code) function?
Then if any user program using own replacement handler for EXDOS errors, then it is can get B1h error code, but can't get message for it with EXOS 28.

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.28. 17:19:32

Zozo you might find that COPY FILE FILE only works for small files - it will read the whole file into memory and then write it out again on top of the original. Fine if the whole file fits into memory but if it doesn't...:oops:

I'd say either filename or file name is correct but it sounds as though I was made to change it to file name at some point and missed one! Personally I find filename easier to read. The same Q exists over pathname. I don't think it's as clear cut in this case but I still prefer pathname and it is nice to be consistent! Wikipedia has filename but not pathname.

I'm not sure about error B1h. Does it print any extra parameters for that message (eg. two drive letters)?

B.

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.28. 22:17:15

Quote from: BruceTanner

Zozo you might find that COPY FILE FILE only works for small files - it will read the whole file into memory and then write it out again on top of the original. Fine if the whole file fits into memory but if it doesn't...:oops:

Then this happen :-D
[attach=1]
But this is only in the 0.3, the released 1.x version don't allow this operation.

Quote

I'd say either filename or file name is correct but it sounds as though I was made to change it to file name at some point and missed one! Personally I find filename easier to read.

Ok, in 1.4 "filename" will be used at both message.

Quote

I'm not sure about error B1h. Does it print any extra parameters for that message (eg. two drive letters)?

Only one drive:
[attach=2]

Like as other errors:
[attach=3]

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.28. 22:54:43

I forgot one:
9Fh  .INP       - Invalid number of parameters
In version 1.3 changed to "Wrong number of parameters"
Which are the better?

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.28. 23:00:27

Quote from: Zozosoft

I forgot one:
9Fh  .INP       - Invalid number of parameters
In version 1.3 changed to "Wrong number of parameters"
Which are the better?

I think ”Wrong number of parameters” is more user-friendly, ”invalid” is a bit computer-techy-geeky

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.28. 23:14:25

I do remember we had some re-entrancy issues with EXOS with the Abort/Retry messages - the main program has called EXOS to do eg a file read and it's gone deep into EXOS and the device driver, and then has to print the message with more EXOS calls...I don't know if the 0B1h change could have something to do with this

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.28. 23:23:12

Quote from: BruceTanner

I think ”Wrong number of parameters” is more user-friendly, ”invalid” is a bit computer-techy-geeky

Ok, i kept it.

Quote

Missing the:
- File exists
- RAM disk already exists
- Invalid file attributes
- Invalid MAPDISK
- Data error
- No RAM disk

For these also are unknow the IS error identifier. Most of them found in the VT-DOS documentation. (.FILEX, ?, .IATTR, .IMAP, .DATA, ? ) But not for the two ones about the RAM disk, because no RAM disk on TVC.
Looking the logic of other codes what do you think about .RAMX and .NORAM?

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.28. 23:31:38

Quote from: Zozosoft

Looking the logic of other codes what do you think about .RAMX and .NORAM?

Sounds very likely they are the ramdisk error codes! It should be reasonably easy to generate them too to check the error code values!

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.28. 23:42:44

Quote from: BruceTanner

I do remember we had some re-entrancy issues with EXOS with the Abort/Retry messages - the main program has called EXOS to do eg a file read and it's gone deep into EXOS and the device driver, and then has to print the message with more EXOS calls...

Interesting, I will look it is any special routine about this problem.

Quote

I don't know if the 0B1h change could have something to do with this

It is use same EXOS calls as other errors, just the text source changed: moved from error message table to other messages table.

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.29. 08:32:46

Probably when MAPDISK was removed to save ROM space the error message was removed too as it could no longer occur.

Maybe then when someone put MAPDISK back in they discovered the prompt did not work correctly, so they put in the test for 0B1h and the message text. So no real reason for not having it as an error message, just someone not understanding the whole system or the best way of doing it.

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.29. 09:26:42

Good idea, but in one drive system the B: mapdisked to A: at system start.
Anyway version 0.3 have MAPDISK command, and 0B1h working same way as 1.x versions.

I can guess only one reason: to hide message from other programs which are using EXOS 28 (Explain error code) because look strange "Insert disk for" as error message :-)

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.30. 11:52:02

There is the cleaned error table, now need to create the missing messages.
BFh  .NOUPB
This is happened when Unit Handler called for sector operations but the Unit Parameter Block not filled with boot sector parameters. Some disk errors also set status bit in UPB for set it is as invalid.
*** UPB not valid
are right?

BDh  .ICMD
This is happened when the Unit Handler got a unknow function code.
It is will be important in the future because when the EXDOS updated for using big, FAT16 disks, then need to define new FISH and Unit Handler function codes for the 32 bit LBA sector transfers. These are will be unknow for the old handlers, and the new handlers will be reject the old 16 bit LBA commands for avoid file system damage.
This error have a message in the version 0.0 documentation:
*** Invalid unit handler command
Probably use "function call" or "function code" instead "command" like as EXOS error messages?

BCh  .IUNUM
It is happened when used unknow internal unit number for operation, for example try to read from 5. floppy drive.
In the future this also can be more possible, with the removable SD Cards, if one card removed or replaced with less partitions, then less unit numbers will be valid.
From the 0.0:
*** Invalid unit number

BBh  .ISECT
If sector number for read/write point outside to disk area then this error occured. For example on 720K disks sector are exist from 0-1439, from 1440-... generate this error.
It is usaly occured when the FAT table or directory entry damaged.
From 0.0:
*** Invalid sector number

B0h  .ICALL
FISH called with unknow function code. As I say before the Unit Handler calls, in the future this is will be important.
Following EXOS similar error (0FFh):
*** Invalid FISH function code

A3h  .IFAT
This is occured when FAT entry point outside the disk. (I found bugs, or least missing feature about this checking :oops: It is not always checked, and when accepting the invalid value then will generate .ISECT error. 000h and 001h are also accepeted :oops: )
My suggestion:
*** Invalid FAT entry

9Bh  .OV64k
Try to transfer data over FFFFh Z80 address. For example read 200h bytes starting at FE00h. It is very frequent error because TAPE, NET and other EXOS devices not checking this problem.
Any good idea for the message?

9Ah  .FILE
End of file entry readed from the FAT before it is ending by the file size from directory
My suggestion:
*** Invalid end of file

Anyway good to talking about these, I see many more verification need to be added in my EXDOS expansions :oops:

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.30. 14:08:57

Looks good to me zozo! My only comments are minor - ignore or change as you wish!

0BFh .NOUPB
*** Invalid UPB would be more consistent with the other error messages

0BDh .ICMD
I agree - be consistent with the other error messages

0B0h .ICALL
I would put File System Handler instead of FISH. If an end user saw something about a fish they would either be alarmed or amused!

09Bh .OV64k
If EXDOS behaves differently to the other devices isn't this really a bug in EXDOS? Could it be changed just to read up to FFFF and do away with this error?

B.

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.30. 14:35:01

Quote from: BruceTanner

09Bh .OV64k
If EXDOS behaves differently to the other devices isn't this really a bug in EXDOS?

I think this is for protect system area at Page 0. Anyway all old tape released program fixed which are generated this error. Only when found new old program are possible :-)
Or when writing new program and typing some wrong addresses :oops:

Anyway I will look it is possible first loading to FFFFh and then generate this error. Now immediately generated before start loading.

But need a good message...
*** Memory overflow
*** 64K memory overflow
*** 64K address space overflow
???

Title: Re: EXDOS
Post by: lgb on 2014.April.30. 14:54:28

Quote from: Zozosoft

BFh  .NOUPB
This is happened when Unit Handler called for sector operations but the Unit Parameter Block not filled with boot sector parameters. Some disk errors also set status bit in UPB for set it is as invalid.
*** UPB not valid
are right?

"UPB is not valid" sounds more correct.

Quote

9Bh  .OV64k
Try to transfer data over FFFFh Z80 address. For example read 200h bytes starting at FE00h. It is very frequent error because TAPE, NET and other EXOS devices not checking this problem.
Any good idea for the message?

Address space overflow, or something similar?

Quote

9Ah  .FILE
End of file entry readed from the FAT before it is ending by the file size from directory
My suggestion:
*** Invalid end of file

It sounds a bit odd for me. I think it should be something like "unexpected end of file" or so?

But - I guess - my ideas is too much based on my experience of UNIX-like systems, no more "segmentation fault" here at least :)

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.30. 14:58:57

Quote from: lgb

I think it should be something like "unexpected end of file" or so?

Good idea!

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.30. 22:15:36

Quote from: Zozosoft

*** Memory overflow
*** 64K memory overflow
*** 64K address space overflow

Which is the best? Or other suggestions?

Title: Re: EXDOS
Post by: BruceTanner on 2014.April.30. 22:20:34

Quote from: Zozosoft

Which is the best? Or other suggestions?

I'd go for *** Lazy programmer :evil:

But if I can't have that I'd go for *** 64k memory overflow :)

Title: Re: EXDOS
Post by: Zozosoft on 2014.April.30. 23:04:26

Quote from: BruceTanner

I'd go for *** Lazy programmer :evil:

:mrgreen:

Quote

But if I can't have that I'd go for *** 64k memory overflow :)

Ok.

Final one: if the data not readed from WD Data Register before the next byte decoded, then it is lost, WD set Lost Data error bit in the Status Register. (At the writing write 00h when the next data byte not written in time to the Data Register)
This error reported by the DISKIO but later it is decoded same Data error as the WD CRC error.
Probably because in standard system this can not be occured. But with Turbo EXDOS (handling HD disks) are very often possible if the Z80 not switched to enought high clock frequency.
I want to add new error code and message for this.
*** Lost data
Techicaly right but not too informative for the end user. He can think something lost from the disk.
*** Lost data because CPU running too slow
Informative, but I think too long :oops: Ok now we have lot of ROM space :-) but I more like the original style messages.
Any good idea?

Title: Re: EXDOS
Post by: BruceTanner on 2014.May.01. 00:05:08

Good idea separating the errors, much less misleading if you get one.

I'd go for either *** Missed data or *** CPU too slow

Title: Re: EXDOS
Post by: lgb on 2014.May.01. 00:31:47

Quote from: BruceTanner

Good idea separating the errors, much less misleading if you get one.

I'd go for either *** Missed data or *** CPU too slow

Hmmm,
*** Missed data by slow CPU
? Combined (both of the ideas combined - I mean), not so long, no "because" construct which is not so nice in an error message in my opinionm etc.

Title: Re: EXDOS
Post by: szipucsu on 2014.May.02. 10:45:08

Quote from: lgb

"UPB is not valid" sounds more correct.

It really sounds better but as I can see the error messages from 20 years ago, verbs are very rare in them. That's why I suggest "UPB not valid", without an "is".
Error messages always had the style of a newspaper article title, without verbs. I don't think we should break this "tradition".

Title: Re: EXDOS
Post by: BruceTanner on 2014.May.02. 11:00:34

Quote from: szipucsu

It really sounds better but as I can see the error messages from 20 years ago, verbs are very rare in them. That's why I suggest "UPB not valid", without an "is".
Error messages always had the style of a newspaper article title, without verbs. I don't think we should break this "tradition".

The main reason for not having verbs in the error messages of 20 years ago is probably lack of ROM space! But I agree - keep the tradition. However a lot of the messages are of the form ”Invalid xxx” so I suggest *** Invalid UPB

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.02. 14:52:34

Quote from: Saint

Zozo -- where is your modified EXDOS ROM which I will need for the driver to work?

There is the current version. Not a final, but working :-)
For system without floppy controller (for example SD Card only) need to use the "nowd" version.
It is a nother bug in the DISKIO which are needed to fix it :oops: If WD177x not present (or dead) the DISKIO frozen in infinite loop while wait Non Busy state from WD.

Szipucsu! Can you check it the new German messages? The HELP screen and errors: 154, 155, 160, 163, 176, 187, 188, 189, 191
In the snapshot just press F1 for list error messages. I used the existing messages and Google translate to create new ones, probably not too good results :oops:

Title: Re: EXDOS
Post by: szipucsu on 2014.May.02. 18:06:47

Quote from: Zozosoft

Szipucsu! Can you check it the new German messages? The HELP screen and errors: 154, 155, 160, 163, 176, 187, 188, 189, 191
In the snapshot just press F1 for list error messages. I used the existing messages and Google translate to create new ones, probably not too good results :oops:

The help screen seems OK for me.

154 Unerwartetes Datei-Ende ("E" in capital)

155 I would say: "Speicherplatz Überlauf."

160 "Ungültiges" (not unzulässiges) (FCB - What is it?)

163 "Ungültiges" (Is Eintrag the best word for entry? I don't know...)

176 OK!

187 "Ungültige"

188 "Ungültige"

189 "Ungültiger"

191 "Ungültiges" (What is UPB?)

The best solution would be to ask somebody who is from Germany.

Title: Re: EXDOS
Post by: lgb on 2014.May.02. 18:49:20

Quote from: szipucsu

It really sounds better but as I can see the error messages from 20 years ago, verbs are very rare in them. That's why I suggest "UPB not valid", without an "is".
Error messages always had the style of a newspaper article title, without verbs. I don't think we should break this "tradition".

Ok, but then "not valid" = "invalid" so "Invalid UPB" sounds still better. In my opinion, I mean.

Title: Re: EXDOS
Post by: gflorez on 2014.May.02. 23:50:27

Hello Zozo. If space is available I would like retouching some the Spanish EXOS messages, both old and new. Some need to be shortened and others need to be more explicit by changing one word or two.



Is this snapshot the final list? I will compare and correct the old messages.


By the way, in Spanish all things have gender, male or female, then, to do a strict translation, I need to know what mean those acronyms(UPB, FCB) to know if they are boys or girls......... Then I will write "incorrecto" or "incorrecta"

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.03. 10:56:48

Ok, there is the current English message table, and the Spanish extracted from your ROM. Sometimes you used 0 bytes when the message short. I now removed these and modified the lenght bytes.

You can extend messages as you want, no space limit :-) just currect the length bytes. I suggest to use Programmer's Notepad (http://www.pnotepad.org/), it is can display character count of selected text then very easy to modify length bytes.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.03. 12:29:08

I forgot: FCB = File Control Block
UPB = Unit Parameter Block

Title: Re: EXDOS
Post by: gflorez on 2014.May.03. 13:44:02

Okay, block is male gender in Spanish(bloque).....

Thanks.

Title: Re: EXDOS
Post by: szipucsu on 2014.May.03. 15:30:08

Quote from: Zozosoft

I forgot: FCB = File Control Block
UPB = Unit Parameter Block

This is important for the German messages, too! That's why I asked about FCB and UPB "What is this".

So:
error 160 and 191: Ungültiger ("r" at the end!)

(Block is male both in German and in Spanish, great! :D )

PS: Take attention to the German endings! UngültigeR, ungültigE, ungültigeS (three genders, three endings!)

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.03. 16:33:55

Quote from: szipucsu

three genders, three endings!

Crazy language! :lol:

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.03. 18:04:29

Ok, I edited the German messages. Szipucsu, can you chechk it again?

One more question: when do the German messages begin with capital letters? Originaly total mixed... (http://enterprise.iko.hu/errors.htm)

Title: Re: EXDOS
Post by: szipucsu on 2014.May.03. 19:01:36

Quote from: Zozosoft

when do the German messages begin with capital letters? Originaly total mixed... (http://enterprise.iko.hu/errors.htm)

I think they should always begin with capital letters. But, in that messages only the nouns are written with capital letters (as nouns in the German language are always written with capital). But I would begin all the messages with capital letters as in English.

---
Szerintem mindet nagybetűvel kéne kezdeni. A németben a főneveket nagybetűvel írjuk, ott csak azok az üzenetek kezdődnek nagybetűvel, amik főnévvel kezdődnek. De, ahogy az angolban, a németben is úgy lenne logikus, ha minden hibaüzenet nagybetűvel kezdődne. Én nagybetűsre írtam át ezért mindent.

Title: Re: EXDOS
Post by: szipucsu on 2014.May.03. 19:07:56

174 Unzulässiger Parameter

(der Parameter)

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.03. 19:16:30

Quote from: szipucsu

174 Unzulässiger Parameter

(der Parameter)

It is mistyped by Enterprise Computers GmbH :-)

Title: Re: EXDOS
Post by: szipucsu on 2014.May.03. 19:27:50

If there is a full-stop at the end of the German messages, they should begin with capitals.

---
Ha pont van a német hibaüzenetek végén, akkor nagybetűvel kéne kezdődniük...

Title: Re: EXDOS
Post by: gflorez on 2014.May.03. 22:30:54

I've edited the Spanish error messages and counted the characters. Added some accents. Don't know if "ú"(from "Número") has the correct control code in the text, chr$(126), "~" on the UK side of the ROM.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.03. 23:27:38

Ok, try it! In the snapshot just press F1 for list errors.

Title: Re: EXDOS
Post by: gflorez on 2014.May.04. 01:02:40

You are fast. Only I forgot one accent, and modified the name of "RAM-DISK" to "disco RAM" like in the English sentences.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.04. 01:14:50

Quote from: gflorez

You are fast. Only I forgot one accent, and modified the name of "RAM-DISK" to "disco RAM" like in the English sentences.

Ok, updated.

Title: Re: EXDOS
Post by: gflorez on 2014.May.04. 10:23:17

It seems finished to me, Zozo. I will test the ROM from now on.

Title: Re: EXDOS
Post by: szipucsu on 2014.May.04. 10:26:11

Most Spanish messages are very similar to the English ones. Just put an "o" or "a" to the end of the words and you have the Spanish equivalent. Everybody could easily understand them:

directory - directorio
duplicate - duplicado
parameter - parámetro
invalid - invalido / invalida
code - código
disk - disco
error - error (!)

---
Gustavo! Not a DOS disk would not be better this way? Disco no es de DOS? Or: No disco de DOS?
Por "Not a DOS disk" ¿no es mejor Disco no es de DOS? ¿O: No disco de DOS?

Title: Re: EXDOS
Post by: gflorez on 2014.May.04. 10:55:26

Hello szipucsu!

You are right, English and Spanish languages(better named Castillian, as we have other spanish languages, like Gallego, Catalán or Euskera) are very similar, is easier for Spanish people to learn English as it seems to us like a simplified idiom. Then all tongues have its difficulties, as phrasal verbs and irregular verbs, but is easier than the complexity of the Spanish temps of the verbs..... The most difficult part to us is the pronunciation.
------------
Tienes razón, el Ingles y el Español(Mejor llamado Castellano, pues tenemos otras lenguas que también son españolas, como el Gallego, Catalán o Euskera) son muy similares, es mas fácil para los españoles aprender Ingles porque nos parece un idioma simplificado. Pero todos los lenguajes tienen sus dificultades, como los "phrasal verbs" o los "irregular verbs" pero es mas fácil que la complejidad de los tiempos verbales del Español... La parte mas difícil para nosotros es la pronunciación.

Title: Re: EXDOS
Post by: gflorez on 2014.May.04. 11:34:48

I have put "No es un disco DOS" because it was exactly the warning error of the Spanish translated Microsoft DOS on the early PCs....

It sounds to me like the disk hasn't the DOS brand or better it has not the DOS format, as we really want to express.

On the other hand, if you add a "de" before "DOS" in the sentence, it doesn't adds much more sense, but begins to form a  tongue-twister as you repeat excessively the "d" sound(we pronounce DOS as the Spanish "2"). Then "dedos" is finger in Spanish"....
----------------------------------------------

He puesto "No es un disco DOS" porque ese era exactamente el mensaje de error en el DOS traducido al Castellano de los primeros PCs...


Me suena como si el disco no tuviera la marca del DOS o mejor como si no tuviera el formato DOS, como realmente queremos expresar.


Por otro lado, si añades un "de" delante de "DOS", no añade mucho mas sentido a la frase, pero empieza a parecer un trabalenguas, porque se repite excesivamente el sonido "d".( En Castellano DOS se pronuncia como el numero 2). y entonces "de DOS" se puede confundir con "dedos".

Title: Re: EXDOS
Post by: gflorez on 2014.May.04. 12:03:36

Oh sorry szipucsu you was right, that message was untouched from the far years when there was no spare space in the ROM.

Then "No es un disco DOS" is the correct sentence for the reasons I said.
-------------------
Oh perdón szipucsu, tenias razón, ese mensaje estaba sin tocar desde los tiempos en los que no había espacio libre en la ROM.

Por lo tanto, "No es un disco DOS" es la frase correcta por las razones mencionadas.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.04. 14:28:06

Quote from: gflorez

Then "No es un disco DOS" is the correct sentence for the reasons I said.

Ok, updated. Any more? :ds_icon_cheesygrin:

Title: Re: EXDOS
Post by: gflorez on 2014.May.04. 14:30:37

Sorry Zozo. Thanks.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.04. 17:08:51

Ok, here are the current versions.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.07. 21:14:37

Gustavo!
There is IS-DOS Spanish version, extracted from your old modified EXDOS-ISDOS ROM.
It is ok?

This will be built in to the new 1.4 Spanish ROM.

Title: Re: EXDOS
Post by: gflorez on 2014.May.07. 22:02:28

 Do we have room for more explicit messages too?

If  so let me add some verbs and complements to the sentences.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.07. 22:07:44

Quote from: gflorez

Do we have room for more explicit messages too?

Currently no :-( It also needs to be disassembled.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.07. 22:12:45

I found one missing translation, at about 1300h, it is part of the MODE command, when writing 40 or 80 column screen, the secondary language message left Hungarian.

Title: Re: EXDOS
Post by: gflorez on 2014.May.07. 22:35:13

Ok, not a hard work. I`ll rearange some lines and fix that error. Tomorrow morning, as I haven`t a PC now.

Title: Re: EXDOS
Post by: gflorez on 2014.May.07. 23:14:43

I can't wait till tomorrow.... Only two modifications possible.... and made.

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 11:21:06

The most frustrating bug when using EXDOS with EP64:
[attach=1]

The EXDOS manual talking about it:

Quote

If you are using an Enterprise 64 with EXOS version 2.0

 - You will not be able to use the 'null' filename to load the file
  'START' from disk (see appendix E). If you press Fkey 1 [START]
  from BASIC, EXDOS will think that you are trying to load a file
  from the RAMDISK.

I debbuged the problem: the bug is in the EXOS 2.0 device handler interface.
The EXOS string (http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/kernel/Ch11.html#11.1) used at channel open have a 4 parts all are optional
- device name
- "-" character
- unit number
- file name
Some valid examples:
"TAPE-2:GAME.BAS"
"DISK1:GAME.BAS"
"2:GAME.BAS"
"B:GAME.BAS"
"TAPE2:"
"GAME.BAS"
""
If no device name definied then the Default Device used. If no unit number definied then 0 unit number used.
When using EXDOS, the Default Device are the DISK: and DISK0: means the current drive. DISK1 to DISK26 the drives from A to Z.
When using just filename for example "GAME.BAS", then DISK device used, and 0 unit number passed by the EXOS to DISK device, then using default drive for load GAME.BAS.

It is a special function of the EXDOS when null filename used for loading then using "START" filename. This is for IS-BASIC, when pressing F1 key as in tape system, it is enter command START. It is use "" filename for loading.
The problem about it in the EXOS 2.0: when using null EXOS string then the Default Device right used, but forgot to use 0 as default unit number. C register contains the unit number passed to device driver, at this situation contain some random data (probably the length of default device name string), it is =5. Then the DISK device think need to use 5. disk drive which are the E: then come the No RAM disk error, because no RAMDISK at startup.

Anyway if you create RAMDISK and put the START file to E: then the START command works :-)

If device name or unit number are definied then the right unit number passed to DISK device, for example:
LOAD "DISK:"
LOAD "DISK0:"
LOAD "0:"
LOAD "DISK-0:"
are load the START file from the default drive.
But these need a many more typing than just pressing F1 key...

The best solution are the upgrade EXOS in the machine... but todays many EP64 machines in the collections don't want to be opened.
So, I thinking add some hack to DISK device for bypassing this problem:

IF filename="" AND unitnumber=5 AND EXOS=2.0 THEN LET unitnumber=0 :-)

With this modification the START will be works on unmodified EP64! But this will generate another bug :oops:
LOAD "DISK5:" will be load START file from the default drive instead drive E: when using EXOS 2.0.
But I'm really sure nobody typed LOAD "DISK5:" command in the last 30 years :ds_icon_cheesygrin:
(LOAD "E:" will works corretly, and no problem with LOAD "DISK5:filename" commands.)
Then I think this will be acceptable compromise, the START command (just press F1 key in BASIC) are very often used, need to be working also with EXOS 2.0.

What do you think about add this modifications to EXDOS 1.4?

Title: Re: EXDOS
Post by: gflorez on 2014.May.18. 23:01:55

I like your efforts to homogenize EXOS and EXDOS to work with every configuration. Now is a good oportunity, I think you must do it.

Title: Re: EXDOS
Post by: BruceTanner on 2014.May.18. 23:08:38

Well deduced and described zozo :)  go for it! :smt023

Title: Re: EXDOS
Post by: Zozosoft on 2014.May.18. 23:18:47

Already done :-)
This code inserted (with subrutine call) at the DISK open entry point:

Code: ZiLOG Z80 Assembler

1.     LC778:  LD A,(0B21CH)
2.                     CP 0B2H
3.                     JR Z,C778END    ;EXOS 2.1+
4.                     LD A,(DE)
5.                     OR A
6.                     JR NZ,C778END   ;NOT A NULL FILENAME
7.                     LD A,C
8.                     CP 5
9.                     JR NZ,C778END   ;NOT A DISK5
10.                     LD C,0                  ;0 UNIT NUMBER
11.     C778END

Also added ISDOS to ROM, it is compressed by Epcompress (from IstvanV).
There is the first test version.

Title: Re: EXDOS
Post by: Zozosoft on 2014.October.15. 23:53:07

Latest EXDOS 1.4 (near to final), big modification about EXDOS.INI search, because now need a HDD (SD) booting :-)

Search the EXDOS.INI at drives: E-F-B-A
Because possible to put something crazy to F:EXDOS.INI :-D , added feature for skip it: pressing Left SHIFT key will skip the EXDOS.INI search (like as at PC from MSDOS 5.0+ you can skip the configuration files).
At the ENTERPRISE screen press down the SHIFT and press other key, and still down the SHIFT for few moments.

At default only run one EXDOS.INI. For example it is found on F: then don't search it on floppies.
With the CTRL key possible run all EXDOS.INI files for example after the F: then also run from A: (if the first INI give back the control).

With the ALT key only the floppy drives (B-A) searched for the INI file.

The actual drive:
At the start of EXDOS.INI the drive which are contain the INI will set to the actual drive.
If one EXDOS.INI succesfully executed then the actual drive saved and will be restored at the end. For example INI runs from F: and no INI at floppy drives then the F: will be the actual drive when entering to the BASIC prompt.
If more INI files executed then the drive of the last one will be preserved.
If the INI file change the drive, for example runs from F: and change to H: and no other INIs, then the H: will be the actual.

If no any INI files (or skiped by SHIFT) then the F: will be the default actual drive if it is exist. If not exist then the A: used as default.

(Think about your PC: it is start with C: if hard disk installed. At Enterprise the F: the first hard disk drive letter (it is can be a IDE disk or SD card))

Title: Re: EXDOS
Post by: lgb on 2014.October.16. 18:08:36

Something odd happened here, when I tried to use this EXDOS version in JSep:

http://ep.lgb.hu/jsep/demo.new/ (http://ep.lgb.hu/jsep/demo.new/)

It uses its "default" EXDOS (it's EXDOS20.ROM by its name at least), you can start ISDOS from IS-BASIC with command ":ISDOS" with no problem (I guess it needs IS-DOS.SYS from disk, but it's on the default disk image used by the emulator), you can try it.

Now, I've just installed (onto the JSEP server so it can use it) the EXDOS version you posted here, you can try it here:

http://ep.lgb.hu/jsep/demo.new/?exdos=exdos14.rom (http://ep.lgb.hu/jsep/demo.new/?exdos=exdos14.rom)

What I can see (from IS-BASIC again):

*** Unexpected value given.
*** BASIC data has been corrupted.

The last line repeats. Is it some kind of bug, or just bad combination of ROM images I use with my emulator?

Title: Re: EXDOS
Post by: Zozosoft on 2014.October.19. 10:57:59

Yes it is a bug :oops: :oops: :oops: (Hungarian version working) I will fix it.

Title: Re: EXDOS
Post by: Zozosoft on 2014.October.19. 11:56:52

Ok, fixed it, I have replaced the ROM file below.

Title: Re: EXDOS
Post by: lgb on 2014.October.19. 13:41:44

Quote from: Zozosoft on 2014.October.19. 11:56:52

Ok, fixed it, I replaced the ROM file below.

Indeed, it works now: http://ep.lgb.hu/jsep/demo.new/?exdos=exdos14.rom (http://ep.lgb.hu/jsep/demo.new/?exdos=exdos14.rom) I've replaced the ROM image with your new one. Thanks!

Title: Re: EXDOS
Post by: Zozosoft on 2016.October.16. 22:51:10

Two new error messages will be added to final EXDOS 1.4:
One are old error, without own message:
*** Lost data byte
This is directly from the WD177x (see the datasheet). It is happened when the CPU don't read the data from Data register before the next data byte arrived. It is can be happened with Turbo EXDOS, when HD disks used on non turbo Z80 clock.
(Previously this is translated as simple Data error)

Next is totaly new:
*** Controller not ready
It is happened when the WD177x can not accessed. For example using SD cartridge without EXDOS card :-)
Previously the EXDOS freezee at this situation. This is why needed remove floppy support from the SD ROM. Now controller check added, then not needed separate floppy and non-floppy EXDOS versions.

Any suggestions for German and Spanish translations?
I tried with google translate:
*** Verlorene Daten-Byte
*** Controller nicht bereit

*** Perdidas bytes de datos
*** Controlador no está listo

Title: Re: EXDOS
Post by: gflorez on 2016.October.17. 00:21:51

On a correct Castillian(one of the Spanish languages) I would like these messages:

*** Se ha perdido el Byte de datos or *** El Byte de datos se ha perdido
*** El controlador no está accesible

But then they would clash with the condensed messages of the ESP.rom. Better I select these:

*** Byte de datos perdido
*** Controlador no accesible

Title: Re: EXDOS
Post by: gflorez on 2016.October.17. 12:21:14

Or better female, as here we have put gender to the controller....

*** Controladora no accesible

Title: Re: EXDOS
Post by: Zozosoft on 2016.October.18. 22:04:23

Final (https://enterpriseforever.com/programozas/exdos-283/?action=dlattach;attach=16425) (I hope :oops: ) EXDOS 1.4

Bugs fixed from the beta version: ATTR, ATDIR, and ISDOS (when not built in the ROM) commands now don't freeze :oops:

New additions:
-Most important: DISKIO now checking the presence of WD177x (with register write/read), then not needed anymore special non-floppy version for SD adapter
-For this new error definied (193): "Controller not ready"
-New error definied (192) for the Lost Data error reported by FDC.
-DISKIO now using fixed port addresses (1xh), then EXDOS ROM can be used at any segment number
-German and Spanish version with built in ISDOS now have the proper language version
-the original ISDOS command (which used in the not built in versions) have a bug, which is reported in old Enterpress article. Now it is fixed: it is reset the BOOT DRV variable if the ISDOS loading failed
-at EXDOS.INI handling added one more key: the Right SHIFT will force run EXDOS.INI. This is for the "go to the EP logo screen" reset, where the EXDOS.INI will not run at default
-in one floppy drive system will not search the EXDOS.INI on drive B: (drive B: are mapdisked)
-FORMAT will write modern boot sector to floppies: 32 bit disk ID also written for PC, added FAT12 filesystem identifier, and boot code modified for don't freeze PC if it is try to boot from EP disk
-separate versions for EXDOS card with WD1772, it is set the default STEP RATE to 3 which is faster (3ms instead 6ms). Now it is done at the early initialization of EXDOS, then the drive check before the EP logo screen also use the faster speed.
-the non built in ISDOS versions have a lot of free space at the second segment, can be combined with other EXOS ROM expansions (for example the HXC, we talked it about somewhere)