SDCard HxC Floppy Emulator Preordering

[DrCoolZic]

Examples: Maupiti Island (Maxis crack - 12 sectors per track)

Be aware that this is not "real" 12 * 512 bytes sector (6144 bytes) / track as this far above what can be read by the Atari see http://info-coach.fr/atari/software/FD-Soft.php

In fact this is a protection mechanism (see in http://info-coach.fr/atari/software/preservation.php) that I call sector within sector and the full explanation can be found In the document http://info-coach.fr/atari/documents/my ... ection.pdf

[DrCoolZic]

That thread has misleading title: STT image files

I did a search but could not find it ? Can you provide pointer
Thanks

PS ordered the USB HxC Floppy Emulator

[SofiST]

yes, those are in the new implementation of firmware & porgrams.
I wonder if it will work in my SD HxC as it does not have that extra hardware on it.

I don't have SD version, but as know it works with preconverted images to own format. Hardly that mentioned updates need any hardware changes, or even firmware change. The point is - if I'm correct about need to run preconverted images with SD version that you need only new version of converting SW, and reconvert (older ones) + copy on SD card images.
As own format must support all features as skew and irregular sector IDs, all STT, ST, MSA must work, just now faster.
It would be good that someone of U2 (Wongck and DrCool) write here how it went ...

[SofiST]

Be aware that this is not "real" 12 * 512 bytes sector (6144 bytes) / track as this far above what can be read by the Atari see http://info-coach.fr/atari/software/FD-Soft.php...

I don't think so. It is not supposed to be protection, and there is even option for copy, right after boot. Actually, Atari can read so much, but can not write. Except if floppy drive has slower rotation speed. I'm pretty sure that author had such drive, otherwise it would not work. And I tested it. Not to mention that STT format supports not such tricky things as sector in sector. I tested it so, that wrote STT image on HD floppy (on PC- where 6144 bytes easy fit on track. Then it worked on real Atari.
After it I tried to copy on DS floppy (from game launcher self, on STE), but it failed. Naturally, as drive has exactly 300 rpm.

I did a search but could not find it ? Can you provide pointer
Thanks

I wrote here main content of that post, but if you insists: viewtopic.php?f=3&t=19789
Now you own me one STT image file

[wongck]

yes, those are in the new implementation of firmware & porgrams.
I wonder if it will work in my SD HxC as it does not have that extra hardware on it.

I don't have SD version, but as know it works with preconverted images to own format. Hardly that mentioned updates need any hardware changes, or even firmware change. The point is - if I'm correct about need to run preconverted images with SD version that you need only new version of converting SW, and reconvert (older ones) + copy on SD card images.
As own format must support all features as skew and irregular sector IDs, all STT, ST, MSA must work, just now faster.
It would be good that someone of U2 (Wongck and DrCool) write here how it went ...

yeah. Thanks for pointing out.

there are 2 different updates
1. for the firmware
2. for the convertor program.

the firmware update release notes mentioned some new diy hardware.... and we all know the mess I did on soldering 2 resistors
so i was wondering if i need to do those hardware stuff if I was to go to the new firmware.

the converter proggie, no issues.
i am using those now

[DrCoolZic]

Be aware that this is not "real" 12 * 512 bytes sector (6144 bytes) / track as this far above what can be read by the Atari see http://info-coach.fr/atari/software/FD-Soft.php...

Actually, Atari can read so much, but can not write. Except if floppy drive has slower rotation speed.

The 3 1/2 FD are spinning at 300 RPM which implies a 200 ms total track time. As the MFM cells have a length of 4 µsec this gives a total of 50000 cells and therefore about 6250 bytes per track.
It is therefore not possible to fit 6144 bytes of DATA in a 6250 bytes track (look at the minimum gap value in my site http://info-coach.fr/atari/software/FD-Soft.php

Not to mention that STT format supports not such tricky things as sector in sector. I tested it so, that wrote STT image on HD floppy (on PC- where 6144 bytes easy fit on track. Then it worked on real Atari.
After it I tried to copy on DS floppy (from game launcher self, on STE), but it failed. Naturally, as drive has exactly 300 rpm.

Actually this is the interesting part: the program reading such track does not need to know anything about sector withing sector It just reads the 12 sectors as if there where separate sectors Not that if all sectors are 512 bytes the last sector has probably a CRC error but STT format should be able to handle this information (I am not familiar with the STT format)

Actually it is interesting to note that in most cases an imaging program does need to know or care about details of the protection: it just need to record precisely what is read by the Atari FDC, however reproducing the same behavior on a FD is usually not possible or difficult.

[SofiST]

I think that we agreed that is not possible to write so much ....
But explaining case different. You should try that image file, and will see that there is talk about some super tight format, and 960 KB per disk. I post it here ...
Btw. I know about case where last sector missing CRC. It is by all 6 ReadySoft 'laser' games - as Space Ace, Dragon's Lair serials.
There is 12 sector/track, but last is truncated for 144 bytes. CRC is before it. STT can handle it, but I have no correct STT files for, because Steem can not make good STTs from STX images (all OK). By all images 3-4 sectors missing - always first ones on track. I asked Marakatti to do STT images right from original floppies, but still nothing ...

[DrCoolZic]

I think that we agreed that is not possible to write so much ....
But explaining case different. You should try that image file, and will see that there is talk about some super tight format, and 960 KB per disk. I post it here ...
Btw. I know about case where last sector missing CRC. It is by all 6 ReadySoft 'laser' games - as Space Ace, Dragon's Lair serials.
There is 12 sector/track, but last is truncated for 144 bytes. CRC is before it. STT can handle it, but I have no correct STT files for, because Steem can not make good STTs from STX images (all OK). By all images 3-4 sectors missing - always first ones on track. I asked Marakatti to do STT images right from original floppies, but still nothing ...

I have just read some documents today where people talk about insane capacity on a DD FD. This is using protection on Amiga like Turican 1.1 MB
Therefore I had some doubt ... so I went to an expert ... Clauss Brod who wrote Scheiben Kleister II ... look here http://www.clausbrod.de/cgi-bin/view.pl ... yperformat he has written a program to get the most of an Atari diskette. So using 80 tracks he was able to go to 880K which is already pretty good. But this is about 5600 bytes per track => like 11 sector of 512 bytes.
Therefore 12 real 512 bytes sector / track is not feasible.
However I have been able to write track with over 12 sectors (e.g. 13 sectors) and read them correctly in that case you can read 6656 bytes from a track but of course this is not real sectors with independent byte content
Read "sector within sector" for more info on real example from games: Theme Park Mystery (image works) has 12 sectors / track on all tracks or about 980K

[SofiST]

What about checking suplied STT images, instead listing here some more-less known things ?

I repeat that this is Maupiti crack, with copy option, what works not. In copy is of course format rutine, and it has 12 sectors to format, in 2 pass, with different patterns. So, I write here unlike you something concrete and checked.
Why fails ? Because first sector on track is missing always after format. And that's why I say that author had slower floppy drive.
Amiga has pretty different floppy controller, and you can have whole tracks with perfectly readable data inside.

[DrCoolZic]

What about checking suplied STT images, instead listing here some more-less known things ?
I repeat that this is Maupiti crack, with copy option, what works not.

I am no sure what I am suppose to check (beside I know almost nothing about STT)?
To give more information about protection on a game I need an original FD. I do not think that I have Maupiti Island in my collection but I will check.
From your description the technque looks very similar with Theme Park Mystery that I have analyzed and has 12 sectors / track on all tracks.

[SofiST]

What about checking suplied STT images, instead listing here some more-less known things ?
I repeat that this is Maupiti crack, with copy option, what works not.

I am no sure what I am suppose to check (beside I know almost nothing about STT)?
To give more information about protection on a game I need an original FD. I do not think that I have Maupiti Island in my collection but I will check.
From your description the technque looks very similar with Theme Park Mystery that I have analyzed and has 12 sectors / track on all tracks.

You need to check STT images what I posted here ! Find in them 'sectors in sectors' . Look copy code with some debugger - Steem Debugger for instance ... And read what others write

Ahhhh , and I must to say for 1000-th time that I do not talk about original Maupiti, but crack !!!!! I know how Maupiti is protected, btw. Only my problem is that I can not get English version Pasti images.

[DrCoolZic]

You need to check STT images what I posted here ! Find in them 'sectors in sectors' . Look copy code with some debugger - Steem Debugger for instance ... And read what others write

I have tried to read the sst files under steem and it says: "Maupiti1.stt is not in the correct format, it may be corrupt" (same with second image) ???
Actually it would be fun to try as I have never tried my detection program on an image! (one problem program expect FD to be write protected. Is this possible under Steem? could not find a switch fro that?

Find in them 'sectors in sectors'

I doubt that stt store this kind of information which is rather complex and not useful for emulation/preservation.

Ahhhh , and I must to say for 1000-th time that I do not talk about original Maupiti, but crack !!!!! I know how Maupiti is protected, btw. Only my problem is that I can not get English version Pasti images.

If this is a crack what is the point of checking? Just to check that stt format can contain more data than real FD? Again the purpose of this protection is that you can read correctly 12 sect/trk (or even 13 or more if you want) but of course you cannot copy this info into another floppy.

And read what others write

I do or at least try

[SofiST]

I have tried to read the sst files under steem and it says: "Maupiti1.stt is not in the correct format, it may be corrupt" (same with second image) ???
Actually it would be fun to try as I have never tried my detection program on an image! (one problem program expect FD to be write protected. Is this possible under Steem? could not find a switch fro that?

What Steem version ? It works well with Steem (Debugger) 3.2, Windows vers.. Only that need to deactivate Pasti before, so can open.
STT should be write protected, or at least you can not write into with Steem. But there are switches in floppy options for protecting images. Or just set files as write protected with Total Commander ?

I doubt that stt store this kind of information which is rather complex and not useful for emulation/preservation.

Huh. You repeat my words from this thread

If this is a crack what is the point of checking? Just to check that stt format can contain more data than real FD? Again the purpose of this protection is that you can read correctly 12 sect/trk (or even 13 or more if you want) but of course you cannot copy this info into another floppy.

This thread is not about protections but HdX floppy emulator - and what it can !
The point of checking is that you see how you were wrong with your postings here
And as said, can copy to HD floppy - and it even works if have HD circuit in ST(E).
Sorry for many exclamations and smileys

[DrCoolZic]

Sorry dont want to disrupt more this thread but in case you are interested about what is going on with Maupiti Island look here http://www.sarnau.info/atari:protection_maupiti_island or here viewtopic.php?f=47&t=19948#p174592

[SofiST]

Thanx. Any chance to check STT support with HxC, SD variant ?

[Jeff_HxC2001]

Thanx. Any chance to check STT support with HxC, SD variant ?

What is done for the USB variant , is done automatically for the SD variant.
So STT is supported by the SD variant...

[wongck]

My SDCard HxC is working great.
However, I see that there is a new firmware v1.3.0.2 & possibly some new hardware adjustment for Amiga write mode.
Question is: will this new firmware work on the SDcard HxC emulator that does not have the mod for the Amiga write mode?

[SofiST]

...
What is done for the USB variant , is done automatically for the SD variant.
So STT is supported by the SD variant...

Yes, you do excellent job with all those updates.
I just want that some user/owner describe here how it exactly goes with SD variant.

[DrCoolZic]

Thanx. Any chance to check STT support with HxC, SD variant ?

What is done for the USB variant , is done automatically for the SD variant.
So STT is supported by the SD variant...

Just to be sure SD variant does not support STX? Or at least the variable bit rate?
Thanks

[Jeff_HxC2001]

My SDCard HxC is working great.
However, I see that there is a new firmware v1.3.0.2 & possibly some new hardware adjustment for Amiga write mode.
Question is: will this new firmware work on the SDcard HxC emulator that does not have the mod for the Amiga write mode?

Yes.

[Jeff_HxC2001]

...
What is done for the USB variant , is done automatically for the SD variant.
So STT is supported by the SD variant...

Yes, you do excellent job with all those updates.
I just want that some user/owner describe here how it exactly goes with SD variant.

Thanx. Any chance to check STT support with HxC, SD variant ?

What is done for the USB variant , is done automatically for the SD variant.
So STT is supported by the SD variant...

Just to be sure SD variant does not support STX? Or at least the variable bit rate?
Thanks

STX can be converted to HFE for the SD HxCFE at a fixed bitrate.
Variable bitrate will be done latter.

[DrCoolZic]

STX can be converted to HFE for the SD HxCFE at a fixed bitrate.
Variable bitrate will be done latter.

This is quite interesting. I thought I had read somewhere that to minimize cost the SD variant would not be able to do variable bit rate.

[wongck]

My SDCard HxC is working great.
However, I see that there is a new firmware v1.3.0.2 & possibly some new hardware adjustment for Amiga write mode.
Question is: will this new firmware work on the SDcard HxC emulator that does not have the mod for the Amiga write mode?

Yes.

Great I am on it.

[Jeff_HxC2001]

Rev C SD HxC Floppy Emulator (with amiga write support) Preorder is now open ! :

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=180575793600

[majere]

Rev C SD HxC Floppy Emulator (with amiga write support) Preorder is now open ! :

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=180575793600

thanks, I just ordered one for me.

now have to wait a bit