Under the OS

[danwinslow]

So, I'm thinking about using the memory under the OS, but there's a lot I don't know about it.

 

1. I would be in an interrupt at the time, either a VB or a timer IRQ. Obviously, bad things could happen if another interrupt fires when the OS is not there. I'm thinking that won't happen, as (both?) are already protected from other interrupts, or at the least I could turn off other interrupts. Is that accurate?

 

2. Are there major DOS's that use that memory? What apps would I be blocking with a system driver that needs the OS RAM?

[Bryan]

The complexities of getting to and from RAM under the OS generally precludes its use for DOS. Video interrupts are completely deterministic so as long as IRQ's are disabled (sei), you can cleanly make the switch in an NMI routine. First thing you need to do is have a replacement set of 6502 vectors that point to something unless you plan on being back out before another NMI or IRQ can happen.

 

EDIT: Ah, sorry. Didn't know about the SpartDOS/RealDOS thing.

[flashjazzcat]

Disk-based SpartaDOS and RealDOS live under the OS, and SpartaDOS X is capable of doing so. As long as you have a set of machine vectors in RAM pointing to wrapper code which re-enables ROM when an interrupt fires, it's quite simple to keep mainline code under the OS. If you want your ISRs in the Shadow RAM, it'll be a tad more complex.

Edited January 21, 2015 by flashjazzcat

[Rybags]

There are Doses that use Ram under the OS, it becomes a case of make the user aware, then they have to make their own arrangements, e.g. use older 2.x or a SpartaDos setup that doesn't use that Ram.

 

Timer IRQ you'd be most vulnerable because they happen all over the place.

Really, the best solution might be just keep the OS switched out and handle all interrupts by yourself.

There's various methods where you can switch Rom back in and get the OS code to handle things but it can all get pretty complicated.

 

But bottom line - if it's a closed game/application environment, just disable every possible int source that doesn't have relevance and it makes things a whole lot simpler.

[danwinslow]

Ok, well, I was afraid of that. This is a resident system driver that needs to work with common DOS's, so I guess the OS RAM is out.

Thanks all!

[AGiambra]

I've done a lot of development in this area and acutally it works quite well. I just finished a program called RAMDIR that moves the 8 directory sectors from each mounted disk drive into the RAM under the OS. From then on, any time you access the drive, is accesses the directory from RAM instead of the drive, saving a lot of IO. Of course, if the directory gets updated, my program writes those sectors out so that the disk drive is always in sync. I have fully tested it and it works fine. I've posted the listing at the link below.

 

The trick to using RAM under the OS is to get in and out quickly. You can shut off interrups while you are processing so you don't have to worry about an interrupt breaking into your code. But you don't want to shut them off too lone, that's why you've got to be fast.

 

Hope this helps.

 

https://dl.dropboxusercontent.com/u/39633452/RAMDIR.TXT

[AGiambra]

Here's one I wrote that got published in the August 1986 issue of Analog magazine. If you have DOS XL, the external command such as COPY, INIT, DUPDSK are all files with a COM extension. So when you issue a COPY command, the OS has to first load COPY.COM into memory before the file actually gets copied. I'm an impatient person so I wrote RAMXL. It works like this. You choose the commands you use most often such as COPY, INIT, DUPSK. You rename the extension of each one from COM to MEM. When you boot your machine, my program looks for any files with the MEM extension. It loads them into the RAM beneath the OS and keeps them there. From then on, anytime you issue a COPY or INIT or DUPDSK command, the program retrieved them from the RAM under the OS, which is extremely fast, and then executes them.

 

To execute any file that has been copied into memory you type RUN 2300 COPY <fileA> <fileb> or you type RUN 2300 DUPDSK. My program resides at 2300 and protects itself from SYSTEM RESET so it is always there.

 

Here is the listing for that one:

 

https://dl.dropboxusercontent.com/u/39633452/RAMXL.TXT

 

 

[danwinslow]

Thanks! That's pretty cool stuff!.I probably can't actually use the OS RAM for other reasons, but it's very interesting reading.