MyDos 16MB ATR, how to extract/copy off files?

[1050]

Confirmed, the MyDOS.ATR in post #19 had the ramdisk

turned off so MyRD won't touch it or go there by design.

 

Not to be rude, but rtfm applies here and you will

have to H save DOS files to your boot drive if you

want to keep your new settings at all times in every

other type 2.0 DOS. Which is what MyDOS is. So

the same rules always apply. It is understandable

that these things get forgotten when they aren't

done daily, it's still required.

 

E474, Please boot that ATR posted.

press S and the number you want for a ramdisk.

press H and then one and then RETURN.

reboot. watch the magic.

 

Because you don't have a directory called

:RAMDISK

on D1: and it's not filled with files you want copied to

your ramdisk, the only thing you get in your ramdisk

once you have turned it on by giving it a drive number

is DUP.SYS.

 

Use Q Make Directory, enter

D1:RAMDISK

and copy wanted files into that directory.

 

Your BDCAP.ATR has the ramdisk turned on but it's set

as drive 9 and you won't notice it from the menu display.

But if you'll boot that image and press 9 you will see

DUP.SYS in your ramdisk just the same.

 

As near as I can tell, Hias didn't try 4.55 beta 4 with

dir2atr.

He did try 4.53 and states it does work. I think that's

as far as the testing goes. I see no reason it wouldn't

work as beta 4 is not that much different.

 

Tom's mistake was in using Marslett's 4.50 code before

Puff got it and put in several fixes including the one

for 16 meg partitions where bad sector counts were found

to be piling up. Tom may have been first to release it

too, I wasn't around or clued in at that time so can't

really say other than it's a possible reason for his

buggy version.

 

Only Sparta and MyDOS will do 16 meg partitions.

And dmsc reminds us that BW-DOS will do so as well.

DOS 2.5 ED is unique to itself and MyDOS ED is also.

Don't recall how Sparta does ED so a complete blank

there. If you are using Atari800Win, you can do copies

to from H1: etc., but best luck I've had is full file

spec on both sides of the copy. I avoid wildcards

since they seem to ruin it every time. I typically

don't do large files, so not much experience with that

side of large ATR images in the first place.

 

No flames, Marius, but I can't say I've ever had your

troubles here with several 16 meg drives on a black box.

Can't imagine your issues, but believe every word is

your experience. It's still buggy to be sure, but if

you'll stick to commonly done things it seems to work

fine for the most part here. Hardly ever a catastrophe.

 

Hi Mathy,

boy things did go sour in here huh?

[+Nezgar]

Hi,

 

I tried loading an ATR of SpartaDos 3.2g, but it doesn't work with sio2bsd (on a Raspberry Pi). I get:

 

Serial port: /dev/ttyAMA0

POKEY quartz 1781618.500000 Hz and HS Index 0 constant 7.186100 is assumed

Default speed: HSINDEX=40 (19200 bits/sec.)

Default turbo: HSINDEX=0 (123963 bits/sec.)

User selected: HSINDEX=0 (123963 bits/sec.)

[sNIP]

18 -> '?': $31, $3f, $0004 ($74)

 

SIO cmd $3F is the 'get high speed index' command. It also looks like your SIO emulator is advertizing pokey divisor index 0, which is way beyond the capabilities of the native UltraSpeed driver in SpartaDOS 3.2. I'd recommend configuring a divisor of 6 or lower in your sio2bsd for reliability.

[E474]

Hi,

 

Thanks very much for the advice.

 

I tried setting up a Ramdrive as described by Mathy, and it worked perfectly (thanks!). I don't recall doing all of these steps with MyDos 4.534, but I am not sure whether the MyDos 4.534 DOS.SYS/DUP.SYS had already been set up to use a Ramdrive, or if I just don't remember doing these steps.

 

I tried sio2bsd with a lower divisor (I had assumed that it would work as is), and managed to boot SpartaDos 3.2g with:

 

$ sio2bsd -b 2 Spartados\ 3.2g\ \[fte\].atr

 

Any higher value for -b didn't work, e.g. -b 3 stopped at the same point as not using -b at all.

 

I just tried to use the BW-DOS atr, and that works fine in an emulator, but it only boots the first 3 sectors on a stock 800XL with sio2bsd. I tried -b 1 (and higher values), but didn't have any luck.

 

Also, I just dug out a copy of RealDos 30, and that seems to work fine now (I have no idea why it didn't work before).

 

Now I have a SpartaDos that works with sio2bsd, I will see how the Ramdisk works. I remember using SpartaDos a lot BITD, but I seem to remember there where some problems with Happy/Lazer compatibility, which ended up trashing files/disks every so often. Are there any simple fixes for this situation? I think I used to boot up the Lazer/Doubler drive in US Doubler mode, but I only have this option on my Lazer/Doubler drives, not on my Happy (clone) drive. Could it also cause problems on my BitWriter drive?

 

I tried to get PCLINK.SYS to work with SpartaDos 3.2 a while back (copied to real disks as I couldn't get it to work with sio2bsd), but I couldn't get it to work - I think I will give it another go though, as maybe a lower divisor will help. I have a feeling that PCLINK.SYS doesn't work with Sparta 3.2, and I just looked on the RealDos ATR, and that doesn't have a copy, so I am not sure if PC-LINK could be made to work with RealDos either.

 

Does anyone have the sources to PCLINK.SYS, btw?

 

Thanks for all the help!

[+Nezgar]

PCLINK.SYS is only for SpartaDOS X 4.4+ (cartridge based). The file is part of the SpartaDOS X toolkit, available here: http://sdx.atari8.info/index.php?show=en_download_special

 

The RAMDisk driver that comes with ICD disk based SpartaDOS will only support a 256K ramdisk max (320K XE). I covered third party handlers that can be used to go up to 1MB earlier in this thread. Not sure if that changed with the last FTe releases of 3.2.

 

I believe there should be a ramdisk driver capable of 1MB inlcuded with RealDOS, but I might have only tried it once. It seemed to do funky character set glitching while in use, which john pickens hyper-speed ramdisk didn't -- and that one also works with RealDOS.

 

The only risk with Happy/Laser drives was writing to single density disks in ultraspeed mode, without first running some sort of utility to enable buffered writes on the happy drive to workaround the issue. Byte 3 of each written sector would be incorrect. This is resolved by enabling the 'ultraspeed emulation' using the happy utility disk, or with INDUS.SYS in spartaDOS X. Best to add Indus.SYS to your spartaDOS X config.sys to ensure any happy drives get the configuration set every time. The drive will be 'fixed' until it is next power cycled.

 

Most ultraspeed sector copiers (including MyCopyR) send the command to the drive automatically as it was a well known issue at the time. It was faster to have buffered writes anyway, so it would have been nice if it was the default, in retrospect...

[E474]

Hi,

 

Thanks very much for the detailed info, I don't have a SpartaDos cartridge, so am using 3.2G. I will try using indus.sys and see if that works on SpartaDos 3.2.

 

The RealDos ramdrive works with the Sys-Check 2 ram, but there are some glitches with the character set, so I will try the ramdrive you posted about (which is described in http://atariage.com/forums/topic/287691-ramdisk-driver-for-dos-25-and-sys-check-2-512k-ram/- I think this thread has jumped around a little.

 

I will try disassembling PC-link.sys, just to see what it is doing, but I have too many other projects to spend much time on it, unfortunately.

 

Thanks again for all the help, am out of town for the next week or so, so won't be able to do any testing in real hardware for a while.

[+Nezgar]

Thanks very much for the detailed info, I don't have a SpartaDos cartridge, so am using 3.2G. I will try using indus.sys and see if that works on SpartaDos 3.2.

Sorry to say!, INDUS.SYS is also SpartaDOS X only... your best way for now is just to use the Happy utility disk first before booting spartaDOS.

 

You will also be safe, if you use only Double Density disks... (but writes will be slower)

 

Another workaround is to use Hias' highspeed OS patch, he also added sending the fast buffered writes command if a happy drive is detected: http://www.horus.com/~hias/atari/#hipatch

 

There's a nice pre-built OS ROM image based on XL/XE rev 2 with this HSIO patch, reverse BASIC, and fast math pack as well. Then you can be assured it's done every coldstart:

http://atariage.com/forums/topic/206880-130xe-reverse-option-key-for-basic/?p=3944284 (It's also very nice having UltraSpeed with EVERY bootable disk!)

 

It could be simple to write a utility that sends only the 1 command too...

[Mathy]

Hello rdea6

 

You need to use the 'O' option to set ramdisk type and...

 

In most cases you do not need to use "O" for this, MyRD will auto-detect the size of your RAMdisk. This makes it easier to swap computers if not all of them have equal amounts of RAM.

 

Sincerely

 

Mathy

Edited February 11, 2019 by Mathy

[HiassofT]

MyDOS stores the ramdisk drive number in $070A, which is saved in the boot sectors when writing a DOS to disk.

 

In the MyDOS 4.53 source code (and in the MyDOS 4.53/4 DCM image from Mathy's site) the default number is 9, which gives you a ramdisk on D9:.

 

In the MyDOS 4.55 beta 4 source code (and DCM file from Mathy's site) the value was changed to 0 - which seems to mean "no ramdisk". No idea why that has been changed.

 

I've extracted the boot sectors which dir2atr uses to create bootable MyDOS images from the images on Mathy's site which means the current MyDOS 4.55 beta4 mode that I implemented in dir2atr last week has ramdisk support disabled by default.

 

I then also had a look at the 4.53/3 boot sectors, the image on Mathy's site has the ramdisk number set to 4, the boot sectors written out by dir2atr has it set to 8. Urgs.

 

This definitely needs a cleanup and fixing in dir2atr, and I'm inclined to change the default ramdisk number to 9 for all current MyDOS modes (4.53/3, 4.53/4 and 4.55 Beta4). I'm open to suggestions though, if there's a strong preference for using D8: instead I could use that as well. D9: looks like a better choice to me though as that allows D1:-D8: to be real disk drives and is the default in 4.53 source code.

 

so long,

 

Hias

[_The Doctor__]

MyDOS stores the ramdisk drive number in $070A, which is saved in the boot sectors when writing a DOS to disk.

 

In the MyDOS 4.53 source code (and in the MyDOS 4.53/4 DCM image from Mathy's site) the default number is 9, which gives you a ramdisk on D9:.

 

In the MyDOS 4.55 beta 4 source code (and DCM file from Mathy's site) the value was changed to 0 - which seems to mean "no ramdisk". No idea why that has been changed.

 

I've extracted the boot sectors which dir2atr uses to create bootable MyDOS images from the images on Mathy's site which means the current MyDOS 4.55 beta4 mode that I implemented in dir2atr last week has ramdisk support disabled by default.

 

I then also had a look at the 4.53/3 boot sectors, the image on Mathy's site has the ramdisk number set to 4, the boot sectors written out by dir2atr has it set to 8. Urgs.

 

This definitely needs a cleanup and fixing in dir2atr, and I'm inclined to change the default ramdisk number to 9 for all current MyDOS modes (4.53/3, 4.53/4 and 4.55 Beta4). I'm open to suggestions though, if there's a strong preference for using D8: instead I could use that as well. D9: looks like a better choice to me though as that allows D1:-D8: to be real disk drives and is the default in 4.53 source code.

 

so long,

 

Hias

correct, the ramdisk convention has always been either drive 9 or 8 for MyDos in almost any circle I've traveled in. Why it would be 4 sounds like an oops... I have enjoyed it as drive 9 since forever it seems, it keeps it out of the way. At one time I kept to 8 drive swap-able blocks of 16M drive partitions with either 384k or 256k ramdisk on D9:. Loved it! Very handy in pushing stuff around.

[HiassofT]

Yes, D4: looks like an oops. The puzzling thing though is why 4.55 beta4 defaults to 0 / ramdisk off. This seems odd.

 

so long,

 

Hias

[dmsc]

Hi!

 

I just tried to use the BW-DOS atr, and that works fine in an emulator, but it only boots the first 3 sectors on a stock 800XL with sio2bsd. I tried -b 1 (and higher values), but didn't have any luck.

So, there is a difference in the handling of 256 byte sector images between emulators and sio2bsd, I don't know which way is the correct. My "mkatr" tool generates images with all the data for sectors 1 to 3 and stores actual data in the first half of each sector. sio2bsd expects data in the first 768 bytes of the image instead

 

See attached ATR, I tested in real hardware with sio2bsd and works. Note that bwdos also has a ramdisk handler for memory expansions and a handler for fast-sio, all optional.

 

Have fun!

bwdos-16m-fix.zip

[E474]

Hi,

 

My vote would be for drive #9 as the default for the ramdisk (I think this is the default for the 130XE ramdisk in dos 2.5). Thanks for implementing MyDos 4.55 (beta 4) support in dir2atr!

 

8 X 16MB disk images is 128MB of storage, which is huge for an 8-bit system! Unfortunately sio2bsd only supports 4 drives (iirc), so I can only access 64MB.

[HiassofT]

Here are test versions of dir2atr with fixed MyDOS boot sectors (all three variants have now ramdisk on D9: and only D1: configured). A quick tests with MYRD2 on 4.55 Beta 4 worked fine

 

source code: http://www.horus.com/~hias/atari/atarisio/testing/atarisio-190211.tar.gz

win32 binaries: http://www.horus.com/~hias/atari/atarisio/testing/tools-win32-190211.zip

 

so long,

 

Hias

[HiassofT]

Unfortunately sio2bsd only supports 4 drives (iirc), so I can only access 64MB.

Use atariserver. It supports up to 8 drives and you're already building it from the AtariSIO source, together with dir2atr :-)

 

so long,

 

Hias

[+CharlieChaplin]

One can also use the (up to 1MB) Ramdisk driver of BW-DOS 1.30 with SpartaDOS 3.2x and 3.3x, as well as several other BW-DOS utilities (e.g. Menu.COM)...

[atarixle]

I have multiple MyDOS 16MB Volumes in use, either ATR-Images for emulator or SIO2xx use, or as a KMK-IDE2-Partition.

 

My 1MB RD is driven perfectly by the internal, auto-configured MyDOS-RD-Driver (as D9: ).

 

MyDOS can write only 720 Sectors onto DOS2.5-Disks, but it can read all files on DOS2.5-Disks with 1040 Sectors. So if you want to fill your 16MB drive, just copy them from any DOS2.5-Source.

Beware that MyDOS can only 64 files per directory, but you can creat theoreticly an infinite amount of sub-directories (only limited by the size of the volume).

 

COPYFNF.TUR (on my BOSS-X-Disk) is a Turbo-BASIC-Program that can copy files and folders from one MyDOS-Volume to another MyDOS-Volume (or another sub-directory) directly or using the RAM-Disk as a temporary buffer.

 

To get files of any size off the MyDOS-Drive (like from MyDOS to any other) you have to define what "any other" is. I always use an emulator's H: drive. As H: is a completely separate emulator-DOS (H: is not D:), it has nothing to do with MyDOS, SpartaDOS or DOS2.5. So it not always can handle MyDOS-subdirectories. Some emulators do not even translate filenames (you literary can use large filenames for H: disks on Atari800Win). Some H: devices (Altirra I think) also support sub-directories - but I never really tried that.

Edited February 11, 2019 by atarixle

[Alfred]

I was playing around with MyDos 4.53 in Altirra and I couldn't get H: to work, either to or form. MyDos always gives an error 165 on copying, but it will do a directory listing. So I had to use my IBM2AT copier, which did work.

 

Frankly, after all the years with SpartaDos, I found MyDos to be excruciating to use. The lack of the concept of current working directory is just crippling. The Q to see the D: default is helpful, but in no way compensates for lack of WD. I was also astounded to find I can't even run the Six Forks code because of course it trashes DUP.SYS during the binary load. We're getting a decent CLI DOS for at least 800's with Axlon cards, this is ridiculous.

[flashjazzcat]

If memory serves, MYDOS whitelists device names in the DUP menu, which would explain the 'H:' issue (someone correct me if I'm wrong).

 

Heartily agree with the comments on the working directory. It was also excruciating trying to create a file selector (in TLW) which works with this DOS, and the result is highly frustrating in operation when attempting to navigate hierarchies on multiple drives.

[+Stephen]

If memory serves, MYDOS whitelists device names in the DUP menu, which would explain the 'H:' issue (someone correct me if I'm wrong).

 

Heartily agree with the comments on the working directory. It was also excruciating trying to create a file selector (in TLW) which works with this DOS, and the result is highly frustrating in operation when attempting to navigate hierarchies on multiple drives.

Emphasis mine :

... do anything other than use a DOS 2.5 style disk with this DOS.

[+Nezgar]

Every day for years I remember this compelling plug for MyDos on the BobTerm loading splash screen. I always took it as a personal endorsement from Bob Puff himself.. but I have come across a post with a screenshot of the 1.21 splashscreen by DrVenkman that didn't have that bottom text, so maybe so maybe it was hacked in or out later? Although my first download of BobTerm was from CompuServe, which I would have thought was a pretty authoritative source.

 

It always intrigued me to think of a DOS 2 menu style DOS that supported subdirectories, but there was no way I was going to give up my CLI, timestamps, and "change directory" with harddisks with folders nested many levels deep after being exposed to SpartaDOS, especially SpartaDOS X...

[phaeron]

MyDOS has two issues with H: devices.

 

The first is that it uses a non-standard syntax for default directory listings and expects ** to be interpreted as *.*. This is not universally supported and results in no files listed on some H: handlers unless H:*.* is explicitly used.

 

The second is that it doesn't allow wildcard copies from devices other than D: If you try to copy from H:*.* to D2:, you get Error 165 because MyDOS opens H:*.* -- which works and opens the first available file -- and tries to copy it to a file called D2: -- which doesn't and gives Error 165.

[E474]

Hi,

 

I'm going to check out atariserver - it was on my to do list - and 8 * 16MB ATRs sounds like fun - I just need to build the interface cable with the logic level shifters, I'm using a first generation Raspberry Pi, so the GPIO pins are aren't the same for sio2bsd and atariserver.

 

I'll also give Hias's high-speed XL OS a go with the Sys-Check 2 card, I'm quite looking forward to trying it out.

 

Also will give BW-Dos a go, so far the list of DOSses that support a large 16MB disk are:

 

- MyDos

- RealDos

- SpartaDos 3.2(G?) upwards

- BW-Dos

 

I don't know if there are any others too, but I think you need a different file/disk structure for large files or disks, so probably this hasn't been implemented very often.

 

I also tried Atari Commander, this looks really good, though I can't remember how well it handled drive H:/H1: in the emulator. I didn't try Tom's Navigator as it sounded like it might have some bugs in it. I tried Professional Copy 2.0, but I couldn't find an English language toggle, and I was too lazy to write a cheat sheet via Google translate from Polish, which is a pity as the authors appear to have really gone to town on this program.

 

I will also have a play around with MyDos directory navigation and wildcards (thanks for the tip), ** is a bit non-standard, I wonder how it is handled in CIO/XIO assembler calls.

 

Presumably a device handler (HATABS style?) could be written to implement PC-link support, I was reading up on them in the Antic(?) 2 part article, but I am not sure where one would go in terms of memory location if it was going to be usable by dos/dup/basic, etc., though it does sound like it would be an interesting/useful project, and would give another way of extracting files from a large MyDos image.

 

I will have a look at writing some code that puts the happy into the correct mode to avoid the disk corruption bug, I have seen a web page with a long list of extra SIO codes, presumably it is in there somewhere.

 

Thanks for all the tips and advice!

[E474]

Hi,

 

Actually, checking my bookmarks, I have: http://atariage.com/forums/topic/87388-unhappy-mode-utility/and https://www.atarimax.com/jindroush.atari.org/asio.html

 

The closest to enabling buffered output looks like enable fast write, but I would have to check this, unless someone knows the correct Happy command with parameters?

[+Nezgar]

Hi,

 

Actually, checking my bookmarks, I have: http://atariage.com/forums/topic/87388-unhappy-mode-utility/and https://www.atarimax.com/jindroush.atari.org/asio.html

 

The closest to enabling buffered output looks like enable fast write, but I would have to check this, unless someone knows the correct Happy command with parameters?

Yes, enable fast write is the correct command.

 

You will hear the audible difference in write speed as well.

 

Edit: the exact command is $48 ("H" for Happy) with DAUX=$0020

 

There's a good discussion about it in the thread about the development of Hias's HSIO patch:

http://atariage.com/forums/topic/127837-highspeed-sio-patch-v110-released/?p=1543501

[_The Doctor__]

bitd mydos was a godsend for people who couldn't afford spartados, or spartados x.... it brought them into bigger storage and subdirectories and you can assign a working drive for directories or as d:... no it's not sparta but it was a stepping stone to sparta... it was great at the time... and I still use it for certain devices even today..