AstFan

Some people worked on it, and here is description : http://www.sarnau.info/atari:pasti_file_format Surely that desc. from author self would be better and likely more detailed, but we are where we are ... He is too 'busy' for it . Or just wants all credits for self, or who knows ... I can say that pasti format is very similar to STT format (Steems extended one, for some simpler protections, not much spread). Since author, it seems refuses any cooperation and sharing specs, we can do 2 things: waiting that his highness one day do promised things (supporting SW, publishing specs, doing support for floppy writing etc.). Or maybe that we do things self. I will soon try with converting some STX images to STT ones - it should work with some specific protections, and STT is writeable on floppies and works well with HxC emulator.

Don't let that name confuse you It is just system of firm Magnetic Scrolls . Basically, it is custom WIMP for playing games. So, Windows, Icons, Mouse, Pull-down menus . Most similar to MAC 'Windows' . I guess that they made platform independent main code for it, as games were made for most of 16-bitters. There are couple other games for ST with WIMP, as Deja Vu 1-2, Uninvited, Shadowgate . But they use regular GEM, AES .

For sure, OS functions are not speed champions. In case of TOS there is a lot of for game unnecessary things done by usual Trap calls. Like saving all registers (this is not too slow), then saving almost complete stack (little slower), then comes more-less efficient branching by function # , etc ... But if function is called only by initialisation it is not problem if is slow(er). I currently do game adaptations updates for TT, and almost every second game has problems because writing directly into Video HW registers. If they used TOS calls there would be no so much non-working on TT. But TOS call usage is possible only if low RAM is not destroyed by game self. Still, all necessary settings can be done before game low RAM part load - with TOS calls. But that practice is not common. Sloppy programming : it is possible in many ways. I see mostly problems with IKBD chip programming in games - maybe there was no good documentation available in 80-es ? Can not blame programmers not doing Falcon and TT compatible code before those machines arrived. Although, there are cases of some weird code, which does nothing useful, contrary... Case of EPIC and some traps when 68030 is detected - total crap. Considering : "If it were a single-sided disk (on the ST) I seem to remember using disks that would step the head one track with each rotation of the disk (bump-bump-bump) as fast as possible, reading the data as fast as was physically possible. I don't ever remember an Atari 8-bit doing this. However, on either system, I remember head positioning and grinding (and delays) as the software forced the drive check for copy protection." If there is only 9 sectors/track it is possible easy. But with by Atari ST usual 10 s/tr no way, even with fastest code. Because we need some time after step for head settle (that oscillations stop). So, only way to avoid 2 rotations average for 1 track read is skew. It means that second track starts not with sector 1, but with 10 or 9 . Then during stepping and settle down time sectors 9 and 10 will be under head, and sector #1 od track 2 just right in proper moment. It is of course little slower than skewless 1 track/rotation read, but not much more, just 10-20% . And it explains why popular Fast Copy Pro is so fast. But there is many other programm which does same skewed formatting of floppies. And even TOS self, at v. 2.06 .

Filesys functions are needed if game must load some further data after start - and it is case when not all data fits in RAM at once. Filesys provides some functions which require extra code with direct floppy access - as easy accessing any part of file. Considering graphic and sound: yes, sound and graphic is programmed usually with direct HW access. But for instance setting screen base, res goes via XBIOS calls. And it is recommended (by Atari) and most compatible way. If you write directly into Video sync. reg. it will fail on TT for instance. From experience, what is most called: video settings, IKBD chip settings, RAM allocation, BIOS calls for keyboard reading, mouse reading. Mouse handling is btw. not as expected in GEM (AES), but in GEMDOS. Only that is not initialised before AES start. Same stays for Line-A. All Line-A functions together with via blitter executed ones are in GEMDOS, not GEM . So, games with AUTO or boot start can use TOS mouse functions - examples: Dungeon Master, Millennium 2.2 (later use Line-A too) .

My statistic says different, and I went through nearly 500 games. Actually, about 50-60% of Atari ST games uses TOS more than just for starting. XBIOS, BIOS functions called, and mostly filesystem functions (loading files via regular GEMDOS) . For instance all Silmarils games are very TOS dependant, and they made quality games, isn't ? Yes, clock cycle depending code is used for some great effects, enhancements. Unfortunately it ended with era of pipelined CPUs, where it works not. Maybe not so unfortunately, because parallel with new CPUs better video modes and more res. came too

If you want 'premiere' emulator, best ask some big SW firm to make it and pay for :-) Still, it will be 'clunky' and 'excessive busy'

I agree that ST conversion can be made. But game seems not worth of effort. Parallax looks good, but soon getting headache from ...

Instead "best" - which is pretty messy and unreliable in fact, try this : http://www.thegamearchives.com Or http://planetemu.net/ For hard disk adaptations/fixes: still active site, now with TT support too: http://atari.8bitchip.info/fromhd.php

STX is special format for copy protected floppies. It is not possible to convert it to usual writeable formats as ST or MSA without loosing protection infos. If you want to write some game to floppy you need to DL some crack which is usually in writeable format as ST or MSA. In some rare cases STX is possible to convert to ST, MSA format - because people imaged many floppies without actual copy protection in STX format. But you need to be expert to judge what is such. 'Conversion' self is doable only with emulator on PC.

Master/slave is trivial thing considering 'converter cards' - you mean IDE-CF adapters ? All what you write just confirms unreliable work - like garbage. And it is always worse when 2 cards are attached at once. Suggestion: try with 2 Sandisk cards as master + slave. It is nothing unusual when some Kingston card reports as Hitachi or whatever. Kingston is just assembler, but chips are made by known (mostly) manufacturers. I have Kodak card which reports as Sandisk, and other similar cases .

4GB image with many games : http://atari.8bitchip.info/DiskImgPP1.html More games : http://atari.8bitchip.info/fromhd.php 520 STF can be upgraded to max 4MB. But it is not easy - need soldering skills.

Card brand and type is important on Falcon. Even more than on ST machines (with IDE adapter). What I can recommend is to do write reliability test, since it is most problem. Then, don't format with Hddriver. Format is for very old MFF/RLL drives only. With CF you need only to partition. Interesting is that I have same looking cheap Kingston CF card (not high speed), but 1GB only. And it is not good with Falcon - writing errors. On ST it works flawless and fast.

It is always 'pleasure' to see how people discussing primitive things without carefully reading what other saying. Anyway, what I can recommend is (and will say nothing new) : If want to transfer files from PC onto Atari ST: format floppy to regular 720K, DOS format. Best is to do it on PC. Under Win XP, Vista need to open console and type: format a: /n:9 /t:80 . Such disk will be usable under any TOS version. Formatting on ST with Desktop formatter is not good idea, even if TOS os 1.04 and higher. If nothing else, you loose 2KB of disk space because of stoopid set FAT size. Use some SW what has option to make DOS compatible format (FastCopy Pro for instance). If want to write floppy image files onto floppies with PC then formatting on ST is just waste of time. Just take care that set format on in imaging SW. Considering told that there is SW what can fix floppy formatted with some older TOS to be readable on PC - it stays, and such SW just writes proper start bytes. But I think that it just increases overall confusion - some people may think that it can fix any Atari formatted floppy, what is not correct. Most of problems is because bad floppies - poor qaulity. And of course because people does not read instructions, rather tries according to some own ideas how it would work - and usually it is wrong :-) Not to forget really hardly understable way how XP floppy driver works: it will open 800KB Atari floppy without any notice. But will read/write nn so, that skip every 10-th sector on track - so soing a mess.

Really too much incorrect and shallow writing here. TOS version is not important in fact. You just don't format with Desktop formatter if want to use that floppy on PC. There is a lot of floppy formatting SW for Atari ST, so you may produce 100% POC compatible floppy. FloImg works well on Vista and WIndows 7 - better said fdrawcmd is compatrible with them. Just get recent version.

Direct from disk playback in background on STE, TT, Falcon. Low system load. Different concept than usual SW for audio. http://atari.8bitchip.info/STEbap.html

Despite my nick here, I don't think that TOS was ever great. Why people comes back ? Mostly from same reasons why comes back with other oldies too :-) What was good, maybe 'great' with Atari ST is that it was pretty powerful machine good for diverse users (general usage): gamers, serious SW, programmers etc. And all it for low price. By me, it was the reason for success until 1990. We have some really great SW for it. TOS self has some stoopid flaws, not much known, discussed. For instance there is some 20 KB of RAM space wasted when running programs from AUTO. Only SW what used it is Dungeon Master. Then, really stoopid case of using extension PRG in AUTO folder DOS compatibility is choosen, but then why they did not make it fully ? Instead, floppy format not same, later patched little. Hard disk: using FAT16, but with different partition table without real reason, + different partition parameters with BGM made it incompatible with DOS.

Considering doing FAQ in WIKI: in theory it would be good. But in reality, it happens that same people not doing search of forum (threads) not goes on WIKI too. Instead, they post what is asked many-many times . I guess that some 10 FAQ on top of sections should do the thing. I can do some of them in my areas as mass storage, floppy imaging game adaptations and similar. Btw. I wrote on WIKI too, but don't have impression that it is much visited. I think that something like on EAB would be good : a lot of SW related (sub)sections . I too think that forum should be restored as it is possible with present data. Not much chance that will ever get it from old host, and I have experiences with that.

What is interesting in all this, or should be noticed, without any malice: main admins of forum in last years, MugUk and Techie Allison are away from restoring and even more, some are away from forum for longer time. For me, bigger concern than restoring all possible posts and Wiki etc. is: will there happen some really positive changes considering forum management, administrating, moderating. It was just not good in last 3 years. Instead leaving that most active and contributing people lead forum, it was on Atarilegend members, just by some inertia. Plus, there is a lot of people listed as moderator who is away from forum for years. Then, forum desparately missing better handling, some FAQ sections to avoid constantly repeating questions about common issues as disk imaging and similar. In fact, nothing good is made really in last 3 years. Contrary, many people left forum. Some new came, and some became very active. Maybe that give them right to lead forum ... I don't care for past merits. Please, give it to new, active people (and I don't think here on myself). I'm afraid that with same leadership as so far we can just wait new periods of forum down and less and less active and contributing people there.

Actually, graphic code in TOS is done in ASM too. Line-A, VDI ... But surely not the fastest ASM possible. Plus, it is slowed down with inefficient C-type parameter passing.

What I said is from experience. And OS not always runs in supervisor mode - for instance AES must run in user mode (except Trapped function handling code). I did not test it because have no 68010 CPU, but for sure that some SR reading must be in AES (Desktop) code. By experience too: most of games works all time in Supervisor mode, so no SR read problem on 68010 should happen. Exception is game Gravity for instance. I don't get what you want with "Move sr.ea is a user mode problem not a supervisor one If the OS uses this instruction it won't matter." . We want that all SW run on our machine, isn't ? Btw. there may be other problems with 68010: if it executes some instructions faster than 68000 it may affect timing sensitive code. However, it is mostly demo and game related.

Not correct. Only at 2.06 there is support for higher CPU versions. Although 68010 and 68012 are upward compatible, there is one case where code will fail: move sr to somewhere instruction. It is not privileged on 68000 but is privileged on higher ones. So, if SW performs such instruction in user mode on 68010 it will cause bombs. In TOS 2.06 and higher ones there is special code to override mentioned case, to make older SW runnable.

Yes. TOS 2.06 has support for 68010.

Atari ST and followers, so TT have not so much similarity with Apple machines - except using 680xx CPUs and WIMP. TOS has nothing with Apple, Macintosh. It is made by Digital Research, and is called GEMDOS with reason. It is actually pretty much function equialent to DOS on PCs. Not surprise, as DR made his DOS for PCs, + GEM . Don't see much sense for 'legal' instructions . Later versions are pretty much compatible - except some stack tricks and similar.

All these games are Mega STE compatible - as they are released after appearance of Mega STE. And Substation works well with 16MHz. Even hard disk compatible - except Stardust. So, no fixed version need. It seems that Shou has some minor failure with his Mega STE. These games are very picky, and may experience some problems even when other games work fine. For hard disk runnable Stardust visit: http://atari.8bitchip.info/fromhd.php

Right. Only thing what is not up to date may be: IDE hard disks. Instead them: Compact Flash cards. Then: 'instead of floppies' : I think that hard disk storage (what is SD in fact, looking by capacity, filesystem, drivers) is pretty different in many aspects than floppy storage. So, using SD, CF, hard disks is a new way of computer usage. For instance: playing games from hard disks requires new aproach, new solutions, adapting games, doing some help tools like Floppy Image Runner etc.