The MyDos Ramdisk?

[+Larry]

Has anyone ever seen a hack of the MyDos ramdisk (or replacement) that could put the ramdisk to a PBI drive? For instance, if using an MIO with an unexpanded 800XL, it would be very handy to make the ramdisk from the MIO's ram. It's not quite as fast as internal ram, but plenty fast and more convenient than using MEM.SAV on the HD.

 

-Larry

[Kylev]

Larry,

 

The MIO comes equiped with the ability to use its RAM for that purpose unrelated to what DOS you choose to use. I am guessing that this is not the real thrust of your question?

[+Larry]

Hi Kylev-

 

No, not quite. To me, the number one benefit of a ramdisk is the "automatic" switching between a cartridge/Basic and the DUP.SYS menu. In truth, the modern hard drive systems are so fast that using MEM.SAV is very fast and almost as convenient.

 

The modification would have to be to MyDos to be able to recognize the MIO's ram instead of expanded ram as it's ramdisk. I *think* it would be fairly easy, but probably beyond what I know how to do. OTOH, the MIO and MyDos have been around a long time, so if it were simple, then probably someone would have done it already. If nothing else, I'll look through the MyDos ramdisk source code and see if I get any ideas. If it's really well commented (unlikely), I might be able to figure something out.

 

-Larry

[flashjazzcat]

Surely the MIO RAMdisk operates at the OS SIO vector level (which non-PBI RAMdisks aren't able to do without a custom OS), so surely the best bet would simply be to put the MEM.SAV file on one of the PBI RAMdisk drives. I'm guessing here, though, since I don't have an MIO. I'm not seeing the need to modify the RAMdisk driver source code, though, unless I'm missing something. A PBI RAMdisk seems like a really elegant solution as it is. Modifying the MyDOS RAMdisk source code seems unnecessarily hacky to me, although I guess it would be possible. All depends whether the MIO RAM is only visible when the PBI device is switched in or not.

[1050]

In order to integrate a ramdisk with the least amount of effect on LOMEM, they only check if the drive number requested was the same as the Ramdisk as set up and then bypassed all SIO set ups and routines except for one half of a basic buffer pointer. Since SIO routines are never called in Ramdisk access, the MIO would never know you rang. This is also why MyDOS's own VTOC fixer program can not see a Ramdisk nor can it fix it, just as an aside.

 

So we be broken. And for all this time too. Bug number eleventy nine. Not even on the list.

 

It's been so long since I had a MIO hooked up, I can't remember exactly how it behaves with MyDOS, but IIRC Sparta can and does boot with the MIO ramdisk. MyDOS can't and won't.

 

MyDOS's MEM.SAV doesn't work in that manner FJC, the mere presence of a MEM.SAV file means nothing to MyDOS.

 

Larry, you might try ramdrive, I never have, but he talks it up pretty good.

http://www.angelfire...pino/atari.html

[flashjazzcat]

MyDOS's MEM.SAV doesn't work in that manner FJC, the mere presence of a MEM.SAV file means nothing to MyDOS.

 

Hmmm... I thought you could specify that MEM.SAV resided on a "regular" SIO drive, and that this could be a PBI RAMdisk. I certainly understand why the MyDOS RAMdisk driver wouldn't be able to see the MIO drive, just as you describe.

[+Larry]

Thanks for the info, 1050 and FJC!

 

I had thought of Ramdrive 1.0, and found the ARChive buried in my utilities. I remembered that Raphael had written about the flexibility of RD1 in his docs, so thought that might be a possibility. Thanks for the link! So he originally wrote it for (ZORK) and Dos 3? (!!!) That may be the only third-party software ever written to support Dos 3!

 

Anyway, I'll give it a try. Will certainly be easier than hacking RAMBOOT.M65!

 

-Larry

[1050]

Hmmm... I thought you could specify that MEM.SAV resided on a "regular" SIO drive, and that this could be a PBI RAMdisk. I certainly understand why the MyDOS RAMdisk driver wouldn't be able to see the MIO drive, just as you describe.

Let's say you did that and the MIO was visible, it still doesn't work in that manner. But this is exactly how 'other' AtariDOS type 2.0 MEM.SAV schemes work sure enough, but MyDOS only requires a flag be set and it will write/read a MEM.SAV file to/from the drive it's set to do that to (usually the same as the ramdisk, but it doesn't have to be). A pre-existing MEM.SAV file is not required either. When DUP.SYS is called for, a test for the flag which would still be set is done and the MEM.SAV file is written, only then is DUP.SYS loaded. Going back to BASIC, or M. Running at hex address, tests for the flag's state and then reads back into memory the MEM.SAV file before going to BASIC or running at the address input. N. Load MEM.SAV sets the flag and then loads the named machine language program just like L. Load Memory would do. L. Load Memory clears the MEM.SAV flag which allows a MEM.SAV file to retain it's contents, thru several program loads if needed. L. Load Memory is the only way to clear the flag and N. Load MEM.SAV is the only way to set it. Other than hacking it directly which is certainly possible. The flag is bit 7 of byte $07BE.

 

A bit more complex and flexible than the standard method of MEM.SAV use. Unique in function to MyDOS alone as well, the feature doesn't even work until you get to the beta releases, I'm thinking beta 3 finally got it working.

 

Larry, the ramdisk driver is NOT in RAMBOOT.M65, that is just the source code for the ramdisk.com file. It will need changing too, but that's not the driver code, that is in MyDOS code proper. Rapheal says in plain english that his ramdisk works with MyDOS 4.50 and yet it shouldn't for all the above reasons leaving me mightily perplexed. But anymore that's really nothing to brag about as it seems to be my normal state of affairs.

 

And just for an illustration of my last point, FJC - you should be exactly right after all. We make MEM.SAV live on the MIO ramdisk which is a different drive number than the MyDOS ramdisk and viola. Larry would have to use beta 3 and get his flag set correctly but after that, it should work gangbusters. Jeeze Louise, my first customer and I almost run him off.

 

Larry the locations to poke are $132B and $1338 for beta 3, you want to put the MIO's ramdisk drive number in those two locations. The first one is for the MEM.SAV file and the second one is for the DUP.SYS file, you want both to live on the MIO ramdisk, but all you need to start with is the DUP.SYS file on the MIO ramdisk. The number to poke there is $30 plus the drive number so for drive 6, you want to poke $36 in those two locations. And this can be done from BASIC with some number conversions done. 4907 and 4920 become the decimal locations to poke and 48 is the drive offset that you need to add your desired MIO drive number to and then you poke this number over there in those two places. Then peek 1982 and add 128 to the value at that location and poke it back. Unless it's already above 128 to begin with - there is no telling what state the flag will actually be in, but all you need to do is set bit 7 (which is any number over 128) and then you type in the letters DOS and go there, it should all happen like magic if you have a copy of DUP.SYS on the MIO ramdisk. In daily use you would want to build an autorun file to do this for you so you don't have to do it manually each time you boot up. And when you're ready to go to BASIC with MEM.SAV active after using L. Load Memory a few times, you press N. Load MEM.SAV and then RETURN with no file name entered and then B. Run Cartridge or M. Run at address.

 

And then Larry is correct too, this can be taken care of in RAMBOOT3.M65 although you really don't want to actually raise up that zombie and have it start walking around. It will eat your hardrive when you are not looking every time. Format D1: is built into that one.

 

FF FF 2B 13 2B 13 36 38

13 38 13 36 E2 02 E3 02

62 07

 

The above is your autorun file for setting the MIO ramdisk to be drive number 6. If you want a different drive number just change the values currently at $36 to be what ever drive number you want as instructed above. Address $0762 is a return instruction as per proper autorun file construction, it returns from the file INIT vector to DOS's control. All autorun.sys files should NEVER use the file RUN vector for those who don't know better - DOS doesn't like it. Don't forget to manually copy DUP.SYS to the MIO ramdisk. Doing that via an autorun file would be quite a bit more involved. Wish I could point you to source for a simple ramdisk.com file that could be made to do that, but I don't really know of any. I'll see if I can fix RAMBOOT3.M65 and post it here in a few days.

[flashjazzcat]

Let's say you did that and the MIO was visible, it still doesn't work in that manner. But this is exactly how 'other' AtariDOS type 2.0 MEM.SAV schemes work sure enough, but MyDOS only requires a flag be set and it will write/read a MEM.SAV file to/from the drive it's set to do that to (usually the same as the ramdisk, but it doesn't have to be).

 

Hmmm... so are you saying you CAN make MyDOS read and write MEM.SAV from/to a (RAM) drive on the MIO?

[+Larry]

Cool! I'll give this a try! Thanks for the info!

 

If you get the time to fix Ramboot3, that would be great, but looks like RAMcopy (Analog July, 1986, pp. 11-13) looks like it would fill the bill. (I haven't tried it yet, but will get all this checked out tomorrow.)

 

-Larry

[IndusGT]

Cool! I'll give this a try! Thanks for the info!

 

-Larry

 

let us know how it works, I no longer have an MIO but its RAM working seamlessly with MYDOS would make me reconsider getting one from MetalGuy

Edited July 26, 2013 by IndusGT

[+Larry]

Will do.

 

Another possible application is the extra SRAM on the MyIDE-II. Right now, you can set up a configurable D8: on the cart as a "ramdisk," but it currently exists, no MEM.SAV features on it.

 

-Larry

[1050]

Hmmm... so are you saying you CAN make MyDOS read and write MEM.SAV from/to a (RAM) drive on the MIO?

As long as MyDOS doesn't know it's a ramdisk by sharing the drive number for it's own ramdisk then YES, it should hollar out via SIO routines just like a real drive request/exchange there upon which the MIO drops in it's PBI rom SIO driver at $D1xx and takes over it's emulation of a real drive from there. That code works, so no problems there. You should be able to have yet another MyDOS ramdisk using the standard extended memory as well.

 

I would have solid tested answers usually but I have no Atari at the moment to try any of this stuff on. I'm wondering how I'm going to deliver on the fixed RAMBOOT3.M65 right about now too. I'll look at Ramcopy as well, but in the meantime here is that autorun file for making MyDOS beta 3 look for MEM.SAV and DUP.SYS at drive 6. Rename it to .AR0 or .AR1 extension if you have an AR0 file already.

 

MIO6.zip

 

It's a genuine zip file. If the drive number doesn't suit you just disk edit it until it does.

[+Larry]

I have not been able to get this to work with the MIO so far. Have sent info. and and APE boot log to 1050. It appears that MyDos cannot find DUP.SYS after executing the Autorun file.

 

Edit: With a little different procedure, I have been able to get the ramdisk working properly with the MyIDE-II SRAM. It appears to behave perfectly -- I can leave BASIC and go to Dos; then go back to BASIC and my program is still completely functional. Also, so far, it will not work using a 64K machine -- must have expanded ram.

 

-Larry

[+Larry]

Still working on this, and have run across several interesting features using MyDos 4.55 Beta 3 and the MIO 1.4.1 firmware. The MyDos ramdisk (RAMBOOT.SYS) and MEM.SAV to/from the ramdisk are completely functional using Omnimon XL. Since Omnimon XL is an 800 replacement OS, I was very surprised to see that it worked correctly. SELECT + RESET still pops you into Omnimon (but not into the MIO setup menu).

 

Does anyone else recall being able to use the expanded memory correctly when using Omnimon XL? (Perhaps I've just forgotten this feature?)

 

-Larry