Going the Next Level Up
I was brought up on Turbo Pascal V3 and it is available for CP/M-80. But no, it is for the Z80 (or at least the one I tried did not work).
Okay, a C compiler would be pretty cool. First compilers of the CP/M era are generally K&R (not ansi) which means the syntax (of the function definition) is not the same as modern compilers. So every modern C program will need to be modified.
Next, many of the compilers are short integer and offer floating point as an add-on (i.e. the professional version).
Finally, you do need the documentation!
BDSC
Okay, first of the line is the free and professional version of bdsc. Looks good but it does not run under the Linux CP/M emulator I am using.
Aztec C
Looks good, works with Linux CP/M emulator and I have the documentation.
Better still the minimum package (with floating point) is:
Now you will need to add other libraries as you require them but the above is only 160kb.
Here is an example (under my Linux CP/M emulator):
- ./cpm cc test.c
- ./cpm as test.asm
- ./cpm ln test.o m.lib c.lib
- ./cpm test
Here is my test.c:
#include "stdio.h"
#include "math.h"
main()
{
char buf[80];
float r;
printf("please enter your name: ");
gets(buf);
r=sqrt(1.1);
printf("hello, %s, %f welcome to the growing community of Aztec C users\n",
buf,r);
}
And the Output:
./cpm test
please enter your name: AlanX
hello, AlanX, 1.048798 welcome to the growing community of Aztec C users
The only downside is that the COM file is rather large (12.4k) for such a small program, but then COM file needs to include all the libraries (i.e. static) and the 8080 is a rather primitive CPU (8 bit and no FPU).
Without floating point maths, the executable is still 8.5kb.
Yes and No
Modified makeDisk256 to read native CP/M files rather than hex files (saves a lot of work renaming files once they are on the machine.
Took a day trying to workout why the compiler did not work on the machine. I only have 32kb of RAM (less CP/M) for a 39kb executable.
Any, uploaded a precompiled test file (TEST.COM) and it works.
Only problem is when the program exits it kills my machine. Likely a problem in my CBIOS.
Here is the run:
my CP/M 2.2 V1A
A>DIR
A: STAT COM : ED COM : ASM COM : DDT COM
A: LOAD COM : SUBMIT COM : XSUB COM : PIP COM
A: BASIC COM : BASIC DOC : UNZIP COM : TEST BAS
A>STAT *.*
Recs Bytes Ext Acc
64 8k 1 R/W A:ASM.COM
59 8k 1 R/W A:BASIC.COM
51 8k 1 R/W A:BASIC.DOC
38 6k 1 R/W A:DDT.COM
52 8k 1 R/W A:ED.COM
14 2k 1 R/W A:LOAD.COM
58 8k 1 R/W A:PIP.COM
41 6k 1 R/W A:STAT.COM
10 2k 1 R/W A:SUBMIT.COM
1 2k 1 R/W A:TEST.BAS
28 4k 1 R/W A:UNZIP.COM
6 2k 1 R/W A:XSUB.COM
Bytes Remaining On A: 180k
A>STAT DSK:
A: Drive Characteristics
1984: 128 Byte Record Capacity
248: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
0: Checked Directory Entries
256: Records/ Extent
16: Records/ Block
16: Sectors/ Track
4: Reserved Tracks
A>BASIC
BASIC/5 INTERACTIVE INTERPRETER V Z1.0 10/16/77
NEW OR OLD? O
OLD PROGRAM NAME: TEST.BAS
READY
LIST
10 FOR I=1 TO 10
20 PRINT I
30 NEXT I
40 END
RUN
1 2 3 4 5 6 7 8 9 10
READY
SYSTEM
A>B:
B>DIR
B: CC COM : CC COM : CC MSG : AS COM
B: LN COM : C LIB : C LIB : M LIB
B: STDIO H : MATH H : COMPILE TXT : TEST C
B: TEST COM
B>A:STAT *.*
Recs Bytes Ext Acc
52 24k 1 R/W B:AS.COM
277 36k 2 R/W B:C.LIB
307 40k 2 R/W B:CC.COM
27 4k 1 R/W B:CC.MSG
1 2k 1 R/W B:COMPILE.TXT
54 24k 1 R/W B:LN.COM
70 26k 1 R/W B:M.LIB
3 2k 1 R/W B:MATH.H
11 2k 1 R/W B:STDIO.H
2 2k 1 R/W B:TEST.C
97 14k 1 R/W B:TEST.COM
Bytes Remaining On B: 68k
B>DIR
B: CC COM : CC COM : CC MSG : AS COM
B: LN COM : C LIB : C LIB : M LIB
B: STDIO H : MATH H : COMPILE TXT : TEST C
B>TYPE COMPILE.TXT
cc test.c
as test.asm
ln test.o m.lib c.lib
test
B>TYPE TEST.C
#include "stdio.h"
#include "math.h"
main()
{
char buf[80];
float r;
printf("please enter your name: ");
gets(buf);
r=sqrt(1.1);
printf("hello, %s, %f welcome to the growing community of Aztec C users\n", buf,r);
}
B>TEST
please enter your name: AlanX
hello, AlanX, 1.048798 welcome to the growing community of Aztec C users
my CP/M 2.2 V1A
my CP/M 2.2 V1A
my CP/M 2.2 V1A
[and it continues]
AlanX
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.