• Please review our updated Terms and Rules here

ZCPR3 for Montezuma CP/M on TRS-80 M4

V

vldmrrr

Experienced Member
Joined
Aug 20, 2016
Messages
169
Location
IA, USA
I've really got used to zcpr on Kaypro, and now having created a bootable 800K MM CP/M image for gotek, I really miss zcpr functionality. For Kaypro it came with a nice installer on micro cornucopia disks. I started to look for something similar for MM. And I have found this archive that contains the following installation instructions in READ.ME file:
Code: 
    1.   Format a bootable CP/M system disk under Montezuma CP/M
         2.2.
    2.   Copy SYSIMAGE.OBJ onto this disk.  This *must* be the
         first file copied onto this disk.
    3.   Copy INITLIZE.COM and DU.COM onto this disk.
    4.   Run DU.COM and issue the following commands:
              G2
              <;-68;>;W;+69;/72
              X
    5.   Put this disk into drive A: and push RESET.
The archive does not contain this SYSIMAGE.OBJ file. I am not sure where this one is supposed to come from. There is a script to recreate it from running system as follows:
Code: 
ERA SYSIMAGE.OBJ
DU T0;S1
Y;+;/72
KSYSIMAGE.OBJ
X
But I am still not sure how to get an actual zcpr3 into the system. Searching for zcpr3 did not lead me to any generic installable package with instructions. There are a lot of bits and pieces around, including source code, bunch of *.lib or other mysterious files, for example here.
So if anyone could point me to some coherent package with instructions that could be applied to this case, please do.
 
I will try to find the code.


The full README is:

To make a bootable ZCPR3 disk for a TRS-80 model 4 or 4P,

1. Format a bootable CP/M system disk under Montezuma CP/M
2.2.

2. Copy SYSIMAGE.OBJ onto this disk. This *must* be the
first file copied onto this disk.

3. Copy INITLIZE.COM and DU.COM onto this disk.

4. Run DU.COM and issue the following commands:

G2
<;-68;>;W;+69;/72
X

5. Put this disk into drive A: and push RESET.

It is not necessary to use LDR.COM to load the rest of the Z-
system, as INITLIZE.COM performs these functions. Use LDR.COM
only to change segments from the default configuration.

A modified version of CONFIG has been provided. To run it,
SYSIMAGE.OBJ must be the first file on the disk (located at
allocation group 2). Do not use the save-to-disk option in
CONFIG.OBJ (the old config.com) as it will over-write critical
areas. Instead, you will be prompted after the "exit" option.
DU.COM, ZEX.COM, CONFIG.COM, CONFIG.OBJ, and CONFIG.ZEX must all
be on the disk.

CONFIG.OBJ is (c) Montezuma Microsystems. Anyone using that code
must already have the original bios from Montezuma along with the
license to use it. This should be self-enforcing,
as it won't run in another environment.


**********************************************
*
* This file contains code written by Kent Hursh in
* October 1986 to modify Montezuma CP/M 2.2 to use
* ZCPR3. Portions are modified from the Heath-Zenith
* implementation by Bill Stuntz. ZCPR3 is written
* by Richard Conn. The ramdisk initialization code
* is disassembled from the bios in Montezuma CP/M 2.2
* copywrighted by Montezuma Microsystems.
* Anyone using that code must already have
* the original bios from Montezuma along with the
* license to use it. This should be self-enforcing,
* as it won't run in another environment.
*
* With the above caveats, these files may be freely
* copied. TRS80 modifications (c) 1986 Kent Hursh,
* Artisan Software, 4384 US 33, Athens OH 45701.
*
* Comments and other correspondance may be sent by
* email to khursh@oucsace.cs.OhioU.Edu or by
* USnailNet to Kent Hursh, Artisan Software,
* 4384 US 33, Athens OH 45701.
*
***********************************************
 
shirsch said:
You should be able to use NZCOM (auto-installing Z-System) on a TRS-80. Download from here:
http://www.gaby.de/edownf.htm
Click to expand...
Thank you, I did not know about nzcom, it does work fine on MM CP/M and it was fun to learn. My only gripe so far is that it takes way long to load compared to plain vanilla zcpr - I have to think twice before pressing reset button. It is like booting windows after long life with dos, if you know what I mean. So I will continue to play with nzcom, but also I will still be on lookup for plain zcpr installation - for what I am doing at the moment nzcom is a huge overkill.
 
For faster loading please configure your NZCOM and then make a 'copy' with NZBLITZ

NZBLITZ is an NZCOM utility that permits saving and direct loading of
system images. It simply replaces everything from CCP up to CBIOS with the
new system, writes NZCOM.CCP to disk (to A0: by default), then boots the new
system. The ENTIRE user environment is replaced (including shells, RCP, FCP
IOP, TCAPS, DOS, CCP, and ZDOS clock/stamp drivers). This allows a fast cold
load of a system - full up with desired drivers, shells, path, and options.

Aside from speed in loading a fully configured system, NZBLITZ can be very
useful for saving space on floppy systems. Because NZCOM is not needed (nor
NZCOM.LBR) once the COM file is created, there can be a savings in disk space
if you typically use one standard system. Vs 1.0 (4/27/90) by Cam Cotrill.

ZCNFG.COM and NZBLITZ.CFG may be used to configure NZBLITZ to allow saving
the system image up to the start of the CBIOS (the default), or up to a fixed,
specified top-of-save address.

If you specify FFFFh (the default specified top-of-save address), the
system image from the CCP all the way up to the top of memory, including
the CBIOS is saved. This allows those of us running custom NZCOM systems
that use the existing standard Ampro Z-system buffers that reside above the
CBIOS to also save systems with NZBLITZ at the cost of a slightly larger
NZBLITZ image file. See AMPRO.ZCM for a sample ZCM file for Ampros that
uses the standard Ampro above-CBIOS Z-system buffers in an NZCOM system.

You may also configure a lower top-of-save address if you wish to save the
CBIOS but your system has other features at the top of memory that you
don't wish to save, such as dedicated ROM space.

Hoe to use:

Operation - 1/3
NZBLITZ is an NZCOM utility that permits saving and direct loading of
system images. NZBLITZ started life during development of NZCOM. In greatly
expanded form, it became the /C (clone) option.

NZBLITZ is a very simple minded utility. It doesn't look to see what
elements of the running system can or should be saved (TCAPS, MCL, Shell
Stack, etc). It simply captures everything from the CCP (or lowest loaded
RSX) up to the CBIOS (or above) into a system loader utility. When the system
loader utility is run, it replaces the entire saved system, as specified by
its configuration, writes NZCOM.CCP to disk to the drive and user specified in
the NZCOM NZBIOS, then boots the new system.

Operation - 2/3


This strategy has several very significant side effects. First, the ENTIRE
user environment is replaced - this includes Shells, RCP, FCP, IOP, TCAPS,
DOS, CCP, and in the case of ZSDOS and ZDDOS the clock and stamp drivers that
live in the NZCOM user area! This allows a cold load of a system - full up
with drivers, shells, path, and options set as you want in very short order -
4 seconds on my hard disk system. By comparison, a startup alias to load the
same system by "traditional" methods would take 14 seconds. If the CBIOS is
saved as well, installed hard disk, RAM disk and other special drivers need no
longer need be loaded or initialized at each cold boot, saving even more time.
Completely configured systems can be loaded or replaced almost instantly.

The system loader files created by NZBLITZ are stand-alone COM files,
complete with loader. These COM files also respond to ZCPR style help.
Though these files contain a ZCPR header, they do not require a Z-system in
order to run. This is no accident, as one primary purpose for the NZBLITZ is
to cold start NZCOM systems. Aside from speed in loading a fully configured
system, NZBLITZ system loader files can be very useful for saving space on
floppy systems. Because NZCOM or NZCOM.LBR are not needed once the COM file
is created, there can be a savings in disk space if you typically use one
standard system.

Operation - 3/3

When you run an NZBLITZ system loader file, you may suppress the write of
the NZCOM.CCP file by including the '/F' option on the command line. If
you use this option, be CERTAIN that your current NZCOM.CCP runs at the
same address as the system you are going to load does. Otherwise, the system
will crash - and quickly! The system loader uses a function 37 reset, then
exits directly to the CCP (which issues a function 13 reset right away) to
reset all disks.

See your NZCOM documentation for more information on customizing your
NZCOM systems.
 
vldmrrr said:
Thank you, I did not know about nzcom, it does work fine on MM CP/M and it was fun to learn. My only gripe so far is that it takes way long to load compared to plain vanilla zcpr - I have to think twice before pressing reset button. It is like booting windows after long life with dos, if you know what I mean. So I will continue to play with nzcom, but also I will still be on lookup for plain zcpr installation - for what I am doing at the moment nzcom is a huge overkill.
Click to expand...

I never found the startup latency to be objectionable, but perhaps MM CP/M is an outlier. I'll give it a try here. The nzblitz approach that fritzeflink documents sounds like a good workaround as well. I have never felt the need to use it and am not familiar with it.
 
Quick followup: I have been working with Montezuma Micro CP/M on my M4 for a day or so using a FlashFloppy (Gotek) as drive A:. Initially I used the disk definition that Larry Kraemer posted which has an interleave of +9. It was incredibly slow and NZCOM would have been unbearable in such an environment. Then I started experimenting with interleave and discovered I could take it down to +2. With that setting it's many times faster and enjoyable to use. If you are working with real floppies, I'm not sure how to re-interleave the diskettes but with FF it's a matter of changing one line in the IMG.CFG file. Here's the definition I'm using for MM CP/M boot diskettes:

# TRS-80 M4 Montezuma Micro SSDD
[::184320]
cyls = 40
heads = 1
id = 1
interleave = 2
secs = 18
bps = 256
mode = mfm
rate = 250
 
shirsch said:
Quick followup: I have been working with Montezuma Micro CP/M on my M4 for a day or so using a FlashFloppy (Gotek) as drive A:.
Click to expand...
OK, that is interesting. I am also using FlashFloppy (Gotek).

When I started with TRSDOS I was not able to boot any image I created with that IMG.CFG file. What I ended up was converting those images to HXC native format (.hfe), and these were working fine without any IMG,CFG file - I just removed it from FF directory.

Then when I moved on to play with CP/M I just kept the same arrangement using hfe images without IMG.CFG, because that allows mixing TRSDOS and CP/M images on the same USB stick. But I should try to use raw format for CP/M images instead.
 
vldmrrr said:
OK, that is interesting. I am also using FlashFloppy (Gotek).

When I started with TRSDOS I was not able to boot any image I created with that IMG.CFG file. What I ended up was converting those images to HXC native format (.hfe), and these were working fine without any IMG,CFG file - I just removed it from FF directory.

Then when I moved on to play with CP/M I just kept the same arrangement using hfe images without IMG.CFG, because that allows mixing TRSDOS and CP/M images on the same USB stick. But I should try to use raw format for CP/M images instead.
Click to expand...

You are always able to intermix raw disk images with HFE - even in the same directory. FF is smart enough to understand that a file extension of .hfe (case insensitive) contains parameters within it. Extension of '.dsk' means look in the IMG.CFG for a definition (or use built in).
 
I have used NZCOM and NZBLITZ on both Model 4 and 4P. It is a true joy to see Zsystem on TRS-80, or even just MM CP/M, one only wonders what if it was available in the Model III 1980 period; meaning, if the Model 4 design was introduced in 1980 allowing native CP/M. How much more market share dominance for both CP/M and TRS-80, possibly extending CP/M reign and DRI creating iterations of new innovations/DOSs.

For those who might not know, the FCC would not allow Tandy to sell the Model I+Model I Expansion Interface past 1/1/1981 due to the excessive RF interference on home TVs+AM Radios. So Tandy rushed to come up with a quick fix to continue selling Z80 home computers. The solution came in the form of a repackaged Model I+EI+DiskDrives+Monitor into a single enclosure, RF shielded to meet the FCC regulations; hence the Model III was born. So the Model III is practically a Model I. It was not until 1983 with the Model 4 that CP/M and bank-switched CP/M Plus can run natively, by which time CP/M+8bit micros were already on the decline and being gradually replaced by 16bit micros. Jim.
 
Last edited:
You must log in or register to reply here.
Back
Top