Alphaload SSDD Master Utilities sector copied to ATR fails to boot.

[TZJB]

I am attempting to boot a newly sector copied double density Alphaload Master Utilities ATR from RespeQt Disk 1 and it is failing to boot past sector 5.

 

[Disk 1] Mounted 'Alphaload Master Utilities.atr' as 'DD Diskette (180k)'.
Serial port speed set to 19200.
[Disk 1] Sending [COMMAND ACK] to Atari
[Disk 1] Speed poll: 8
[Disk 1] Sending [COMPLETE] to Atari
Serial port speed set to 57600.
[Disk 1] Sending [COMMAND ACK] to Atari
[Disk 1] Get status: $ff
[Disk 1] Sending [COMPLETE] to Atari
[Disk 1] Sending [COMMAND ACK] to Atari
[Disk 1] Read Sector 1 ($001) #1 in track 0 ($00)
[Disk 1] Sending [COMPLETE] to Atari
[Disk 1] Sending [COMMAND ACK] to Atari
[Disk 1] Read Sector 4 ($004) #4 in track 0 ($00)
[Disk 1] Sending [COMPLETE] to Atari
[Disk 1] Sending [COMMAND ACK] to Atari
[Disk 1] Read Sector 5 ($005) #5 in track 0 ($00)
[Disk 1] Sending [COMPLETE] to Atari
Serial port speed set to 19200.
Serial port speed set to 57600.

Serial port speed set to 19200.
Serial port speed set to 57600.

 

It seems that all my other Alphaload DD disk sector copied to ATR are also failing to boot. This is frustrating me hence the topic.

 

I have tried various sector copiers including Happy, Copy2000, Copymate 3.8, Supercopymate XE etc. Diskcopy (TurboDOS) thinks the disk is Quad density as it often does with DD! All produce the same result.

 

A seperate sector copy to an ATR then booted from Fujinet D1: has the same boot failure so it's not just RespecQt with this issue.

 

The Alphaload Master disk will copy to a real disk and boot from that so it's not the copier causing this problem, but I don't know what.

 

Has anyone experienced this issue before while creating ATR backups? Any assistance gratefully received.

 

This is the image most recently created for reference:-

 

Alphaload Master Utilities.atr

 

 

[TGB1718]

That image loads fine in Altirra, so the .ATR is fine

[www.atarimania.com]

Not sure this is related to your problem but I remember that, back in the day, some non-standard DD menu disks from the UK just wouldn't load with some floppy drives. IIRC, they worked with my 1050 with US Doubler but failed to boot on my Indus GT.

[TGB1718]

Just hooked up Respqt on my 130XE and tried loading and it fails as you said, goes sector 1,4,5 then hangs.

That is on a PAL system, so what @www.atarimania.com says there may be problems with some menu disks.

 

Interestingly, I just set Altirra to PAL, it does boot, the Atari Logo is fine, but the menu is garbage. 

Edited May 20, 2023 by TGB1718

[blacka013]

Hi,

 

I've just tried this in Atari Win Plus 4.0, and it loads and runs the programmes when you select them.

 

Regards

[TZJB]

3 hours ago, TGB1718 said:

That image loads fine in Altirra, so the .ATR is fine

 

That is good news.

 

I tested in Altirra too but it locks up at sector 5 for me. What settings are you using and do the Alphaload menu options select OK?

 

1 hour ago, TGB1718 said:

Just hooked up Respqt on my 130XE and tried loading and it fails as you said, goes sector 1,4,5 then hangs.

That is on a PAL system, so what @www.atarimania.com says there may be problems with some menu disks.

 

Interestingly, I just set Altirra to PAL, it does boot, the Atari Logo is fine, but the menu is garbage. 

 

Thanks for duplicating my problem. I still have issues with Altirra though. 800XL PAL should work but doesn't for me.

Edited May 20, 2023 by TZJB

[TZJB]

25 minutes ago, blacka013 said:

Hi,

 

I've just tried this in Atari Win Plus 4.0, and it loads and runs the programmes when you select them.

 

Regards

 

Thanks I will try that, but it should boot with a real Atari 800XL too.

[TZJB]

1 hour ago, www.atarimania.com said:

Not sure this is related to your problem but I remember that, back in the day, some non-standard DD menu disks from the UK just wouldn't load with some floppy drives. IIRC, they worked with my 1050 with US Doubler but failed to boot on my Indus GT.

 

It does seem similar. It could be related to the interleave being set to USD ultraspeed skew which affects the read timings. The Indus GT syncromesh has a very different interleave to any other drive as I understand it.

[TGB1718]

28 minutes ago, TZJB said:

That is good news.

 

I tested in Altirra too but it locks up at sector 5 for me. What settings are you using and do the Alphaload menu options select OK?

I'm emulating USD drives, the same as my "real" setup

[TZJB]

35 minutes ago, TGB1718 said:

I'm emulating USD drives, the same as my "real" setup

 

Hey, that is most weird. It booted in Altirra with USD drive D1:! I tried @Nezgar fast USD ROM too so it must be to do with SIO timing.

 

I also tried Speedy drive emulation in Altirra with my Lazer ROM and it worked too.

 

Which gave me the thought to try Happy mode in RespecQt - Didn't work.

 

Then I tried CHIP mode - IT WORKS. The darn thing boots now!

 

Thanks everyone. It took a while but I got there.

 

Still not truely sure what the issue is though, or why they won't load with Fujinet. I can't emulate a CHIP with that.

 

EDIT: Just realised what the corrupt menu thing is. BASIC needs to be off, then it's OK.

 

 

Edited May 20, 2023 by TZJB

[E474]

Hi @TZJB

 

    It should work with a FujiNet, you just need to set the correct pokey divisor for AlphaLoad/US Doubler. See this thread (and the threads mentioned in it):

 

 

  I think (from memory), US Doublers use UltraSpeed, and Happys use Warp Speed, and they are not the same. Not sure how you can select emulation/speed in RespeQT as I don't have it set up.

 

  Hope this helps.

 

[+nasty niff]

wont work from fujinet or any cart from what i am aware. it tries to initalise ultra speed , thats why alpha load disk wont run on speedy upgrades or similar from europe, only works on doubler and happy. similar code was used in the later AURA menus so theyd run at full speed from doubler and happy...

Edited May 21, 2023 by mistapaul

[+CharlieChaplin]

Maybe you can try if other british menu disks (e.g. Howfen DOS, Multiboot, Mockingbird, Elton C., Ian K., Jon C., Mikran, Rob C., etc.) show the same strange behaviour ?!? You can find some examples here: http://ftp.pigwa.net/stuff/collections/holmes cd/Holmes 1/ATR Programs/Applications A-Z/index.html

 

[+nasty niff]

they should work as they dont initialise ultra speed..

[+CharlieChaplin]

Afaik, Howfen DOS does initialize ultraspeed:

 

 

Choose menu maker, then option D - U.S. Double.

Now try to boot the new created menu on the SSDD disk.

 

Think there are a few other british menus that make use of US Doubler ultraspeed for SSDD (180k).

 

[+nasty niff]

alpha menus you dont get a choice like howfen dos, its just us ultra speed.

[TZJB]

On 5/21/2023 at 1:57 PM, E474 said:

Hi @TZJB

 

    It should work with a FujiNet, you just need to set the correct pokey divisor for AlphaLoad/US Doubler. See this thread (and the threads mentioned in it):

 

 

  I think (from memory), US Doublers use UltraSpeed, and Happys use Warp Speed, and they are not the same. Not sure how you can select emulation/speed in RespeQT as I don't have it set up.

 

  Hope this helps.

 

 

Thanks for the link. I did set Fujinet to the lowest HSIO setting of 9 55 Kbps. This is with the latest TNFS fixed firmware version which doesn't seem to go to any lower speed, and I believe that you found HSIO 10 to work with Alphaload disks?

 

Setting the disk drive emulation in RespeQt is just a button on the disk drive number position and Alphaload works with the Chip/Super Archiver button pressed.

 

Ultraspeed relies on an Ultraspeed sector skew interleave format on the disk due to the US Doubler 2KB SRAM sector buffer whereas a Happy drive with Warp Speed has a 6-8KB SRAM track buffer. I am copying the disk from a Lazer drive with Warp Speed to a new RespecQt ATR image set to normal.

 

The image boots fine with a physical Lazer drive and copies to another disk with a Lazer drive where interleave seems irrelevant due to the track buffer. However the Happy emulation in RespecQt does not seem to buffer the track so it doesn't fully boot whereas Chip emulation in RespeQt does.

 

22 hours ago, CharlieChaplin said:

Maybe you can try if other british menu disks (e.g. Howfen DOS, Multiboot, Mockingbird, Elton C., Ian K., Jon C., Mikran, Rob C., etc.) show the same strange behaviour ?!? You can find some examples here: http://ftp.pigwa.net/stuff/collections/holmes cd/Holmes 1/ATR Programs/Applications A-Z/index.html

 

 

I have all of those images and they boot correctly as they are not double density. In fact some are only 64K images. HowfenDOS is one of the few that formats to double density.

 

As you suggested, I created a HowfenDOS menu disk in USD Ultraspeed double density on my 1050 disk drive set to USD mode, then copied an Alphaload file to it. The disk was copied to an ATR image in RespecQt and mounted as D1:. Powering the 800XL, the HowfenDOS double density disk image booted correctly so that's a plus, except I never used HowfenDOS for anything else.

 

As far as I remember the other British menus could only format up to 1050 Enhanced Density so should load normally with any drive emulator anyway.

 

The problem seems to be specific to Alphaload double density disks attempting Ultraspeed. Long ago we chose Alphaload over Multiboot due to the density of Alphaload holding twice the files! In hindsight I wish we hadn't....

 

Edited May 22, 2023 by TZJB

[E474]

Hi @TZJB,

 

   I don't actually have a "real" Fujinet, just Fujinet-PC setup to run on a Raspberry Pi. If there isn't a way to set Pokey Divisor to 10, then it sounds like it might be a bug. It's a bit tricky for testing om real hardware though, if AlphaLoad only works on PAL systems. I will flag it as a bug on the FujiNet thread.

 

   Btw, US Doublers only have 384 bytes of RAM (128 bytes in the RIOT chip, and 256 bytes in the stacked RAM chips). 2K of SRAM would be much more roomy!

[TZJB]

1 hour ago, E474 said:

Hi @TZJB,

 

   I don't actually have a "real" Fujinet, just Fujinet-PC setup to run on a Raspberry Pi. If there isn't a way to set Pokey Divisor to 10, then it sounds like it might be a bug. It's a bit tricky for testing om real hardware though, if AlphaLoad only works on PAL systems. I will flag it as a bug on the FujiNet thread.

 

   Btw, US Doublers only have 384 bytes of RAM (128 bytes in the RIOT chip, and 256 bytes in the stacked RAM chips). 2K of SRAM would be much more roomy!

 

Oh, okay. I thought maybe an older version of Fujinet firmware supported Pokey Divisor 10. I am also thinking my maths didn't add up, 256x8 = 2 Kbits not Bytes. I've gone off of US Doublers....

[spacedmonkeys]

Sorry for digging up a year old thread, but did you ever get to the bottom of this?

 

I have recently dug out my disk collection, and it is mostly versions of Alphaload along with a few Rob C / Multiboot and other UK menus.

 

I want to get all of these disks transferred to ATR format (just ordered a 1050-2-PC), and with some of the more "precious memory" ones, I'd like to write them to my SIO2SD. When I was a teen I spent a few weeks copying to and from multiboots to Alpha and putting all the games on Alphaboots in alphabetical order...so:

 

I have tried putting a couple of the Alphaload games/utils ATR's that I have leeched (from atari sector/brenski) in the past on to my SIO2SD and I see the exact same problem as you, they load a few sectors and then stop, making a "disk write" sio sort of noise.

 

The same ATR's work perfect in Altirra.

 

Anyone have Alphaloads working off 'modern' storage?

[+DjayBee]

I tried running the image from the first post in Altirra and failed ... mostly.

 

This loader implements its own SIO code and needs a Happy or US Doubler Drive. Anything else farts out.

 

Therefore I doubt that anyone will make it work with a SIO2something device.
IIRC RespeQt supports a Happy mode. This might be worth a try.

 

Edited May 16 by DjayBee
Added Altirra screenshot

[spacedmonkeys]

I don’t think the Atr’s in the first post are any good. I have some that work fine in Altirra I will post later.
 

So I guess I will need to look in to converting all my alphaload disks to multiboot/rob-c/ian-k menus so that they will work? I know there are programs to do that. But then they won’t be hi-speed?

 

I remember having a similar problem 20 years ago or so and working with the guy who made the APE(??) software - the one which used a 1050-to-serial interface? Anyway he implemented a patch so I could make ATR’s from the Alphaloads, but I never had time to get many of them done back then. Be a shame if I can’t get them converted now.

[TZJB]

4 hours ago, spacedmonkeys said:

Sorry for digging up a year old thread, but did you ever get to the bottom of this?

 

I have recently dug out my disk collection, and it is mostly versions of Alphaload along with a few Rob C / Multiboot and other UK menus.

 

I want to get all of these disks transferred to ATR format (just ordered a 1050-2-PC), and with some of the more "precious memory" ones, I'd like to write them to my SIO2SD. When I was a teen I spent a few weeks copying to and from multiboots to Alpha and putting all the games on Alphaboots in alphabetical order...so:

 

I have tried putting a couple of the Alphaload games/utils ATR's that I have leeched (from atari sector/brenski) in the past on to my SIO2SD and I see the exact same problem as you, they load a few sectors and then stop, making a "disk write" sio sort of noise.

 

The same ATR's work perfect in Altirra.

 

Anyone have Alphaloads working off 'modern' storage?

 

I had to re-read what I wrote as I had already forgotten!

 

Yes the Alphaload disks worked with RespecQT in CHIP drive emulation mode for some reason.

 

I did the same thing, moving SSSD Multiboot menu titles to SSDD Alphaload menus a long time ago. It saved lots of disks, but now we have this problem.

 

To my knowledge only RespecQT in CHIP drive emulation mode can boot these successfully with a real Atari 8-bit at present.

[HiassofT]

I did a quick test with the ATR from the first post in this thread with AtariSIO and it booted fine if I set the highspeed pokey divisor to 10 (52kbit/sec) instead of the default 8 (57.6 kbit/sec).

 

IIRC RespeQt, SIO2SD have similar options somewhere in their setting menus (although divisor 10 might not work with all serial ports on the PC - USB adapters mostly should be fine though).

 

I also quickly checked the master disk ATR and DD multiboot/multiload ATRs generated with the first option in the master menu (no idea what the other options are for...) and they all have the decimal 10 / hex 0A divisor stored at offset 199 (hex):

 

Changing that to hex 08 makes the ATR bootable with default 3xSIO / 57.6 kbit/sec highspeed SIO settings

You could also change it to hex 28 / decimal 40 to make it boot in standard SIO speed - that should work with all drives / emulators, even if they don't support ultra speed SIO at all

 

so long,

 

Hias

[TZJB]

25 minutes ago, HiassofT said:

I did a quick test with the ATR from the first post in this thread with AtariSIO and it booted fine if I set the highspeed pokey divisor to 10 (52kbit/sec) instead of the default 8 (57.6 kbit/sec).

 

IIRC RespeQt, SIO2SD have similar options somewhere in their setting menus (although divisor 10 might not work with all serial ports on the PC - USB adapters mostly should be fine though).

 

I also quickly checked the master disk ATR and DD multiboot/multiload ATRs generated with the first option in the master menu (no idea what the other options are for...) and they all have the decimal 10 / hex 0A divisor stored at offset 199 (hex):

 

Changing that to hex 08 makes the ATR bootable with default 3xSIO / 57.6 kbit/sec highspeed SIO settings

You could also change it to hex 28 / decimal 40 to make it boot in standard SIO speed - that should work with all drives / emulators, even if they don't support ultra speed SIO at all

 

so long,

 

Hias

 

Thanks so much Hias. Good detective work.

 

I think I did try and set divisor 10 for Fujinet at the time and failed.

 

Now that we know the offset 199h is where the divisor can be set we can fix this problem it seems, and the answer is to go faster!

 

I have been using HxD hex editor on the PC and just checked random Alphaload images to find that 199h is set to 0A so 130+ more to go....

 

Any ideas on automation of this task?

 

Although I'm just being lazy. My initial effort attached:-

 

Alphaload cheats Disk Side A.atr

 

Alphaload cheats Disk Side B.atr