• Please review our updated Terms and Rules here

Lo-Tech EMS as a RAM disk on 5160?

Chr$

Chr$

Experienced Member
Joined
Aug 13, 2021
Messages
159
Location
Saxony, Germany
I have a Lo-Tech 2mb EMS ISA card that I picked up for cheap and fixed (all the 4 RAM chips were shorted and pads had been ripped - perhaps a previous owner plugged it in the wrong way round). It works now and I have the LIM driver for it in my config.sys - it also passes the tests in the Lo-Tech EMS test program, but does only consist of 512kb as it only has one 512k RAM chip fitted.

I find it hard to get my head around the whole XMS, EMS, High memory etc etc! I'm a bit too young to have had to go through all that first hand. I've tried a few things with no success, perhaps it's not possible but I wondered if there was a way to get a standard IBM 5160 to recognise and use the EMS memory as a Ramdisk defined as drive D:?
 
Yeah there is, in fact with some creative software and a battery mod you could even make it persistent since the card uses all SRAM
 
What version of DOS are you running? Later versions of PC-DOS have a RAMDRIVE.SYS built-in that can use EMS memory
 
I have CF cards (and XUB) with either PC DOS 3.2 or MS DOS 6.22. I did try adding RAMDRIVE.SYS in CONFIG.SYS but that didn't work.
 
Is there any other program using EMS? Is the EMS driver installed before RAMDRIVE.SYS in CONFIG.SYS?

The RAMDRIVE command should look like DEVICE=RAMDRIVE.SYS 2048 512 128 /A
2048 is the size of the RAMDISK in KB unless planning on reserving some EMS for other applications or cache*, give it all to the RAMDISK
512 is the sector size in bytes. Maybe choose smaller sectors if the software to be placed in RAMDISK had very small files.
128 is the number of root entries. Make it slightly larger than the number of files planned to be placed in the RAMDISK
/A tells it to use expanded memory.

* Few DOS applications use EMS for anything and most of those that do only use about 512K. Cache doesn't provide much benefit since most CF cards are just so fast.
 
Last edited:
Per above, you will need to have the EMS driver loaded before ramdisk.sys. FWIW, if you’re going to just use the memory entirely for the disk I think you can use the “/3” switch for LTEMM.EXE; this will reduce its memory footprint by about a K.

Re: cache, on my Tandy 1000 with a V20 upgrade and a homemade memory expansion that’s compatible with the lo-tech EMS board I’ve actually benchmarked a RAMDISK.SYS RAM disk against my XT-CF (with an SD card adapter) and they are practically the same, IE, a modern flash card is almost as fast as RAM in an XT, factoring in file system overhead. So, yeah, cache is pretty pointless unless you have an original MFM hard disk.
 
That worked, thanks. I did use RAMDRIVE.SYS before to no avail, I must have had something set wrong. Unfortunately the MFM HDD is dead, but I have it plugged into power just for the closeness to authentic noise.

Even though pretty pointless, I'd love to add a battery to the EMS, just as a little project (the board is already bodged due to the damaged pads, so may as well bodge it some more).
 
Even if you battery back the SRAM. does ramdrive not initialize the drive each time it is loaded?
 
I suspect you’ll need to write, or at least patch, completely custom software. I think there *may* be RAMDISK software out there for conventional and XMS memory that’s able to survive a warm boot, but I’m willing to bet a nickel without looking that the EMS driver clobbers memory at startup when it counts up the RAM size.
 
EMS 4.0 allows setting handles as non-volatile to preserve data between reboots. But that's going to depend on both hardware and software support.
 
Just remember the Lo-Tech board is very much EMS 4.0 in name only. Its hardware capabilities are strictly 3.2 (IE, single set of page registers, no large page frames or conventional/UMB mapping outside the hardware defined page frame, etc.) I don't *know* if the driver clears memory when it counts it, it's possible it writes whatever byte was there back as it counts through the pages, but I certainly wouldn't count on it without verifying.

My Google-Fu is failing me at the moment, but I know someone who posts to this forum sometimes made a card a few years ago that was basically a superset of the Lo-Tech board except his design could take both RAM and ROM chips, and he'd been working on RAM/ROM drive software for it. (It's killing me I can't find it; his project documentation is what inspired me to add EMS to my homemade Tandy 1000EX/HX expansion board because it tipped me off to the fact that a pair of 74LS670 could perfectly substitute for the four 74LS573s used in the Lo-Tech, and thus take up a lot less board space.) It's possible he might have completed some stand-alone RAM drive software for the board that could be mildly patched to work with a plain lo-tech plus a battery.

EDIT: N/M, I found the link to the RAM/FLASH board, finally. I guess it looks like they he didn't really consider a "non-volatile RAM disk" use case. Here's the link to the Github repo that has the work on the ROM extension for the flash drive scenario, FWIW.

There are some very simple RAM disk drivers floating around out there. For instance, in the Oldskool Tandy 1000 archive there's a RAM disk driver that only occupies about 1/2K of memory that's designed to work with a rare/oddball 512K variant of their 1000EX/HX Plus memory expansion card that gave you 128K of upper memory between C000 and DFFF; the driver gives you a 128K RAM disk. If there is source for a similarly tiny driver it seems like it'd be very possible to rewrite it so it'd point to the physical EMS page frame and implemented paging by directly fiddling the registers, instead of relying on the EMS driver. But 8088 assembly isn't my bag so...
 
Last edited:
(blawblawblaw)

Regarding the idea of adding a battery, I guess one thing I would chuck out there is exactly *how* do you want to do that? It wouldn't exactly be kosher to just parallel a battery onto the VCC lines of the RAM chips; without some kind of power fail switching circuitry to isolate the RAMs when the lights go out the battery will then try to power the whole computer, probably with undesirable results.

A possible solution might be to use a DS1315 real time clock chip to handle the brownout detection/battery switchover. This chip specifically is designed to be able to do this, IE, convert a plain SRAM into an NVRAM in addition to providing the time functionality. The trick here is that this chip is designed to operate on a battery voltage of around 3v, not 5v, but that probably wouldn't be a deal breaker because the RAM chips specified for the Lo-Tech boards are capable of operating on anything from 2.7v to 5.5v supply current. You just would need to make sure that they don't draw more power than this chip can handle; looking at the datasheet for the two it looks like the maximum supported standby power for the DS1315 is 10uA, and the typical standby power for the ASC4008 is 4uA. So... maybe you'd be pushing it if you tried to power more than two chips?

(And of course you'd want to use a suitable backup source; I'd say probably want to use a set of AAs instead of the usual coin battery. Possibly 2 sets of AAs, since the chip supports two independent battery banks, it picks whichever one has higher voltage when it goes to standby.)

The fun thing about the idea of using the DS1315 is you'd get the timekeeping function for free; my *guess* is it might even work with the standard SmartWatch driver; it's usually expected that the chip is hanging off a ROM chip instead of RAM, but since the chip is activated solely through reads it would *probably* be fine to have it in front of RAM in this application. That said, there may be another standby power chip without the clock function that would work just as well.
 
FWIW, which it probably very little, I tried a dumb little test on my lo-tech compatible EMS card involving a BASIC program, and looks very much like loading the driver changes the contents of the EMS memory pages. So even if you can find a "standard" EMS ramdisk software that allows persistent drives (I couldn't find one in Google Round #1) it might not work on the Lo-tech EMS card/driver in particular.

(Not to mention I'm guessing EMS drivers that allow marking frames as "persistent" wouldn't survive a cold reboot anyway, unless they use page frame memory on the card to record their state.)

I could paste the BASIC code in here if anyone's interested, but all it does is use an OUT command to force-map a page of memory into the lowest slot the page frame, sets the SEG for peeks/pokes to the page frame, and then pokes a known value into 16K of RAM; then the second module does the same mapping and reads back what it sees. Long story short:

1: With a "standard" load of the driver it zeros the pages, complete loss of memory, on a soft reboot.

2: If I add the "/n" to skip the memory test the first two bytes of a page still get clobbered during the counting process, it doesn't write the contents back; skipping through it looks like they all end up with "00 00" in the first two positions.

Just for laughs, since I'd written this program already, I did perform a stupid test to see if the SRAM contents would survive a short power blip. (Some old SRAM chips were notorious about able to retain memory for *quite a while* with no power.) Apparently that doesn't apply to the ASC4008, it appeared to be pretty thoroughly randomized after just a 10 second-ish power-off. ;)
 
I never thought of making it non-persistent to be honest. The driver writes 55AAh then tests it back to each page, to count the pages available on intiialisation:

Code: 
        MOV    ax,chkchr
                mov     es:[0],ax
                cmp     es:[0],ax
                jne     imgch1
        xor    ax,ax
                mov     es:[0],ax
        CLC
        jmp    imgch3
imgch1:
        STC

It could be modified to non-destructively test (i.e., write back whatever was there before) but it would also need to preserve its working set (RAM used), I suppose one page, which would slow everything down as it would need to switch to that page on every call and I think complicate the code quite a lot.

@Chr$ glad you've sorted the board!
 
FWIW, I don’t think there’s anything wrong with how the EMS driver works; trying to save state through any reboot, let alone a *cold* one, seems like a pretty out there ask. I did see a reference to a RAMDisk software called ‘Jetdrive’ that *supposedly* supported warm-rebootable RAM disks on at least some hardware but I couldn’t track down anything more than mentions in a few PC Mag articles; it’s possible it drove the supported cards directly.

For the suggested use case here I would say it makes more sense to patch some RAMdisk software to drive the card directly and skip the EMS layer. The hardware is certainly simple enough.
 
You must log in or register to reply here.
Back
Top