<HTML>
  <HEAD>
    <TITLE>Disk to ROM</TITLE>
    <LINK REL="stylesheet" TYPE="text/css" HREF="memotech.css" MEDIA="all">
  </HEAD>
  <BODY>

    <H1>Disk to ROM</H1>

<!--...sintro:4:-->
<P>There are many ways for Memotech MTXs to boot from disk :-
<UL>
  <LI>FDX
  <LI>SDX (original or later kind)
  <LI>SD Card (as in
      <A HREF="http://www.nyangau.org/rememotech/rememotech.htm">REMEMOTECH</A> or
      <A HREF="http://www.nyangau.org/rememorizer/rememorizer.htm">REMEMOrizer</A>)
  <LI>Compact Flash (CFX or MTXplus+)
  <LI>RAM Disc (pre-initialised from ROM content, as used on Videowalls)
</UL>

<P>This program helps to provide a simpler alternative to the last case,
by supporting the creation of a <B>ROM Disc Image</B>.

<P>It is possible to create a
<A HREF="http://www.nyangau.org/bootrom/bootrom.htm">CP/M boot ROM</A> and
<A HREF="http://www.nyangau.org/sdxrom/sdxrom.htm">SDX BASIC ROM</A>
that will read content from the ROM Disc Image.
The idea is that you write
<UL>
  <LI>a suitable CP/M boot ROM
  <LI>a suitable SDX BASIC ROM
  <LI>the ROM Disc image
</UL>
<P>to a large (eg: 512KB) EEPROM, and install in a
<A HREF="http://www.nyangau.org/romcard/romcard.htm">MTX ROM Card</A>.
Because this ROM Card can supply content in <B>two</B> ROM slots (ie: 4 and 5)
the ROM Disc Image content can be available to both CP/M and SDX BASIC.

<P>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.

<P>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 <B>compressed</B> 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.

<P>Therefore to cram in as much as possible, the approach should be
<OL>
  <LI>pick a supported
      <A HREF="http://www.nyangau.org/memotech/disktypes.htm">disk type</A>
      a bit bigger than the EPROM size
  <LI>make a CP/M disk image
  <LI>copy in some files
  <LI>run DISK2ROM to see how big the resulting ROM Disc Image is
  <LI>if space remains, and you have more files, go to 3
</OL>

<P>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.

<P><B>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).</B>.
If you get this wrong it won't work, and it won't be obvious why.

<P>You can use
<A HREF="http://www.moria.de/~michael/cpmtools/">cpmtools</A>,
<A HREF="http://www.nyangau.org/cpmfuse/cpmfuse.htm">CPMFUSE</A> (Linux),
<A HREF="http://www.nyangau.org/cpmcbfs/cpmcbfs.htm">CPMCBFS</A> (Windows) or even
<A HREF="http://www.nyangau.org/memu/memu.htm">MEMU</A>
to create and add files to CP/M disk images.

<P>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.
<!--...e-->
<!--...sExamples:4:-->
<H2>Examples</H2>

<P>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 :-
<PRE>
$ ./disk2rom cpmfiles.mfloppy-03 CPMFILES.RDI
$ cat BOOT031.BIN CPMFILES.RDI &gt; CPMFILES.ROM
$ memu -n-subpages 2 16 -rom2 CPMFILES.ROM -s -v</PRE>

<P>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 :-
<PRE>
$ ./disk2rom games.mfloppy-03 GAMES.RDI
$ cat SDX031.BIN GAMES.RDI &gt; GAMES.ROM
$ memu -n-subpages 2 16 -rom2 GAMES.ROM -s -v
ROM 2
USER LOAD "GAME.BAS"</PRE>

<P>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 :-
<PRE>
$ ./disk2rom mixed.mfloppy-03 MIXED.RDI
$ cat BOOT032.BIN SDX032.BIN MIXED.RDI &gt; 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"</PRE>

<P>The examples above assume the use of a recent MEMU that supports
<UL>
  <LI>user defined number of subpages in all ROM slots
  <LI>using <CODE>-romX</CODE> option to upload to multiple subpages
  <LI>the new <CODE>-rompair2</CODE> option to upload to multiple subpages
      over two ROM slots
  <LI>defaults to <CODE>-mon-ignore-init</CODE>,
      so the examples above don't bother to supply it
</UL>

<P>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.

<P>In particular, if using the
<A HREF="http://www.nyangau.org/romcard/romcard.htm">MTX ROM Card</A>
you'd be able to use 640KB type 07 filesystem with maybe as much as
600KB of content.

<P>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 :-
<PRE>
make test2</PRE>

<H3>Making suitable CP/M boot ROMs</H3>

<P>Get the
<A HREF="http://www.nyangau.org/bootrom/bootrom.htm">CP/M boot ROM</A>
package, and edit the EQUs in BOOTCONF.INC.
<P>
<TABLE>
<TR><TH>To make<TH>Set these to 1
<TR><TD>BOOT031.BIN<TD>CRT56, ROMFDC, BOOTB03
<TR><TD>BOOT032.BIN<TD>CRT56, ROMFDC, BOOTB03, ROMPAIR
<TR><TD>BOOT071.BIN<TD>CRT56, ROMFDC, BOOTB07
<TR><TD>BOOT072.BIN<TD>CRT56, ROMFDC, BOOTB07, ROMPAIR
</TABLE>

<P>You could set CRT80 rather than CRT56 if you had an 80-column card.

<P>You could also set BOOTF5x if you had RAM Disc.

<P>As this is a ROM Disc system, the STYPEx values should be set to R O X.

<H3>Making suitable SDX BASIC ROMs</H3>

<P>Get the 
<A HREF="http://www.nyangau.org/sdxrom/sdxrom.htm">SDX BASIC ROM</A>
package, and edit the EQUs in SDXCONF.INC.
<P>
<TABLE>
<TR><TH>To make<TH>Set these to 1
<TR><TD>SDX031.BIN<TD>ROMFDC, DRVB03
<TR><TD>SDX032.BIN<TD>ROMFDC, DRVB03, ROMPAIR
<TR><TD>SDX071.BIN<TD>ROMFDC, DRVB07
<TR><TD>SDX072.BIN<TD>ROMFDC, DRVB07, ROMPAIR
</TABLE>

<P>You could also set DRVF5x if you had RAM Disc.
<!--...e-->
<!--...sHow it works:4:-->
<H2>How it works</H2>

<P>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.

<P>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
<UL>
  <LI>the page number, plus 0x80 if the sector data is compressed
  <LI>the low byte of the offset into the page
  <Li>the high byte of the offset into the page
</UL>

<P>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
<A HREF="http://www.nyangau.org/remcmd/remcmd.htm">ZMON Remote Command mode tool</A>,
when transferring data in compressed mode,
and in fact the code was lifted from there.

<P>No sector is allowed to straddle pages,
so padding is applied to avoid this.

<P>Finally, the output file is padded to the nearest 8KB page.

<P>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.

<P>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.
<!--...e-->
<!--...sDownload:4:-->
<H2>Download</H2>

<P>DISK2ROM can be downloaded from 
<A HREF="http://www.nyangau.org/disk2rom/disk2rom.zip">
   <CODE>http://www.nyangau.org/disk2rom/disk2rom.zip</CODE></A>.

<P>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.

<P>The author of DISK2ROM and this documentation is <B>Andy Key</B>
(email <CODE>andy.z.key@googlemail.com</CODE>).

<P>{{{ Andy
<!--...e-->

  </BODY>
</HTML>
