|
 |
The Memotech MTX Series |
 |
Memotech Multi-Function Expansion System
MFX CP/M 3 (CP/M Plus)
one ?)
Introduction
Memotech computer disk systems were based on the CP/M 2.2
operating system, as are all of the modern day Memotech
removable storage systems, including
REMEMORizer, CFX
and the original release of
MFX. Even the
ostensibly non-CP/M SDX BASIC disk system's underlying disk
structure was based on Memotech's version of the CP/M operating
system.
Digital Research released a later version of CP/M as CP/M 3,
also referred to as CP/M Plus. Quoting
from the CP/M Plus Operating Guide, "CP/M(R) 3, also
marketed as CP/M Plus(R) , is a single-console operating system
for 8-bit machines that use an Intel(R) 8080, 8085, or Zilog(R)
Z80(R) CPU. CP/M 3 is upward-compatible with its predecessor,
CP/M 2, and offers more features and higher performance than
CP/M 2."
Some home micros, such as the Amstrad PCW, featured CP/M
Plus. For most users, CP/M 3 offers very few benefits over a
CP/M 2 system, but the most significant are support for
additional memory through bank switching and support for file time/date
stamps with support for a Real Time Clock. The larger memory
available (512kB) and the option to install a Real Time Clock in
MFX meant that there was some incentive to port CP/M 3 to MFX.
Martin has gotten CP/M 3 running on MFX. The "disk"
geometry is considerably different to CP/M 2.2, so the Memotech
SDX ROM cannot access the disk from BASIC, but the the CP/M mode
works well and can coexist with the CP/M 2.2 system on the same
media with separate boot options for the two systems. Although
games, including HEXTRAIN, can't be run from CP/M 3, the system
can be booted to CP/M 2.2 and games run as before.
How it was done
The structure of CP/M 3 is pretty much
the same as CP/M 2.2, being made up of a BIOS (Basic Input
Output System), BDOS (Basic Disk Operating System) and a CCP
(Console Command Processor) as described on my
CP/M 2.2 Structure page.
The BIOS is the interface to the hardware of the target system
and must be customised to suit.
The original Digital Research source
files for CP/M have been released into the Public Domain and are
freely available from The
Unofficial CP/M Website on
gaby.de, a website
dedicated to CP/M and computer history.
Digital Research CP/M 80 source files
were all written to target the Intel 8080 using 8080 opcodes.
Up until release 2.2, the source files could be compiled using the DR
ASM
assembler or MAC, Macro assembler.
Release 3 required the relocating features of RMAC,
the DR Relocatable macro
assembler. For Z80 systems, DR did provide a kludge Z80.LIB for cases where you
could take advantage of the Z80's capabilities. However it was
just that, a kludge. As noted on the S100 website, "it can be
very frustrating looking up the Digital Research opcode of the
equivalent Zilog one". 1
When developing for MTX, Martin usually uses his self written
Z80 assembler, running on a RISC OS machine, originally an Acorn
PC, but nowadays, a Raspberry PI. Martin's first attempts at
developing a CP/M 3 BIOS for MFX were to try to convert the 8080
opcodes from the DR source to the equivalent Z80 opcodes for
processing by his Z80 assembler on his Raspberry Pi. This proved
to be somewhat problematic so he took an alternative approach,
much more in line with the DR method. Installing a copy of
RMAC under MFX's CP/M 2.2, he was able to compile the original
8080 source code as written before going on to modify the BIOS
for MFX.
The source files that Martin used included the
various "fixes" that Digital Research applied to CP/M 3.0,
resulting in a version number of 3.1. These fixes also added the
option to use UK date format (ddmmyy) instead of the default US
format (mmddyy) as well as a patch to added
Y2K
compatibility.
Anyone who runs CP/M 3 on MFX
should be aware of the significant effort that Martin has put in
to getting it running. To that end, I asked Martin to give me a
better insight to what was needed to get a working CP/M 3 BIOS
for MTX . . . . . . .
"The source code
archive contained the BNKBIOS.SUB script that uses RMAC to build
the BIOS from the sources. On completion that calls GENGPM.COM to
build the final CPM3.COM file. Once the initial parameters for
GENCPM are set the entire process is automatic. The worst part
for a Z80 programmer, is that everything has to be written in
Intel 8080 assembler, with a macro library to provide support
for the Z80 only opcodes.
The MFX Bios is built from 7
files:
BIOSKRNL – This is a DR
file and other than adjusting the compile time switch to select
between banked and unbanked builds DR documentation says it
should not be altered.
BOOT – Contains the
code to load the CCP which can be edited and the entry point for
the system call to set the date and time that has to be
supplied. Changes to the routine to load the CCP were minimal,
TIME requires adding 150 or so lines of code.
MOVE – Contains 2
routines both have to be supplied by the BIOS writer, MOVE and
XMOVE. XMOVE sets up the parameters for an inter-bank memory
transfer. MOVE does the actual transfer for both inter-bank and
intra-bank transfers. Neither is particularly complicated and
there’s only 100 lines of code to accomplish both
CHARIO – This is a big
file, it’s need to provide all the character based transfer
routines. MFX provides keyboard, printer and VDU based
transfers, but not serial, those are programmed to just return
dummy values. The keyboard code required translating 300+ lines
of Z80 code from the CPM2 driver into the 8080 equivalents. The
VDU handling code was another 700 or so lines translated from
the original Z80 to 8080. The printer support was the easy bit,
that only requite 10 lines of code translating to 8080. There’s
no new code in here but a lot of translation required.
DRVTBL – This is just
the drive table pointers, not the tables themselves and required
minimal work
SDCARD – This is a
completely new file, to provide disc handling, replacing the
floppy drivers in the original archive. It’s based on the
original MFX SD handling routines. There’s around 600 lines of
Z80 to 8080 translated code that provide the 4 system routines
read, write, init and logon that all of the disc transfers are
channelled through. In addition, there’s 200 or so lines of new
code for the drive tables, disc geometry calculations and memory
bank control. Memory control is important as the disc buffers
are in a different bank to the TPA where programs are loaded.
SCB – This is a DR
supplied file and is required to be left untouched as it
provides the System Control Block, the system variables
basically.
Not masses of new code, but all the Z80 to
8080 translation was a chore. The biggest source of errors was
forgetting that where the Z80 used LD 8080 uses umpteen
different mnemonics depending on whether it’s 8 bit or 16 bit
and whether the data is coming from another register or memory.
The worst thing to debug? JP it’s a
valid instruction for both CPUs but does different things.
Neither assembler will flag it as an error they just assemble
different instruction. JP is simple jump a new location on the
Z80, and on the 8080 it means only do the Jump if the last
result was positive. The eventual way to check accuracy of the
translated code was have the 2 assembler output listings side by
side and compare the hexadecimal output for unexpected changes.
Using a program to check the output wasn’t really an option as
the memory references in the final code were wildly different
between CPM2 and CPM3 and swamped any real errors.
Once the CMP3.SYS file is complete,
everything gets transferred over to the raspberry Pi where
there’s a number of utilities to build a complete disc image for
transfer to an SD card and testing on the MFX itself.
DR envisaged that the system tracks
would contain a CPM loader, and that loader, which was
essentially a non-banked BIOS/BDOS would load the full CPM3 from
CPM3.SYS. Since there were enough problems just getting the
banked CPM3 to run writing yet another version wasn’t going to
happen. Instead, the disc builder utilities pick CPM3.SYS apart
and put it onto the system tracks along with the bootloader etc.
The other annoying part of the process
is actually getting original files that work. Of the 3 source
archives, one has errors in the one of the pre-built modules,
such that even when the BIOS was assembling correctly the BDOS
was corrupt and the system failed to start. Luckily there was an
uncorrupted version in another of the archives.
At that point the BIOS boot string would
at least appear before the system locked up. The reason, the CCP
in the archive with the working BDOS was corrupt! The CCP from
the original archive was fine. There have been similar issues
with some of the other utility files too. "
Bank Switching - what's the point?
When I read that CP/M 3 provided RAM bank switching
capabilities, I assumed that this would allow
application programs to access more than the Z80's normal
maximum 64kB of RAM. However, this is not the case, but what
CP/M 3's RAM paging functions do facilitate is a larger CP/M
system size, allowing system functions to be offoaded from the
core BIOS to paged areas of RAM. Paging out of system functions
increaces the Transient Program Area size.
To
illustrate, the first Memotech FDX system had a CP/M system size
of 54kB. Memotech SDX systems have a 59kB system size with the
top of memory at 59k, above that are some buffers and the
hardware drivers copied from ROM. Below that lies CP/M 2.2 which
takes up about 6.5kB, leaving a TPA of about 53kB.
With
the CP/M 3 system, where some system functions, including those
for RTC support, are put into paged RAM, the TPA is increased to
about 61kB - a useful increase of around 15%. This is despite
the fact that CP/M itself is much bigger than CP/M 2.2. In the
current build, the bootloader, BIOS and BDOS are taking up over
20k of drive space, with the CCP an additional 4k on drive A.
That's instead of CP/M 2's 6.5k for bootlaoder, BIOS, BDOS and
CCP plus external drivers. However the banking means that
despite that 61K is still available to user programs.
How it works
Since CP/M 3 was going to be incompatible with Memotech SDX
BASIC, including games, it was essential that support for the
CP/M 2.2 system was retained. CP/M3 more or less required a new
partition format. CP/M2 expects each track to be 26 sectors of
128 bytes, that works out at 3.25k per track. CP/M3 works with
the native sector size, for CF and SD that's 512 bytes, meaning
there's no way to define a track that is 3.25k long. It is
possible that the track could have been made to be 6.5K long and
things made to work. However a 4k track size and a 4K block size
makes the disc geometry calculations incredibly simple.
To allow the system to be able to boot existing MFX SD cards and
to avoid breaking HEXTRAIN, the MFX CP/M 3 SD card structure was
kept the same as that used for CP/M 2.2. MFX firmware version
140124 added support for Bill's enhanced storage functions which
enabled the MFX to support usage of larger capacity SD cards,
allowing the extra storage space to be FAT formatted. The card
structure was made up of the
Master Boot Record, followed by 8 x 8MB partions, then
the HEXTRAIN data block, with the remaining card capacity able
to be FAT formatted.Only 4 of the 8MB partitions were visible to
CP/M at any one time, normally, partitions 18 to 1B were mapped
to drives B to E, but partitions 1C to 1F could be remapped to a
drive letter using the RECONFIG program. Normally, the 4 higher
8MB partitions were not actually used, leaving a 32MB block that
could be made available to CP/M 3. The syscopy.com
utility could be used to write a copy of the CP/M system tracks
to any of the available partitions, which, when mapped to drive
letters, were bootable.
Although the 8MB partitions supported up to 512 directory
entries, as CP/M does not support subdirectories, 512 files in
the root directory was not very user friendly and thought
unnecessary. We decided that the 32MB of space could be better
used by CP/M 3 if configured as a more, smaller, "disks" and
decided that 8 x 4MB partitions was more appropriate. By
defualt, CP/M 3 would have supported 256 directory entries, but
enabling timestamping for a "disk" uses one of the four
directory areas, reducing the number of directory entries to
192. A bit more restricive, but unlikely to be a problem.
With 8 x 4MB "disks", the online disk capacity is the same
as the 4 x 8MB "disks" avaialble in CP/M 2.2, albeit that the
number of available directory entires will be slightly less if
date/time stamping is used.
In Memotech's implementation
of CP/M 2.2, Drive A was always mapped to the boot drive. By
default, the system booted from drive B which was then mappted
to Drive A, although they appeared as different drive, the
contents of both drives were the same. For CP/M 3, there are 8
partitions of 4 meg each from A to H, with the system booting
off A. Drive C is intended to be the system backup, the other 6
partitions hand back 24k storage space by not having space
allocated for system tracks. A new utility,
nameme.com, is used to write a copy of the CP/M
3.1 system to the backup partition.
The CP/M 2.2 and CP/M 3 disk image areas are only visible to the
associated system version, there is no facility to directly
transfer files between the two. However, this isn't really a
problem as both systems can use FTP to transfer files via a host
PC. It is possible that fatcopy.com
could be modified in the future to achive the same thing locally
too (Bill?).
Hardware / Firmware Changes
Retaining support for the traditional CPM 2.2 on
the MTX requires a separate boot ROM for CPM3. Since MFX is
already using ROM pages 4,5 and 6, that meant re-programming the
GAL to open up ROM slot 3 as well. The MFX boot screen has been
given a make over and the colours changed to red on black to
match the MTX themed black PCB & red FPGA board used for the
most recent revisions of MFX. Other hardware changes are an RTC
fitted to to the old VRAM socket and changes to the FPGA to
provide acces to both the SPI clock and set up an off CPU memory
buffer to support the banked memory.
No one left behind
As noted
above, CP/M 3 is likely to be of most benefit to MFX users who
have a Real Tume Clock fitted, i.e., MFX boards with serial
numbers xx40 and above, where the VRAM socket can be repurposed to
allow the installation of an RTC module.
However, it is
possible for MFX owners with earlier PCBs to run CP/M 3, albeit,
without the benefit of the RTC. A "softload" version of the CP/M
3 system can be loaded by an
executeable program on the CP/M 2.2 system which invokes the
CP/M 3 BIOS and swaps to the associated disk partition. In this
case, a GAL replacement is not required as the system does not
need to boot from ROM 3. A replacement SD card loaded with the
CP/M 2.2 and 3.1 partitions is required, depending of the
firmware version of MFX, the card may be SD or SD/HC (firmware
versions below 167 only support SD media).
(Support for
SDX BASIC and games, including HEXTRAIN, are unchanged from the
original disk image.)
What it looks like
An updated
look for the MFX boot screen, red on black to match the
MTX themed black PCB & red FPGA board combination.
Reset options are now :-
< C >
for CP/M 2.2
< 3 > for CP/M 3.1
other options are unchanged from ROM version 167 |
 |
Hitting
<Ret> during the CP/M 3 boot process invokkes the
Monitor ROM. You need to be VERY quick if you
are to interrupt the boot process!
The
most useful function available from the Monitor ROM is
likely to be the ability to restore the system traccks
on "A" from the backup tracks stored in "C".
Option C
- not shown in this screenshot |
 |
The system
booted into CP/M 3.1
The CP/M 3 equivalent to the
DOS autoexec.bat command file is profile.sub. It can be
used to submit programs for execution when the system
starts. In this case, the file calls the SETDEF program
to configure the date to use UK format. |
 |
| The
default CP/M 3 directory listing is the same as CP/M
2.2, i.e., showing only the file and extension names,
four to a line. |
 |
A
screenshot from Martin's system.
With file
date/time stamps enabled, date and times that the files
were created and modified are available.
This
screen also shows that the number of available directory
entries is reduced from 256 to 192. |
 |
| CP/M 3.1
"softloaded" from CP/M 2.2 on an MFX running with a
Cyclone II FPGA and ROM version 140124 |
 |
Other
| Download |
Support Programs |
Version |
|
Source |
Object |
Build |
Date |
| n/a |
 |
go3.com - Softboot of CP/M 3.1 from
CP/M 2.2 system boot
Allows older MFX boards without
the EP4CE10 FPGA to run CP/M 3.
Requires an SD card
with CP/M 2 and CP/M 3 partitions loaded |
250126 |
26/01/25 |
| n/a |
|
go3.com - Release version |
250216 |
16/02/25 |
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
References
1. S100 Computers
website A useful
resource for generic CP/M programs and documentation
|
