There are many ways for Memotech MTXs to boot from disk :-
This program helps to provide a simpler alternative to the last case, by supporting the creation of a ROM Disc Image.
It is possible to create a CP/M boot ROM and SDX BASIC ROM that will read content from the ROM Disc Image. The idea is that you write
to a large (eg: 512KB) EEPROM, and install in a MTX ROM Card. Because this ROM Card can supply content in two ROM slots (ie: 4 and 5) the ROM Disc Image content can be available to both CP/M and SDX BASIC.
It is also possible to write only the CP/M boot ROM or the SDX BASIC ROM, followed by the ROM Disc image, and put this in a conventional ROM Card (ie: one that only supports a single ROM slot, typically slot 2 or 3). Its less likely you'd want to use one of the conventional ROM Cards though, as they typically only support 32KB or 128KB.
If the EEPROM was 512KB (eg: W27E040), and you subtracted 8KB for the CP/M boot ROM and 8KB for the SDX BASIC ROM, you might think the largest disk supportable is 512-8-8=496KB. However, the disk content is compressed before writing to the ROM Disc Image, so in fact, a variable amount of content, often larger than the uncompressed size, can usually be stored.
Therefore to cram in as much as possible, the approach should be
Use the largest ROM Disc Image produced by DISK2ROM that when combined with the CP/M boot ROM and/or SDX BASIC ROM, fits in the EEPROM.
Be sure that the resulting file fits in your EEPROM size. If you are testing in MEMU, be sure that you have configured the right number of subpages in your ROM slot(s).. If you get this wrong it won't work, and it won't be obvious why.
You can use cpmtools, CPMFUSE (Linux), CPMCBFS (Windows) or even MEMU to create and add files to CP/M disk images.
Back in the day, to support running Videowalls on systems without disks, I wrote code in the CP/M boot ROM that copies from ROM to RAM Disc. I wish I had written a ROM Disc driver instead, as this would have meant the MTX needn't have had any extra RAM. The actual MTXs used for controlling Videowalls were MTX System 2, and so had 256KB DRAMs supplying 208KB usable RAM, so it wasn't a huge issue at the time. Still, this way is better, especially when you add in the benefit of compression, and larger EEPROM sizes.
Imagine we have a CP/M boot ROM configured for type 03 using 56 column VDP mode, and a type 03 filesystem containing around 150KB of CP/M related content, that we hope will fit into a 128KB EEPROM :-
$ ./disk2rom cpmfiles.mfloppy-03 CPMFILES.RDI $ cat BOOT031.BIN CPMFILES.RDI > CPMFILES.ROM $ memu -n-subpages 2 16 -rom2 CPMFILES.ROM -s -v
Or, if we have a SDX BASIC ROM configured for type 03, a type 03 filesystem containing around 150KB of BASIC games content, that we hope will fit into a 128KB EEPROM :-
$ ./disk2rom games.mfloppy-03 GAMES.RDI $ cat SDX031.BIN GAMES.RDI > GAMES.ROM $ memu -n-subpages 2 16 -rom2 GAMES.ROM -s -v ROM 2 USER LOAD "GAME.BAS"
Or, if we have a CP/M boot ROM configured for type 03 using 56 column VDP mode, an SDX BASIC ROM configured for type 03, and a type 03 filesystem containing around 300KB of mixed CP/M and BASIC games content, that we hope will fit into two 128KB ROM slots :-
$ ./disk2rom mixed.mfloppy-03 MIXED.RDI $ cat BOOT032.BIN SDX032.BIN MIXED.RDI > MIXED.ROM $ memu -n-subpages 2 16 -n-subpages 3 16 -rompair2 MIXED.ROM -s -v DIR *.BAS MTXL ROM 3 USER LOAD "GAME.BAS"
The examples above assume the use of a recent MEMU that supports
-romX option to upload to multiple subpages
-rompair2 option to upload to multiple subpages
over two ROM slots
-mon-ignore-init,
so the examples above don't bother to supply it
When working with real hardware, it is more appropriate to use slots 4 and 5, as the CP/M boot ROM and the SDX BASIC ROM would normally sit in those slots.
In particular, if using the MTX ROM Card you'd be able to use 640KB type 07 filesystem with maybe as much as 600KB of content.
There is an example in this package of around 600KB of games, some CP/M, some BASIC, that you install into the dual-ROM card, or you can test using MEMU, by typing :-
make test2
Get the CP/M boot ROM package, and edit the EQUs in BOOTCONF.INC.
| To make | Set these to 1 |
|---|---|
| BOOT031.BIN | CRT56, ROMFDC, BOOTB03 |
| BOOT032.BIN | CRT56, ROMFDC, BOOTB03, ROMPAIR |
| BOOT071.BIN | CRT56, ROMFDC, BOOTB07 |
| BOOT072.BIN | CRT56, ROMFDC, BOOTB07, ROMPAIR |
You could set CRT80 rather than CRT56 if you had an 80-column card.
You could also set BOOTF5x if you had RAM Disc.
As this is a ROM Disc system, the STYPEx values should be set to R O X.
Get the SDX BASIC ROM package, and edit the EQUs in SDXCONF.INC.
| To make | Set these to 1 |
|---|---|
| SDX031.BIN | ROMFDC, DRVB03 |
| SDX032.BIN | ROMFDC, DRVB03, ROMPAIR |
| SDX071.BIN | ROMFDC, DRVB07 |
| SDX072.BIN | ROMFDC, DRVB07, ROMPAIR |
You could also set DRVF5x if you had RAM Disc.
The first two bytes of the ROM Disc Image are a magic number, and serve to align what follows so that no sector index block straddles the boundary between the first and second 8KB pages.
Consider a 640KB type 07 image. This has 640*1024/128 = 5120 sectors. So DISK2ROM writes out 5120 3 byte sector index blocks, each one containing the location of the sector data, as
Then the sectors are written, either as 128 uncompressed bytes, or as run-length encoded data. Run length compressed data is a sequence of runs or literals. Runs are stored as -count, repeated_byte. Literals are stored as +count, byte1, byte2, ... byteN. This is similar to the algorithm used in the ZMON Remote Command mode tool, when transferring data in compressed mode, and in fact the code was lifted from there.
No sector is allowed to straddle pages, so padding is applied to avoid this.
Finally, the output file is padded to the nearest 8KB page.
The code is smart enough to spot when the same sector appears more than once in the source filesystem image, and only writes the sector data once. Multiple sector index blocks can therefore refer to the same sector data. This is particularly handy, because most filesystem images will have many sectors with all 0x00's or all 0xe5's in them.
Finally of course, there is code in the ROM Disc drivers in the CP/M boot ROM and SDX BASIC ROM, which understands how to read (and decompress) this format of data.
DISK2ROM can be downloaded from
http://www.nyangau.org/disk2rom/disk2rom.zip.
Copying of this program is encouraged, as it is fully public domain. Even the source code is included in the package. It was created on the authors time and equipment. Caveat Emptor.
The author of DISK2ROM and this documentation is Andy Key
(email andy.z.key@googlemail.com).
{{{ Andy