ParanoidLittleMan

FLOEXTR.ZIP Above is special program for batch extracting content of ST, MSA image files. Usage instructions included. Can use it with emulators Steem and Hatari. Fastest work is with GEMDOS hard disk emulation, but from some reason Steem and Hatari don't preserve original file date and time, but will write there current one. If want to have original file date use real hard disk emulation with them - like ACSI emulation with Hatari, with Steem will need pasti.dll , and of course need image of hard disk/Flash card content and driver activated. Can do all it on real Atari ST, equipped with mass storage, just take care of enough free space on partition.

SYSINFO will work fine from C or whatever partition.

There are several ways to extract files from ST floppy image. Even if you don't have floppy drive with PC can use FloImg: http://atari.8bitchip.info/floimgd.php Open Another Image File, File Transfer . Then copy it to SD card . Can do with emulators - set ST image for floppy A, set some folder as GEMDOS drive in disk options, and then can copy file from it to partition assigned to that folder. On Atari can use Floppy Image Runner http://atari.8bitchip.info/imgrun.php or Virtual Floppy (that goes with my hard disk driver). And there are some others probably. And just for case: are you sure that in this case only *.PRG file is needed to run it, and no other files ? Even if no copy protection program might be done to run only from A: . I talk from experience - many of it can not run from hard disk (C: , D ...) without further changes.

First, that my reply was more to SnarkdluG, because this claim "Since Ultra Satan is hard disk drive replacement and *.ST is floppy disk images it is not really meant to go together. " Total nonsense, how on Earth they go together for plenty of people ? First question in this thread was about UltraSatan, and I was first who replied, very detailed, but that's irrelevant for some people, who like rather to find something bad instead .. SW for writing ST, MSA, and even STT images onto floppies is here: http://atari.8bitchip.info/floimgd.php And not only Windows v. , there is little lower Atari version too. TRACC - for whole disks, and CopyACC for filewise copy. Btw. I don't think that asking about UltraSatan, Gotek, Greaseweasel means that someone don't want to invest money. It seems rather like being in dilemma what to buy from mentioned. And yes, I can recommend UltraSatan, and it will help in writing ST images onto floppies a lot, so not only hard disk adaptations. If the goal is to write onto floppy disks owned, it can be done in different ways. First problem is to transfer downloaded ST/MSA images to Atari. Then, where to store them with Atari ? With only floppy drive, that's serious backdraw, and while is possible, really would not recommend to anyone in 21st Century. Now mass storage is cheap. However, writing images with same drive, with what it will be used on Atari (so, using built in drive, Atari self for) is best way considering reading reliability - there are always some differences between floppy drives, like head position. Instead UltraSatan Parcp(USB) could serve for transfers too, but then still need to split images, and that needs time, some knowledge. Let see other solutions: Gotek: by me surely better now than using floppy drive, even if copy protected stuff will not work in most cases. I don't know what max image sizes it supports on STs, but if it is for instance 880 KB, that could be fine for transferring images of 800 KB to PC. Third way - getting specialized device (flux technology), what can copy practically everything, so copy protections too - I think that it is most useful for people owning lot of original disks (games in first place), so they can preserve them as they are. If no originals, still can DL images (not ST, MSA, but much longer ones, with protections) and write to real floppies. I really don't know about that is available, are there some restrictions still in policy (like it was/is with IPF images) ? My personal experience is that floppy disks are just in way too bad shape now. It was bad enough for me 20 years ago, when I started to move everything possible on hard disks. It was easy with Sinclair Spectrum - SW was usually in single file (because tape storage), so it was easy to solve start of it from floppy (first added floppy drive), or hard disk. With Atari ST, it's FAT12/16 filesystem, floppy controller and multiple files, possible really many ways of copy protection + ways of loading SW from floppies it is much-much more complicated, I would say at least 100 times. But one thing is common: floppies are unreliable now. I have couple hundreds of floppy disks, and I'm sometimes forced to use them - for testing floppy release of some game - usually do it when can do better than existing 'cracks' (like some TOS compatibility fix, trainer options ...). But it goes usually that I find couple bad floppies, where write errors are indicated during write, so they go in trash. Last time with Pang it was really too bad, and took about whole hour while I reached flawless disk, and it worked. It was already tested in emulators, but I always do real HW test, as real one. Wasted time, nerves. But I still do those ST images, because some can use them, and maybe have better luck with floppies. Can get them here: http://atari.8bitchip.info/ASTGA/astgam.php Beside unreliability of old floppy disks and drives what hurts is how people tends to make simple explanations and statements. This with Atari ST SW running was not simple even in times when almost nobody had hard disk. It's really not easy to judge what is what makes some SW not working well, or at all. TOS version incompatibility, poor code, or even silly problem that game works only with 512 KB (or 1 MB) RAM, but not on machines with more - and that's not all. To the end of this longer post something based on recent work of me: game Barbarian 2 by Palace SW. I started thread about it's copy protection here: https://atariage.com/forums/topic/316467-barbarian-2-by-palace-interesting-copy-prot/ That decrypting during load slows it down, but even more slowdown is because file loads are divided into 512 byte chunks, with slow code for placing it to final dest. - and it loads really slow. So, I replaced it with direct load, from already decrypted disk image, and was even able to put it all on single floppy (with little packing) . Original is on 3 SS floppies and all it fits on some 600 KB space. And it works with Virtual Floppy too, or old Floppy Image Runner - because all disk access is via TOS. That's what matters, not disk image format. Why this is so complicated ? In biggest part because SW authors used lot of diverse ways for loading from disk(s) - partially because copy protection, partially to have more free RAM (direct FDC access can be solved with very short code, about 500 bytes, and then you have some 40-50 KB more free space, because no need for TOS disk workspace) . And sadder part: sometimes it is just because low knowledge, poor documentation, lack of equipment and/or will for testing.

Well, if someone took out resistors from it, that's most likely because it was broken, maybe seriously and could not repair. That's indicated by writing on chip at right. So repair can be much more harder than putting there missing resistors.

Found some interesting things in code of game, and a way to put it all on 1 disk, + much faster load. So, there is ST floppy image file. Min RAM 512 KB. Unlimited lives opt. B21FLO.ZIP

I did not mention Floppy Image Runner because now there are some newer solutions, which work with less RAM. Look my previous reply here.

Did not see such protection, even if saw really plenty of them. Copy protection self is Rob Northen Copylock, early version. What is interesting is that disks are actually FAT12 with regular files, but all it is encrypted, so can not see anything of files when looking with some hex viewer for instance. Game code self using regular Trap #1 calls for file access, but there is shorter decrypt code, hooked to RWABS (trap #13 4), what restores normal floppy content. Of course, it will be good only when copy protection is passed, which is encrypted too. The decrypt code self: * Barbarian 2 Palace * RWABS for floppy decrypter code org $300 movem.l d0-4/a0/a6,-(a7) ; 000300: 48E7 F882 lea 34(a7),a6 ; 000304: 4DEF 0022 btst #$d,28(a7) ; 000308: 082F 000D 001C bne.s l312 ; 00030E: 6602 move usp,a6 ; 000310: 4E6E l312 cmpi.w #$4,(a6) ; 000312: 0C56 0004 bne.s l374 ; 000316: 665C btst #$0,3(a6) * odd address ?; 000318: 082E 0000 0003 beq.s l33E ; 00031E: 671E bsr.s l380 ; 000320: 615E l322 move.l $7c,d3 ; 000322: 2639 0000 007C add.w d2,d3 ; 000328: D642 moveq #127,d0 ; 00032A: 707F l32C bsr.s l38E ; 00032C: 6160 move.l (a0),d4 ; 00032E: 2810 sub.l d3,(a0)+ ; 000330: 9798 add.l d4,d3 ; 000332: D684 dbra d0,l32C ; 000334: 51C8 FFF6 addq.w #1,d2 ; 000338: 5242 subq.w #1,d1 ; 00033A: 5341 bne.s l322 ; 00033C: 66E4 l33E lea 14(a6),a0 ; 00033E: 41EE 000E moveq #6,d0 ; 000342: 7006 l344 move.w -(a0),-(a7) ; 000344: 3F20 dbra d0,l344 ; 000346: 51C8 FFFC trap #15 ; 00034A: 4E4F lea 14(a7),a7 ; 00034C: 4FEF 000E move.l d0,(a7) ; 000350: 2E80 bsr.s l380 ; 000352: 612C l354 move.l $7c,d3 ; 000354: 2639 0000 007C add.w d2,d3 ; 00035A: D642 moveq #127,d0 ; 00035C: 707F l35E bsr.s l38E ; 00035E: 612E add.l d3,(a0) ; 000360: D790 add.l (a0)+,d3 ; 000362: D698 dbra d0,-l35E ; 000364: 51C8 FFF8 addq.w #1,d2 ; 000368: 5242 subq.w #1,d1 ; 00036A: 5341 bne.s l354 ; 00036C: 66E6 movem.l (a7)+,d0-4/a0/a6 ; 00036E: 4CDF 411F rte ; 000372: 4E73 l374 movem.l (a7)+,d0-4/a0/a6 ; 000374: 4CDF 411F move.l $bc,-(a7) ; 000378: 2F39 0000 00BC rts * ret via trap #15 what goes via trap #13 vector l380 move.w 10(a6),d2 ; 000380: 342E 000A move.w 8(a6),d1 ; 000384: 322E 0008 movea.l 4(a6),a0 ; 000388: 206E 0004 rts ; 00038C: 4E75 l38E lsl.l #1,d3 ; 00038E: E38B btst #$1,d3 ; 000390: 0803 0001 beq.s l39E ; 000394: 6708 btst #$15,d3 ; 000396: 0803 0015 beq.s l3A4 ; 00039A: 6708 bra.s l3A6 ; 00039C: 6008 l39E btst #$15,d3 ; 00039E: 0803 0015 beq.s l3A6 ; 0003A2: 6702 l3A4 addq.l #1,d3 ; 0003A4: 5283 l3A6 rts ; 0003A6: 4E75 At address $7C decrypt key value is placed, and if it is set properly, + vectors for trap #13 and #15 too, files can be accessed and copied.

Here is Barbarian 2 by Palace, for hard disks: BARB2PAL.ZIP Complete game with trainer opt. Min RAM 1 MB.

There are ways to use ST floppy images on Atari, stored on SD cards, via some adapter like UltraSatan. But first to say: not everything will work. Some games in first place. And some games will not work with Gotek too, although more will work than from mass storage. It is one thing to work in emulator, and other with real HW - if SW (game) has direct disk access, and not via TOS functions it will not work. And there may be some copy protections too. May hard disk driver has Virtual Floppy feature http://atari.8bitchip.info/pphdr.php that's good for not copy protected SW, what used TOS calls for disk access (trap #1 and XBIOS ), and some games work with it, but for sure is better to use hard disk adaptation if it is available (and there is plenty of it now) . Virtual Floppy is more for user disks, which are in regular format, so they will work for sure on real Atari, and some large images are possible too - up to 2MB . Even better is virtual floppy in improved TOS : http://atari.8bitchip.info/tosimav.html To add that they are better than 'converting' ST image -actually copying files from it on hard disk. Because some SW is coded to run from disk A only.

TOS 1.04 can not work in STE, only in ST. And btw. 1.04 and 1.06 are practically identical, done in same time (1989), except extra functions in 1.06, for supporting it's extra HW. Even if someone would relocate 1.04 to address space of 1.06, that will not work in STE - because will not initialize all HW. 1.62 is just bugfixed 1.06 (medium res. DESKTOP.INF bug) . Considering PSU load with expanded RAM: that will be no problem, RAM consumes little power. But, because of age, recapping PSU is very recommended.

MMU emulation might be needed for some SW. I'm not sure how it is good now. Earlier it was problematic. There were some flaws in video emulation too. I use v. 2.1 . Don't know about newer - not using it frequently. 512 MB TT RAM ? What SW will need it ? 🙂

PP HD driver, regular version from 2014 is latest. There is newer one, with Virtual Floppy feature, what is extended functionality. http://atari.8bitchip.info/pphdr.php Yes, some ST(E) machines were shipped with TOS ROM chips without sockets (hard saving times ?) - in that case need to remove chips, solder sockets, and then can put updated EPROMs there .. I dealt with Barbarian 2 from Psygnosis - hard case. Here is test version: BARB2PST.ZIP Not complete game, 3-rd floppy is not yet implemented. There are 2 launchers - 1 is for machines with 1 MB RAM, other for 2 MB or more, then will have some animation after start .

Here is that PDF TOS_Extension_Card.zip But that's not for some hard disk interface, I just looked thru it, and saw those false limits. I did not see ICD driver DOCs, but that claim is certainly wrong. Why I know it ? Because my driver SW has no those special limits for first partition, and btw. any partition can be set as first (C:) during driver start. http://atari.8bitchip.info/pphdr.php Plus, I know TOS well, and even did some improving of it's FAT16 code. Possible that those claims about 16 and 32 MB limits are because lack of information - for larger partitions driver self need to reserve larger buffer space, so called BCB (buffer control blocks). Initially it is 2 KB, what is good for floppies, and hard disk partitions with logical sector size of 512 bytes. For larger ones larger logical sectors are needed, and that needs larger buffer space too. For 512 MB partitions 32 KB buffer space is needed (1.04 and above). So, the correct statement would be: there are 'limits of TOS' - some are caused by TOS self, some are caused by lack, unavailability of DOCumentation, or just pure shallowness of those who published it. To add, that 16 MB for partition was too little even in 1985. Just calculate how much is 1024/16 - 64 partitions would be needed to fill 1 GB drive - possible, but would need using some Chinese letters for later ones 🙂

Just received e-mail from one user of TOS Extension Card by CodeHead Technologies - it is for TOS 2.06 in STs . And what saw in original DOCs for it (PDF attached): "WARNING: Beginning with TOS 1.04, Atari computers allowed GEM hard drive partitions up to 32 megabytes in length; however TOS 1.00 and 1.02 are limited to 16 megabyte partitions." Sadly, not so rare case of misinformation.

Actually, 16 MB limit for first (boot) partition is not TOS limit, for TOS all partitions are equal in that manner. The reason why some drivers have it is that main part of driver (usually some *.SYS file) is placed on partition C, and it can become fragmented - for instance when installing updated version. Code to read it is in master bootsector (MBR), and there space is limited. With smaller size partition it is simpler. Btw. there are ways to read and execute longer code from MBR, actually simple way, so that 16 MB limit is just limit of conception of driver. Now, some small partition sizes limit for all of them is probably driver code limit. What might be because used C compiler limits, for instance. I don't remember driver with such limits, but I really did not see much of them. Everything is possible in coding waters. Certainly, with drive sizes in those times it was not so bad to have smaller partitions. I had 2.5 inch IBM drives of 160 MB, and all partitions were under 32 MB - with good reason - they were so TOS/DOS compatible. For larger partitions than 32 MB special partitioning and driver is needed to have it. There were limits with drives and adapters too - known 1 GB limit for ACSI (DMA) of Atari ST. IDE (AT bus) disk max capacity with CHS addressing - if remember correct it was 512 MB .

Wizard Royal ? http://www.atarimania.com/game-atari-st-wizard-royal_10859.html

I don't think that ICD drivers support DOS type partitions. Can you access files, partitions on SD cards with some modern OS directly, without extra SW ? In any case, use this only in case of problem, and that's is not be able to access first partitions on Flash cards with Win 10. Not working autoboot can be fixed with reinstalling driver. And just doing Check will not harm for sure.

Here is fixing tool: ACSIFIXT.ZIP Read included instructions. This is for ACSI devices only - like UltraSatan, Satandisk, GigaFile, diverse ACSI-SCSI adapters, etc. If there will be need, I will make program version for IDE disks (CF cards) too.

I can confirm that there were/are significant delays in delivery in latest 2 months.

Hmmm... - there are actually 2 Barbarian 2 games: one from Psygnosis, other from Palace . And they surely don't use TOS keyboard read. Will make HAGA releases of both. That page is instructions for Virtual Floppy feature of improved TOS. You can not DL it - it needs replacement of TOS chips in ST. http://atari.8bitchip.info/tosimav.html And that will not solve disk replacement in case of Barbarian games . Originals are even without regular files, so I guess you used some crack where it was filed. Ah, and yes, I'm the same 🙂

Yes, there were/are many, which I never seen, heard about . Atarimania does great job by hosting really almost everything what was made, or at least there is page about game. My latest adaptations: http://atari.8bitchip.info/fromhd2.php Ameoba Wars : classic game Life for GEM, in med res. Aventura Original & Aventura Espacial : adventures in Spanish language, with nice graphic. Star Trek by Erictronics : lot of well done samples from original Star Trek series (TOS) Hollywood Hustler : not only samples, but lot of digitized pictures, animations. On 3 floppies originally, from 1994. Debut : Planet simulation with platform game part. This was hard case because strange floppy formats. Did not see any floppy release with all 3 parts of game, so did it too: http://atari.8bitchip.info/ASTGA/D/debut.php

This was loooong time ago. In meantime lot of it happened, lot of games is adapted for hard disk run - and that's what is more comfortable way of running multi floppy games. Considering using floppy image files on Ataris equipped with hard disks/Flash card adapters there are better ways now. But first to reply about disk change: it works not with all SW/games - if code in SW replaces TOS keyboard reading code pressing of shift will be not detected, so no 'disk' change. And there is actually no way to solve it without changing game's code self - separately for each one. What is done in most of hard disk adaptations - needed for exit to Desktop and state saves. Now we have better ways of 'running' floppy images - main advantage is that images are not kept in RAM, but on hard disk, and when there is floppy disk/data access from SW (via TOS calls like Trap #1 and XBIOS ) then it will be read from hard disk and not RAM. So, less RAM usage, more and larger images possible. Hard disk driver with Virtual Floppy feature: http://atari.8bitchip.info/pphdr.php It can work with ST floppy image files up to 2 MB size. And why 2 MB ? Right because avoiding 'disk' changes, if possible. User can put in so large image file up to 3 usual DS floppy contents. But don't expect that it will work with everything. Some SW, especially games have diverse ways of checking which floppy is inserted and even if all files are present in large image, will not detect that proper disk is inserted (check of disk Volume label, some special sector ...) . Then again, only changes in game code can solve it. Even better Virtual Floppy solution: http://atari.8bitchip.info/tosimav.html It is integrated in TOS (improved original TOS versions), and that gives best results - RAM usage is same as by machines equipped only with floppy - hard disk driver is in ROM, and takes not RAM. Very large image files are possible, there is better disk image change with keyboard (that was hard part to solve), but as is said above - if SW/game code takes over keyboard read from TOS, it will not work. My idea, 12 years ago about making some 'on fly' patching of disk access code was never realized, and things are that there is too much diverse direct FDC access code often done not well, that it is almost impossible, for sure too much complications and time would be needed, for part of cracks, which might be not complete, for instance. Better to use STX and other images of originals as source - there are enough problems with them too. Btw. jmprice - what program/game is that ?

"internally stripping out the sync?" - that's what every analog ( PAL, NTSC, B/W ) TV does. Sync must be separated from video to work. In other words, composite sync , pardon sync in composite video is fine.

Those E1, E2, E3 are not drive letters, they are volume labels which my partitioner creates. Actually it is P1 for first, primary type partition, E2, E3 are extended partitions. Windows will assign for them free drive letters - for instance if there is C,D,E,H for hard disk partitions in PC, then it will assign F,G, I, J ... for partitions on removable. I found what is problem: second byte of partition record now (according to Microsoft) can not hold value 1, that's 'invalid' . However that's usual value there, because that field is for CHS value of first partition, and it is usually 1. Surely, CHS is obsolete, but it really harms nothing to have there value 1, and 3 bytes reserved for it are not used for something other. I just wrote there $80, detached card, and reinserted - and Win 10 mounted first partition too. Fine. Then, let's see other cards, and surprise: it mounted first partition on them, even if there was value 1 on that loc. by them ! Then I reinserted card where I corrected that value, and wrote there 1, to restore original value - and after reinsert it still mounted first partition on card ... Some kind of A.I. ? 😄 I even restarted Win, and it still recognizes first partitions now. Really funny. Now, question is will need to make some simple program to correct that value in MBR, so people can easily override problem ?