Tetra Quest complete image - hopefully

[ParanoidLittleMan]

That Warriors II release seems very rare. Not sure that there is separate USA and UK release of Microdeal v. Works fine at 50 and 60 Hz, no any check or set of refresh rate. I mean fine as much not good coding allows. Looked little in - and whole video generation control is not well done. Programmer had no practice with Atari ST and 68000 CPU. For instance IKBD interrupt starts with saving sr to address, and last operations are: move address,sr ; rte . That was after quick view.

Corrupted or not, maybe just degraded after some 30 years ...

[ijor]

Not sure that there is separate USA and UK release of Microdeal v. Works fine at 50 and 60 Hz, no any check or set of refresh rate.

 

I don't know for sure if there were separate releases, but that's rarely the difference between US and UK releases. The difference is usually the packaging, sometimes the protection and the title screen, sometimes the master. Most of the times the actual game is identical. There aren't many titles with explicit different refresh rate.

 

Corrupted or not, maybe just degraded after some 30 years ...

Kodak80 disk is not degraded neither damaged. Otherwise you would get CRC errors. Anyway, the problem is the timing and I know already that the timing problem has no relation to the data or the code. It's related to the alignment of the sectors.

Edited January 4, 2019 by ijor

[ParanoidLittleMan]

Whatever it is really is not what is my area of interest. As may see, it works not on his 2 Atari computers too.

I made some Steem update: http://atariage.com/forums/topic/286752-steem-32-updates/

[ParanoidLittleMan]

Kodak80 disk is not degraded neither damaged. Otherwise you would get CRC errors. Anyway, the problem is the timing and I know already that the timing problem has no relation to the data or the code. It's related to the alignment of the sectors.

Well, I don't know what SW and examination methods you use, but there are CRC errors on all sectors of track 0, except bootsector.

Test done with SCP image file and Steem SSE 3.91 .

Test with STX image made with Aufit and with Pasti in Steem 3.2 gives CRC error only in sector #2 . So, something is bad with conversion, it seems. In any case, there is CRC error.

And you can ask that Kodak80 to make same test with his org, floppy and my SW Tracc.http://atari.8bitchip.info/TRACCPR.ZIP

And of course, may try with making Pasti image, I guess.

[ijor]

Well, I don't know what SW and examination methods you use, but there are CRC errors on all sectors of track 0, except bootsector.

Test done with SCP image file and Steem SSE 3.91 .

Test with STX image made with Aufit and with Pasti in Steem 3.2 gives CRC error only in sector #2 . So, something is bad with conversion, it seems. In any case, there is CRC error.

 

That's an interesting conclusion you make there. My own analysis and my own tools show me that there are no errors (again, except sector 2 that it is the copy protection). Aufit's analysis and conversion gives identical results to mine. Yet, you say that your tool is right and all the other tools are wrong ??? Didn't occur to you that the problem, perhaps, might be with your tool or with Steem SSE FDC emulation (or a combination of both)?

 

Let's see the track analysis performed on a real Atari with other tools:

 

 

That's a real Atari with the SCP image. As you can see, there are no CRC errors except on sector 2. And, once again, sector 2 is the copy protection. It is the weak sector that obviously has a CRC error by design, it is not damaged. You can easily verify this by yourself by analyzing the code that checks the protection.

 

You are still free to think that I'm wrong (and Aufit, and Procopy) and you are right. But, honestly, I am getting tired of this. Everything that I say you claim that I'm wrong. And I don't understand why you insist when you said in the previous message that you are not interested and this is not really your area of interest.

Edited January 6, 2019 by ijor

[ParanoidLittleMan]

You said no CRC errors, and there is, at least one. Next time try to be more specific, instead usual blah "Yet, you say that your tool is right and all the other tools are wrong ???" Really should stop with that childish 1 bit attitude - one is whether right and best in everything, while others are all wrong in everything. Or it is opposite. It's never any of that 2. Truth is always between - as no absolute white or black.

When you say that I said that I'm right, you insulting me and the facts. Where I said it in last couple posts ? And your quoted sentence was much worse.

I said that it seems that conversion to STX was not OK. Maybe. I did not say that maybe Steem SSE handles not properly SCP images. But that is natural to think such thing, Still, much better than Hatari 2.1 - which just freezes with this SCP. My tool is for sure OK. That's very simple program, what will say CRC error if getting such flag from FDC. Done about 28 years ago, before even ST and MSA formats existed. Used own floppy image format. I analyzed this protection in 2012, was really not in mood to do it again. And saying that no protection in Microdeal release was wrong - there is protection still - checking total loading time of sectors by using Timer-B . Then using that value in decryption of later stage. And I seen some other ones in past doing similar. Just were not so on edge. How's that it failed on real HW ? Hot's that you did not mention that here ? Ah, attacking other one is easier.

But there was benefit in all this, if you can override this personal misunderstandings and vanity. I see now much better that low level floppy emulation is still with flaws. In practically all emulators. I corrected what I could in short time. I wrote to Steven Seagal about problem. I could write to Jorge Zwick, but that man don't like 'unfriendly' messages - like asking to update and publish Pasti.dll on his site, where is some alpha/beta v. from many years ago.

Yes, I think that you are wrong in your attitude - and yes, I'm not interested much for copy protections. But interested in some normal communication. And to admit to people if they did something useful. Thank you for your time sir.

Some people had time to do about what is missing there: http://sarnau.info/atari-st-protection-pasti-file-format/

http://atari.8bitchip.info/STXdesc.html

[ParanoidLittleMan]

OK, I think that we can make some conclusion here, just to go back to topic:

Why I said 'we', when I will do it self ?

Nobody is perfect

 

This game has 2 releases, it seems. Funny thing is that most likely first release was in compilation. But if we look game and it's flaws, then it is not funny anymore - game is just not well done, despite good idea. Controls are bad, highscore and password is poorly done and confusing. Looking code shows lack of experience with Atari ST and MC68000 .

Both releases have serious flaws considering content of floppy disk: Microdeal one missing last tracks, where 2 screen data is. Compilation release has bad floppy timing - what is most likely just another bad coding. They removed copy protection, but not completely in Microdeal release - that's why fails in Steem when is converted to ST/MSA . Shallow work overall. What about testing it before start duplicating floppies ?

 

I have some ideas how to make it better. But after all feedback about what I did with Swiftar http://atari-forum.com/viewtopic.php?f=3&t=32576&p and some other games ...

Edited January 6, 2019 by ParanoidLittleMan

[ijor]

But there was benefit in all this, if you can override this personal misunderstandings and vanity. I see now much better that low level floppy emulation is still with flaws. In practically all emulators. I corrected what I could in short time. I wrote to Steven Seagal about problem. I could write to Jorge Zwick, but that man don't like 'unfriendly' messages - like asking to update and publish Pasti.dll on his site, where is some alpha/beta v. from many years ago.

 

When you start going personal I will not reply. You are free to think what you want. You are even free to say what you want, at least within some limits. I will continue with the topic somewhere else.

[ParanoidLittleMan]

Oh, like I wanted reply ... Continuing somewhere else ? Why in future mode, when already did it ? Why this thread started at all ? Why SCP image of Tetra Quest appeared at all this days ? Why people cares not for obvious facts, but only for personal things ? Yes, if this would not be personal, whole this stupid discussing could be just not present here. Am I personal because started thread about missing good images of Atari ST games ? http://atariage.com/forums/topic/286301-atari-st-games-without-good-image/

Twisting of facts, that's what happened. Then, I started this thread with asking for testing. But instead it some nasty comments from usual hero in it Then someone took on self complete judgement, and turned this in some discussion about new copy protection scheme. What would be OK if he could talk enough clear, and would not start this with very wrong assumptions. "They aren't images that are identical except on the damaged/missing areas. Several tracks are completely different, and again, that's besides the bad tracks" . Like we don't know how to compare disk images. Interesting ... Later it appears that no bad tracks, that are not 'completely different' releases.

And of course, our judge just forgot to mention here important thing: this works not on real HW too - from original floppy. So much about being fair and not personal. Latest question mark here: Is favorising self and twisting other's words personal ?

[ParanoidLittleMan]

And to close this thread: the results :

http://atari.8bitchip.info/ASTGA/T/tetraq.php

There can DL STX image, which has 2 fixes to work with usual emulators, ST, MSA images which are equ. with STX image in fact.

 

I will quote here supplied txt with STX image:

Tetra Quest Pasti image with some fixes, removed
unnecessary track images

This game has 2 releases - Microdeal one, what missing last tracks,
so will not see some screens - like that for highscore.
Other one is in compilation Tristar Warriors II - and it has problems
too. Floppy code is poorly done, and it just works not on most of systems.
Copy protection relies a lot on accurate floppy rotation speed. Other part
of protection is some weak bit type, but again, passed not on many Ataris,
it seems.
That's most likely the reason why they removed second part of protection.
But did not remove first part in Microdeal releases - instead it, they removed
2 bitmaps :-)

OK, enough of sad story. This STX image is based on Tristar Warriors release,
and has 2 fixes (hacks, if you like it more).
1st deactivates rotation speed dependency, second skips over weak bit type
protection check. Totally 8 bytes are changed in image.
Additionally, I removed all track images, because no track load used.

So, we have now STX image, what works with usual emulators like Steem,
Steem SSE (3.9.1) and latest Hatari 2.1 .

PP, Jan 7 2018.

 

Additional explanations: this is really case of floppy release of some SW poorly executed by publishers. Both releases have serious flaws. Unlike some, I don't see this as emulation problem. As can see, there are problems on real Ataris too. Coder just made it working on floppy drives with very accurate rotation speed (or better said: very close speed to his test config.) . Other part of protection I will not comment, but fact that it is deactivated in another release says something. Still, not true that "The protection was removed by the publisher. The disk can be copied with a software copier." . First part of protection is still there, and it relies a lot on floppy drive rotation speed. Thanks for making confusion here. But I'm not surprised - similar problem was with famous FastCopy Pro (v3) .

 

Credits: thanks to unknown who imaged Microdeal release and sent it to Atarimania. Thanx to other people who imaged Tristar Warriors II release, especially to great man, who 'inspired' me in PM to chose this username here

You see, I was not personal - no names, no flames

[tjlazer]

Finally, I was able to combine complete floppy image of Tetra Quest. Based on 2 images from different sources - one is STX image at atarimania, other is SCP image

https://mega.nz/#!s2p2gSII!9efB9yyBkqjq9ECNKzRLHsx0EkUaBl6CTPi4o-Yl85Y

Both have errors, but luckily not on same areas. So, it was actually 10 minutes task to put together image combined from good parts of 2 . I already deprotected it years ago, and it works.

Tested only in Steem 3.2 with TOS 1.04 and Hatari 2.1 with TOS 2.06 . Half Meg RAM is enough. Don't see that level code entering works, and lazy to look manual

http://atari.8bitchip.info/ASTGA/T/tetraq.php

 

This is what missing from image what is at atarimania - and that's not because floppy was damaged or like - it's just edition done with mastering error, untested properly for sure.

Let's we be better than those money hungry publishers .

 

 

Wrote your ST image to disk and it does not load. Stays at black screen, tested on Mega ST 4 TOS 1.04 and 4160STE TOS 2.06. Your HAGA version works fine.

[ParanoidLittleMan]

I tested it on real HW, with real floppy disks, and it works. But must say that from 5 floppy disks, only with 2. The reason is age if them, of course, + that this is 11 sectors/track.

But bootsector shows 9 sectors/track - that may confuse copy SW.

So, disk in good shape + SW what can write hyperformat, and can manually correct CHS values. I used my Tracc - same what I used to check where are CRC errors - see screenshot in post above.

It is even possible, and will be more reliable to use HD floppy - without covering hole - on Mega STE for instance, or ST(E) with HD floppy add-on .

[ParanoidLittleMan]

This talk about hyperformat above made me thinking little about that loading time check. It makes perfect sense:

Pirate copies need to be done with 11 sectors/track, and that means normally very small sector gaps, and chance that some sector will be no read at once, so will need to wait another rotation. Normally, hyperformat is with interleave, so sector order is 1,3,5,7,9,11,2,4,6,8,10 - right because small gaps. But this game is with short sector #11, only 128 bytes, so no need for small gaps, no need for interleave.

So, may say with confidence that it is copy protection. Because most of copy SW is not ready for such track format. And especially was not so in 1988. And yes, as usual, I was in right in my first posts, when said that I deactivated copy protection.

It's another thing that check was not done very well, and fails on real HW too, not only on emulators.

[tjlazer]

Oh ok I used a few different disks and also a HD one with your FloImage tool on Win 7.