use of ZMAC.COM to build CPM3 system (CPM3_2063_Retro)?

[Richard Deane]

I am trying to build a cpm3 system for john winan's 2062_retro board.

"Soldergirl" has published CPM3_2063_Retro on gitlab and I am having
trouble using zmac on romwbw cpm3 on sc131 (z180) and Dean
Netherton's RC-EZ80. Also tried on Joyce Amstrad PCW emulator

I use CPM3 because it's my preferred system, and because MAKE.COM needs it.

Just simplifying down to

K>ZMAC ldrbios
K:ZMAC COM

ZMAC Relocating Macro Assembler v 1.7, 04/09/93
Copyright 1988,1989 by A.E. Hawley

gives this error or a hang

+++ BAD INT @0547[1000:0040:0500:0540:FEF4:0EE9:1EFD]

Any suggestions?
The same error occurs under zsdos (cp/m 2 clone)
Has anyone had success with zmac?
Are any other assemblers able to handle the syntax of zmac?
=============================
Notes from my experience with this gitlab download
1) The R and W commands from SIMH/AltairZ80 are OS specific due to the
embedded / (Linux) or \ (windows) in directory paths. This gitlab
repository is setup for use with Altairz80 under Windows.
2) The mix of upper and lower case file names is confusing and
simpler with converting all to uppercase.
3) Be cautious of text file endings which seem to be for Linux. I'm
sure there must be a way to download / gitclone with CP/M CRLF line
endings.

cheers
Richard

[Wayne Hortensius]

Hmm. It worked for me under ZSDOS. I copy and pasted the source into vi
on a Linux box, set ff=dos, saved it, moved over to the CP/M machine,
ZMP'd it down there and assembled it.

A2:SOURCE>>zmac ldrbios

ZMAC Relocating Macro Assembler v 1.7, 04/09/93
Copyright 1988,1989 by A.E. Hawley

A2:SOURCE>>

Regards,
Wayne

[Wayne Warthen]

Hi Richard,

I do have problems running ZMAC in some scenarios.  ZMAC seems to want to run with a ZCPR environment.  If I run ZMAC under ZPM3 or NZCOM, it works well.  Otherwise, it destabilizes my system as though it has corrupted OS memory.  I have never taken the time to track down the specifics of this.

Thanks, Wayne

[Richard Deane]

Thanks, I will try with ZPM3. Gives me heart that it can work.
Cheers
Richard

> --
> You received this message because you are subscribed to the Google Groups "retro-comp" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/retro-comp/07c29fa8-441a-4923-9f92-5449d64856c2n%40googlegroups.com.

[Richard Deane]

Thanks,
ZPM3 worked for me.

> --
> You received this message because you are subscribed to the Google Groups "retro-comp" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/retro-comp/20251116140108.3ecde87c%40mars.

[Wayne Warthen]

Glad to hear that worked for you Richard.

Your experience peaked my interest and I spent a little while tracking down the source of this issue.

An explanation follows, but ultimately the solution is to ensure that the bytes at ZMAC.COM file offset 0x09 and 0x0A are both value 0x00.  I expect you will find that they are 0x00 and 0xFE respectively.  Patching these two bytes to be 0x00 should enable ZMAC to work properly on any CP/M-like OS, not just ZCPR variants.

All ZCPR compatible executables have a header.  The header identifies the executable as being ZCPR compatible.  Part of the header (at offset 0x09-0x0A) is a word pointer to the ZCPR environment block.  This pointer is dynamically updated by ZCPR when it loads programs.  The file itself is supposed to have 0x0000 at offset 0x09 indicating that the pointer is not initially valid.  ZCPR executable files can be modified to set this pointer on the disk copy of such files.  This is required for older versions of ZCPR.  However, the pointer will only be correct for specific installations of ZCPR.

It appears that Al Hawley inadvertently left the pointer value set to 0xFE00 in the distributed copy of ZMAC.COM.  No doubt this was correct for his ZCPR installation. So, if this copy of ZMAC is loaded under ZCPR, it will work fine because ZCPR will dynamically "fix" the value.  However, if ZMAC is run on non-ZCPR OSes, it will see the pointer, assume it is pointing to a valid ZCPR environment block, and use it.  Ultimately, this results in the program writing data to completely arbitrary locations and therefore corrupting memory.  The location(s) of memory being corrupted will depend on the specific OS and installation.  So, there are cases where it runs on a non-ZCPR system, but this is just pure luck.

ZCPR headers should always have this pointer set to 0x0000 when distributed.  The value in the ZMAC.COM file is definitely incorrect.  In my experience, patching the pointer value (on the disk file) to be 0x0000 fully resolves the issues reported.

Thanks, Wayne

[Richard Deane]

Thank you, that was very helpful and educational.
richard

> To view this discussion visit https://groups.google.com/d/msgid/retro-comp/e2029333-3f1d-4859-9785-7ff491ae58d8n%40googlegroups.com.