MyPicoDos 4.05 released

[HiassofT]

After some 3 years I thought it's time for a new official MyPicoDos release, V4.05

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

 

Changes since the last version (V4.04):

 

Updated highspeed SIO code to V1.30, supporting up to 126 kBit/sec

Highspeed SIO can be activated while booting MyPicoDos, reducing total boot time

New PicoBoot boot-sector only COM loader

Special SDrive versions with autoswitch to 110 or 126 kBit/sec

 

so long,

 

Hias

[spookt]

Excellent, thanks Hias!

[Roydea6]

Thanks!! I have installed in my Game atr's. I prefer the file version so if I am using the Emulator I load the 'N' version and 's' version for my Sdrive and real atari..

[+therealbountybob]

Hi Hias,

 

I use v4.04 and the barebones version on my standard 1050... will the new version do anything extra for me

 

How do I use the new single file boot version

 

There are several games that I cannot get to run e.g. Highway Duel

(also Balloon, BetaFighter, BetaRun, Hammurabi, Ms Bullimia, Slingshot, Zuzel)

Is there a reason for this or a way of patching these files - anything I can try (let me know if you want a disk posting to look at )

 

When I mentioned a myPicoDOS menu with the OS/A emulator built in, to save double rebooting - I was thinking you could make an additional version of your program

[HiassofT]

Hi!

 

I use v4.04 and the barebones version on my standard 1050... will the new version do anything extra for me

If you are only using a stock drive you can stick to 4.04 barebone.

 

How do I use the new single file boot version

Run the picoboot initializer to init a disk, just like you'd do with the MyPicoDos initializer. Then the boot sectors contain code that loads the very first file on the disk (you won't see any picodos.sys file or so). It's best if you start with a freshly formatted disk, so that you can be sure the file you copy to it will be placed in the very first directory entry.

 

BTW: it doesn't matter if you copy the file to the disk before you run picoboot init or after it - the picoboot code checks the very first directory entry.

 

When booting the disk, be sure to press option as the picoboot code doesn't disable basic (like MyPicoDos does automatically for you when you load a COM file).

 

There are several games that I cannot get to run e.g. Highway Duel

(also Balloon, BetaFighter, BetaRun, Hammurabi, Ms Bullimia, Slingshot, Zuzel)

Is there a reason for this or a way of patching these files - anything I can try (let me know if you want a disk posting to look at )

Just had a look at Highway Duel, it collides with MyPicoDos. MyPicoDos needs RAM up to $092A, but the 4th COM block of Highway Duel starts at $0900 so it overwrites the COM loader of MyPicoDos - crash.

 

Haven't checked the other games yet, but I suspect the don't work for similar reasons (BTW: you can easily check the COM blocks with my "ataricom" program on your PC).

 

These issues can (sometimes) be fixed by running the COM file through a packer/compressor. The resulting, packed, COM file then can use for example $1000-$BFFF and the decompressing code moves the data to the correct memory locations.

 

As for several of the new games, here comes a short rant: unfortunately some programmers only seem to check if their software works with the builtin COM loader of the emulators. I've seen programs with COM blocks starting somewhere in the stack space or even zero page. Such programs will never work with any DOS or other COM loaded on a real Atari. But this is actually the fault of the programmers, even if they only have emulators it would be quite easy to check if they can load a DOS (or gamedos or whatever) in the emulator and start their software with this DOS - not the builtin COM loader of the emulator.

 

When I mentioned a myPicoDOS menu with the OS/A emulator built in, to save double rebooting - I was thinking you could make an additional version of your program

I thought about this a little bit but I'm still not convinced it's a good idea. Sure, it should be doable, but it means a lot of work and also quite large loading times for the few cases where it's actually needed.

 

Better install a switchable OS ROM in your Atari (you just need a 27256 EPROM and a switch) and you can switch between OS/A and XL OS within a second. I did this mod some 20 years ago and never used any of the "translator disks" since then :-)

 

so long,

 

Hias

[pps]

Hello Hias,

 

don´t know, if you read it in the NYD 2011 thread, but we discovered strange things using myPicoDOS and Altirra emulator.

 

As you have added emulator detection, it might be an issue of your code.

 

Starting the myPicoDOS with highspeed auto detection evering goes right at ATARI 800 win+ -> Highspeed stays off and you get that speed you choosed in emulation settings. Starting the same atr with Altirra emulator you get a very long loading, as the Highspeed seems to set on by myPicoDOS.

 

Maybe Altirra behaves in many things as a real machine, so your test fails? Maybe phaeron has a bug in his emulator - I don´t know.

[phaeron]

I had some trouble following the MyPicoDos source, but I suspect it's a bit of both. Altirra doesn't rigidly check SIO transfer rates, so if the disk routine is attempting a high speed transfer and checking whether it succeeds, that might explain that misdetection issue. It wouldn't explain the similar issue Rybags saw with AspeQt, though, because in that case the communication with the PC isn't going to work unless the PC side switches the baud rate to match.

[HiassofT]

First of all thanks for the feedback!

 

I'm currently not at home, so I can't do any tests, but I'll try to explain what's happening:

 

Due to the missing speed-checks in emulators the emulated drive is mis-detected as a 1050 Turbo. The 1050 Turbo protocol transmits the command frame in standard speed, if bit 7 of DAUX2 is set it switches to 70kbit (divisor 6) after transmitting the command frame (before receiving the command ACK/NAK).

 

The 1050 Turbo check sends a Get Status ($53) command in 1050 Turbo mode, on real Ataris this fails, as the Atari is configured to 70kbit when waiting for the command ACK but standard drives (except the 1050 Turbo) transmit the ACK (and the data frame) in 19kbit. Since the emulators don't check the baudrate, the transmission succeeds and the highspeed SIO code uses 1050 Turbo mode.

 

This is why you are seeing >$8000 sectors in the emulator.

 

Next thing is the highspeed SIO code:

 

If there was a transmission error (i.e. a framing error or checksum mismatch) it falls back to standard speed. If there was any other error (i.e. a command NAK or a device error) it stays at highspeed.

 

Since accessing a >$8000 sector should result in a command NAK (wrong sector number), at least for images with <$8000 sectors, the highspeed code doesn't switch speeds and stays at (1050 Turbo) highspeed.

 

This is where the new code of MyPicoDos kicks in (it's not really an emulator detection code, but more or less just a disable-highspeed check). Actually there are two different parts:

 

First one is when highspeed is enabled during booting: in this case a single transmission error disables highspeed SIO. So this should be safe (at least on <$8000 sector images).

 

Second one is in the MyPicoDos menu: If it encounters a SIO error, the SIO is retried at standard speed. If the latter succeeds highspeed SIO is disabled. If the SIO call at standard speed also fails, it stays at highspeed SIO.

 

So, unless there's some bug in my code, I suspect the highspeed code might do a fallback to standard speed after a failed highspeed transfer (which then succeeds) and thus highspeed doesn't get disabled and every sector is first read in highspeed (failing) and then again in standard speed (succeeding).

 

The AspeQt issue seems to be another thing. I successfully tested my highspeed code with AspeQt some time ago, but I'll re-check it when I'm back home this weekend.

 

@Rybags: could you please send me some more information about your setup (OS and AspeQt version, standard or USB serial adapter, pokey divisor settings etc...)?

 

so long,

 

Hias

[Rybags]

WinXP SP2, selfmade APE over RS232.

 

Aspeqt set to 3x max speed, version number looks to be 0.5.1

[HiassofT]

Scrub what I wrote about the auto-fallback, actually the following is happening:

 

The highspeed code always falls back to standard SIO (for the second retry), except when the device sent an "error" instead of a "complete". So the code in MyPicoDos to disable highspeed SIO is practically useless.

 

It's pure coincidence it works with Atari800 (+Win), because of a SIO bug in Atari800(win): When accessing the non-existent sectors >$8000 it responds with a command ACK followed by an error plus a data frame. So the highspeed code stays at highspeed, retries the same command again - also resulting in an error - and MyPicoDos completely disables highspeed SIO.

 

So I guess this is the best I can do until the emulators properly check the SIO speed settings :-(

 

At least the image boots fine both with Atari800 (falling back to standard speed) and Altirra (with the nasty "farts" though).

 

BTW: Atari++ isn't affected by this issue, it implements the $3F (get speed byte) command and so the highspeed SIO code detects the emulator to be an ultra speed capable drive - which is identical to standard SIO except for the higher baudrate.

 

I'll have a look at the AspeQt issue Rybags reported later.

 

so long,

 

Hias

[phaeron]

I modified Altirra to check the receive baud rate and I've been able to get MyPicoDos 4.05 to run in XF551 high speed mode. I think I'm going to need to put in a drive emulation level selector -- it's a bit uncomfortable emulating a feature set that doesn't actually correspond to any physically shipped drive, and I'd like to fix that.

[HiassofT]

I modified Altirra to check the receive baud rate and I've been able to get MyPicoDos 4.05 to run in XF551 high speed mode.

This is great news, thanks a lot!

 

I think I'm going to need to put in a drive emulation level selector -- it's a bit uncomfortable emulating a feature set that doesn't actually correspond to any physically shipped drive, and I'd like to fix that.

Good idea, I guess this could be quite useful when it comes to emulating copy protected images (i.e. be sure to stay at 19200 to not mess up timing, only support the stock 1050 commands).

 

so long,

 

Hias

[HiassofT]

Hi!

 

I got that too... and using Aspeqt to boot on real machine you could hear lots of retries and bad commands going on.

 

I think it has something to do with the loader and switching to high speed SIO - it must send out some commands and/or AUX values that are specific to some custom device. Seems that it doesn't give up too easily, usually a piece of software will put that trick away once it fails the first time.

WinXP SP2, selfmade APE over RS232.

 

Aspeqt set to 3x max speed, version number looks to be 0.5.1

I just booted into WinXP (SP3) but I couldn't reproduce your issues.

 

I tried AspeQt versions 0.5.1 and 0.6, both work fine with my serial cards (a cheap moschip9835 based one and a 16C950 card). With the 16C950 card even pokey divisor 0 works fine.

 

I suspect you could be suffering from some transmission errors which trigger the temporary fallback to standard SIO speed. Do you have any other devices connected to your SIO chain?

 

BTW: please run the 'diag-ext.atr' diagnostic program from my highspeed SIO patch with a DD image attached as D2:. This should clear up what's happening.

 

so long,

 

Hias

[Rybags]

Looks like my PC-side Serial hardware doesn't want to work with any custom Pokey Divisors.

 

Just tried NYD2011 Disk 1 with highspeed @ 3x and it works fine.

[HiassofT]

Looks like my PC-side Serial hardware doesn't want to work with any custom Pokey Divisors.

This is very likely, unless you have a 16C950 or similar card or use an FTDI based usb dongle.

 

If you use the custom pokey divisor in AspeQt it calculates the baudrate by using the formula

baud = 1781610.0 / (2*(divisor+7))

(note that the base-frequency was choosen to be half-way between PAL and NTSC rate).

 

So for divisor 8 you get 1781610/30 = 59387 bit/sec.

 

Now it's up to the windows driver to decide what to do with this value (it may either round up/down to the next supported baudrate or maybe even just return an error).

 

If you use the fixed 1x/2x/3x settings AspeQt sets the baudrate to the standard 19200/38400/57600 bit/sec supported by all ports.

 

Just tried NYD2011 Disk 1 with highspeed @ 3x and it works fine.

Great, thanks for the info!

 

so long,

 

Hias

[atari8warez]

Hias

 

Hias, does MyPicoDos 4.05 follow AtariDOS boot scheme (i.e. Read the first 3 sectors on the disk, and use DFLINK ($70F-$710) to determine the 1st sector of PICODOS.SYS) or is PICODOS.SYS read starting from sector 4 regardless (i.e hard coded)?

 

I need to know how exactly the disk is booted to add MyPicoDOS support to AspeQt Folder Image boooting.

 

Thanks

Ray

Edited January 21, 2013 by atari8warez

[HiassofT]

Hias, does MyPicoDos 4.05 follow AtariDOS boot scheme (i.e. Read the first 3 sectors on the disk, and use DFLINK ($70F-$710) to determine the 1st sector of PICODOS.SYS) or is PICODOS.SYS read starting from sector 4 regardless (i.e hard coded)?

MyPicoDos uses several bytes in the first boot sector for this purpose. The bootcode is loaded to $1000, here are the offsets in the bootsector:

$9, $a: starting sector of picoboot.sys (lo, hi)

$b: offset to sector chaining/data len in data sectors, $7d for SD and $fd for DD sectors

$c: high sector mask: $03 for standard DOS2.x disks (up to 1024 sectors), $ff for MyDOS disks with 16-bit sector chaining

$d, $e: sector length (lo, hi), $0080 for SD and $0100 for DD

 

The highspeed capable versions of MyPicoDos have an additional flag to control highspeed:

 

$f: 0: highspeed disabled, 1: highspeed enabled after boot, $81: highspeed enabled during boot

 

Please note that the different MyPicoDos versions (standard, barebone, sdrive, remote console) have both different boot sectors AND picodos.sys - the boot sectors must match the picodos.sys.

 

In AtariSIO I use a different approach to make virtual images bootable with MyPicoDos:

 

I store a simple loader in the bootsectors only, which first loads the highspeed code from AtariSIO and then loads MyPicoDos via a special "m" ($6d) command and then starts MyPicoDos. $6d works similar to $52, the data returned is a single density boot image of MyPicoDos.

 

Have a look at the AtariSIO source code, esp. tools/6502/bootloader.src for the bootcode, the MyPicoDos blob can be assembled with "make atarisio-mypdos.bin" from the MyPicoDos source (this bin file is also present in the AtariSIO source).

 

so long,

 

Hias

[+CharlieChaplin]

Alright,

 

here is another strange thing - probably a bug of MakeATR, but has to do with MypicoDOS (tested with 4.04 and 4.05 barebone):

 

- whenever I use MakeATR 0.6 to create a big HD image (1MB up to 16MB) in MyDOS format and format it, then (leave MakeATR and) boot MyDOS and use option "H" to write DOS onto that image, it works without any errors. Next, I can use MakeATR again to put as many *.XEX/*.COM files onto this image as there is space... no problems.

 

- whenever I do the same with MakeATR 0.6 and create a big image (1Mb up to 16MB) in MyDOS format and format it, then (leave MakeATR and) boot MypicoDOS 4.05 and write the barebone version onto the big image, this works. But when MypicoDOS has been initialized (Picodos.SYS has been created on the image) then I cannot use MakeATR anymore to put *.XEX/*.COM files onto this image. MakeATR suddenly reports an error: "unknown DOS format, couldn`t continue"...?!?

 

Why does MakeATR still work correct after initializing a DOS (MyDOS 4.5x, DOS.SYS and DUP.SYS) onto the 16MB image - and why doesn it NOT work anymore after I initialize Mypicodos (Picodos.SYS) onto the 16MB image ?!? Afaik, DOS uses the 3 boot sectors + some more sectors for DOS.SYS and err, Mypicodos (Picodos.SYS) - doesn`t it also use the 3 boot sectors + some more sectors for Picodos.SYS ?!? Or does MypicoDOS also store some data in the DIR sectors, like some older gamedos versions do...?!?

 

Tested this also with smaller images (90k, 130k, 180k) and whenever I write DOS or MypicoDOS onto these images, MakeATR then works without any problems. So, it seems only the big images do have this bug... (as said before, most likely a bug of MakeATR but only in conjunction with MypicoDOS)...

 

 

Greetings, Andreas Koch.

 

P.S.: Attached a 16MB MyDOS ATR image with Mypicodos barebone on it - MakeATR cannot open this image anymore. The same 16MB MyDOS image with MyDOS on it can be opened with MakeATR without problems...

makeatr06.zip

makeatr_test_16mb.zip

Edited January 21, 2013 by CharlieChaplin

[Roydea6]

http://www.atarimax.com/flashcart/forum/viewtopic.php?p=3878#p3878

 

You should use DIR2ATR to make your 16mb Atrs, and only add the mypicodos.sys after partition finallized..

or leave pico.sys off the Atr and AUTORUN mypdosx.AR0..

x=version of mypdos used..

[atari8warez]

MyPicoDos uses several bytes in the first boot sector for this purpose. The bootcode is loaded to $1000, here are the offsets in the bootsector:

$9, $a: starting sector of picoboot.sys (lo, hi)

$b: offset to sector chaining/data len in data sectors, $7d for SD and $fd for DD sectors

 

 

That's what i needed to know, thank you. I am planning to support one version (preferably high-speed) for AspeQt Folder Image booting.

Edited January 22, 2013 by atari8warez

[atari8warez]

MyPicoDos uses several bytes in the first boot sector for this purpose. The bootcode is loaded to $1000, here are the offsets in the bootsector:

$9, $a: starting sector of picoboot.sys (lo, hi)

$b: offset to sector chaining/data len in data sectors, $7d for SD and $fd for DD sectors

$c: high sector mask: $03 for standard DOS2.x disks (up to 1024 sectors), $ff for MyDOS disks with 16-bit sector chaining

$d, $e: sector length (lo, hi), $0080 for SD and $0100 for DD

 

 

Hias

 

Hias, the readme.txt file says "MyPicoDos uses a XF551 compatible way to determine the disk density: First it reads sector 4 (this is required by the XF551), and then it uses the "get status command" to see whether the disk is single or double density."

 

I created a standard, high-speed at boot type atr image for testing and here's the boot log of that atr from AspeQt:

 

As you can see below, first GET STATUS is issued, then boot sectors (1-3) are read, then sector 4 was read once (i believe that's for XF551 compatibility) and then sector 4 was read once again as the first sector of picodos.sys, then the rest of the sectors for picodos.sys where read. Note that a GET STATUS was not issued after sector 4 was read. However if you look at the end of the log you will see that happening after the entire picodos.sys file is read.

 

In any case my question is what's special about sector 4? ( I have never used a XF551) what does mypicodos read from that sector? or is sector 4 was chosen simply because it's the first data sector? (which just happens to be also the first sector of picodos.sys file on the .atr image i created with the initializer)

 

 

[Disk 1] Get status.
[Disk 1] Read sector 1 (128 bytes).
[Disk 1] Read sector 2 (128 bytes).
[Disk 1] Read sector 3 (128 bytes).
[Disk 1] Read sector 4 (128 bytes). [x2]
[Disk 1] Read sector 5 (128 bytes).
[Disk 1] Read sector 6 (128 bytes).
[Disk 1] Read sector 7 (128 bytes).
[Disk 1] Read sector 8 (128 bytes).
[Disk 1] Read sector 9 (128 bytes).
[Disk 1] Speed poll.
Serial port speed set to 57600.
[Disk 1] Read sector 10 (128 bytes).
[Disk 1] Read sector 11 (128 bytes).
[Disk 1] Read sector 12 (128 bytes).
[Disk 1] Read sector 13 (128 bytes).
[Disk 1] Read sector 14 (128 bytes).
[Disk 1] Read sector 15 (128 bytes).
[Disk 1] Read sector 16 (128 bytes).
[Disk 1] Read sector 17 (128 bytes).
[Disk 1] Read sector 18 (128 bytes).
[Disk 1] Read sector 19 (128 bytes).
[Disk 1] Read sector 20 (128 bytes).
[Disk 1] Read sector 21 (128 bytes).
[Disk 1] Read sector 22 (128 bytes).
[Disk 1] Read sector 23 (128 bytes).
[Disk 1] Read sector 24 (128 bytes).
[Disk 1] Read sector 25 (128 bytes).
[Disk 1] Read sector 26 (128 bytes).
[Disk 1] Read sector 27 (128 bytes).
[Disk 1] Read sector 28 (128 bytes).
[Disk 1] Read sector 29 (128 bytes).
[Disk 1] Read sector 30 (128 bytes).
[Disk 1] Read sector 31 (128 bytes).
[Disk 1] Read sector 32 (128 bytes).
[Disk 1] Read sector 33 (128 bytes).
[Disk 1] Read sector 34 (128 bytes).
[Disk 1] Read sector 35 (128 bytes).
[Disk 1] Read sector 36 (128 bytes).
[Disk 1] Read sector 37 (128 bytes).
[Disk 1] Read sector 38 (128 bytes).
[Disk 1] Read sector 39 (128 bytes).
[Disk 1] Read sector 40 (128 bytes).
[Disk 1] Read sector 41 (128 bytes).
[Disk 1] Read sector 42 (128 bytes).
[Disk 1] Read sector 43 (128 bytes).
[Disk 1] Read sector 4 (128 bytes).
[Disk 1] Get status.
[Disk 1] Read sector 360 (128 bytes).
[Disk 1] Read sector 361 (128 bytes).

Edited January 22, 2013 by atari8warez

[HiassofT]

Hias, the readme.txt file says "MyPicoDos uses a XF551 compatible way to determine the disk density: First it reads sector 4 (this is required by the XF551), and then it uses the "get status command" to see whether the disk is single or double density."

 

I created a standard, high-speed at boot type atr image for testing and here's the boot log of that atr from AspeQt:

The boot code first reads sector 4 and after that the first sector of picodos.sys (which also happens to be sector 4).

 

The quote from the docs refers to how the disk-density detection works within MyPicoDos. At the end of the log you see a "read sector 4" followed by "get status" and then "read directory sectors".

 

Way back then when I implemented this I didn't have a XF551 either. People told me that the XF551 has troubles detecting the disk density (and setting the drive status bits) unless a data sector within the first track is read. The recommended way to circumvent this XF551 bug was to issue a "read sector 4" command.

 

In MyPicoDos I use an immediate command, i.e. DSTATS set to 0, and a delay to discard any bytes the XF551 might send before the "get status" and "read directory sector" commands. This is mainly important when first accessing the drive (eg user switches to D2:) or if the user inserted another disk and re-reads the directory.

 

You don't have to care about all of this in AspeQt :-)

 

so long,

 

Hias

[atari8warez]

The boot code first reads sector 4 and after that the first sector of picodos.sys (which also happens to be sector 4).

 

The quote from the docs refers to how the disk-density detection works within MyPicoDos. At the end of the log you see a "read sector 4" followed by "get status" and then "read directory sectors".

 

Way back then when I implemented this I didn't have a XF551 either. People told me that the XF551 has troubles detecting the disk density (and setting the drive status bits) unless a data sector within the first track is read. The recommended way to circumvent this XF551 bug was to issue a "read sector 4" command.

 

In MyPicoDos I use an immediate command, i.e. DSTATS set to 0, and a delay to discard any bytes the XF551 might send before the "get status" and "read directory sector" commands. This is mainly important when first accessing the drive (eg user switches to D2:) or if the user inserted another disk and re-reads the directory.

 

You don't have to care about all of this in AspeQt :-)

 

so long,

 

Hias

 

Ok, so you actually ignore whatever data is coming from sector 4, and that XF551 compatibility check is not an issue.

I do however have a problem with the boot procedure.

 

AspeQt allows booting from a Folder Image as follows:

 

1. A data file containing the first 3 sectors of a bootable DOS disk ($boot.bin) must exist in the mounted PC Folder, as well as the DOS file to be booted. In MyPicoDOS's case that would be the picodos.sys

2. When the computer is turned ON while connected to AspeQt with a Folder Image on D1:, AspeQt sends the boot sectors from the $boot.bin file by updating the DFLINK ($70F, $710) with the first sector number of the DOS.SYS file in the Folder Image. In MyPicoDOS's case AspeQt updates the $9 and $A bytes of the first boot sector with the first sector number of the PICODOS.SYS.

3. The boot loader loads DOS.SYS and the computer drops to BASIC (if enabled). This works fine with AtariDOS and MyDOS (and with any other DOS compatible with AtariDOS). I do have a problem with MyPicoDOS though. For some reason after the PICODOS.SYS is loaded the computer simply hangs. I never see the BASIC prompt and the computer becomes irresponsive.

 

Apparently there is something different in MyPicoDOS boot procedure and that's what I am trying to understand...

[HiassofT]

In MyPicoDOS's case AspeQt updates the $9 and $A bytes of the first boot sector with the first sector number of the PICODOS.SYS.

Be sure the other bytes I mentioned (sector length and highspeed) are set appropriately, too. I'd recommend trying with highspeed=0 or 1 (not $81) to simplify the boot process.

 

If highspeed is set to $81, the bootloader switches to using highspeed SIO as soon as the highspeed code is loaded. So you'll see a $3F command in the middle of the boot process and the rest of picodos.sys will be loaded in highspeed.

 

MyPicoDOS though. For some reason after the PICODOS.SYS is loaded the computer simply hangs. I never see the BASIC prompt and the computer becomes irresponsive.

 

Apparently there is something different in MyPicoDOS boot procedure and that's what I am trying to understand...

The boot process is quite similar. It loads picodos.sys until the sector link is $0000 (end of file) and then starts mypicodos.

 

Best thing to test, I think, would be to do a trace with data bytes included and then compare the results of ATR booting with virtual folder booting.

 

so long,

 

Hias

[atari8warez]

Be sure the other bytes I mentioned (sector length and highspeed) are set appropriately, too. I'd recommend trying with highspeed=0 or 1 (not $81) to simplify the boot process.

 

If highspeed is set to $81, the bootloader switches to using highspeed SIO as soon as the highspeed code is loaded. So you'll see a $3F command in the middle of the boot process and the rest of picodos.sys will be loaded in highspeed.

 

 

The boot process is quite similar. It loads picodos.sys until the sector link is $0000 (end of file) and then starts mypicodos.

 

Best thing to test, I think, would be to do a trace with data bytes included and then compare the results of ATR booting with virtual folder booting.

 

so long,

 

Hias

 

I am currently using $81 for high-speed and other bytes are OK. I will give it another try and see what happens....