I started with a cpm 2.2 target for the new clib tonight and compiled startrek.c for it:
https://drive.google.com/open?id=0B6XhJ ... TN1Z3VZMlk
I implemented console_01 terminals using direct console i/o which means the library is calling cpm for one char at a time and is taking care of line editing. This way you get all the z88dk features like password mode and whatnot. I did run into a couple of things. One thing I wasn't surprised about is that a backspace has to involve backspace, print space and backspace again to actually erase the last char of an edit line. The other thing I was surprised about is that under emulation it seems that cpm is supplying a cursor for direct console input. This bdos function returns immediately and indicates whether a keypress was available or not so I did not expect a cursor to be printed. I'm wondering if this is an artifact of emulation -- I am using "runcpm" which allows cpm emulation to occur in a command console and cpm drives are mapped to windows directories. So I am thinking it's using windows' read console function and that is supplying the cursor. Does anyone know!
for
sure if cpm does generate this cursor for direct console i/o? I've removed the software cursor from the driver for now but I think it will have to go back in.
I elected to treat CTRL-Z as EOF on the input terminal and I specifically added an interrupt-line-editing feature to the console drivers so that cpm users can enter CTRL-C and have the edit operation immediately terminate. But I am leaving it up to the program to read this CTRL-C and do something about it; ie I am not causing a program exit. Maybe it should be a compile time option to choose whether CTRL-C causes immediate exit?
The output console is currently not windowed, but the next step is easy to add a windowed console. I'm just not sure what sort of terminals were standard in the cpm world, maybe vt52 and vt100? I just need a means to set cursor position before printing.
I also plan to do a lightweight console driver using the standard read console functions in cpm. It will give applications the standard cpm console interface.
Tomorrow I will also look at adding stdpun, stdlst, etc, following bds C's lead with supplying analogues to stdin, stdout, stderr for cpm's standard streams.
------------------------------------------------------------------------------
[z88dk-dev] cpm target for new clib
I settled on a few things:
* ctrl-c will cause immediate program termination (via exit()) as this is expected cpm behaviour
* I put the software cursor back in; I don't think it makes any sense that cpm on a real machine would supply a cursor when using direct console io
* cpm keyboards have a capslock key that is used internally by bdos and is not accessible from the program. Despite that I enabled a software capslock (ctrl-f) that affects the z88dk terminal code (not cpm bdos); this is because an ictrl() can be used to set the caps lock bit in the terminal so there should be a way for the user to disable it at the keyboard.
I added an 8080 check at startup but I left out the msdos one. I think the 8080 check is quite important but less so the msdos?
I've also now included command line parsing. I was looking at what we have now but I decided that because the command line is in a temporary buffer under cpm and the program should have access to argc, argv during the entire program execution, that the command line should be parsed and the words stored someplace else. That place being the stack
The parser is generic so it can be used with any target:
http://z88dk.cvs.sourceforge.net/viewvc ... iew=markup
What it does is limit the command line to 128 chars (that makes sure stack usage is not totally unreasonable) and then copy words to the stack as they are found. Parsing also stops when a file io redirector is found (ie '>' or '<') as in the current implementation. It does not do file io redirection, however, it only sets up so pointers and returns to the caller so that it can decide what to do. I'm thinking, aside from stdin/stdout redirection, we can do other streams as well with ">2" (stderr) and the like. After pushing found words onto the stack, it pushes argc and argv in the correct order for sdcc or sccz80.
The current cpm crt with 8080 check and command line parsing:
http://z88dk.cvs.sourceforge.net/viewvc ... iew=markup
Of course file io on the new clib is not ready yet so there is no file io for cpm on the new clib except by direct bdos calls.
The output of a compile is "name_CODE.bin"; the name is unavoidable due to how sections are handled by z80asm and the output file should be renamed "name.com" before consumption by cpm. I'll probably look at -create-app and have it use this other name if the normal one is not found so that a compile with -create-app will generate the com for you.
I'm still looking at introducing stdpun, stdlst, etc for cpm's other standard streams, as well as introducing windowed terminals and a lightweight cpm driver (we must put ourselves on equal footing with the likes of hitech and bdsc before I run the benchmarks. I also gave a quick glance to standard cpm graphics but it seems you don't get access to a bitmap at all and all interfacing is by draw commands. That means standard cpm probably cannot get our graphics, games and proportional font engines.
------------------------------------------------------------------------------
* ctrl-c will cause immediate program termination (via exit()) as this is expected cpm behaviour
* I put the software cursor back in; I don't think it makes any sense that cpm on a real machine would supply a cursor when using direct console io
* cpm keyboards have a capslock key that is used internally by bdos and is not accessible from the program. Despite that I enabled a software capslock (ctrl-f) that affects the z88dk terminal code (not cpm bdos); this is because an ictrl() can be used to set the caps lock bit in the terminal so there should be a way for the user to disable it at the keyboard.
I added an 8080 check at startup but I left out the msdos one. I think the 8080 check is quite important but less so the msdos?
I've also now included command line parsing. I was looking at what we have now but I decided that because the command line is in a temporary buffer under cpm and the program should have access to argc, argv during the entire program execution, that the command line should be parsed and the words stored someplace else. That place being the stack
The parser is generic so it can be used with any target:
http://z88dk.cvs.sourceforge.net/viewvc ... iew=markup
What it does is limit the command line to 128 chars (that makes sure stack usage is not totally unreasonable) and then copy words to the stack as they are found. Parsing also stops when a file io redirector is found (ie '>' or '<') as in the current implementation. It does not do file io redirection, however, it only sets up so pointers and returns to the caller so that it can decide what to do. I'm thinking, aside from stdin/stdout redirection, we can do other streams as well with ">2" (stderr) and the like. After pushing found words onto the stack, it pushes argc and argv in the correct order for sdcc or sccz80.
The current cpm crt with 8080 check and command line parsing:
http://z88dk.cvs.sourceforge.net/viewvc ... iew=markup
Of course file io on the new clib is not ready yet so there is no file io for cpm on the new clib except by direct bdos calls.
The output of a compile is "name_CODE.bin"; the name is unavoidable due to how sections are handled by z80asm and the output file should be renamed "name.com" before consumption by cpm. I'll probably look at -create-app and have it use this other name if the normal one is not found so that a compile with -create-app will generate the com for you.
I'm still looking at introducing stdpun, stdlst, etc for cpm's other standard streams, as well as introducing windowed terminals and a lightweight cpm driver (we must put ourselves on equal footing with the likes of hitech and bdsc before I run the benchmarks
. I also gave a quick glance to standard cpm graphics but it seems you don't get access to a bitmap at all and all interfacing is by draw commands. That means standard cpm probably cannot get our graphics, games and proportional font engines.------------------------------------------------------------------------------
Ah forgot, link to simple test program:
https://drive.google.com/file/d/0B6XhJJ ... sp=sharing
------------------------------------------------------------------------------
https://drive.google.com/file/d/0B6XhJJ ... sp=sharing
------------------------------------------------------------------------------
It is fantastic news !!
I already extended the +newext option in appmake to optionally recognise other extension delimiters than '.', it will be online soon.
You could use it to rip off everything after the underscore.
I don't think there was a standard terminal with CP/M, the VT100 was widely used but was not the most popular.. it was the applications adapting to the ESC sequences.
I'm not sure about the cursor problems you told about, but it could be some original HW showed it.
------------------------------------------------------------------------------
I already extended the +newext option in appmake to optionally recognise other extension delimiters than '.', it will be online soon.
You could use it to rip off everything after the underscore.
I don't think there was a standard terminal with CP/M, the VT100 was widely used but was not the most popular.. it was the applications adapting to the ESC sequences.
I'm not sure about the cursor problems you told about, but it could be some original HW showed it.
------------------------------------------------------------------------------
I did a quick research, historically most of the software was written for one or more of the following terminals:I don't think there was a standard terminal with CP/M, the VT100 was widely used but was not the most popular..
ADM3, VT52, H19
VT100 was supported sometimes and it is for a good portion a superset of the VT52, many OEM drivers emulated one of the three modes above.
Other common terminals were the Wyse and Televideo ones.
------------------------------------------------------------------------------
I tried your test program and compared it to a classic z88dk compile.
The resulting program was about 1K bigger (but it got more than 2K smaller than yours with the #pragma exclusions) and gave different results: i think the first argument should be the invoked program name.. in the classic version I chose to leave it blank.
Also I don't fully understand why you decided to copy the command line buffer: being in the first 256 bytes, could it really change during the program execution ?
------------------------------------------------------------------------------
The resulting program was about 1K bigger (but it got more than 2K smaller than yours with the #pragma exclusions) and gave different results: i think the first argument should be the invoked program name.. in the classic version I chose to leave it blank.
Also I don't fully understand why you decided to copy the command line buffer: being in the first 256 bytes, could it really change during the program execution ?
------------------------------------------------------------------------------