For many years I've been using John Elliott's ZXCC - the CP/MTony
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
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
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
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. :-)
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.
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.
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.
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.
On Thursday, December 30, 2021 at 11:07:22 PM UTC, Tony Nicholson wrote:opposite convention, but I'd prefer to keep round-trip compatibility with DOS Plus over ISX.
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/MCan'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
using the same conventions that the updated HI-TECH C compiler does.
(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
John Elliott
Johnfind 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
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
Mark
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 toSETDEF: SETDEF [FILESIZE=ISX] or SETDEF [FILESIZE=DOSPLUS]. I hope that won't be required, though.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 292 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 206:25:16 |
| Calls: | 6,618 |
| Calls today: | 2 |
| Files: | 12,168 |
| Messages: | 5,316,890 |