Some updates to John Elliott's ZXCC

[Tony Nicholson]

For many years I've been using John Elliott's ZXCC - the CP/M
2/3 emulator for crosscompiling and running CP/M tools under
MS-DOS and Linux/Unix/macOS.

I've just found and fixed what I think are a couple of issues
with ZXCC when using my updated version of the HI-TECH
Z80 C compiler v3.09 (the latest version v3.09-9 is available
from https://github.com/agn453/HI-TECH-Z80-C ).

The fixes involve -

* Returning the correct error response for a BDOS Call RSX
(function 60) - for "non-existent RSX',
* Updating the processing of command-line options for zxc
that accept a filename or directory name, and
* Fixing the BDOS Read Console Buffer (function 10) so that
it accepts command buffers with a length >127 characters.

I've loaded ZXCC 0.5.7 from John's distribution site onto
GitHub and merged my changes. You can get them at

https://github.com/agn453/ZXCC

If anyone reading this has found (and fixed) any other issues
with ZXCC - I'd appreciate you raising them on GitHub or
replying to this thread.

Thanks.

Tony

[fridtjof.ma...@gmail.com]

Tony

From my am9511 -- see howto.txt

"Please note that there is an error in Zxcc -- in edops.h opcodes
0xed 0x70 and 0xed 0x71 are wrong: replace with

instr(0x70,8);
{unsigned char x;input(x);
store(hl,x);
}
endinstr;

instr(0x71,8);
{unsigned char x=fetch(hl);
tstates+=out(tstates,b,c,x);
}
endinstr;

Note that this has NO effect on running zxc, etc. Just using Zxcc
as an emulator driving i/o devices like am9511."

This has no effect on Zxcc usually... just if trying to do i/o (adding to the emulator).
Ran across this when integrating am9511 into Zxcc.

FredW

[Tony Nicholson]

On Friday, August 20, 2021 at 3:34:18 PM UTC+10, FredW wrote:

[snip]

> From my am9511 -- see howto.txt
>
> "Please note that there is an error in Zxcc -- in edops.h opcodes
> 0xed 0x70 and 0xed 0x71 are wrong: replace with
>
> instr(0x70,8);
> {unsigned char x;input(x);
> store(hl,x);
> }
> endinstr;
>
> instr(0x71,8);
> {unsigned char x=fetch(hl);
> tstates+=out(tstates,b,c,x);
> }
> endinstr;
>
> Note that this has NO effect on running zxc, etc. Just using Zxcc
> as an emulator driving i/o devices like am9511."
>
> This has no effect on Zxcc usually... just if trying to do i/o (adding to the emulator).
> Ran across this when integrating am9511 into Zxcc.
>
> FredW

Thanks Fred.

I have added this fix to my ZXCC GitHub repository (with credit to you and a
pointer to your am9511 files).

Tony

[Russell Marks]

Tony Nicholson <agn...@gmail.com> wrote:

> For many years I've been using John Elliott's ZXCC - the CP/M
> 2/3 emulator for crosscompiling and running CP/M tools under
> MS-DOS and Linux/Unix/macOS.
>
> I've just found and fixed what I think are a couple of issues

It might be worth letting John know about this if you haven't yet, I
see there are recent updates on his JOYCE page for example.

> If anyone reading this has found (and fixed) any other issues
> with ZXCC - I'd appreciate you raising them on GitHub or
> replying to this thread.

One thing I remember noticing is that DAA isn't quite right (this also
affects some emulators I released years ago, which used essentially
the same Z80 emulation). The fix I did was a bit crude, just porting
DAA from yaze instead. :-)

One way to see the difference this makes is running "zexdoc", also
from yaze (or yaze-ag). I think it'll still fail "zexall" though.

------------------------------ cut here ------------------------------
--- zxcc-0.5.7/bin/z80ops.h 2001-07-15 23:15:09.000000000 +0100
+++ zxcc-0.5.7-daa-fix/bin/z80ops.h 2021-08-21 23:12:30.330014108 +0100
@@ -317,15 +317,43 @@

instr(39,4);
{
- unsigned char incr=0, carry=cy;
- if((f&0x10) || (a&0x0f)>9) incr=6;
- if((f&1) || (a>>4)>9) incr|=0x60;
- if(f&2)suba(incr,0);
- else {
- if(a>0x90 && (a&15)>9)incr|=0x60;
- adda(incr,0);
- }
- f=((f|carry)&0xfb)|parity(a);
+ /* Frank D. Cringle's DAA implementation, converted from yaze 1.10 */
+ unsigned int acu,temp,cbits;
+
+ acu=a;
+ temp=(acu&15);
+ cbits=(f&1);
+ if(f&2) /* if N */
+ {
+ /* last operation was a subtract */
+ int hd=(cbits || (acu>0x99));
+ if((f&16) || (temp>9))
+ { /* adjust low digit */
+ if(temp>5) f&=~16;
+ acu-=6;
+ acu&=0xff;
+ }
+ /* adjust high digit */
+ if(hd)
+ acu-=0x160;
+ }
+ else
+ {
+ /* last operation was an add */
+ if((f&16) || (temp>9))
+ {
+ /* adjust low digit */
+ if(temp>9) f|=16; else f&=~16;
+ acu+=6;
+ }
+ /* adjust high digit */
+ if(cbits || ((acu&0x1f0)>0x90))
+ acu+=0x60;
+ }
+ cbits|=((acu>>8)&1);
+ acu&=0xff;
+ a=acu;
+ f=((acu&0xa8)|((acu==0)<<6)|(f&0x12)|parity(a)|cbits);
}
endinstr;

------------------------------ cut here ------------------------------

-Rus.

[Udo Munk]

Russell Marks schrieb am Sonntag, 22. August 2021 um 01:00:42 UTC+2:
> One thing I remember noticing is that DAA isn't quite right (this also
> affects some emulators I released years ago, which used essentially
> the same Z80 emulation). The fix I did was a bit crude, just porting
> DAA from yaze instead. :-)

This is because almost all documentation about DAA is wrong, Zilog, Mostek, Zaks book ...
If I remember right Zilog corrected it in their latest Z80 users guide though.
In the z80pack sources I left my old version implemented according to the books, active
is a working one that was figured out by Mark Garlanger. Source is more readable then
what I have seen elsewhere, so you might have a look and shows the problem with the
wrong documentation.

[Russell Marks]

I did look at a few implementations and descriptions of DAA - the yaze
and z80pack implementations are pretty similar, but personally I found
the yaze one slightly easier to follow.

-Rus.

[Tony Nicholson]

Rus,

On Sunday, August 22, 2021 at 9:00:42 AM UTC+10, Russell Marks wrote:

> It might be worth letting John know about this if you haven't yet, I
> see there are recent updates on his JOYCE page for example.

Thanks - I hadn't thought to look into John's JOYCE code. He's been
known to lurk here (like I have for the past 30+ years). I'll forward
details to him soon.

> One thing I remember noticing is that DAA isn't quite right (this also
> affects some emulators I released years ago, which used essentially
> the same Z80 emulation). The fix I did was a bit crude, just porting
> DAA from yaze instead. :-)
>
> One way to see the difference this makes is running "zexdoc", also
> from yaze (or yaze-ag). I think it'll still fail "zexall" though.

Indeed, running 'zxcc zexdoc' flags an error with the <daa,cpl,scf,ccf>
instruction group - confirming this. Thanks for the patch.

Running zexall throws many errors.

Tony

[Tony Nicholson]

Thanks to Mark Ogden and Michal Tomek, there's been further updates
to ZXCC - the CP/M cross-compiling emulator.

The latest update now compiles under Microsoft Windows (as a set of
command-line utilities built using both Visual Studio and under Cygwin)
as well as the previous macOS/Linux support.

Get it from

https://github.com/agn453/ZXCC

This release also fixes a long-standing "exact file size" emulation to
match the (undocumented) way this is handled by CP/M 3 and MP/M
using the same conventions that the updated HI-TECH C compiler does.

Have a Happy New Year / Hogmanay

Tony

[John Elliott]

On Thursday, December 30, 2021 at 11:07:22 PM UTC, Tony Nicholson wrote:
> This release also fixes a long-standing "exact file size" emulation to
> match the (undocumented) way this is handled by CP/M 3 and MP/M
> using the same conventions that the updated HI-TECH C compiler does.

Can't say I approve of the choice made there - when I wrote zxcc (and all my CP/M software), the convention I used was the same one that Digital Research used in DOS Plus, so I think it's as 'official' as it would get. I'm aware that ISX used the opposite convention, but I'd prefer to keep round-trip compatibility with DOS Plus over ISX.

(And yes, I'm aware that PIPEMGR has been similarly mangled. I know the licence allows it - doesn't mean I have to like it.)


--
John Elliott

[ogd...@gmail.com]

John
When I made the changes to zxcc, I did note that there were two different approaches used for exact file size. The one you implemented did not align with the modifications done to the Hi-Tech C library as such files were being corrupted. As I didn't find any specific information in the CP/M 80 re exact size, although I admit I didn't consider 8086 versions, I modified to align with Hi-Tech C, the alternative of modifying the Hi-Tech library is certainly possible, as is the option to have a command line switch to use either.
Mark

[John Elliott]

On Wednesday, March 2, 2022 at 10:04:23 AM UTC, ogd...@gmail.com wrote:
> John
> When I made the changes to zxcc, I did note that there were two different approaches used for exact file size. The one you implemented did not align with the modifications done to the Hi-Tech C library as such files were being corrupted. As I didn't find any specific information in the CP/M 80 re exact size, although I admit I didn't consider 8086 versions, I modified to align with Hi-Tech C, the alternative of modifying the Hi-Tech library is certainly possible, as is the option to have a command line switch to use either.
> Mark

I did write up what was known about which programs used what conventions at <http://www.seasip.info/Cpm/bytelen.html>, though I clearly need to revise it to give greater prominence to DOS Plus being a genuine DRI product.

--
John Elliott

[John Elliott]

If it did become necessary for 8-bit CP/M software to support both conventions, then rather than command-line switches or configuration files I'd suggest holding the setting in the SCB (byte A9h isn't currently used) and adding an extra option to SETDEF: SETDEF [FILESIZE=ISX] or SETDEF [FILESIZE=DOSPLUS]. I hope that won't be required, though.

[Tony Nicholson]

On Wednesday, March 2, 2022 at 11:07:39 PM UTC+11, John Elliott wrote:
> If it did become necessary for 8-bit CP/M software to support both conventions, then rather than command-line switches or configuration files I'd suggest holding the setting in the SCB (byte A9h isn't currently used) and adding an extra option to SETDEF: SETDEF [FILESIZE=ISX] or SETDEF [FILESIZE=DOSPLUS]. I hope that won't be required, though.

I've updated both the ZXCC and HI-TECH-Z80-C repositories on GitHub
to return to the DOS Plus convention for exact file size - based on updates
supplied by Mark Ogden.

You'll find them at

https://github.com/agn453/ZXCC

and

https://github.com/agn453/HI-TECH-Z80-C

The HI-TECH Z80 C v3.09-13 version retains support for the "Jon Saxton"
ISX/ISIS mode via an EXACT system environment variable. Select the
mode by adding a line to the ENVIRON file (that is usually located on drive
A: in user 0).

The C library close() routine examines the value of EXACT to adjust the last
sector byte count convention. It does this only when you are running CP/M 3,
DOS Plus or MP/M.

The value of the EXACT environment variable determines whether to use
DOSPLUS or ISX mode. Only the first letter is tested, and if the value is not
set, then the run-time routines assume CP/M 2.2 mode (relying on a Ctrl-Z
end-of file marker in text files).

My ENVIRON file has (for example)

TMP=M:
HITECH=0:A:
EXACT=DOSPLUS

to direct temporary compiler files to my ram drive, the compiler files are on
drive A; in user 0 (with the SYS attribute set) and to use the DOS Plus
convention for exact file sizes under CP/M 3.

I've also updated the PIPEMGR RSX sources (included on the HI-TECH Z80
C repository) to use DOS Plus exact file mode by default. Change the
"exact" definition in the assembler source and rebuild to get a version that
uses ISX/ISIS mode. Remember to re-attach the new PIPEMGR.RSX to
programs that use it with GENCOM after you upgrade HI-TECH C.

Tony