Enterprise Forever
:UK => Programming => Topic started by: elmer on 2021.January.04. 20:29:19
-
There is a crash bug in IS-DOS, probably introduced sometime between when the IS-DOS specification (http://enterprise.iko.hu/technical/PER-16-2_ISDOS_System_Specification.pdf) document was written, and the final IS-DOS version 1.0 was released.
The important difference is in the way that IS-DOS uses memory.
In the original specification, IS-DOS would always allocate 64KB of memory, and then its program code would stay in the same location all of the time, unless that location was changed with a "RELOCATE" command.
In the shipping version of IS-DOS, the program code moves itself automatically from the Page0 segment to a different segment, usually Page3, when a CP/M program is run ... and then it moves itself back to Page0 once the CP/M has finished.
This means that EXOS keeps more segments free for other things whenever IS-DOS doesn't actually need the memory in order to run a CP/M program.
The crash bug occurs whenever a CP/M file is loaded that is larger than the amount of memory that is available for a CP/M program (the TPA size).
IS-DOS detects this, and displays an "*** Insufficient memory" message ... but it does not move itself back to Page0, and it keeps all of its memory.
The next time that a CP/M program is run, IS-DOS get confused because it is not in Page0, and its memory allocation breaks, memory is leaked, and a crash occurs.
In practice, it is unlikely that anyone will ever encounter this problem in normal use, because it is something that only happens if memory is low (i.e. you run IS-DOS on an Enterprise with more that 64KB, but less than 112KB), or because you specifically try to run a program file that is larger than 51KB.
Now it isn't very difficult to patch IS-DOS to fix this bug, but I don't see it as being worthwhile unless someone is patching IS-DOS for other reasons.
-
It could be great to upgrade from 2.2 version to 3+, profiting from the Enterprise memory paging capabilities.
-
It could be great to upgrade from 2.2 version to 3+, profiting from the Enterprise memory paging capabilities.
But i think it would be also a bigger task, hard to do by patching the code, the source code would be needed also for this action.
-
Yes, but "only" the ISDOS Enterprise code is needed, because the CP/M 3+ source is accessible here (http://www.cpm.z80.de/source.html).
-
It could be great to upgrade from 2.2 version to 3+, profiting from the Enterprise memory paging capabilities.
But i think it would be also a bigger task, hard to do by patching the code, the source code would be needed also for this action.
It would be technically cool to have CP/M 3 compatibility on the Enterprise, but I agree with geco, the only way to sensibly achieve this would be to have the original IS-DOS source code to start from.
While I am able to do a certain amount of reverse-engineering to understand how a program is working, there is no substitute for seeing the original programmer's comments in the source code.
Apart from that, if we did have CP/M 3 compatibility on the Enterprise, would it actually be useful?
I cannot personally remember there being any high-quality CP/M 3 software that someone would want to run in modern times.
Do you know of any CP/M 3 programs from the Amstrad CPC or PCW that we would find useful on the Enterprise?
With my limited imagination, I suspect that the thing that might be most useful today would be to modify IS-DOS to have a larger (61KB?) TPA.
Another useful upgrade would be to add either MSX-DOS2 compatibility, and/or ZCPR3 compatibility.
Both MSX-DOS2 and ZCPR3 have improved "Environment" and "Batch File" capabilities that would be useful on the Enterprise, and MSX-DOS2 seems to support expanded memory in a fairly similar way to how the Enterprise already works.
-
Ok, it is true, upgrading to 3+ is an impossible task, but if you ask for interesting PCW programs, there are a lot of them here (http://www.habisoft.com/pcwwiki/doku.php?id=es:aplicaciones:indice).
-
Ok, it is true, upgrading to 3+ is an impossible task
It is not actually an "impossible" task, just very, very difficult and time-consuming.
I have disassembled, and can modify, about 3KB of IS-DOS that relates to the fast video driver and CP/M program startup/exit, because those are the areas that I need to change in order to speed up the video driver so that VEDIT and WordStar are more pleasant to use, and don't look so slow when compared to the Amstrad CPC.
That still leaves almost 6KB of very dense and complex BDOS-emulation code that has a *lot* of complex interactions within it, that I do not even begin to understand.
Even if I did understand it well enough to patch the code, there still wouldn't be anywhere near enough free space within the current memory layout to add all of the new BDOS and BIOS functions from either CP/M3 or MSX-DOS2.
Having the original source code available would make things much less time-consuming and frustrating, especially the addition of MSX-DOS2 functionality, since IS-DOS is already compatible with MSX-DOS1, and both IS-DOS and MSX-DOS are designed to use MS-DOS format discs and not CP/M format discs.
but if you ask for interesting PCW programs, there are a lot of them here (http://www.habisoft.com/pcwwiki/doku.php?id=es:aplicaciones:indice).
Yes, there were some very nice business/productivity programs written for the Amstrad PCW computers!
With a market of approx 8 million PCWs sold, nearly 3 times the number of Amstrad CPC sales, there was an incentive for developers to produce good business software for it.
But I think that you will find that most of those programs on that list are not pure CP/M3 programs, and that they rely on either the "GSX" RSX or, more often, the Amstrad XBIOS firmware routines.
Even then, I expect that the best of those programs would use the Amstrad PCW screen hardware directly for speed.
To get those programs running on the Enterprise would need a full PCW-emulator ... which might be unusable in practice, since the PCW's screen is wider than the Enterprise can display.
See here (https://www.seasip.info/Unix/Joyce/hardware.pdf) for PCW hardware information.
What is interesting to see here (https://en.wikipedia.org/wiki/Amstrad_CP/M_Plus_character_set) is that the Amstrad's CP/M3 character set uses a similar method to the Enterprise (i.e. ISO-646) for displaying international characters.
-
I wonder , so much PCW were sold? 8 million sounds very much, it is close to the number of sold Speccies which is above 10 million if i know well, but none of them is close the number of sold Enterprises :ds_icon_cheesygrin: :ds_icon_cheesygrin:
-
I checked, only 5 million Speccy were sold,3 million CPC, 12,5-17 million C64, and 8 million PCW, i have never thought that.
Sorry for the off.
-
I suspect that the thing that might be most useful today would be to modify IS-DOS to have a larger (61KB?) TPA.
On a ep128 you could theoretically have the bulk on the BDOS emulation code in a segment outside the TPA, all you'd need in the TPA would be the entry points and some paging code. Nearly 64Kb TPA!
-
But i think it would be also a bigger task, hard to do by patching the code, the source code would be needed also for this action.
Ok, there is it :ds_icon_cheesygrin:
I started to order it, but continously out of free time.. :oops:
Before patching anything, need to recreate the source configuration, which is result file bit-to-bit same with the released original version.
Need to find the right link order, and find differences if any exist then modify back. Don't know, but possible some files are later than the released version.
(I do same work for get a EXDOS 1.0, 1.1, 1.2, 1.3, 2.0, 2.1 sources, which are now enhaced to EXDOS 3)
Original sources using M80 and L80, possible to do the job under IS-DOS, but much faster to use XCPM utility from Lgb, which are run these CP/M programs under Windows (Linux version also exist).
Run M.BAT then L.BAT for do the job.
SJASM only used for add the 16 bytes EXOS header to the file.
IS-DOS.SYS are the original file. Note: the original file 13824 bytes, but in the header only 13680 lenght, then the total valuable data are 13696 bytes. This SYS file are the truncated version without the additional garbage.
IS-DOS.COM the result of the compile.
Have a good luck!
-
On a ep128 you could theoretically have the bulk on the BDOS emulation code in a segment outside the TPA, all you'd need in the TPA would be the entry points and some paging code. Nearly 64Kb TPA!
Yes, that is my thought, especially since IS-DOS already jumps through a number of unneccessary hoops to page its code in Page3 whenever a BDOS or BIOS function is called, and so it might not be too bad to have it page into a dedicated code segment.
The question seems to be whether IS-DOS would be better off as a mostly-compressed 11KB relocatable extension, or as a full 16KB absolute extension, which would then allow it to page in and run its code as needed.
Note ... there's a decent amount of self-modifying code in there, so it can't just run as a ROM.
As it is, my main interest is in *removing* some of that unnecessary page switching from the video driver so that it runs faster!
Well, that and adding some of the extra Heathkit/Zenith H-19 (http://koyado.com/Heathkit/H19C_Terminal_files/Heath%20Z19%20Terminal%20Operating%20Manual.pdf) ESC codes that weren't in the video driver's more-limited VT-52 emulation. ;-)
-
Thank you very much Zozo, it really seems to be hard, I hope we could create to reproduce the source of the actual binary.
-
Ok, there is it :ds_icon_cheesygrin:
I started to order it, but continously out of free time.. :oops:
Thank you Zozo, these will be a huge help! :mrgreen:
Before patching anything, need to recreate the source configuration, which is result file bit-to-bit same with the released original version.
Need to find the right link order, and find differences if any exist then modify back. Don't know, but possible some files are later than the released version.
(I do same work for get a EXDOS 1.0, 1.1, 1.2, 1.3, 2.0, 2.1 sources, which are now enhaced to EXDOS 3)
I wondered how you were working on the EXDOS upgrades!
I think that I'm familiar enough with the IS-DOS internals at this point that figuring out the link order shouldn't be too hard. :)
It will be interesting to see how the source it written in order to build the final IS-DOS executable, which is comprised of three sections of code that run in totally different areas of memory, all put together in one file.
-
i will try to create one file from sources, i hope, it can be managed. Until now i could manage these kind of activities, and i hope it can be done for IS-DOS also.
-
There is another reason we might need to be able to re-build IS-DOS: EXDOS 3 and FAT16 support in CP/M apps.
EXDOS 3 has to use an extra byte in the "reserved" area of the FISH FCB structure (for flags which were previously held in the top 4 bits of a FAT12 cluster number). The question that has been in my mind recently is: when IS-DOS converts FISH FCBs to CP/M FCBs, and back again, is this byte also copied? Probably not :oops: but I haven't been able to try it yet :oops: :oops: Looking at the source now, definitely not :oops: :oops: :oops:.
I cannot remember from 30+ years ago if there is an unused / reserved byte in CP/M FCBs that can be used; if there are, it should be an easy fix but if there are not, it will need more thought...:roll:
-
i will try to create one file from sources, i hope, it can be managed. Until now i could manage these kind of activities, and i hope it can be done for IS-DOS also.
Good luck! Having it all in one SJASM source file would be useful for quick assemby.
I'll send you my disassembly of the whole of IS-DOS, partially commented, and the SJASM build files that I am using for making the patched versions. :cool:
-
There is another reason we might need to be able to re-build IS-DOS: EXDOS 3 and FAT16 support in CP/M apps.
:ds_icon_cheesygrin:
I cannot remember from 30+ years ago if there is an unused / reserved byte in CP/M FCBs that can be used; if there are, it should be an easy fix but if there are not, it will need more thought...:roll:
One of the things that I'd love to import from other versions of CP/M 2.2, if it isn't already used in IS-DOS, is the otherwise-undefined LAST RECORD BYTE COUNT, that CP/M 3 uses to define exact file sizes.
https://www.seasip.info/Cpm/bytelen.html
-
... there's a decent amount of self-modifying code in there, so it can't just run as a ROM.
Maybe, once the code sorted, you can compare it with the EXDOS+ISDOS Rom we manage. As far as I know the two Roms were packed on Hungary, not by Intelligent Software. But I don't know if in this case the Rom is only a container to load in Ram the ISDOS extension.
-
Maybe, once the code sorted, you can compare it with the EXDOS+ISDOS Rom we manage. As far as I know the two Roms were packed on Hungary, not by Intelligent Software. But I don't know if in this case the Rom is only a container to load in Ram the ISDOS extension.
The "ROM ISDOS" just copy (decompress) the IS-DOS.SYS file to 100h and start is, simulate the original 05h type file start.
And only a little modification: when the IS-DOS reload itself, modified it for copy it again from ROM instead from loading from disk.
-
Original sources using M80 and L80, possible to do the job under IS-DOS, but much faster to use XCPM utility from Lgb, which are run these CP/M programs under Windows (Linux version also exist).
Run M.BAT then L.BAT for do the job.
Just in case anyone else is trying: using M80 with XCPM when I was working on EXDOS, I found that it could not produce .PRN files. Might just be the Linux version...:roll:
-
Just in case anyone else is trying: using M80 with XCPM when I was working on EXDOS, I found that it could not produce .PRN files. Might just be the Linux version...:roll:
Under Windows is working!
-
Here is the SJASM version of the sources of IS-DOS 1.0, it is ugly, because i changed all TAB's to spaces, but i started it and it is working, it seems our original ISDOS.SYS was dumped from the memory, because there are 2 bigger areas and a 2 byte and a 4 byte space which contain data, compiled source contains 00h-s, and filled up after start.
Please check it, and report if you find any problem.
-
Here is the SJASM version of the sources of IS-DOS 1.0, it is ugly, because i changed all TAB's to spaces, but i started it and it is working, it seems our original ISDOS.SYS was dumped from the memory, because there are 2 bigger areas and a 2 byte and a 4 byte space which contain data, compiled source contains 00h-s, and filled up after start.
Cool, thanks! :)
Yes, the only thing that makes sense to me is that source was built on a computer that had used MOVECPM to make a 48KB CP/M system (with 40KB TPA), and leave the top 16KB free for linking programs directly into the Page3 ($C000-$FFFF) region.
The two numbers printed when you assemble START.MAC are the addresses needed for the L80 "/P" options that put IS-DOS into the correct area of memory.
Then the development batch file would just save out the memory (using the numbers printed), and the ISSQUASH program mentioned in START.MAC is then used to process the memory dump and insert the missing checksum data, and the serial# data, into the final IS-DOS.SYS image.
That is kinda cool, and it certainly helps to explain (to me) how the programmers at IS managed to develop the Enterprise ROMs with rather primitive M80/L80 programs that were available back then.
IIRC, there were a number of CP/M add-in boards for the IBM PC back then that would have allowed for this kind of workflow.
-
IIRC, there were a number of CP/M add-in boards for the IBM PC back then that would have allowed for this kind of workflow.
Yes, Bruce already wrote it earlier: at the IS used PC with a Z80 card. Softwares started before any Enterprise hardware exist.
-
I've kept on working (for the moment) with the original source files that Zozo kindly posted earlier, and his build scripts only need a few changes to compile a good version of IS-DOS ...
Change MAKECOM.ASM ...
defpage 0
page 0
output IS-DOS.NEW
org 00f0h
incbin ISDOS.BIN,008Ch
PEND: equ $
end
Change L.BAT ...
DEL OS.REL 2> nul
XCPM LIB80.COM OS=CODES,EXCODES,BOOT0/E 2> nul
REN OS.LIB OS.REL
XCPM L80.COM OS,/P:C9E4,START,VID,CLI,CMD,FNINIT,CLIV,/P:E100,FIX,CLIO,CLIF,REBOOT,FNVAR,FUNC,CPM,CHAR,BUFDEV,VIDEV,END,ISDOS.BIN/N/Y/E <nnnn 2> nul
SJASM4 MAKECOM.ASM
To explain ... the L80 command line is too long if you add in all of the filenames and the "/P" commands, so I used LIB80 to create an OS.REL library from the first three assembled files, so that it can be used to shorten the command line.
This is than complicated because XCPM doesn't seem to support LIB80 renaming the output file from OS.LIB to OS.REL, so I had to specifically add that to the L.BAT file.
When L80 links a file to the top of memory like this, it adds a 128-byte header onto the file to move the data into place when the .COM file is run, so I had to modify MAKECOM.ASM to strip off the extra bytes from the front of the file.
When that is all built, you basically get a file called "IS-DOS.NEW" that is almost-identical to the shipped version of IS-DOS.SYS.
There are a few differences, but the only one that actually matters is that the "Duplicate Definition" of "ORM" that L80 reports is something that MUST be fixed.
Attached is a file showing the differences between IS-DOS.SYS and ISDOS.NEW, where they come from, and why they are expected and don't matter.
Anyway, the point of this is to confirm that the original source files from 1985 really do correspond to the shipped version of IS-DOS that we all know and love. ;-)
-
Yes, I got nearly the same differences with the sjasm version, except if i remember well the 6 bytes from CMD.MAC.
I used 0C900h as delta, because i set org 00f0h before EXOS header
-
the L80 command line is too long if you add in all of the filenames and the "/P" commands
The .REL files do not have to have the same base name as the source files, and back in the day (and still for EXDOS 3) we would assemble the sensibly-named .MAC source files to a less-sensibly-named two letter .REL file, for example START.MAC would assemble to ST.REL, REBOOT.MAC would assemble to RE.REL etc to shorten the L80 command line length!
XCPM doesn't seem to support LIB80 renaming the output file from OS.LIB to OS.REL.
I am not surprised, XCPM is very hacked together by lgb and he did warn us that not all functions are supported! :roll:
Anyway, the point of this is to confirm that the original source files from 1985 really do correspond to the shipped version of IS-DOS that we all know and love. ;-)
This is very good news! :mrgreen:
-
Yes, I got nearly the same differences with the sjasm version, except if i remember well the 6 bytes from CMD.MAC.
You did a better job than me! ;-)
I don't know why I wanted to get the original M80/L80 build working, but it seemed nice to think that we could actually build this code on an Enterprise itself someday (if IS-DOS allowed us to leave the top 16KB segment free for L80 to use ... which the original IS-DOS specification would have supported).
Anyway, another thing ... Bruce, while I was getting frustrated trying to figure out how to make this work, and couldn't find out where XCPM came from, I ended up making a 48KB CP/M environment to do the M80/L80 build in RunCPM (https://github.com/MockbaTheBorg/RunCPM). Is that a program that you have seen (it is linux-compatible)?
-
So... M80 or SJASM? :twisted: :lol:
Good work both, choice is good! :mrgreen:
-
Is that a program that you have seen (it is linux-compatible)?
No I haven't; I did try another CP/M emulator (forgotten the name) but it required the use of CP/M disk images and a program to read/write files to it from the host, which was a pain.
The advantage of continuing to work with M80/L80 for EXDOS (apart from having to do lots of conversion work - it is more complicated than IS-DOS) is that you can diff the new source files vs the original. That said, I put all my changes in IF..THEN..ENDIFs and I haven't used diff at all!
-
if you wish, i can try to create a sjasm source from exdos too, and if i can do it, you do not need to deal with cp/m emulation and disk images anymore.
-
if you wish, i can try to create a sjasm source from exdos too, and if i can do it, you do not need to deal with cp/m emulation and disk images anymore.
Thank you for the offer, but it is not necessary now - the cp/m thing was only one thing I tried - lgb's xcpm is much more usable, and the changes are done now.
-
lgb's xcpm
OK, that was the extra clue that I needed ... I found it! :cool:
https://github.com/lgblgblgb/reCPM
-
lgb: https://enterpriseforever.com/profile/?u=6 (https://enterpriseforever.com/profile/?u=6)
-
lgb: https://enterpriseforever.com/profile/?u=6 (https://enterpriseforever.com/profile/?u=6)
Cool! :)
I suspected that he was active in the community here once I saw his location, and that he had developed an Enterprise emulator.
The .REL files do not have to have the same base name as the source files, and back in the day (and still for EXDOS 3) we would assemble the sensibly-named .MAC source files to a less-sensibly-named two letter .REL file, for example START.MAC would assemble to ST.REL, REBOOT.MAC would assemble to RE.REL etc to shorten the L80 command line length!
Hahaha ... nice workaround for the problem, much better than using lib80!
I've applied that trick and have got IS-DOS building with just simple XCPM calls.
I am not surprised, XCPM is very hacked together by lgb and he did warn us that not all functions are supported! :roll:
Now that I can see the source code and understand what it is doing ... it is a very, very nice solution to get the old source code building on a modern computer!
I like having RunCPM too as an alternative, the critical thing with both of them being that they just accesses files on your regular PC, and that there is no need for using disc images.
That keeps the source editable with modern editors, and usable with "modern" tools such as grep/diff/patch.
It also allows using Source-Code-Control systems such as GIT or PERFORCE, which might be cool is you get to the point of having multiple people working on code, or want to keep a formal log of the changes that are made.
SCC is something that us programmer-types didn't ever really have to think about in the 1980s, but is such an important part of modern software development.
-
There is a crash bug in IS-DOS, probably introduced sometime between when the IS-DOS specification (http://enterprise.iko.hu/technical/PER-16-2_ISDOS_System_Specification.pdf) document was written, and the final IS-DOS version 1.0 was released.
...
Now it isn't very difficult to patch IS-DOS to fix this bug, but I don't see it as being worthwhile unless someone is patching IS-DOS for other reasons.
Returning to this, now that we have the original source code, the bug is in the source file CLI.MAC, line 854 ...
NOMEM: LD A,.NORAM##
RET
It should be ...
NOMEM: LD E,0 ; Move IS-DOS down to page 0.
CALL MOVIS##
LD A,.NORAM##
RET
-
Coooool :smt041
-
There is a time for version 1.1!
-
There is a time for version 1.1!
I am keen for the EXDOS 3 fix to go in the first new version, I'll do it tomorrow!
-
There is a time for version 1.1!
Hopefully you'll give me the time to add the faster video code into the source files! ;-)
I am currently modifying the IS-DOS source code to build with the SLR Z80ASM assembler, which is about 99% compatible with M80, but runs much, much faster.
The changes are done, and the source builds, but now I just have to figure out a linking issue. FYI, the source still builds fine with M80, the changes really are very minor.
I had to add 2 new fake BDOS function-calls to XCPM to get Z80ASM to work ... do you gentlemen want a patch file for lgb's ReCPM source?
-
Hi elmer,
Here are two slightly modified files...could you incorporate them into your "IS-DOS 1.1" source please? The changes are all within IF EXDOS3...ELSE...ENDIF blocks (with EXDOS3 EQU TRUE at the top) so that it is obvious what I have changed (they are not big changes!) Thanks!
BTW SD Card versions of EXDOS 3 will have ISDOS.SYS in ROM! :roll:
-
Here are two slightly modified files...could you incorporate them into your "IS-DOS 1.1" source please?
Absolutely! :)
BTW SD Card versions of EXDOS 3 will have ISDOS.SYS in ROM! :roll:
That will be cool, there are a few improvements that can be made if IS-DOS is either in ROM, or in a RAM extension.
Having it as a RAM extension is probably best, even on a 128KB Enterprise, so that it can just page in its runnable self-modifying code as needed ... but I do understand that you've got enough spare space in a 32KB EXDOS to store 11KB-or-so of compressed IS-DOS code.
As for the SD Card ... is there enough space in the SD Card ROM for a 32KB EXDOS???
From my quick look at the SD Card ROM files, it *seemed* like there is only about 24KB of space for EXDOS and the SD Card driver code, unless you start using the 32KB that is currently used by the BASIC ROM and a language ROM.
-
As for the SD Card ... is there enough space in the SD Card ROM for a 32KB EXDOS???
It is have a 3x16K at the segment 04-06h.
07h are special segment: it is a ROM and RAM and memory paged I/O. ROM are 8x8K pageable. In the current version with EXDOS 1.4 only the first 8K page used, but the new EXDOS 3 will use more pages, for store ISDOS and others.
-
and others.
Please don't think of any others! :lol: ;-)
-
Aha! At last you have found some utility to the extra FlashRom(512KB) space on the cartridge.
-
It is have a 3x16K at the segment 04-06h.
07h are special segment: it is a ROM and RAM and memory paged I/O. ROM are 8x8K pageable. In the current version with EXDOS 1.4 only the first 8K page used, but the new EXDOS 3 will use more pages, for store ISDOS and others.
Excellent, that is a very nice piece of hardware that SzörG created! :cool:
-
Here is the latest IS-DOS source, buildable with either Z80ASM or M80, both using the L80 linker.
Bruce's EXDOS3 changes are included, but currently disabled so that this corresponds exactly to version 1.0 of IS-DOS.SYS
For anyone that wants to track the differences, here is what I needed to change from the original files that Zozo posted ...
"FCB1" and "FCB2" were defined in both START.MAC and the private EXDOS CLIDATA.MAC. I have renamed the IS-DOS ones, used in START.MAC/CLI.MAC/CMD.MAC.
"ORM" was defined in both CLIV.MAC and the private EXDOS CLIVAR.INC. I have renamed the IS-DOS ones, used in CLIV.MAC/CMD.MAC.
All uses of the M80-specific "CODE" macro, which were used to either define self-modifying code addresses, or define single-byte opcodes used to skip over the next instruction (to avoid branch instructions), have been removed and replaced with code and comments that work on both assemblers.
Most of the uses of "IF1" and "IF2" have been changed, since Z80ASM only needs a single pass to build the source. There are a couple of files left that still use these, but they aren't critical to building a functioning IS-DOS.SYS.
I have included the Z80ASM.COM and SLRLNK1.COM in the archive, both configured (using their CONFIG programs) to default to ".MAC" source files and ".SLR" script files (which avoid the need to rename files to get around CP/M's 128-character line length limit).
There are also 32-bit and 64-bit Windows builds of the modified XCPM that works with Z80ASM, together with a patch file for the changes from the current version of lgb's "ReCPM" project on github.
Enjoy! ;-)
-
Nice work! :smt038
Next to do :oops:
Add a Hungarian and Spanish localized versions as a option to the sources.
Originaly these are made by binary editor.
-
May be we could edit more intelligible texts with more space available.
-
I only miss directory management from ISDOS. Do you have such a plan? Yes I know ... CPM! But MSX-DOS knows ... Sorry for the bad English ...
-
I only miss directory management from ISDOS.
What do you mean exactly? You can use directories under IS-DOS
Pontosan mire gondolsz? Lehet könyvtárakat használni IS-DOS alatt.
-
Használni lehet, de emlékeim szerint nincsenek könyvtár kezelő ISDOS funkció hívások.
De most, hogy ezt mondod elbizonytalanodtam. Megnézem. :oops:
-
I understood now: you talk about IS-DOS function calls (CALL 5)
Értem már, az IS-DOS funkcióhívásokra (CALL 5) gondolsz.
-
May be we could edit more intelligible texts with more space available.
Yes, this is something that can reasonably be done ... as long as they don't all get much longer, and so use up a lot of extra space.
There are only about 320 bytes of usable space left in the current IS-DOS.SYS program file, and in where it actually runs when in memory on the Enterprise.
That really isn't a lot of space to play with, and I need most, or maybe all, of that memory to improve the performance and capabilities of the video driver, which is what I personally feel is the most-important thing to add to an IS-DOS version 1.1, because it directly effects the user-experience of running existing programs like WordStar, VEDIT and Turbo Pascal.
Beyond that, adding some MSX-DOS2 functionality (or CP/M 3, or Z-System) will need a major reorganization of how IS-DOS actually runs when it is in memory, and that is likely to break things and need a lot of work and testing to make it stable.
Please remember, from a programming point-of-view, you can already accomplish nearly all of this extra functionality just by using native EXOS and EXDOS calls within an IS-DOS program, or you can just write a native EXOS application.
-
you can already accomplish nearly all of this extra functionality just by using native EXOS and EXDOS calls within an IS-DOS program, or you can just write a native EXOS application.
And you can make an EXOS/EXDOS program that can be run from IS-DOS or loaded as an EXOS program! https://enterpriseforever.com/programming/com-file-for-is-basic-and-is-dos/ (https://enterpriseforever.com/programming/com-file-for-is-basic-and-is-dos/) :mrgreen:
-
And you can make an EXOS/EXDOS program that can be run from IS-DOS or loaded as an EXOS program! https://enterpriseforever.com/programming/com-file-for-is-basic-and-is-dos/ (https://enterpriseforever.com/programming/com-file-for-is-basic-and-is-dos/) :mrgreen:
Nice trick! :ds_icon_cheesygrin:
-
Yes, this is something that can reasonably be done ... as long as they don't all get much longer, and so use up a lot of extra space.
Not much longer, only 1 or 2 characters could allow to put an article on the sentence that makes better sense. Also, sometimes other sentences are shorter on Spanish/Hungarian than in English, and that space can be put on other text line. But usually English is a more compact language.
Off-topic: In my opinion, English is more compact and schematic, but on the other side, Spanish or Hungarian languages are more accurate on expressing the thoughts.
A good example (https://enterpriseforever.com/sound/zeneprogramozas/msg81464/#msg81464) from Szipucsu today.
-
Ok.... maybe I offended somebody, so I am going to explain me.
From my point of view, English, as a common-world-language, has lost a vast amount of its vocabulary on the colloquial use, while the not so common languages have added a lot of its words while still maintaining their own.
I like English and I understand how it has become a common language, not only because the most powerful country in the world uses it, because some of the best singers of both sides of the Atlantic sea perform using it, or because there are very good writers in English that is worth to read their books.
For me it has some characteristics that could have made it "easier" compared with other languages:
-It makes an intensive use of onomatopoeia. A lot of words are based on how the thing sounds...
-Few verb tenses, except a short list of irregular verbs.
-Fixed sentence constructions and linguistic elements positions.
-Funny phrasal verbs easy to remember, much like the onomatopoeia.
-Limited vocabulary, but as I have said, this probably was different on the past on United Kingdom.
-Preference for short words, of only 1 or 2 syllables instead of 3 or more on other languages.
And probably I could find more... but I don't want to bore you.
-
Ok.... maybe I offended somebody, so I am going to explain me.
Haha ... I don't think that any English speaker would be offended by what you said! :)
For some of us, the imprecision of the English language is one of its charms, and it is the source of a lot of British humour. ;-)
-
Here is the final set of changes to the IS-DOS 1.0 source to convert it to fully build with Z80ASM and SLRNK1.
The advantages of Z80ASM and SLRNK1 are ...
1) It is much faster than M80/L80.
2) There is no need to output the .REL files with different names to the .MAC files.
3) Labels are significant to 16 characters (rather than 6 in L80), allowing them to be more readable.
4) SLRNK1 can link to Page3 ($C000-$FFFF) without leaving Page3 unused in CP/M. This means that IS-DOS can now be built on an actual Enterprise!
5) SLRNK1 does not put a relocation header onto the output file, meaning that the output that it writes is directly usable as IS-DOS.SYS (i.e. there is no need to use SJASM to strip junk off the start of IS-DOS).
The only significant changes from the source code that I posted a few days ago, was to fix labels that were actually wrong, but worked OK with M80/L80 because the first 6 characters were correct.
I have included new builds of XCPM that use the full 64KB of Z80 memory, to take advantage of SLRNK1 not needing to leave $C000-$FFFF free for the linked program.
-
As I keep working on the IS-DOS source code, I have just come across this.
It looks like the flags that are sent to the EXOS RESET function are wrong, at least according to the documentation that I have seen.
Is it a bug?
Another thing ... why is the SP saved and loaded before and after the EXOS RESET? The documentation does not mention that the EXOS RESET changes the SP ... is the documentation wrong?
;******************************************************************************
OPENALL::
;
; This routine attempts to ensure that IS-DOS's keyboard, video and editor
; channels are open. It does this by first trying to open them, and ignoring
; 'channel exists' errors. If some other error occurs, then the editor, video
; and keyboard channels are closed, and an attempt is made to re-open them. If
; this fails, then all channels up to the first one used by IS-DOS batch files
; are closed, and the open again attempted. If this fails, then another open
; attempt is made with the video in 40 column mode. If this still fails, then
; as a last resort an EXOS reset is done, closing all channels (including
; batch file channels). If it is still impossible to open the channels, then
; IS-DOS gives up and prints 'FATAL IS-DOS ERROR' on the status line and, in
; the traditional Enterprise 'I've given up' way, flashes the border.
;
;
CALL OPEN ; Make sure kbd, editor & vid are open.
RET Z ; Ret if OK.
CALL CLOPEN ; Else close all three and try again.
RET Z ; Ret if OK.
LD H,0 ; Else close all user channels.
CLCHAN: LD A,H
RST EXOS
DEFB @CLOSE##
INC H
LD A,H
CP ISCHAN## ; Reached first IS-DOS channel ?
JR NZ,CLCHAN ; Close next if not.
CALL CLOPEN ; Attempt to open again.
RET Z ; Ret if OK now.
PUSH AF ; Else save error code.
XOR A
LD (VIDMOD),A ; Else try in 40 column mode.
CALL CLOPEN
POP BC
LD A,B
RET Z ; Ret if OK with 80 col. error code.
EXX ; Else reset EXOS.
PUSH HL ; Save HL'.
LD (CLI_SP##),SP ; Save SP.
LD C,0001000B ; Forcibly close all channels. <<<--- BUG ???
RST EXOS
DEFB @RESET##
LD SP,(CLI_SP##) ; Restore SP.
EI
POP HL
EXX
CALL OPEN ; Try openning one more time.
RET Z ; Ret if OK, else give up.
;
FATALIS:: CALL TST_LANG##
LD DE,FATALM ; Else print 'FATAL IS_DOS ERROR' on
JR Z,FIS10 ; status line & flash border.
LD DE,GFATALM ; German.
FIS10: CALL STLINE
;
FLASH: DI
LD A,01001001B
LD B,3
FL10: OUT (BORDER),A
ADD A,A
DJNZ FL10
JR FLASH
-
Yes I think you're right... it's a binary number with leading 0s, but only 7 digitts! :oops: I think it is meant to be 10h, which resets the channels and devices. Having said that it seems unlikely that that piece of code has ever been executed, as it is only a final attempt at doing *something* if it is unable to open its normal channels.
And yes I think you need to reset SP after an EXOS reset. It is because EXOS switches to its own internal stack when you do an EXOS call (because... paging) but to allow re-entrant calls it keeps a re-entrancy count and only switches back to the user's stack when returning from the initial call. But the reset function has to reset the re-entrancy count.
I'm sure it says it somewhere, but I agree it is not in the obvious place in the kernel spec and I can't find it now!
-
Yes I think you're right... it's a binary number with leading 0s, but only 7 digitts! :oops: I think it is meant to be 10h, which resets the channels and devices. Having said that it seems unlikely that that piece of code has ever been executed, as it is only a final attempt at doing *something* if it is unable to open its normal channels.
OK, thanks, I'll change it to 10h, which sounds like the right value.
I think that I have managed to get very *close* to triggering that piece of code while testing the latest IS-DOS changes on a 64KB Enterprise in EP128EMU.
Allocating a dedicated segment for IS-DOS means that there isn't enough memory left on an EP64 for an 80-column text screen, and that fallback code seems to be activating and switching to a 40-column text screen. It is nice to know that you professionals at IS were programming so defensively! ;-)
I'm sure it says it somewhere, but I agree it is not in the obvious place in the kernel spec and I can't find it now!
Thanks for the information, I'll be careful to remember that for the future. :)