ParanoidLittleMan

I did not use word "relative" . And I powered monitor from USA with 220/110 V transformer in Eu, and it worked. Sorry Daniel Santos, you getting false 'advices' . Why it works not ? Because is old - over 30 years. People who talking about power freq. must be at 60 Hz have no clue how PSU in some TV, monitor, computer is built. Even if it is not with switching PSU, 18% lower freq will not make problem. The real problem is that fixing of it may cost more than new TV with Scart input . What is ideal for old computers. I had SM124 - yeah, that's the monochrome one. Btw. smaller than SC... . It started to have narrow and narrower pic some 15 years ago already. And I was just not interested in fixing it - because had LCD with much better monochrome pic. So, I gave it away. Fixing ? I worked in that over 25 years. Ah, bfollowell, explain me what is 120VAV - 120 Volts, Audio-Video ?

Here is 1 GB image with practically all game hard disk adaptations I done in last 14 years. Still needs testing - because that's most time consuming now, I really can not do it all myself in reasonable time. https://www.mediafire.com/file/z7k5lddkcuv5q3c/Gamit4pFt1.zip/file About 650 MB. About 1350 games . Before start to DL, note: this works only with iTOS . Don't even try with regular TOS versions, EmuTOS, MagiC . Even if latest 2 actually support DOS type FAT16 partitions, what is used here, but they just are not enough compatible with regular TOS, use more RAM ... First idea was to do it with single 1 GB partition. But when I was at about 80% of adding games it was clear that will not fit. What ? Hey, it is 1 GB image, so what is the problem ? Slack is the problem. Larger partition size - more space taken by files. Will not go in details here, all it is described on some sites, pages. Just to say that going on 4 partitions instead 1 resulted in about 150 MB + space. And in case of regular TOS, gain would be only half of that. In case of TOS 1.00-1.02 only quart of that. Additionally, 4 partitions gave chance to use those names by disk icons for something useful - see pic in first post. This was also good chance to make for the first time compilation where DIR C:\GAMEX is really used . http://atari.8bitchip.info/GamexUsage.html Quote from page above: "Saving some disk space : as you may see, there are files D15R_*.FIC in many of adaptations. So, normal is that we can save some disk space by storing them in some common DIR and read from there. Support for it is in latest adapts, and from now on will be in all. What to do : create DIR GAMEX on partition 😄 . Copy latest (and only them, not some old versions) files called: D15R_HH4.FIC, D15R_F4.FIC, D15R_5H.FIC, D15R_5F.FIC in that DIR. Then may delete mentioned files from later game's directories. It may save several MBs. If after that game works not, you may always copy back files from ZIP archive ." And gone further - common file GXUT276.PRG instead all those GXUT*.PRG versions in game DIRs. But, since it must be started from game's DIR, I used TOS-es INSTALL APPLICATION feature , and short files GXUT.LNK to launch C:\GAMEX\GXUT276.PRG . The result is that there is about 10-15 MB free space in all 4 partitions, so can do state saves . This image is with special driver, what will load common file D15*.FIC from C:\GAMEX even if game code missing that part. Because early adaptation do not have it, idea came little later. For instance AGE . And there is likely about 30-40 such totally. However, there are some don't like it - Simulcra, Sapiens. They use some RAMdisk tricks. To make them work, I made little proggie (removes that special driver extension), what need to run before game START. Best to copy it in game's DIR. 2SHUTIL.ZIP Time to make YT video ...

I made a promise that will never again answer on questions about how to display more partitions (drive icons) on Desktop. That was answered so many times, and is so 'just try out all those menu items in Desktop menu' type. Plus, it is answered on my site, on page for beginners.

Exact frequency of power for monitors is not relevant. It works fine with 50 Hz too, especially if voltage is little more than 110 V . I mean it works if is not broken. Simple transformers do not change frequency, only voltage. I guess that today is possible to buy converter what can give sinus output at desired freq. voltage. And what is sure is that it costs much more than new TV, monitor. So, that monitor needs experienced repair man - like TV repair man. Assuming that cable is really OK. So, best to check all lines with ohm meter. And that would be: R, G, B , H sync, V sync, GND . And maybe composite sync too, although I'm pretty sure that it does not use it. Then, is it possible that SC1224 sold in USA works not with 50 Hz video signal (not electric power !) ? Someone pls. say his experiences.

Well, if there is case of unreliable mechanical seek, that means that best chances to read it all are with making image of complete disk. Because sequential track access - much less mechanical forces on head movement components. And since it is almost impossible to find now proper controller for that verrrrry old drive for PC, doing it on Atari seems as only chance. First step: get some modern storage for Atari (as is already mentioned). As said, I can make imaging program. But need to know concrete HW settings - ACSI target numbers for MegaFile and for (supposedly) UltraSatan. Later must have enough free space for complete old disk capacity on 1 partition. What is of course no problem today. When image is done, can copy it to PC, and can look content, extract files from it with this my SW: http://atari.8bitchip.info/drimus.php

Not surprised that most of fake were sold at eBay .

Certainly work with MiST . TOS 1.62i , or if it is set to ST mode then 1.04i . 2.16, 2.14 works too, for sure. I say it with confidence, because everything what is changed, added works with regular Atari machines. Works in emulators too. To add here: without Steem Debugger it would be much harder to do all those changes in FAT16 .

I made some simple game starting program for AUTO folder in past. Did not use it for looong time. Need to look at it. Hardest part is to make game list - what must have title of game and location on disk. For some 1300 games that's plenty of typing, editing. In any case, those who like that Paradize menu - just use it. Game starting menu in iTOS ? Will see about it, but not so soon. And there are some games which must be started from Desktop, since use AES/GEM, so usual AUTO run is not good. Or maybe to go on AUTO run via DESKTOP.INF ? User selects game, it is written in DESKTOP.INF file, and will be started practically from Desktop . In most of games their internal saves go to hard disk, in own subdir FILES usually. If it is not solved, that's mentioned in README.TXT . Then can save (and not only then) game state save - usually key F9 be older - it exits, but game is kept in high RAM. By running GXUT*.PRG, or in this case link to it (short file with extension LNK) can permanently save that state, even writing short comment in it. And of course may play 'game in RAM' . Here to mention: recommended to click on 'Free RAM' box to restore normal RAM state - otherwise some games may not start properly. Newer system HAGA works little different - there is separate key for saving current state - usually * on Numpad. / exits to Desktop, with normal RAM state. Later ones were tested without floppy drive connected to Atari. Some older may not work without floppy drive, but nothing is written to floppies.

Cloning would be to create image file of whole drive, and copy it to other disk/Flash card. But as you self wrote, it is better that copy has larger partitions. And I guess, can have more of them, if card capacity is larger - like 4 or more GB. So, all you need to do is to partition SD cards with minimum so much partitions as on source. And then just copy everything from first partition of source disk to first partition of target - what would be I: if you do with Atari, and there are 6 partitions (Mega STE 120 MB drive). Thing can be done with PC too, but then will need PCI SCSI card. And since those disks are most likely not with DOS compatible partitions need special SW to copy files from source to PC. And then from it to SD card partitions ... Since capacities are small, maybe is better idea to make image of whole disk, then using it in emulator, where can copy files to PC drive ... Copy with Atari seems as simplest, but question is: will old drives and UltraSatan work together ? Of course it is faster on PC, but copying couple hundreds of MB will not take so long.

Most of Mega ST-s, which belly I saw were with 2 TOS ROM chips - no wonder, it was 1987 and later. But there are soldering pads near, where can set it to 6 chip mode. And no sockets, yeah. But it is still simpler to add 4 sockets, which all cost under 1 $ than doing 'conversion' to 32 pin. Plus takes no extra space like some board solutions. To add that I ship EPROMs 27C512, which are double capacity, so place for 2 TOS versions/variants. Max v. is TOS 1.04, and of course that's is what in now minimum for decent work with mass storage.

Yes, let's blame demo SW . Where it says that write with it works not well ? Write is actually important part of gaming - because state saves. And that's why there is some free space on partitions. So, 32 GB SD card manufactured in 2014 ??? "Data area is not aligned on flash erase boundary! " - and this is now ridiculous . It is on SD card, or whatever Flash card to take care of boundaries by erase. Whole thing is just smelly. Looks like forged card, especially if it is really from 2014. But what is sure is that write problem is in HW, and 99% the card is culprit. Please go in some shop and buy brand SD card, just not some very fast one. 8 GB will be fine for regular TOS 1.04 and later. Will cost not more than 10 bucks.

TOS 1.04i or original one go normally in 6 28 pin EPROMs . If want 2 chip version that needs 32 pin EPROMs . What 2 chip v. goes in 28 pin sockets is with factory mask programmed ROM chips, where no programming pins, so can have less pins for 1 Mbit capacity. So, in case of ST it needs intermediate 32 pin sockets for 2 chip version. + extra HW in case of 2.06, 2.14 - because different address space of that version. It's usually 1 GAL chip and some soldering. Easier solution is to use 4x 27C512 EPROMs, which are 28 pin. But it needs additional GAL logic too. See how it looks here: http://8bitchip.info/atari/tosimav.html Section "Solution for TOS 2.14 or original 2.06 with 4x 28 pin EPROM chips - no need for intermediate socket, so will remain low. "

I made Atari ST(E) RGB to VGA cable , what means connecting R,G,B signals directly, or via 100 Ohm resistors if contrast is too strong. V and H sync lines directly, and GND . And it works with Philips TV mentioned above . Need to set vertical size to fill screen. Works in both - PAL (50 Hz) and NTSC (60 Hz) modes. This was to expect from TV/monitor capable of those freqs. via Scart input.

I have it. But it's to expect that shipping will cost a lot, because dimensions, even if I'm in neighbor EU country.

This is something I'm working on in last 3 weeks, or better said in last 13 years. So, putting all those hard disk adaptations which I released in last 13 years, and are available on 8bitchip site. There are diverse images with plenty of games online. This one aims most of games on small storage size. Yes, that's 1 GB - as limit of Basic ACSI hard disk protocol, or as limit of internal ACSI-SCSI adapter what was by factory in Atari Mega STE and Stacy. In those times that was pretty large capacity. Of course, today it's far from being impressive or expensive, but still, for Atari SW it is plenty of space. So, I worked on putting as much as possible games (hard disk adapted, installable) in 1 GB partition - yes, that's possible with my iTOS. Knowing that it will need some changes by older game adaptations. Changes are done with common files D15R*.FIC - which are some kind of DLL files. For easier usage, I included them with every game DL. But there is simple way that all it can access it from one location: C:\GAMEX - what is mentioned in instructions too. So, if disk space is tight, users just can delete it from game's DIR, and it will be loaded from that System DIR. And it is same with files HAGA, HAGE ... Can save plenty of space, like over 100 MB in case of 1300 games. I copied games with removed those above mentioned D15R*, HAGA and like files into single 1 GB partition. And after did it for about 70 % if was clear that will not fit more than 1250 (rough estimation) . While sum of all file sizes, when all it is copied in is not over 850 MB. Why ? Because so called slack - FAT filesystem (FAT16 in case of hard disks) means that there is minimal size what some shortest, short file will take on drive - and it is in this case 16 KB - like for 1 byte long file. And that means a lot in case if Atari SW, where we have lot of short files. Btw. it is less with smaller partitions, so it is 8 KB in case of 256-511 partition under iTOS, or 128-255 MB under regular TOS 1.04-4.02 . So, I decided to try with 4x 255 MB partitions. And it worked - much more fits. Actually about 1350 games. That's not all what is on DL page (little over 1400), but I discarded very long variants (like Xenon 2 with audio tracks (32 MB), some older not so compatible ones ...) . That minimal size is called cluster, and is 4 KB instead 16 KB with 4x smaller partition size - gain is about 150 MB in this case. It looks like: And I used possibility to give custom drive names - here obviously they are composed of begin letters of file name DIRectories. Total 27 (letters + 0 for those starting with number) . And there is some free space in each partition for state saves. Hey, where is letter F ? This is done in Steem Debugger, where F is GEMDOS drive, so G is letter for fourth logical drive. On real Atari it will be F . For those who already got iTOS from me here is DL of not complete image: http://atari.8bitchip.info/TestMe/Gamit4pFin1.zip 166 MB. Only last partition. 369 games. Works with all decent ACSI adapters on ST, STE (no TT, Falcon support), Steem with Pasti, Hatari . Even if partition sizes are only 255 MB it needs iTOS - only with it it all fits in 1 GB space (planned 1350 games) . And there are updated DLL like files for it in C:\GAMEX . Some may ask: why iTOS ? Look upper 1 line. Beside it, this was needed to be done 3 years after solving real FAT16 in iTOS - now old game adaptations using TOS 1.04 GEMDOS part in RAM are compatible with iTOS and it's more efficient partitions - it is now actually iTOS core in RAM. Plus, this was good chance to finally put together image with all those D15R*, HAG* system files present only in shared DIR, according to original idea, and to my rational attitude 🙂 Final image will be DL-able soon at MediaFire.

Hurra ! Instead Amiga vs ST war we have now TT vs Paked Stacy war 🙂 Sorry, could not resist 🤩 Serious mode on: That PAK 68/3 in Stacy - is it using regular ST video/graphic HW or there is some added graphic module, card - like Nova ?

As I know 68030 is 68020 with added PMMU unit. And maybe with more flexible data lines - can be set for 32, 16 and ? 8 bit wide bus. What hurts is that was launched later than 80386 - so blame not only Atari, but Motorola too for losing market . And about prices: PCs with 32 bit 80386 were too expensive, even around 1993, 80386SX was what was sold then more .

Yes, I expected that someone will see that those 50066, 25033 freqs are just divided from main, roughly 32 MHz clock, or rather from roughly 8 MHz for CPU. That way Atari saved on one crystal. I had no clue about exact clock in TTs, and will avoid to listen music, played so rushed on it 🙂 And to add that freqs are for sure not exactly same in NTSC (America) and PAL (Europe) STEs (as it is with STFMs too) . There is slight diff. , and the reason is avoiding interference with color carrier in NTSC or PAL encoder. I googled little, but instead exact crystal freqs found another sad example how some 'experts' are poor with knowledge: https://comp.sys.atari.st.narkive.com/vUJrGBhT/atari-st-crystal-frequencies

I did not mean that Atari's 50066 Hz was bad for sound quality or like - just that was not compatible.

Interesting. And why is it (again) that "PC World" used that 44100 Hz (audio CD) sample rate and what can simply binarily divide from it , while Atari went on some special freq. ?

So, what's about this is ? About measuring performance of some computer, or how to make faster, better optimized code ? And, this 'really interesting' talk - sorry, but this are actually trivial things. Using Falcon CT60 in 68030 mode - of course that it is necessary - otherwise it will not run big %-age of regular Falcon SW. And not always because different CPU, sometimes some SW works not just because execution speed is much higher than for what is made and tested on. Then - oh what a shock ! - some SW works much faster on another CPU than other SW, what runs not so much faster .... This should go in programming section, and learn some things before making tables and some big conclusions. So, concrete example: 68000 and 68030 were designed before 80386, and no way that later is only 10% faster at same clock. And as I know 68030 used external cache (too), so much depends from it's size and speed (something ignored here completely by vol) . More concrete: loops are where often most of CPU time is spent. With 68000 there are instructions specially good for loops - DBcc . Then repeating same one in row multiple times will make it faster, because loop control instruction relative time will be less - called enroll usually. But it is not fastest way to do RAM clear, mem block copy, for instance. movem.l with plenty of registers is fastest on 68000. Used in TOS too. Why it is fastest ? Because no instruction fetch for every transfer, write ... And that's is what is better in later CPU - it can repeat same instruction without need to fetch it over and over again. Step above it is MMX and what came after - multiple data processing with single instruction. When we say benchmark, that should be something what performs code similar to average, everyday used SW. Math calculation is good, but only to compare computers, CPU's capability in that area. Really good benchmark need to be thorough, to utilize all computer parts involved in usual SW execution. So video, cache, large RAM areas (because of cache mostly), then OS calls involved too (maybe best as option) - because OS speed matters too. And storage speed is what can be measured, even if it is not basic part, but it has influence on working speed of complexer APPs, and hard disk speed depends in big part from motherboard, hard disk controller/DMA in it, not only from disk speeds self. I know what I talking, I made some benchmark SW. And even did some code post optimizations, not because it was so necessary in most cases, but to learn, see how better it can be - in speed and in code size, although 2 goes not together in most cases 🙂 So, here is one example of optimizing ASM code for speed: http://atari.8bitchip.info/FastCoding.html Yeah, I was wrong - STE with mass storage enough fast can play CD audio format on fly. The hard part is framerate conversion needed. And no, I don't think that I'm off topic.

It is 1.62 US TOS ROM, 100% unchanged content. Btw. that L00 is for language/region, and US code is 00 .

So, overview with main characteristics of currently available Flash card mass storage (aka hard disk) adapters for Atari ST family. Without getting into which is best and similar judging. Will try with chronological order. Satandisk - supports only non HxC SD cards, what means max 4 GB - if you find at all such card. 2 GB is also not easy to find. 1 CD card slot. Transfer rate about 100 KB/sec. It uses ICD ACSI protocol, but capacity detection command is not supported (what does not mean that can not detect capacity of card accurately). UltraSatan - works with HxC cards, I tested with 64 GB card last summer and worked. 2 SD card slots, RTC function. Speed around 900 KB/sec - depends from used SD card too. Hot swap is supported in firmware. ICD ACSI practically fully implemented. Cosmos Ex - 1 SD card slot, characteristics very similar to UltraSatan. No wonder - same designer. Gigafile - 1 SD card slot. As I know supports well ICD ACSI protocol. Someone pls. do/post speed test for .. ACSI-CF - (by me and tori) - 1 CF card slot. Special protocol - mixture of IDE and DMA . Therefore needs special driver and autoboot extension in TOS. Transfer rate about 1.8 MB/sec . Only Sandisk cards - not because they paid me, because only them support 8-bit DMA mode. ACSI2STM - despite name it is for SD cards. Can be built by user self partially. Unfortunately, I don't see clear info about supported protocol(s) on it's site. Is it ICD ACSI only (since supports larger cards), or there is mode with multiple targets of max 1 GB size with single card ? What about SCSI capacity detection support ? I really don't get why author did not contact me, despite there are screenshots of it working with my driver demo versions, games with it ... Some users just don't know what it really can. Transfer rate about 290 KB/sec . ACSI2SD - similar problems as above - not clear about supported protocols, SW for setting desired mode . It links to my old mass storage for Atari ST page, what is good, but concrete and accurate specs are really necessary, so users can use it most efficient and with up to date SW, higher capacity cards. Transfer rate speed test welcome ... Diverse IDE adapters can work with CF cards - with own CF socket or via cheap, passive IDE-CF adapters. Big part of them is DIY type. What kits are available, I really don't know, are some with CF sockets ... And here must to note: problems with writing on CF cards are very spread. The reason is not good signal timing of ST(E) bus for newer IDE specs (where CF belongs). As most reliable brand appears the Sandisk - more compatible signal timing generally. Transfer rates can go up to 1400 KB/sec with CPU, 1.6 MB/sec using blitter. And because TOS FAT16 is low Endian, IDE is 16 bit, byte swap is needed with DOS compatible partitions. It can be done in SW or HW. Which is faster ? 🙂 And that would be all for now. I don't want to deal here with non Atari ST specific adapters - like SCSI2SD, IDE2SD and like.

Yeah, known story, and name 'Jackintosh' confirms that ST in 1985 was already way ahead of Macintosh. Too bad that things changed to opposite later. Actually, it is SW in what ST was for sure not clearly ahead, especially in beginning. Amiga case is different story. I tend to think that whole concept of Amiga - as video, gaming computer was not what Jack Tramiel had in mind - he wanted multi purpose, competition to IBM PC computer (ah, and to MAC, of course). For instance, ST is designed by same man who designed gaming oriented C64. So, they (Shiraz Shivji and Jack Tramiel) as leaders of ST project could go on same way - custom chips helping gaming. Instead it they designed custom chips for mass storage, diverse video modes, including 'professional' high res monochrome, musicians, etc. Ah, and btw. DMA port max speed is actually 16 Mbit/sec - from beginning - why they gave lower values is not clear - most likely just because what was attached to it in first 5-6 years was slower, so it never worked close to max possible speed.