MyDOS Ram-disk and High-speed ISO

[Madi]

I created a bootable directory on a partition (virtual hard disk) with MyDos v4.55 as using Ultimate 1MB under Altirra x64.

I liked the relative simplicity and easiness of MyDOS. I installed MYRAMD2.AR0 (ram disk) on the booting partition and loved it.

I tried to utilize the speed of the 1050 US-Doubler option using ULTRASPD which copies ROM to RAM and installs a high speed SIO. The problem is that, Basic gets disabled and ram disk is also gone ($D301) issue. In addition, the Altirra printer "P:" is disabled too.

My question, is there a way to keep the RAMDISK and also, maintain the high speed SIO at the same time by modifying ULTRASP or any other way?

Note: Both programs (as auto-run) work fine individually (not at the same time).

Thank you

Madi

Edit:: Type ..SIO not ISO

Edited August 18, 2014 by Madi

[1050]

Most problems occur when yet other software including OS code wants to use RAM under ROM where the US code is living, and no pat solution for that exists. MyDOS doesn't go there (under ROM) for that express pupose. If this is an emulator, why in the world are you even trying to use US? As far as I know, that only works with real floppy drives, so I'm slightly confused there as to the need and purpose of doing that.

 

A smaller emulated ramdisk may work? Any way to entirely disable SDX ROM with the Ultimate 1MB? Don't have one, and don't know how they even begin to work, just know SDX does go under ROM and might have conflicts with interloping US code trying to set up shop in the same area. Please post a link to the exact ULTRASPD code you are using so I might spot a trouble area within that code, TIA. I wrote MYRD2 if that's the one you are using, pretty sure it is since it does work so smooth, and the rarity of similar MyDOS ramdisk drivers that share that trait - so thanks for the compliment too, needless to say I really love it, it's my baby.

[Madi]

Thank you 1050 for your valuable input.

 

Quote:

"If this is an emulator, why in the world are you even trying to use US? As far as I know, that only works with real floppy drives, so I'm slightly confused there as to the need and purpose of doing that."

 

I am expecting the arrival of 2 Ultimate 1MB boards I have purchased for my 130XE and 800XL computers. I have 2 drives to go with them, one of which is equipped with US doubler.

So, I am testing the things virtually for the best setup and configurations, to be ready for the big event

 

Quote:

" Please post a link to the exact ULTRASPD code you are using so I might spot a trouble area within that code, TIA "

 

I got it from a zip attachment MyDOS_455_beta.zip from this post:

http://atariage.com/forums/topic/150341-ram-disk-in-mydos-4534/?do=findComment&comment=2079560

 

 

I noticed that MYRD2 doesn’t work similar to DOS 2.5 RamDisk (Running under Altirra x64, 320 Rambo Ramdisk and 130XE ROM).

 

Running MyDOS, one need to press RESET while in DOS menu to enter BASIC in order to keep the basic program intact in memory.

Pressing the “B” key from DOS to go to BASIC before Pressing RESET ends up in wiping out the basic program (applicable to entering DOS first time only).

 

Pressing “N” and copying any thing to any device D:, P: or S: (e.g. copy -> COCA.LST,S:) will copy the file to screen and activates the MEM.SAV and keep a copy of MEM.SAV in the RAMDISK. Actually, did not see any use of SHIFT key here.

 

 

On the contrary, MYRD2 works as intended using the same setup but with 800XL ROM, i.e. no RESET key is needed while in DOS menu to enter BASIC for the first time.

[1050]

Very good, a quite valid reason for emulator use too. Future testing - I like it, much eaiser with a monitor around to do some snooping too.

 

No telling how much an emulator is helping out with the BASIC situation but on a real machine MyDOS will choke and die when trying to go to BASIC if you didn't boot with BASIC on in the first place. Has something to do with zero page usage during boot up and the same locations used by MyDOS a bit later overwritting what was there that is needed for BASIC to be gotten to by the B option. If I knew what or even how it was broken, I'd try to fix it. Nothing I've tried in the past has worked at all. You'll have some real trouble here with a real machine. One can leave BASIC with a RESET press if you kill it properly first, but going back to it by the same method is always a crap shot in my experiance. Especially if you booted with BASIC off. Some emulators make this a non-issue somehow is the gist of what I'm trying to get at.

 

Ok, with 130XE OS try pressing N, then ESC, then B - any joy? An actual file copy is NOT requried to turn on MEM.SAV state, just the pressing of N does it, then escape or break out of the command entry and then go to BASIC via the B option. Reversed OPTION key function may be in play here which might complicate matters with the old 'no go to non-booted BASIC' bug inherent in MyDOS to begin with. And then with just this OS, the emulator may not feel like holding hands with MyDOS to help it along switching BASIC back on as well. Some do, some don't - but always on a real machine this will be a trouble spot in any event.

 

SHIFT key use may have been misrepresented in that post, don't have my real Atari set up for several years now and I forget exactly how to use SHIFT at boot up. But this is ONLY used to obtain a virgin zero wipe MEM.SAV file in the first place - no one has ever needed such a critter, I added the option just in case I might need it in the future. MyRD2 is supposed to look for BASIC rom or any other cartidge active and toggle MEM.SAV on by itself. That doesn't mean it stays active as it can be turned off by Loading a file with L option at any time. And again here - you don't even need to load or move the file, you can escape out or break out, it's only the L press that shuts off MEM.SAV state. So you'll have to be the one to be sure to develop a habit of turning on MEM.SAV when going back to BASIC by using N option first.

 

I can't remember the version number of this particular MyDOS but I'm thinking it's beta 3 with copyright and version info overwritten (tisk, tisk), so I'm suggesting you go to Mathy's site and get Beta 4 and the newer MyRD which fixes the large file load error pointed out in that post at the same time. Couple of other fixes in Beta 4 too and then we are all on the same page as well.

http://www.mathyvannisselroy.nl/mydos.htm

 

I'll work on the US program to see if there is an obvious conflict within it - might take some time, but a good US program that works with MyDOS is a quite popular request. We should have one that works. I'll come back after some disassembly and snooping around and post what I find out. Thanks for making MyDOS better - this is how it happens.

[phaeron]

Yeesh, lots of 30 year old issues coming to surface here....

 

ULTRASPD appears to intentionally turn off BASIC when it first runs. Not sure why it needs to. With Ultimate1MB, you wouldn't want to use a RAM OS patch like this -- you would flash a pre-patched OS image into one of the ROM slots. This avoids all of the problems that RAM patching usually incurs as no unusual PORTB states are required. With U1MB providing four OS slots, you can switch back to vanilla OS whenever needed.

 

Altirra's P: device goes away when a RAM-based OS is loaded, because it uses an emulation hook to intercept P: requests, and those hooks aren't enabled in RAM. I suppose I could switch P: over to using handler hooks instead of a CIOV hook, which should work with a RAM based OS. Obviously, this is an emulation-specific issue.

 

BASIC loses the current program when re-entered due to a bug in MyDOS: it doesn't set the WARMST flag like the Atari DUP.SYS menu does, so BASIC does a cold start. If you press RESET, then the OS itself will set WARMST, and then this problem won't occur. Of course, doing so will also yank out any RAM-based OS, and ULTRASPD appears not to install a hook to reinit itself.

 

[+CharlieChaplin]

Well,

 

if I remember correctly this ultraspeed driver (which also works under MyDOS) was written by Bob Woolley. The docs say that this driver does not work with any programs that change or access $D301 which the ramdisk driver does. My solution for MyDOS was quite simple: a) use the ramdisk driver first as *.AR0 and b) use the ultraspeed driver as *.AR1. After this My-DUP and most programs loaded with it work with ultraspeed.

 

Alas, if you want to copy a big program into the ramdisk while booting, you most likely have to live with standard/slow speed. MyDOS will copy any program(s) found in the subdir :Ramdisk to your ramdisk but I did not get this to work with the ultraspeed driver, think the internal MyDOS order is 1) install ramdisk-driver *.AR0, 2) copy all programs from :Ramdisk into the ramdisk and 3) install and use the ultraspeed driver *.AR1.

 

Looks like MyDOS 4.5x also has a bug concerning the *.ARx programs in conjunction with :Ramdisk. When I wanted to copy a 1MB animation into the ramdisk and then start TB XL (because the viewer for this animation was written in TB XL), I did the following: a) install the ramdisk driver as *.AR0, b) placed the animation in the subdir :RAMDISK which should then be copied into the ramdisk and c) load TB XL as *.AR1 (and since TB XL does not work with the ultraspeed driver, I did not use ultraspeed). When I booted the diskette, the ramdisk driver *.AR0 was installed and then TB XL as *.AR1 got loaded, but nothing was copied to the ramdisk (the subdir :Ramdisk simply was ignored). Tried this several times, and when I renamed TB XL into *.COM suddenly not only the ramdisk driver was loaded but also the animation was copied to ramdisk - but therefore I had to load TB XL manually then. Maybe MyDOS has problems when using several *.ARx programs and the :Ramdisk copy-option (but maybe its a bug of the ramdisk-driver MyRD2). One could maybe use the MyDOS batchfile-enhancement here (instead of the subdir :Ramdisk or instead of *.AR0 and *.AR1), but I have not tried this yet...

Edited August 20, 2014 by CharlieChaplin

[1050]

Don't know if it applies or not, but the rule of thumb for autorun programs is to never use RUN vectors. MyDOS is already using the RUN vector to load DUP.SYS when all the autorun files are done, if you overwrite the DUP.SYS RUN vector you don't get DUP.SYS when done autorunning. This is apparently inherited from DOS 2.0 behavior so should be a universal rule for type 2 DOSes as well. In the days prior to AR0 series loading, working the stack of appended autorun files into a single file that did what was wanted was an artform requiring a skill set above the norm, with AR0 available we tend to throw anything in the pile and hope for the best and it doesn't always work out like we hoped it would. End of the day, no RUN vectors for autorun files still applies. TB XL probably has both INIT and RUN vectors so a bit of imagination (and a tag bit of code) may be needed to get to where you want to be at.

 

Thanks Phaeron for the MyDOS bug report, will attempt a fix for WARMST flag when going to BASIC, was not aware of DOS 2.0 behavior in this area at all. What don't you know about Atari? Jeeze man, it's almost not fair. Any other MyDOS foibles come to mind please feel free to express them, anytime, anywhere. When you talk, I tend to listen...

 

And I'll take another look at MyRD to see if we can restore the prior state of port B to the exact state it was in before MyRD runs, this should allow US code to go first and MyRD to still work as it should, even with prior bit 0 use - I thought I had fixed this with BASIC state but didn't even think about prior bit 0 use at that time apparently. Thanks Andreas, you always bring something to think about.

 

To further complicate the issue of INIT and RUN vectors I have to rely only on my faulty memory here and relate an interesting tidbit I thought I had discovered long ago. The INIT vector is only attempted at the end of each full file sector loaded in, so if your autorun file has code after the INIT vector which is part of the next autorun attempt, this code for the second file may be lost depending on what happens when the INIT address is run. DOS 2.0 uses full sectors when appending files, but MyDOS concatenates files together to get rid of the 'wasted' space which may lead to exactly this lost or overwritten code situation itself. To build an old school autorun file stack properly even for use with MyDOS, one should be using DOS 2.0 so the appended file sector has this wasted space after the INIT vector and the next autorun file in the stack starts exactly at the beginning of the next sector in the file itself. IIRC again (take that seriously), MyDOS will also drop the double FF on a file header when appending files, never a simple deal with MyDOS.

[Madi]

The attached file is a slight modification to ULTRASPD.AR0(AUT) program which was written by Bob Woolley. It is now in XL/XE OS ROM batch.

 

The following changes were made to the OS ROM:

 

- The checksum routine had to be disabled by storing $EA into $C31D-$C31E (thank you bob1200xl)

 

- The address at C95B: 20 71 E9 JSR $E971

is altered to C95B: 20 00 CC JSR $CC00 (routine start).

 

- The routine uses 8 bytes of page 6 (0600 - 0607) to store temp drive index 1 to 8 . Any program (and there are so many of them ) that use page 6 will crash. hence, any suggestion of safe location is highly appreciated.

 

Issues noted:

If the word BYE is typed in basic, READY response is return only. No self test screen.

 

High speed is triggered with the use of the following Drives only:

- Happy (288 RBM, 52Kpbs high speed)

- Speedy 1050 (288 RBM, 56Kpbs high speed)

- US-Doubler (288 RBM, 52Kpbs high speed)

 

Note: the following mode returns "BOOT ERROR" message using the Ultra speed routine:

- Fastest possible ((288 RBM, 128Kpbs high speed)

 

 

** All tests were conducted using Altirra **

 

madi

ULTRASPD.ROM

[1050]

Starting at 480 thru 4FF it should be safe for the drive table and also all of page 5, I would use 480 since it's probably the least likely to have conflicts with any other code. Haven't done a thing yet but was going to see if Hias' US code could be inserted here which also works with the XF-551 and at phenomenal baud rates across the board.

 

http://www.horus.com/~hias/atari/#hipatch

[flashjazzcat]

I often use pages four, five and six for application buffers, and there's no reason to suppose they're reserved. There's really nowhere which won't conflict with something. Bottom of the stack is a risky possibility.

[Madi]

Thank you 1050 and flashjazzcat

 

Actually, I looked at Hias's codes. The Highspeed SIO patches use Page one, beginning of the stack area ($0108 - $0114). The codes are more comprehensive and versatile compared to Bob Woolley's code's. I will make the ROM patch based on Hais' code and try it.

In the meantime, I modified the Bob Woolley's ROM based code to use the locations ($0108 - $0107) of stack area for indexing drive D1 to D8 (ROM Attached). I only made few testing, but no conflicting was noted.

What really please me, is the support and guidance I get from you. I am learning every day new things about ATARI that I should have done 30 years ago .

madi

ULTRA-MOD.ROM

[phaeron]

Regions to definitely avoid:

• $0400-047F: Cassette buffer, but also used by boot routines. Can't be moved because several games require sectors to be loaded at $0400.
• $0580-05FF: Used by floating point library and BASIC.
• $0600-06FF: Everyone uses page 6, so forget about it.

Bottom of the stack is unfortunately used by some disk loaders... there's really no place to truly hide.

 

There's a fairly large chunk of space in page 2 that's normally used by the relocating loader and that might be reusable.

[1050]

Just to keep Madi on the straight and narrow, the top of the stack is 1FF and the bottom is 100, so you are pretty near the bottom and at some risk. As to my free space advice earlier, all the above coments are quite right as it could be a tangle just about anywhere - I was going by what Mapping the Atari had in it more or less and those words were written in a less complicated time. I completely overlooked Floating point use as well, so the back half of page 5 would be a guaranteed foul up. Looks like the only truely safe area would be a new reserved eight byte buffer within DOS.SYS itself. I will have to look into the possiblity of perhaps dual purposing an existing buffer as well.