ParanoidLittleMan

There is another difference beside magnetic signal strength: frequency, and it is 2x in HD mode, and that needs stronger signal. I don't think that example with scratching is good here. Then, duration of magnetic recording depends actually more from magnetic media quality, temperature, humidity etc. And of course need to avoid exposing it to magnetic fields. Indeed it is best to use DD disks in DD drives, but if there is no such, HD might serve - not for longer storage, or at all for storage. There are much better, cheaper and faster ways for that. Floppies only for running some SW on oldie. As data, file transfer media, if no better equipment at hand. Btw. quality of floppy disks was pretty good in 80-es. Later it went down. As worse, what I had, and here talk only about DD disks were some BASF ones - maybe not originals.

Obviously Atari and DRI programmers used it. Even if maybe some of them were aware that better ones are available.

Socketed chips need to be carefully removed, cleaning contacts (pins) on socket and chip too, then insert them back. Problems appear mostly at those square ones with small pins and distance between. To remove them you can use very tiny screwdriver and put it in at holes at edges. Then push out side down slowly . Best to do it at 2 opposite sides, and only when it went up couple mm to remove totally. Usually there are no physical signs of weakened capacitors. Maybe smaller weight - but you don't have original weights. Things are that it is faster and cheaper to replace them than getting meter capable to measure their capacity. And after 30++ years it's pretty much sure that their lost some capacity. And overheating can be result of bad capacitor too.

It needs opening of machine and perform usual steps: reseating chips in sockets, best to do some cleaning of contacts carefully too. Because of age PSU electrolyte capacitors are most likely weak, so need replacement to new ones. Material is cheap, and can do it with little soldering experience. If above helps not will be harder to find culprit - may be Glue, Shifter, MMU ...

Those lines in Time Bandit are not because video adapter. Most likely corrupted copy/floppy, or maybe some smaller HW error of Atari.

I don't think that head cleaning disk needs some extra corrections - that's mechanical process, so all you need is to make it rotate - not with your hand 🙂 but click on A: for that. Btw. there is micro switch, #7 for activating HD mode in Mega STE, if there was DD drive by factory need to change it's pos. As was with mine, but there was already Ajax chip.

I think that we should separate it for today usage and usage in 'Atari ST years' - what Calimero actually did here. So, in later 80-e, early 90-es I used ST pretty much for both, almost equal - gaming, and some programming, data base handling and like. And actually did combination of two at once: game modding - like trainers, adapting it for hard disk run, or just packed 4 floppy data to single floppy (1.6 MB) . In later 90-es focus was on floppy content presentation - making images of them, and saving to more reliable media. Appearance of good Atari ST(E) emulators for modern computers renewed interest, combined with easy access to old SW via Internet, although there were diverse restrictions, side shut downs in beginning - even if all that SW was out of sale for many years. Currently Atari STs serve mostly for testing purposes. I don't think that 30 years old machines should serve everyday work or fun. And in my case it is much worse because doing diverse HW upgrades, mods, and testings of it, testings of programmed TOS EPROM chips ... So, I just reduced usage time, in purpose that it last longer. And there are some things what can do much better with Steem Debugger .

Spotted better mono emulator than those mentioned here: NC Mono - it can use blitter, but even without it is fastest. Plus, code is really short. So, I think that will go on with it. Probably will add 400 lines mode ... Can get it here: http://vezz.it/atari/stsoft.html

There is special connector for hard disks (in first place) on every ST(E), TT - 19 pin ACSI connector. And it is pretty fast for it's time - max speed is 2 MBytes/sec . There are solutions with cartridge port too. Opening ST is needed for IDE hard disk adapters.

Today, in 2021 easiest way is to use some Flash card based storage. What can be HW floppy emulator (HxC, Gotek ...). Or better some hard disk compatible one - UltraSatan, PeraSAN ... There are over 1400 games ready for hard disk run. That's fastest, most reliable and easiest to use. 'Easiest way to get games' ? Internet DL. And it may look that DL floppy images is easiest, straight way. But then appears that you can not write those images to floppy disks - because no floppy drive in modern computer. External USB floppy drive ? Forget it - can not write most of images because format limits. And even if have internal floppy drive in PC, that's pain in the ass - I talk from own experience. In later time I need to write 3-4 floppies (for 1 game on 1 floppy) that it work, just so unreliable with old drives and disks. I do it only for test purposed - when making new release of some game. Like this: http://atari.8bitchip.info/ASTGA/P/pang.php Otherwise, I even don't have attached floppy drive to my Atari normally. Cartridges: no games were distributed on ST cartridges. There was talk about reasons here many times. Low capacity (128 KB), high price in compare to floppies. Cartridge port was designed mostly for diagnostic purpose, for servicing (fixing) people. There were manufactured diverse things, even video digitizer. Myself made some things too, like EPROM programmer, fast mass storage adapter. And some shorter games can be run from cartridge too. http://atari.8bitchip.info/cartST.html But that's not easiest way, only easy to start game when it is already on cartridge. In case of wanting to play lot of games, some mass storage adapter is better and cheaper solution - prices of Flash cards are really low now, and even with price of adapter it is cheaper than some 4-5 cartridges. And you don't need EPROM programmer. And to add a bit more: with hard disk adaptations of games goes usually state save option - saving game state possible in every moment (in couple seconds), and can play from that position whenever want. + simple exit to Desktop instead reset. It needs min 1 MB RAM, what is anyway recommended today, and if can find and afford STE even better.

In Germany in April 1987 prices were approx same: Atari 520 ST with double sided external floppy drive - 1190-1199 DEM. Amiga 500 (also double sided flo.) same price. ST with single sided was 990 DEM. So, with Atari could save 200 DEM, and myself actually did it, and bought couple months later 2S drive for about 200 DEM. And some RAM expansions too (business) . To add that I was in dilemma: Atari ST or Amiga. What decided was low SW choice for Amiga, and even more my bad experiences with Commodore 64 build quality - there was only 'fat' C64 available, and PSU was just bad design, quality of chips manufactured in MOS (Korea) was poor - too many failures. Well, now I can say thanks to J.T. - he gave me in some way more job and incoming 🙂

I think that '260 ST' cases were just used for 520 STs, and never heard that anyone bought ST with only 256 KB RAM. There were diverse ideas, plans, but many of it appeared not that good, and situation with component prices, especially DRAM changed all time. I guess that Tramiel managed to get very good price by some higher quantity order, and that decided faith of machines with less than 512 KB RAM - dropped further development. Lisa OS ? No way. Apple for sure did not sale it. Probably was just codename used by DRI programmers. In case of home computer equipped with floppy drive, cartridges with SW are not really useful. Even if ROM prices dropped, capacity should be much bigger, so total price would stay high. C64, Atari 400 ... were with slow tape loading normally, so some like 32 KB cartridge with game was very handy - instant start instead minutes. Other problem is time needed to code well and efficient with new, pretty much different CPU. ST was not equipped with HW scroll, HW sprites and like. Explanation was that CPU is enough fast to do it in SW. And yes, that was actually true. Only that it needed couple years that programmers achieve it. There are games with really smooth and fast scroll for bare STs. And to add, 512 KB RAM helped in it a lot (preshifted sprites, background need plenty of space) .

I based that "to ship finished ROM TOS for early buyers for free" because there was lot of STs with only 16 KB boot ROM even years later. Maybe it was some sellers who 'forgot' to inform people about that ? Anyway, in adverts all it seems so great, 'revolutionary' (if I had a $ for every case seeing that word in advert ...), simple ... According to pic of desktop and file names, it was quick conversion of DR DOS and GEM for PC to Atari 68K. 5.25 inch floppy icons, GEM.KOM - probably executable file extension (from COM). AFOLDER - AUTO folder ?

Pretty silly price differences between 1-2, and especially between 2-4 MB versions. I bought RAM for much less in 1990. But this is how sales go in some cases. Here, currently CPU prices gone extremely high, with explanation that all this vaccine shipments causing troubles for manufacturing and shipping for CPU manufacturers. They are even lazy to thinker some believable explanation - how's that that TV prices did not go up, and TV is good example here - approx same prices as PC CPUs, while their size and weight is about 100x bigger. It seems that in this country computer wholesale trade is now in hands of few people/company, and they can do whatever want. But people is not that stupid, and lot if it was/will be bought abroad, ordered from ...

DRI and Atari worked together on TOS, practically from start, that's why I did not like 'third party'. It's not so simple that you just buy C sources and compile it for platform. It was new for Atari, for DRI, so was lot of it to work on. And used C Compiler was by DRI too, what was fur sure not much mature.

I see here lot of contradictional claims, and some really not realistic ones. Like price of $399 for computer with MC68000 in 1985. As I know price was around 1000 $ in beginning. And even, if it was with only 128 KB RAM, could not be so low. Maybe there was really 192 KB ROM in that prototype, with unfinished TOS. Still, it was pretty much useless with so little RAM, because OS, GEM need much more than some 8-bit computer. Remember disappointment of testers when first 520 ST with TOS on disk arrived on market ? When DR Basic was loaded, there was only some 10-15 KB free RAM left. I think that better would be to delay launch, or at least to ship finished ROM TOS for early buyers for free. According to Landon Dyer, who moved to Apple, their code was written much more efficient considering memory usage. GUI was not from third party - it was done by DRI, and it was practically port of GEM for PC. Somehow I tend to think that DRI programmers did not care for things like low RAM/ROM usage. Surely, it is better when all it goes in own company. Tramiel should recruit some experienced programmer people - but that's lot of money .. In case of C64 it was similar - they bought MS Basic . So, CP/M was without folders - that would be serious mistake to launch computer intended for serious work with such OS. Yes, some general GEMDOS C sources are available, and I saw them earlier. What would be nice to see are concrete TOS version sources. And I wonder, how Apple did it ? Maybe OS was done in ASM, big part. Cyprian wrote: "yep, that was really short-term thinking to place ROM area at $FC0000. They should use $Exxxxx and bigger ROM from the beginning. " Yes, should put it lower already at start. But bigger ROM - that would cost a lot. They used 32 KB ROMs because 128 KB ones were too expensive then. And I guess early plan was 4, and not 6 of them. But as we know, SW is what determines things since about 1983 .

Well, what I wrote is based on what I read back in time. All literature says that first (disk based) TOS was presented at CES at beginning of 1985. I don't think that it is possible that whatever CP/M or GEMDOS + GEM with Desktop (and that's longer part) can fit in 128 KB RAM. Even with 256 KB is very tight. Let's see it: screen 32 KB, OS workspace min some 20 KB. AES and Desktop workspace some 30-40 KB. Already min 80 KB. AES+Desktop - about 90 KB min. So, very little left for GEMDOS, maybe little better with CP/M . But that's good only for presentation, not for running some serious SW. There were obviously misjudgements, and they even manufactured cases with 260 ST logo, and even used them 😑 After reading all it here, I really can blame mostly leaders for this mess. It seems that at beginning they had no clue about what OS it should have. Or just seriously misjudged memory requirements - like 128 KB RAM - no way. Even 128 KB ROM appeared way too short. "March: Even more work. Two weeks to crunch TOS to fit into 192K." - funny thing is that they solved it with Line-F emulation in AES, saved some 5-6 KB with it. While could save more by packing RSC + Desktop.inf template data at end of TOS . Happens when people is under pressure. Btw. Landon Dyer was not happy about how DRI people threaten them, programmers at Atari. Little jump to 1992 - TOS 2.06 - biggest step in TOS evolution. As I know it was done completely in Atari. I really don't know what is difference between CP/M and GEMDOS. Know what is difference between GEMDOS and PC DOS FAT16 filesystem. Would be good to read something about CP/M hard disk filesystem. Probably it was limited to small sizes, considering drive capacities of that time. And saying "GEMDOS was a completely brand-new" - nothing is completely new . Back to topic: I think that chances to dig out those early, CP/M TOS versions are really small. It was used only internally, so never went out from Atari/DRI . There is still some commercial SW without good images. Not to mention TOS 1.xx sources ...

What was presented at the end of 1985 was not with CP/M, but with TOS on disk. There was small sized ROM of 16 KB in machines, for booting TOS and GEM. TOSBOOT.ZIP Here is floppy image with early TOS 1.00 US: TOS10US.ZIP UK: TOS100uk.zip Icons are not same, and they are changed because Apple . Here I must say that things look pretty much that DRI was not so motivated (paid ?) for pushing 68000 CPU based platform - we know that GEM was done for PCs too. C compiler for 68000TOS10US.ZIP done by DRI (Alcyon) had some limitations, and they remained at least until 1989. While competition did huge progress. Actually, is there any SW done by DRI after 1985 what became popular ?

As I know STs were sold around 3 millions. Mostly in period 1985-1988 . Falcon - some 30000 only . Indeed, most of sales was in Europe, Germany especially (from where many finished in East Eu.) . Here to add that already in spring 1987 strong competitor arrived on market: Amiga 500. It needed some time to have richer SW choice.

Some drivers have extra limit for first partition - like max 16 or 32 MB . Falcon: TOS 4.02 max 512 MB. TOS 4.04 max 1 GB .

Accidentally spotted some another inefficient code in TOS 1.04 . On multiple places there is something like : move.l d0,d5 tst.l d5 Well, everyone little better familiar with 68000 knows that move to data register sets flags too, depending on value of data. So, no need for tst instruction. And I wondered how some game programmers did not know it ... 1.04 is from 1989, so they had time to know CPU better. But it looks that Alcyon C compiler by DRI was not developed, improved over some 4 years, or more 😞

According to some sites, pages there are 4 Titus Classiques 1-4 . But I see only #1 at atarimania. And barely anywhere else. Their Space Invaders is pretty colorful and differs from original more than usual. So, anyone know about other releases ? Maybe some dumps, links ?

That's not Jookie's driver. It's only presented on his site. And in case of DMA/ACSI adapters transfer rate actually does not depend from driver SW. It depends from DMA chip max speed (what is btw. not correctly given in Atari DOCs) + used adapter. For instance Jookie's first design Satandisk transfer rate is about 150 KB/sec, with same driver that can over 1 MB/sec on UltraSatan - and max rate depends from used SD card type too in case of UltraSatan - funnily I got best with 1 GB Kingston, and with newer, larger capacity ones it is about 900 KB/sec in most cases - and I use brand cards. Since my transfer speed test program is shown here, just to add that will see some difference between Direct HW access speed and speed of Logical drives (partitions) . The reason for it is filesystem in TOS what adds some delays. And that is more in old TOS 1.00 and 1.02 than in 1.04 and later, for instance. And with combined R/W tests you can see how much lower is transfer speed of small data chunks/files.

Added some extra code for mouse: MISSC86.ZIP Commands: F1 - start game F2 - toggle 1-2 player mode F3 - Bonus on/off 0-9 - Set level skip count In play: F4 - abort game Q - fire missile from left silo S - fire missile from middle silo X - fire missile from right silo But first must press Caps shift for above 3 to work. I added code for left and middle silo fire with left and right mouse button, for easier play. Plus, response is made faster by some change in code. Works in color and monochrome mode. PP, Febr. 2021.

Strange controls for game: fire is activated by keys Q and S - and yes, only when they are capital, so need to press Caps shift that it work . That self is already weird, and more is that not mouse buttons are used for fire. Maybe they just did not have good enough DOCs about IKBD programing ? And this works with AUTO run, monochrome mode too 🙂