• Please review our updated Terms and Rules here

make utility

How would that work on a system with no date or time in the file system?

Hmm that would be a problem!

OK, so here's what I'm doing: I have an intention of rebuilding the Kaypro10 "masmenu.com".
I found the sources in the Maslin archive. The notes say to use Aztec C 1.05.
I'm running maxZ80 with the ZCPR system which also happened to have Aztec C installed within.
The Maslin Menu sources have a menmake.dat leading me to think I should be able to find a make utility.
Alas, I have not found the make utility among the archives searching recursively for make*.*.
I guess its just not possible unless some advanced extension of CP/M was doing date/time stamping.

Given the date of the archives, 1995 and beyond, its is likely that he was developing under DOS for CP/M.
(The true file dates are lost in my archive copy)
My mindset was CP/M for the last week, so I may have made a bad assumption that it was done under CP/M tools.

Contents of the makefile:

menu: main part2 subs
xsub
l80
masmenu,menu2,mroot,mgetc,timdat
inbyte,submit,memory,ccpm,lzc/s,masmenu/n/y/e

prep: masprep prepio
l80 masprep,prepio,memory,lzc/s,masprep/n/y/e

masprep: masprep.c masprep.h
czii -mo masprep.mac masprep.c
m80 =masprep
era masprep.mac

prepio: prepio.c masprep.h
czii -mo prepio.mac prepio.c
m80 =prepio
era prepio.mac

subs: timdat memory submit inbyte mroot mget ccpm
:recompiled subroutines

ccpm: ccpm.mac
m80 =ccpm

mget: mgetc.c mgetc.h
czii -mo mgetc.mac mgetc.c
m80 =mgetc
era mgetc.mac

main: masmenu.c menu.h
czii -mo masmenu.mac masmenu.c
m80 =masmenu
era masmenu.mac

part2: menu2.c menu.h
czii -mo menu2.mac menu2.c
m80 =menu2
era menu2.mac

submit: submit.c
czii -mo submit.mac submit.c
m80 =submit
era submit.mac

timdat: timdat.c
czii -mo timdat.mac timdat.c
m80 =timdat
era timdat.mac

memory: memory.c
czii -mo memory.mac memory.c
m80 =memory
era memory.mac

mroot: mroot.c
czii -mo mroot.mac mroot.c
m80 =mroot
era mroot.mac

inbyte: inbyte.mac
m80 =inbyte

backup:
xsub
pip
c:=mas????.c[v]
c:=prepio.c[v]
c:=menu?.?[v]
c:=mroot.c[v]
c:=mgetc.c[v]
c:=menmake.dat[v]
c:=submit.c[v]
c:=timdat.c[v]
c:=memory.c[v]
c:=inbyte.mac[v]
c:=ccpm.mac[v]
.
 
OK- I learned something new today!
Thanks!

Maslin must have cross compiled.
For this I'll probably just make a submit that compiles everything.

You know though, I guess I'm surprised that Kildall and company put up with that.
They were a leading software tool company. Didn't it drive them crazy?
If the file system just had a marker that said the file had been updated, it would
have been enough to enable condition processing. It wouldn't have required date/time,
which a lot of hardware didn't always have.

Some poking around tells me MPM and CPM-86 could use a file system with date/time
- perhaps the same one as DOS FAT?
I'm not going to bother with that...
 
I have read several references to a make utility that was designed to work with PluPerfect's DateStamper add-on for CP/M 2.2. I can't find a copy of either tool though. Of course, could there be a less distinctive term to search on than "Make?"
 
Maybe it's a C thing, I've never been much of a C programmer. But I've used 'make' programs for other languages that don't care about time and date; they only check for the existence or nonexistence of object files.

Otherwise, is there anything that you'd compile for CP/M that it would be prohibitive to compile the whole thing anyway? (again, could be a limitation of C for all I know)
 
Found a few things on walnut creek.

CPMMAKE.ARK 46443 08-31-86 CP/M-Plus version of Unix MAKE util.
MAKE-DS.LBR 59136 09-04-86 Unix Make, CP/M DateStamper version
PMAKE2.LBR 42240 11-16-86 A 'make file' utility for CP/M-80
RCPMKE13.LBR 40832 11-27-87 Unix-like MAKE for ZCPR 33
MAKE.ARC 24192 06-07-93 MAKE is a powerful utility for CP/M-3. MAKE
| is compatible with Microsoft's MAKE utility
| for the IBM PC. It allows for conditional
| execution of commands depending on date&time
| stamps of the files concerned. It recognizes
| the CP/M-3 Error Flag and stops when that
| flag is set. It also uses the CP/M-3 Drive
| Search Chain to search for source files.
MAKLIB12.LBR 24576 06-07-93 AUTOMATED LBR-builder for DateStamper/ZSDOS
| users. ZFILER/ARUNZ scripts crunch "comment
| text" into files, insert into LBR, preserve
| all datestamps. Uses ZFILER's group macro
| feature. Tag files you want in LBR, enter LBR
| name, sit back and watch. Scripts limit
| "comment" to exactly 19 characters, maximum
| allowed by LDIR-B. Target LBR can previously
| exist or not. Nice display. V1.2: fix to
| ERASE.COM, optional rename, long essay re
| ZEX. -- Rick Charnes
MAKE27.LBR 25984 06-08-93 Update to MAKE adds existance checking and
| query if there exists a file on the
| destination DU:. Also supports attribute
| bits,
NEWMAKE.ZIP 38136 08-23-91 Make, simplifies building of programs
 
Those are all CP/M commands in the different sections, so it seems likely that there was some kind of CP/M utility that ran through this file.

Creating some SUB files that replicate each section would be a good approach if you can't locate the original utility.
 
I have read several references to a make utility that was designed to work with PluPerfect's DateStamper add-on for CP/M 2.2. I can't find a copy of either tool though. Of course, could there be a less distinctive term to search on than "Make?"

>Of course, could there be a less distinctive term to search on than "Make?"
Good question!
 
Maybe it's a C thing, I've never been much of a C programmer. But I've used 'make' programs for other languages that don't care about time and date; they only check for the existence or nonexistence of object files.

Otherwise, is there anything that you'd compile for CP/M that it would be prohibitive to compile the whole thing anyway? (again, could be a limitation of C for all I know)

>Otherwise, is there anything that you'd compile for CP/M that it would be prohibitive to compile the whole thing anyway?
Probably no. Just a tiny bit annoying... I didn't know it was going to be this difficult...
 
Those are all CP/M commands in the different sections, so it seems likely that there was some kind of CP/M utility that ran through this file.

Creating some SUB files that replicate each section would be a good approach if you can't locate the original utility.

>Creating some SUB files that replicate each section
Yes, agreed.
 
OK- I learned something new today!
Thanks!

Maslin must have cross compiled.
For this I'll probably just make a submit that compiles everything.

You know though, I guess I'm surprised that Kildall and company put up with that.
They were a leading software tool company. Didn't it drive them crazy?
If the file system just had a marker that said the file had been updated, it would
have been enough to enable condition processing. It wouldn't have required date/time,
which a lot of hardware didn't always have.

Some poking around tells me MPM and CPM-86 could use a file system with date/time
- perhaps the same one as DOS FAT?
I'm not going to bother with that...

I remember thinking that a MAKE utility of sorts without the need for date/time facilities for CP/M by using the presence of .BAK files left over from editing. You look for a .BAK file, count that file as being edited, re-compile and then delete the .BAK file.

Kildall and all who were of that period were using slow floppy systems (have you ever used an 8" ISIS-II box?) . You set things up to compile, and went out for a cup of coffee or did something else. That's the old way. When I worked on mainframe OS, you could get one good compile/assembly in per day. I remember being amazed by one of my friends who was working on UNICOS (Cray) telling me that he didn't bother with partial builds--a complete build only took a few minutes.

People think and work differently today. In the old days, you wrote out your program on coding forms punched cards from them, got 80-80 listings and proofed them before submitting them to be run. A no. 2 pencil was your most useful tool. No video displays, slow I/O.
 
And then there was TurboPascal, and you weren't really sure it actually compiled until you ran it and it worked.

I get a lot of derision for using my 6502 assembler, which is written in Commodore BASIC. Yeah, it takes a half hour, (or is it an hour, I don't even know) to assemble the assembly language port of itself which isn't finished. So, I don't get anything done quickly. But really, I'm not in a hurry. If I was, I'm not incapable of assembling on paper. It wouldn't be the first time I did that.

 
I love the 6502 assembler in BASIC. A great period solution to the =at the time= high cost of software!
 
I love the 6502 assembler in BASIC. A great period solution to the =at the time= high cost of software!

Precisely my original impetus for writing it. It's also been a great excersise in bootstrapping. The only tools needed to make it were a C64, 1541, and TV.

I wrote an assembler which was more like a monitor; it assembled as you typed, into fixed memory locations. Then I wrote a very limited line editor in BASIC. It used a whole disk REL file to work with a small number of lines. I don't remember how many; it's however many 254 character strings can fit on a 160k disk.

Then I rewrote the assembler to assemble from a file, which greatly increased its functionality. I used it to write a very minimal text editor in assembly language. Then I modified the assembler to work with a flat file, and painstakingly wrote a full-featured editor. When that was done, I wrote the assembler in assembly, and greatly improved it. I had a very powerful macroassembler.

In the interim years of not using a C64, I lost most all of that work. All that remained intact was the original assembler. So around 5 years ago, I started over. I've done everything exactly the same, and have gotten as far as writing the assembler in assembly, which is maybe halfway done. I just don't have the time like I did the first time!

 
I remember thinking that a MAKE utility of sorts without the need for date/time facilities for CP/M by using the presence of .BAK files left over from editing. You look for a .BAK file, count that file as being edited, re-compile and then delete the .BAK file.
That should work quite well. Shouldn't be too difficult to write a simplified make program that works this way.

Kildall and all who were of that period were using slow floppy systems (have you ever used an 8" ISIS-II box?) . You set things up to compile, and went out for a cup of coffee or did something else. That's the old way. When I worked on mainframe OS, you could get one good compile/assembly in per day. I remember being amazed by one of my friends who was working on UNICOS (Cray) telling me that he didn't bother with partial builds--a complete build only took a few minutes.
Yep, there was a bit of waiting involved.. obligatory XKCD: https://xkcd.com/303/
On the mini I worked on in the eighties I wrote a tool that would create a batch job of whatever you were doing and queue it on one of the batch processors the operating system kept running. The terminal sessions could only handle one thing at the time, so if you were compiling you would have to wait until it finished. With my tool you could do 'job make' and the make job (I wrote the 'make' too..) would run in the 'background', as it were, and you got a message on the terminal when it finished. In the meantime you could do something else, edit files or something. Otherwise there would be many very long coffee breaks..
KC9UDX mentioned Turbo Pascal. That was a revolution really. I remember it to be as snappy as anything today. Some had concerns about the runtime performance of the compiled program, but I seem to remember that there were better, but much slower compilers around (not at the start, but reasonably compatible compilers appeared on the scene after some time IIRC). So some people would develop with TP and compile the final product with the optimized slow compiler. My programs weren't among those though, I don't think I ever tried that. But that was many years ago and things are a bit vague.
 
Last edited:
I can say this much;: early versions of TP still circles round FPC, whatever that's worth.

I also recall hearing about developers prototyping in TP and compiling in a different compiler for the final product. It seems to me that the documentation for TP4 even expected this. I spent a lot of time optimising code and replacing Pascal with inline assembly (many, many hours spent with Turbo Profiler), and I find it hard to believe that any other compiler could have made a significant difference. But I too never actually did it, so I don't really know.
 
Back
Top