WinUAE: Games using "track 80" do not work?!

[Flachkoepper]

In several games WinUAE stops loading when the disk drive led (showing the currently used track for loading from df0: ) shows "track 80" (e.g. "Space Battle V1.0", which is available at planetemu, or "Seat Driving Simulator" come into my mind). The games freeze and can't be started (except for showing the title or something similar). Is it a bug in WinUAE? (or a security feature?!)

I know that the ADFs themselves are not corrupt, because on my A500 they can be loaded and work properly when I transfer them onto disk.

Thank you very much for any helpful hint! :-)

[Asterix]

did you try "cycle-exact" mode or "more compatible" setting?

a bit more info on your winUAE setup could be helpful

[Flachkoepper]

Hello Asterix, thanks for your answer.

I don't think that the problem is based on the cycling between CPU and Blitter. It seems to be a disk-emulation error or a kind of restriction (?) in WinUAE.

- Take the game "Space Battle V1.0" (see above) as an example:

I use the "Default Configuration" coming with the WinUAE 0.9.92 release. I only change kickstart 1.3 to version 1.2 and turn of DF1:

With this configuration, the loading of Space Battle starts after "putting the floppy" into df0, the gametitle appears, and when you press the joystickbutton the loaderscreen says "disk operation/please wait". Afterwards the trackdisplay counts wildly and stops at track 80 - and nothing happens anymore. As I wrote before, the file itself works properly when I use it with a 3,5" disk on my "real" amiga 500.

This ADF-file is not the only one where it happens (but it is a good example); I just wonder if it is coincidence that WinUAE on several diskimages (not very much at all) stops working, just showing track 80 on the drive display?!

Has anybody got "Space Battle V1.0" working on WinUAE? Did I forget to change any property in the configuration? If it is my fault, I would be thankful for a working configuration

[derSammler]

I don't think that the problem is based on the cycling between CPU and Blitter.

Please try it anyway.

[Flachkoepper]

I did. No effect.

[andreas]

No wonder.

Originally Posted by Flachkoepper

In several games WinUAE stops loading when the disk drive led (showing the currently used track for loading from df0: ) shows "track 80" (e.g. "Space Battle V1.0", which is available at planetemu

Yup. The SCA-infected version hangs indeed at track 80, no matter how "special" I modify my config (KS 1.2, 512K only, CE on, etc.)

@WindowsKiller: I think that any meddling with the problem regarding CE is doomed to fail here afaics. This DOES seem a disk [emulation] problem.
Otherwise, it would feel is as if you were a surgeon and continuously give drugs to a patient to suppress the pain, although you certainly know that you left a needle inside him before closing his skin -

My first assumption *was* that the disk was copied from a protected original, with the protected track been left out. But since Flachkoepper claims it to be working on the real thing, can I still assume this?

[Toni Wilen]

Image used was: Space Battle v1.0 (1986)(Anco)[v SCA]

Tested on my A500 (KS1.2/1.3 0.5M Chip ECS Agnus) -> freezes identically -> emulation is correct

It seems to expect something special at track 80 (routine is at ~0x75e00 if someone is interested in checking it. There is also another check at ~0x294d0)

[andreas]

@Flachkoepper

did you WRITE the image from planetemu on the 3.5'' disk or do you already have a version on disk anyway?
This could be the solution: transferring YOUR (working) version where this track 80 protection check might have been removed already, and using it in WinUAE.

[edit]
Most likely. The SCA-infected version FAILS on my real A1000. It clearly misses a protection track which is checked.
The version on your real disk MUST be different from that. Simple logic.

[derSammler]

Originally Posted by andreas

@WindowsKiller: I think that any meddling with the problem regarding CE is doomed to fail here afaics. This DOES seem a disk [emulation] problem. Otherwise, it would feel is as if you were a surgeon and continuously give drugs to a patient to suppress the pain, although you certainly know that you left a needle inside him before closing his skin -

Come on, Asterix tried to help but Flachkoepper just said " don't think that the problem is based on the cycling between CPU and Blitter". How can he know if he didn't even took the time to try it ? I didn't said that the ce-mode is responsible for this bug... but you have to try if you want to exclude this possibility.

Try to add 11264 bytes of random data to the end of the ADF. I had this problem ages ago as well and it could be fixed this way...

[Toni Wilen]

Originally Posted by WindowsKiller

Try to add 11264 bytes of random data to the end of the ADF. I had this problem ages ago as well and it could be fixed this way...

Disk emulation automatically "reads" random bits when reading non-existing (=non-formatted) tracks.

[Flachkoepper]

Grey hair now turning white...

Andreas and Toni, you were both right! As Andreas assumed, the working version of Space Battle I had was like the planetemu-version, but it is not the same one - I was just confused about my floppydisks, a big sorry for that (shame on me)!

Indeed, the planetemu version does not work, even on my Amiga 500. Track 80 seems to contain the copyprotection of the game.

So, no bug in WinUAE Floppy-emulation! Sorry for my mistake, I will sort my floppydisks in a better way now - Anyway, problem solved, and thanks for your great support! Keep up your great work!!

[andreas]

Please transfer your version from real disk! The version in TOSEC doesn't serve to anyone now!
Thanks!