myram

RAM Disk Driver for NitrOS-9 Level 2

Copyright (C) 2014 Maurice Gene Heskett

Overview

This page documents mram.dr, a RAM disk driver for NitrOS-9 Level 2 systems.

The driver was written to provide a more reliable RAM disk than some earlier options, while still remaining practical on both 6309 and 6809 systems. With additional conditional assembly work in xsm, the same source should be able to support either CPU.

Gene Heskett notes that the converted version grew by a few bytes, but performance remained very close to the original 6309-specific build. On his 6309 native system, megaread averaged about 10.5 seconds. On a plain 6809, the F$Move system call is not as optimized, so read times are expected to be at least twice as long.

Source Files

level2/modules/myram.asm
level2/modules/mr0.asm

Why This Driver Exists

Gene’s motivation for writing this driver was practical:

1. Formatting rammer was unreliable in his experience.
2. The only RAM driver he could make work consistently was the Developer’s Pack version after patching a couple of bugs.
3. The Developer’s Pack driver still made a good model for sizing the device through the descriptor’s sct value, which represents sectors per track. Since the RAM disk is a one-track device, changing sct changes the total disk size.
4. The older ram.dr had hard-coded values that made it unsafe or unreliable once the size got beyond about 504K.
5. The largest part of the work was a complete rewrite of the init routine.
6. The rewritten driver also solves the problem where the device could auto-initialize for one copy operation and then immediately de-initialize when the last path closed.

Design Notes

Device Sizing

The size of the RAM disk is controlled by the descriptor field sct, visible in a dmode report as sectors per track.

Because the device is treated as a one-track disk, this makes sizing simple:

• increase sct to grow the RAM disk
• decrease sct to reduce it

Gene reports that the rewritten driver works well with sct=1b00, which gives roughly a 1.7 MB RAM disk on a 2 MB machine.

He also mentions using sct=1000, which gives a 1,024 KB RAM disk when automatic initialization occurs.

Initialization and Residency

One subtle OS-9 behavior caused major trouble during development:

• OS-9 calls a device driver’s Init routine first
• a write or copy to /r0 can therefore appear to work
• if that operation was the only open link to the device, the link count falls back to zero when it ends
• OS-9 then calls Term, which de-initializes the RAM disk

That meant files copied to the RAM disk could disappear immediately after the copy finished.

To prevent that, the driver was changed so it can auto-initialize without automatically de-initializing as soon as the write path closes. At the same time, it still allows the RAM disk to be explicitly de-initialized later so the memory can be returned to the system pool.

Device Table Handling

Gene also describes a mechanism for locating the driver’s own entry in the device table and incrementing V$USRS so the device can remain resident once initialized.

The key complication is that the device table entry does not exist until the Init routine returns to OS-9. Because of that, the “stay resident” logic had to be split:

• one instruction sets a flag during initialization
• each later read or write checks that flag
• on the first such check, the driver locates its own device table entry and increments the link count
• the flag is then cleared so the extra work happens only once

After that, the added overhead is only the flag test.

Behavior and Limitations

Error Handling

Gene notes several important improvements over older RAM disk drivers:

• overflow or “device full” conditions return error #248
• attempts to use format /r0 return an illegal service request when format tries to recover device parameters
• the driver does not support getstt or setstt calls

Root Directory Allocation

One later tweak extended the initial root directory allocation by 8 sectors.

This was done because dcheck did not like the extended root directory created by loading very large numbers of small files onto the RAM disk. The allocation for sector zero, FAT, root FD, and root directory was increased to $10 sectors total.

Volume Name

If you run:

free /r0

the volume name appears as:

Gene's RamDisk

Performance Notes

Gene reports these rough megaread timings:

• /r0: about 10.5 seconds
• Maxtor 7120s hard drive: about 13 seconds

In both cases, he considers machine speed, especially F$Move, to be the limiting factor rather than the underlying storage medium.

Update Message

The earlier version did not attempt to set the creation date in sector zero information. Because of quirks in OS-9, the usual F$Time path did not return usable data in that context.

The newer version does set the creation date correctly, but the method requires the driver to be present in the os9boot file. Otherwise it may copy garbage into that portion of sector zero.

Gene also notes a later concern: changes in newer NitrOS-9 versions appeared to expand the device table format, which could break the older auto-linking logic. As a result, he revised the approach so it would be less dependent on the exact layout of the device table.

He also adjusted allocation mapping so that:

• systems with only 128K lose one fewer 256-byte page than before
• partial-block sizing cases behave more sensibly
• asking for sct=170 now causes the driver to acquire enough blocks to hold $180 sectors instead of truncating at $15F

The FAT still reflects the sct value you requested.

Closing Note

Gene closes by saying he hopes the driver is useful to the OS-9 community.

Cheers All, Gene Heskett, WDTV5@delphi.com

License

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, write to:

Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor
Boston, MA 02110-1301, USA