agn453 / hi-tech-z80-c Goto Github PK

Something like:

#ifndef _HITECH_H
#define _HITECH_H
#endif

I'm linking a Z80 as file in to my program and get the error above.

global  _vicInt

save_sp:

defw    0

stack:

defs    32

stack_end:                     ; End of stack

psect   data



psect   text

_vicInt:
        ld      (save_sp),sp    ; Save SP
        ld      sp,stack_end
        push    af
        push    bc
        ld      bc,0dc0dh
        ld      a,0
        out     (c),a           ; Clear CIA 1 ICR status        
        ld      bc,0d020h       ; VIC border color
        in      a,(c)           ; Get current color              
        inc     a
        out     (c),a           ; Set new color
	pop     bc
	pop     af
	done:
	ld      sp,(save_sp)    ; Restore SP
        ei
        ret

on zcrtcpm.as:
bvmes: defm 'This program requires a Z80 processor.'

on zrrtcpm.as:
bvmes: defm 'This program requires a CP/M on Z80.'

I would recommend the latter personally.

When compiling with build 13, something seems to be wrong in LIBC.LIB when using the -n switch, see below session from CP/M 2.2 system. If I copy LIBC.LIB from build 12, it works without errors. If I remove the -n switch it also works.
The test program is a very simple hello world file.

#include <stdio.h>

void main(void) {
  printf("Hello...");
}

D>c -v -o -n hello.c
Hi-Tech Z80 C Compiler (CP/M-80) V3.09-13
Copyright (C) 1984-87 HI-TECH SOFTWARE
Updated from https://github.com/agn453/HI-TECH-Z80-C
0:CPP -DCPM -DHI_TECH_C -Dz80 -I HELLO.C $CTMP1.$$$
0:P1 $CTMP1.$$$ $CTMP2.$$$ $CTMP3.$$$
0:CGEN $CTMP2.$$$ $CTMP1.$$$
0:OPTIM $CTMP1.$$$ $CTMP2.$$$
0:ZAS -J -N -OHELLO.OBJ $CTMP2.$$$
ERA $CTMP1.$$$
ERA $CTMP2.$$$
ERA $CTMP3.$$$
ERA $CTMP5.$$$
0:LINQ -Z -Ptext=0,data,bss -C100H -OHELLO.COM NRTCPM.OBJ HELLO.OBJ LIBC.LIB
undefined symbols:
_open
_fseek
_creat
__filbuf
ERA $$EXEC.$$$

There seems to be a problem with either initializing or printing (printf) strings that are longer than 255 characters. The example code below initializes a string with 256 characters. When printing the string using printf(), only the first three characters are being displayed and the rest of the string is being omitted.

If you shorten the sting by exactly one (1) character to match 255 characters, the string is being displayed correctly.

I don't know wether this a problem with the array initializer or with the printf function. But it is reproducible and also affects arrays of strings (e.g. char *text[]; ).

My setup is a RC2014 running RomWBW and CP/M 3. The issue is also showing up on CP/M 2.2.

Example code:

#include <stdio.h>

/* initialize 256 bytes of text */
char test[500] = { 
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX \
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY"
};

int main() {
   printf("len: %d\n", strlen(test));
   printf("string: %s\n", test);
   return 0;
}

Using the following test program I'm unable to pass struct by value or reference. In this case the function pointers are inside a struct. I always get the same error "struct/union member expected". This should work with C89. Function pointers work fine outside of struct.

Note, if I use mathFuncs.addFunc without arguments from typedef it compiles.

#include "hitech.h"
#include "stdlib.h"
#include "stdio.h"

/* Declare a function pointer type for functions that take two integers and return an integer */
typedef int (*MathFunctionPtr)(int, int);

/* Define some simple math functions that take two integers and return an integer */
int add(int a, int b) {
    return a + b;
}

int subtract(int a, int b) {
    return a - b;
}

int multiply(int a, int b) {
    return a * b;
}

/* Define a struct that contains function pointers to three different math functions */
struct MathFunctions {
    MathFunctionPtr addFunc;
    MathFunctionPtr subtractFunc;
    MathFunctionPtr multiplyFunc;
};

int main() {
    int a = 10, b = 5;
    struct MathFunctions mathFuncs; /* Declare a struct variable */

    /* Initialize the struct's function pointers */
    mathFuncs.addFunc = add;
    mathFuncs.subtractFunc = subtract;
    mathFuncs.multiplyFunc = multiply;

    /* Call the add function through the struct's function pointer */
    printf("%d + %d = %d\n", a, b, mathFuncs.addFunc(a, b));

    /* Call the subtract function through the struct's function pointer */
    printf("%d - %d = %d\n", a, b, mathFuncs.subtractFunc(a, b));

    /* Call the multiply function through the struct's function pointer */
    printf("%d * %d = %d\n", a, b, mathFuncs.multiplyFunc(a, b));

    return 0;
}

Validating the v3.09-3 release by compiling the zmodem program ZMP produces a linker error

0:A:LINQ <$CTMP4.$$$
0:A:LIBC.LIB: stdclean.obj: 11: multiply defined symbol: __cleanup
undefined symbols:
__exit
__pnum
_isatty
_strchr
_fcbinit
_stindex

Module ordering in LIBC.LIB is not yet correct.

Hi,

I presume the \dist directory is what is required to be transferred to CP/M, in which case I encountered this issue.

Regards Phil.

The overlay header file references a non-existent stdint.h (what I thought was a C++ header).

I have Ron Murray's original HTC-OVR distribution and this doesn't include this file or reference.

@tsupplis Is there a stdint.h for HI-TECH C somewhere?

When the final com file is generated with c -o -x hello.c libtest.lib are all functions in the obj (inside the library) included in the com or just functions that you use in hello.c?

Just flagging an issue with the ordering of object module dependencies in LIBC.LIB (and LIB280C.LIB). Linking a program is creating an executable that includes unreferenced functions - and therefore the .com file is larger than it needs to be.

https://www.thebyteattic.com/p/agon.html

Hi Tony, I've just posted some benchmarks with the MSDOS version of v7.80.

As the compiler was lent to me, and we don't know whether it is in public domain, I won't publish the code (yet).
I tried to reach the Hi-Tech contacts in the manual, including phone and web, but they're all dead ends.

Did you know someone at Hi-Tech who could provide guidance on the release state of the final Hi-Tech C MSDOS v7.80pl2 professional development system?

I've been able to reproduce a problem reported to me by e-mail.

It concerns the failure of the TESTBIOS.C program when run under the Digital Research CP/M-3 banked BDOS.
TESTBIOS does not fail when using Simeon Cran's replacement ZPM3 BDOS.

The TESTBIOS program uses the library bios() routine to invoke the XMOVE and MOVE routines in the BIOS to copy a string. It has the following sequence -

    bios(29,0x0101);
    bios(25,sizeof src, src, dst);
    puts(dst);

I added some debugging messages into the BIOS XMOVE and MOVE routines. This reveals that the DRI BDOS is doing an additional call to MOVE in between the two bios() calls -

A>MOVE(00EA,0DF4,F72A)
testbios
MOVE(000A,F72A,0DF4)

MOVE(0080,0DF6,F72E)
MOVE(0024,F7AF,0DD0)
MOVE(0010,0DA2,F74E)
MOVE(0024,0DAD,F72A)
MOVE(0021,F72A,0DAD)
A:TESTBIOS COM
MOVE(0080,0081,F72E)
MOVE(0024,F7AF,0DD0)
MOVE(0080,0B1E,F72E)
MOVE(0024,F7AF,0DD0)
MOVE(0024,F290,F72A)
MOVE(0024,F2C0,F72A)

XMOVE(02,01)
MOVE(0080,0000,3300)

XMOVE(02,01)
MOVE(0080,0080,3380)
MOVE(0024,F292,F72A)
Z3ENV is not established.  (This is not an error.)
Press a key: MOVE(0024,2FFB,F72A)
rc = 0061, character = MOVE(0024,2FFB,F72A)
aMOVE(0024,2FFB,F72A)

The next message should say "Did this work?"
MOVE(0024,2FFB,F72A)

XMOVE(01,01)
MOVE(0024,2FFB,F72A)              <-- this MOVE causes the issue
MOVE(000F,2E2D,3396)

MOVE(0010,0080,F74E)
MOVE(0024,FC72,F72A)
MOVE(0021,F72A,FC72)
MOVE(0024,FC72,F72A)

XMOVE(02,01)
MOVE(0080,0600,0D00)
MOVE(0024,0D6A,F72A)
MOVE(0024,0392,F72A)
MOVE(0100,605C,5F5C)

A>MOVE(00EA,0DF4,F72A)

Compare this to the same debug output from the ZPM3 system

A>testbios
A:TESTBIOS COM

XMOVE(02,01)
MOVE(0080,0000,3300)

XMOVE(02,01)
MOVE(0080,0080,3380)
Z3ENV is not established.  (This is not an error.)
Press a key: rc = 0061, character = a
The next message should say "Did this work?"

XMOVE(01,01)
MOVE(000F,2E2D,3396)
Did this work?

XMOVE(02,01)
MOVE(0080,0600,0D00)

A>

What this suggests to me is there is a problem with trying to call the BIOS XMOVE/MOVE routines using the BDOS function 50 (direct BIOS call) using the Digital Research banked BDOS.

A quick google search doesn't show this as a "known" issue - but others may be aware of it.

I can reproduce this problem running DRI CP/M plus under SIMH AltairZ80 emulation and on my Z280RC system.

Tony

Compiling on ZPM3 under MyZ80 1.24. I'm able to build my library on D0:, but when I try to use the library via:

D>c -o -x -i0:d: -lc3l -lc3l vicdemo1.c

I get 0:B:LIBC3L.LIB Can't open

Hi-Tech C is on B0:. I have ENVIORN set up for Hi-Tech C location and TMP. Is there something I need to specify to find my libraries? I tried -l0:D:C3L, but it still doesn't find it.

I try using -I 0:C: to tell hitech c to look at drive c for includes, but nothing works. How do I do this? I'm compiling source on a separate drive.

After you changed -Dz80 to -DZ80 in the C frontend, we need to align the code and headers too.

cpm.h:#if	z80
cpm.h:#else	z80
cpm.h:#endif	z80
float.h:#if	z80
float.h:#endif	z80
hitech.h:#if	z80		/* only has one register variable */
hitech.h:#endif	z80
setjmp.h:#if	z80
stdint.h:#if z80||i8086||i8096||m68k
stdio.h:#if	z80
stdio.h:#else	z80
stdio.h:#endif	z80

Do you want me to do it? also, I don't like the lowercase macro names but is is worth keeping the setting of Hi Tech and using

• z80
• z280

instead?

Other suggestion, I think it would be cool not to use Z280 for the front end itself so that the front end can compile for Z280 on Z80 ..., kind of a semi 'cross compiler' 😀 but of course if optimh depends on running on a z280 ....

FYI https://groups.google.com/g/comp.os.cpm/c/fe3vQ16Fn0I

https://github.com/nikitinprior/dlibr

Best Wishes Phil

I've been splitting my library into individual modules and compile and libr goes fine. When I try c -o -x -i0:d: testprg.c 0:d:libtest.lib 0:a:libc.lib I get can't create testprg.obj without any context. Docs do not really tell you why this happens. The lib is about 45K, but libc is bigger than that.

If you look at one of my ASM modules https://github.com/sgjava/c3l/blob/main/asm/vdcout.as you'll see the typical pop and push of the args. Is there a better way to access the stack via index maybe less expensive?

The new front end is still not working on ZXCC. The output of the $$$ file is corrupted.

This is the previous problem I was raising linked to the initial size adjustment.

Files are automatically transformed and not transparently pushed back if using a Mac.

I'm seeing resulting com files that are at least 10K bigger in some instances. Is there a reason for that? CP/M has a small TPA, so every byte counts. I'm using the same build process and code.

I tried the original c.com and had the same issue. I'm wondering if it has something to do with one of the libraries?

Tested with original HTC and sizes are back to normal. What I noticed is libc.lib is throwing an undefined symbols error with _close. I think you said you reordered stuff in that lib. I'm not sure what I can test on my side to see why resulting com files are bigger.

I get a very weird problem with the new message, in one of my test scenarios, the c front end generates garbled content. if I reduce by one character (removing the dot at the end) everything goes fine....

I suppose it is a question of address access but where and how? no clues.

the issue appears when I try to compile:

c -v -r testbios.c

I get this weird trace

zxcc c --v --r testbios.c
HI-TECH C COMPILER (CP/M-80) V3.09-P009.1-dev
Copyright (C) 1984-2021 HI-TECH SOFTWARE
0:CPP -DCPM -DHI_TECH_C -D_HTC_C -Dz80 -D_HTC_REDIR -I P:TESTBIOS.C $CTMP1.$$$
1:P:K: Not found - change disks, hit a key

rather than the expected:

zxcc c --v --r testbios.c
HI-TECH C COMPILER (CP/M-80) V3.09-P009.1-dev
Copyright (C) 1984-2021 HI-TECH SOFTWARE
0:CPP -DCPM -DHI_TECH_C -D_HTC_C -Dz80 -D_HTC_REDIR -I P:TESTBIOS.C $CTMP1.$$$
0:P1 $CTMP1.$$$ $CTMP2.$$$ $CTMP3.$$$
0:CGEN $CTMP2.$$$ $CTMP1.$$$
0:ZAS -N -oTESTBIOS.OBJ $CTMP1.$$$

No idea whatsoever ....

The rebuilt compiler front end (from cpm/C.C) is not handling prompted for input when run from a submit file.

10E>type t.sub
; Original compiler driver works
c
<-o -v c.c

; Invoke the updated compiler driver (which should prompt for input)
c309-6
<-o -v c.c


10E>t.sub
E:T        SUB
C:SUBMIT   COM  (User 0)

10E>; Original compiler driver works
10E>c                                                                           
A:C        COM  (User 0)                                                        
HI-TECH C COMPILER (CP/M-80) V3.09                                              
Copyright (C) 1984-87 HI-TECH SOFTWARE                                          
c> -o -v c.c
0:A:CPP -DCPM -DHI_TECH_C -Dz80 -I0:A: C.C M:$CTMP1.$$$                         
0:A:P1 M:$CTMP1.$$$ M:$CTMP2.$$$ M:$CTMP3.$$$                                   
0:A:CGEN M:$CTMP2.$$$ M:$CTMP1.$$$                                              
0:A:OPTIM M:$CTMP1.$$$ M:$CTMP2.$$$                                             
0:A:ZAS -J -N -oC.OBJ M:$CTMP2.$$$                                              
ERA M:$CTMP1.$$$                                                                
ERA M:$CTMP2.$$$                                                                
ERA M:$CTMP3.$$$                                                                
0:A:LINQ -Z -Ptext=0,data,bss -C100H -OC.COM 0:A:CRTCPM.OBJ C.OBJ 0:A:LIBC.LIB  
ERA C.OBJ                                                                       
ERA M:$$EXEC.$$$                                                                
                                                                                
10E>                                                                            
10E>; Invoke the compiler driver (which should prompt for input)                
10E>c309-6                                                                      
E:C309-6   COM                                                                  
 Compiler (CP/M-80) V3.09-6                                                     
Copyright (C) 1984-87 HI-TECH SOFTWARE                                          
c> ^C                                                                           
10E>

The compiler just sits at the c> prompt (I have entered the Ctrl-C to break back to CP/M's prompt).

Noticing that the sign-on banner loses the first 9-characters (that correspond to the 9 characters that should have been fed into the c> prompt input.

10E>c309-6                                                                      
E:C309-6   COM                                                                  
Hi-Tech C Compiler (CP/M-80) V3.09-6                                            
Copyright (C) 1984-87 HI-TECH SOFTWARE                                          
c> 

Suspect an issue with the streams handling routines.

This has been an issue for some time, but I can't really figure out whats up.

I'm using romwbw and cp/m, and whenever I try to invoke the compiler from another drive, I get this error:

I>E:c309 -v main.c
HI-TECH C COMPILER (CP/M-80) V3.09
Copyright (C) 1984-87 HI-TECH SOFTWARE
Can't execute $EXEC
I>
What causes this? Is there a way to fix this, so I don't have to manually copy everything over to the hi tech drive every time I want to compile?

Sorry for not pushing with a PR, small recommended change, adding the prototype for the rename function.

...
extern int	dup(int);
extern long	lseek(int, long, int);
extern int	read(int, void *, int);
extern int	unlink(char *);
extern int	rename(char *, char *);
...

The prototypes in dist/TIME.H are missing the time_t pointer argument.

According with the function sources in stdio/CTIME.C, they should be:

extern char *	ctime(time_t *);	/* current local time in ascii form */
extern struct tm *	gmtime(time_t *);	/* Universal time */
extern struct tm *	localtime(time_t *);	/* local time */

Using submit to build library and then apps that rely on library. I first get something like uchar undefined even though hitech.h is included. No sure if my headers are too big, but I'm using ifndef to make sure they are loaded only one time. If I compile the same way without submit it builds. Are there any hints to making larger apps compile?

I'm trying to extract the lbr archive, but I get an error when it hits overlay.h, it says that the extraction is aborting.

I tried to resend it, same effect

A couple of very minor bits I spotted when merging back all your C.C changes. Almost vanilla now apart from the end of -Y

1. Should options contain:

-E      Name of the executable output.

2. Also you fixed a good couple of - in the $EXEC.$$$ generation but a few -o and -c are still there

Line 755:         vec[i++] = strcat(strcpy(cbuf, "-C"), crtmp);
Line 449:         flgs[flg_idx++] = strcat(strcpy(xalloc(strlen(l_dot_obj)+3), "-o"),

Not a cause for concern on clean CP/M but on emulators it may trip them

All the improvements on zcrt are not propagated to zrrt.

• dos header
• cp/m 3 check you added recently
• pipemgr/rsx integration

I have made the integration with both bootstraps being completely inline, worth pushing?

I did exactly the same work ~ 2 years ago but did not feel bold to share. Missing some of your patches. I am realigning and will publish on git. Any interest is joining effort?
In particular the overlays...