- Welcome to 8BitChip Forum.
Recent posts
#1
General chat / Re: Question about PP hard dis...
Last post by Petari - 12-01-2026, 19:00:30 Hola,
Yes, and you can read more, see some YT videos here: hd adapted games
Just to add that I don't like when people call it conversions, or 'patches', cracks . It is much more complex and may need days of work to solve 1 game. Some games have really weird floppy code - talking about those not accessing floppies via TOS functions. And just to understand how it works lot of tracing is needed. Then need to replace parts of it with links to hard disk access code, including needed conversions. Hard disk access is not so simple, as during gameplay that normally works not - there are diverse ways to solve it, and it is not simple.
Then come TOS version compatibility problems, some not so good code in games what need correction, and so on.
Longer story. May read some details on my site.
Then extra functions: state saves, exit to Desktop, unlimited lives and other cheats - and some games really need them. All it costs time - and time is what ? You know it. And time is needed to make all it work from single image file on most common Atari ST(E) models. Yes, single file, but not same for all TOS versions - there is image for TOS 1.04 and higher - 7 GB, now with over 2660 games. And 3.5 GB for TOS 1.00 and 1.02 because TOS v. limits. It has some 1900 games. Other thing is RAM in machine: min is 1 MB. For games needing 1 MB with floppy run 2 MB is needed with hard disk run. And rare case 2 MB for floppy run games need 4 MB. Well, now is not so hard to do TOS v. upgrade and expanding RAM. And to add: overall work with hard disks (now rather SD cards) is much better with later TOS versions - not only accessible size limit is in question - faster and more reliable work.
There is kind of pricing, and it is not for games self, which are btw. accessible for free as floppy images online. I ask donation for my work in latest 17 years for making them runnable from modern and now cheap mass storage. Imagine how much work is needed to just put together properly so much SW, easy selectable and startable, plus making simple reading additional instructions and like + starting different versions of game.
Donation is now like 25 Euros, and it may be more soon considering that inflation is still on.
Running from floppies is now really problematic in many cases because old floppy drives and disks getting bad, unreliable - and hardly replaceable, as not manufactured for long time. I don't even attach floppy drive to my Ataris in latest 10 years. Only in rare cases for some testing. So, hard disk adapt must deactivate all possible floppy accessing, because it may cause crash, freezing without floppy drive (or Gotek and like) .That's additional work. And even if source is some crack (what I don't like, but often no
other) they may be remains of copy protection which needs deactivating.
Other time consuming is finding good image of game - wrote about it here and on other places multiple times.
Yes, and you can read more, see some YT videos here: hd adapted games
Just to add that I don't like when people call it conversions, or 'patches', cracks . It is much more complex and may need days of work to solve 1 game. Some games have really weird floppy code - talking about those not accessing floppies via TOS functions. And just to understand how it works lot of tracing is needed. Then need to replace parts of it with links to hard disk access code, including needed conversions. Hard disk access is not so simple, as during gameplay that normally works not - there are diverse ways to solve it, and it is not simple.
Then come TOS version compatibility problems, some not so good code in games what need correction, and so on.
Longer story. May read some details on my site.
Then extra functions: state saves, exit to Desktop, unlimited lives and other cheats - and some games really need them. All it costs time - and time is what ? You know it. And time is needed to make all it work from single image file on most common Atari ST(E) models. Yes, single file, but not same for all TOS versions - there is image for TOS 1.04 and higher - 7 GB, now with over 2660 games. And 3.5 GB for TOS 1.00 and 1.02 because TOS v. limits. It has some 1900 games. Other thing is RAM in machine: min is 1 MB. For games needing 1 MB with floppy run 2 MB is needed with hard disk run. And rare case 2 MB for floppy run games need 4 MB. Well, now is not so hard to do TOS v. upgrade and expanding RAM. And to add: overall work with hard disks (now rather SD cards) is much better with later TOS versions - not only accessible size limit is in question - faster and more reliable work.
There is kind of pricing, and it is not for games self, which are btw. accessible for free as floppy images online. I ask donation for my work in latest 17 years for making them runnable from modern and now cheap mass storage. Imagine how much work is needed to just put together properly so much SW, easy selectable and startable, plus making simple reading additional instructions and like + starting different versions of game.
Donation is now like 25 Euros, and it may be more soon considering that inflation is still on.
Running from floppies is now really problematic in many cases because old floppy drives and disks getting bad, unreliable - and hardly replaceable, as not manufactured for long time. I don't even attach floppy drive to my Ataris in latest 10 years. Only in rare cases for some testing. So, hard disk adapt must deactivate all possible floppy accessing, because it may cause crash, freezing without floppy drive (or Gotek and like) .That's additional work. And even if source is some crack (what I don't like, but often no
other) they may be remains of copy protection which needs deactivating.
Other time consuming is finding good image of game - wrote about it here and on other places multiple times.
#2
Software / Re: Original source files for ...
Last post by Petari - 12-01-2026, 09:07:49I have ASM S files for complete TOS 1.04 and 1.62 . I needed it for iTOS (my improved TOS, with better FAT16 code in first place, and other things - see page about on site here) .
I don't call it TOS sources as that would be C sources in biggest part. It is result of disassembling TOS versions - that is hard and time consuming process - some things can be done only manually to be correct.
So, complete TOS 1.04 ASM S is about 920 KB long, in single file. Or can have GEMDOS and AES part separately.
Even 920 KB S file can be assembled with Atari ST and Devpac - will need 4 MB RAM . It may take longer time - like half hour to 1. I do it with Steem emulator accelerated to max speed, so needs 1-2 minutes .
Test of accuracy is simple - just need to compare result of assembling with original TOS binary - can do it with Total Commander for instance. And yes, it is 100% same when all is set properly in Devpac.
So, no need for some newer 68000 assembler SW, lot of S and other files - as wrote complete TOS in ASM S format in single file.
I don't call it TOS sources as that would be C sources in biggest part. It is result of disassembling TOS versions - that is hard and time consuming process - some things can be done only manually to be correct.
So, complete TOS 1.04 ASM S is about 920 KB long, in single file. Or can have GEMDOS and AES part separately.
Even 920 KB S file can be assembled with Atari ST and Devpac - will need 4 MB RAM . It may take longer time - like half hour to 1. I do it with Steem emulator accelerated to max speed, so needs 1-2 minutes .
Test of accuracy is simple - just need to compare result of assembling with original TOS binary - can do it with Total Commander for instance. And yes, it is 100% same when all is set properly in Devpac.
So, no need for some newer 68000 assembler SW, lot of S and other files - as wrote complete TOS in ASM S format in single file.
#3
General chat / Question about PP hard disc im...
Last post by soviet9922 - 11-01-2026, 20:32:12Hi!,
First has been a long time user for PP, hard disc driver purchased it years ago.
Was told that PP sells some kind of hard disc image that include all his game conversions ?.
Wondering if this is correct, and if theres more information about the disc image pricing ?.
First has been a long time user for PP, hard disc driver purchased it years ago.
Was told that PP sells some kind of hard disc image that include all his game conversions ?.
Wondering if this is correct, and if theres more information about the disc image pricing ?.
#4
Software / Original source files for TOS ...
Last post by Petari - 11-01-2026, 19:17:40 I looked little about and in disk TOS (1.00) versions which where released with early STs in 1985 until first ROM TOS was completed (November 1985, as I know). UK version has image file size 206554 bytes, and that's over 192 KB some 10 KB.
So, it looks as almost complete ROM TOS 1.00 - size difference is because they added so called line-F emulator in AES part, to make code shorter. Did little testing, and it does not boot ACSI hard disk - that could be some KBs more code, and question is how similar is FAT code - is there at all FAT16 support (likely no) ? So, that 206654 looks little too much. I looked US and De versions, and they are 197784 bytes. - just little more than 196608. Funny thing. As I see small diff is because lack of hard disk support and maybe something other. What means that it was not only size what needed corrections, updates, but hard disk support too - what was added almost sure in 1985, after release of early STs (without full ROM TOS). All it is OK, but I like to be precise with details. And I looked for that disk TOS sources - with not much hope, as there are no real sources for TOS 1.xx versions (I saw only for 2.06) . What I
found is something on GitHub - needed some time to see what is there really, something is missing (called sources for TOS 1.00) .
When I looked files at GitHub (Thorsten Otto) - they are not C-sources, but ASM 'source' files , so practically 'disassembling' of TOS binary content. Why in quotes ? Because most of TOS is done in C, at least 90% - and it is well known. And I know it from own experience - I did that 'disassembling' too - long time ago, for GEMDOS part first.
But real description of it would be something like converting binary content of TOS to ASM source code. And it is hard and time needing process - I even tried with some new tools for modern computers and it needed still lot of manual corrections, mostly because disasm SW detected some parts as code which were addresses and some data, or versus.
The point: misleading title of project - they are not TOS sources, just maybe kind of reconstruct it for rebuilding with some modifications - what I did with my iTOS and with TOS running in RAM versions.
Real TOS sources are in C, with some ASM parts - well known. And they would be now very useful so we can better understand some not so well made parts of TOS - like FAT16 filesystem code - can read about it on my site.
The point is that original source for TOS 1.xx would be welcome and useful - and to do effort about it instead misleading name/description of project and praising who did it - sure it is still useful, but I respect people who cares about accurate (and modest) naming.
Anyone knowing something about real source files (what was done at DRI in most part) ? I'm sure it will not break any copyright now, 40 years later. Only thing it can break is lack of knowledge.
So, it looks as almost complete ROM TOS 1.00 - size difference is because they added so called line-F emulator in AES part, to make code shorter. Did little testing, and it does not boot ACSI hard disk - that could be some KBs more code, and question is how similar is FAT code - is there at all FAT16 support (likely no) ? So, that 206654 looks little too much. I looked US and De versions, and they are 197784 bytes. - just little more than 196608. Funny thing. As I see small diff is because lack of hard disk support and maybe something other. What means that it was not only size what needed corrections, updates, but hard disk support too - what was added almost sure in 1985, after release of early STs (without full ROM TOS). All it is OK, but I like to be precise with details. And I looked for that disk TOS sources - with not much hope, as there are no real sources for TOS 1.xx versions (I saw only for 2.06) . What I
found is something on GitHub - needed some time to see what is there really, something is missing (called sources for TOS 1.00) .
When I looked files at GitHub (Thorsten Otto) - they are not C-sources, but ASM 'source' files , so practically 'disassembling' of TOS binary content. Why in quotes ? Because most of TOS is done in C, at least 90% - and it is well known. And I know it from own experience - I did that 'disassembling' too - long time ago, for GEMDOS part first.
But real description of it would be something like converting binary content of TOS to ASM source code. And it is hard and time needing process - I even tried with some new tools for modern computers and it needed still lot of manual corrections, mostly because disasm SW detected some parts as code which were addresses and some data, or versus.
The point: misleading title of project - they are not TOS sources, just maybe kind of reconstruct it for rebuilding with some modifications - what I did with my iTOS and with TOS running in RAM versions.
Real TOS sources are in C, with some ASM parts - well known. And they would be now very useful so we can better understand some not so well made parts of TOS - like FAT16 filesystem code - can read about it on my site.
The point is that original source for TOS 1.xx would be welcome and useful - and to do effort about it instead misleading name/description of project and praising who did it - sure it is still useful, but I respect people who cares about accurate (and modest) naming.
Anyone knowing something about real source files (what was done at DRI in most part) ? I'm sure it will not break any copyright now, 40 years later. Only thing it can break is lack of knowledge.
#5
Rules and announcements / Re: Server Maintenance
Last post by msolajic - 11-01-2026, 03:00:49Maintenance was completed at 03:00, January 11th 2026.
#6
Rules and announcements / Server Maintenance
Last post by msolajic - 10-01-2026, 22:25:16Hi everybody,
Today, January 10th 2026, we will have to perform urgent security maintenance on the forum (and the web server). We hope that until the morning everything will be working as normal.
Thanks,
Marko, webmaster
Today, January 10th 2026, we will have to perform urgent security maintenance on the forum (and the web server). We hope that until the morning everything will be working as normal.
Thanks,
Marko, webmaster
#7
Software / Re: TOS versions incompatibili...
Last post by Ronald J. Hall - 09-01-2026, 16:37:38Good summary, Peter. Thanks! 
#8
Software / TOS versions incompatibility p...
Last post by Petari - 09-01-2026, 15:02:29 Well, this is something not really present with little older, 8-bit computers - for instance OS was not changed at all in case of Sinclair Spectrum original v. , what was manufactured over some 7 years. The reason was for sure that OS on 8 bitters was much simpler, shorter, and of course it made them easier for coding, predict all possible situations, etc.
Atari ST was designed with much more functions, SW types supported, displays usable, storage types and so on ... , as 8-bit home computers. Plus, there was using of GUI (graphical user interface) at basic (starting) screen for most common functions - browsing disks, starting SW, doing some copy, transfer operations and so on ... Even listing what much more can do with it needs plenty of space.
So, it was needed to do TOS updates during time, to make it work better. And yes, it was better in later versions in many situations. Sure, not only Atari did so in that time, it was usual with all more complex computers, OS.
But, as with all good intentions it may have some bad side effects (not sure that it is good to call it so) - maybe SW authors should be more cooperative and do some new versions of their SW too . Happened only in rare cases. And there were other things, factors which made problems - lack of all possible RAM in programmers computers, not enough testing, not enough detailed DOCs from Atari ...
So let's see most common Atari ST TOS version related SW running problems:
Game (SW) runs well under TOS 1.00 but not with later versions. Mostly, the reason is to use in SW some specific addresses and/or function parameters present in TOS 1.00, which are not declared as some system variables, addresses - they are just result of coding, compiling. And even differ in different language versions. As extreme example I know GFA Artist - it is German program, and works only in German TOS 1.00 . Why ? - They used some direct calls in TOS address space - which have different address in even different lang. versions.
OK, maybe did not care about other lang. versions, but what about later TOS versions ?
Well, not only address changes causing problems. But I saw (and fixed) other similar case: Tracker (Rainbird 1987) - using direct addresses of TOS 1.00 mouse reading code - they changed in later TOS versions, and even are not same in all lang. versions. Sure, it may be problem of not enough detailed TOS DOCs by Atari .I was able to fix it many years later, thanx to much more details about how TOS mouse (and other input devices) code works.
Different TOS (in ROM) start address: TOS 1.00-1.04 starts at address $FC0000, while TOS 1.06, 1.62, 2.06 starts at $E00000 . If some SW does direct read at presumed TOS start address it will cause address error crash if it is not address of TOS start in machine where running SW . Yeah, it is because SW coders were not aware about possible change of it - and it can be done better - if know details how all it works - there are system variables to see what is TOS start address. Still, do not blame only SW authors - Atari should be aware of possible problems, and warn SW authors.
This is pretty specific, and not so spread: TOS function calls (mostly Trap #1) save CPU registers D4-D7, A3-A6 - so they will be same after call ending. That helps code using them - but there are some differences even with it in TOS versions - so in earlier, like 1.00, 1.02 some of registers in range of D0-D3, maybe A0-A3 will not be different after returning of Trap call . And it is case with game Prince of Persia - good with TOS 1.00, 1.02 - not with later . It needs patch to work with 1.04 and later. What I did . Now real question is - why they did coding so ? Not having enough detailed TOS DOCs, or just it was how it worked good in their testings ? Yeah, maybe this is the essence of whole this thing - we just can not blame one side, as all it is too complex, no enough details of how it all happened then ... OK, the point is not to blame someone - the point is to learn from all it - and that would be: take care about details, do OS that handles as much situations well as possible - and that stands for all social, political situations too !
TOS 2.06 compatibility problems: this TOS v. has improved Desktop with more functions, support for HD floppies, 68010 CPU ... Because improved Desktop it uses more RAM, so starting address of SW ran is higher some 20 KB than in 1.04 - and that may be too much for some SW, especially games.
Floppy code is changed (because HD support) and it uses Timer-C for time-out detection - as it is set at boot. But if some SW changes Timer-C parameters, code for floppy read/write will fail. And it is case with many games - they use Timer-C for own purpose, with own parameters, code. I made special fix for such case, what makes floppy access working with TOS 2.06 even when Timer-C is changed from start setting .
And of course TOS v. incompatibility has influence to running SW from hard disk too. However there is something what can help for both: running from hard disk (now rather SD card) and TOS v. problems: running specific TOS version in high RAM . So, we can choose TOS v. best for that purpose, and run all what can work with it - may need some corrections, but that will be good then for all configs with diverse TOS versions - so corrections for only 1 TOS v. Sure, that needs more RAM in computer, but with hard disk run more RAM is already needed, and that plus 90-180 KB RAM is no problem - there is enough space in 1 MB for game run: 512 KB, then for saving machine state at game start (usually some 150 KB) and extra code needed for specific hard disk run operations (including state saves, hard disk aceess ...). If game needs 1 MB RAM for floppy run 2 MB RAM is needed. For very RARE games needing 2 MB RAM for floppy run 4 MB is needed - not real problem today.
Some smartheads wrote around 2009 that most of Atari ST games had direct floppy access code , and that don't use TOS function calls. And they did not make 'patching' of TOS using games at all (Klaz did some with own code for it) . Total count of such 'patches' is under 400 . I myself did over 2700 . And percentage of TOS using games is actually some 65-70% . What I knew even at 2009, when all it was relative new for me. And that was reason why I developed systems for running TOS in RAM, hard disk access during game play and other things. Will not go here in details - can see about on same pages on this site. Just this: first version was for games starting from AUTO folder PRG - then needs only GEMDOS part of TOS (about half) . Which TOS v. ? Of course 1.04 (UK) - latest v. for unmodded ST machines , and it can work well with STE machines too (in RAM) .
Count of games using AES is much lower, but there is lot of good ones - so made full TOS 1.04 in RAM too. And in latest years even 1.62 in RAM because some games needed it (really only few) .
And one more good thing too : as my adapts normally have simple exit to Desktop and state saves - activating them by simple key press - TOS in RAM helps in it too - if game using TOS for keyboard read then implementing it is really simple (with little help added to TOS in RAM) - if game uses own code for such read then need to trace it, understand how works and add some changes in game code - well, better said some hooks to achieve additional key press detections.
Atari ST was designed with much more functions, SW types supported, displays usable, storage types and so on ... , as 8-bit home computers. Plus, there was using of GUI (graphical user interface) at basic (starting) screen for most common functions - browsing disks, starting SW, doing some copy, transfer operations and so on ... Even listing what much more can do with it needs plenty of space.
So, it was needed to do TOS updates during time, to make it work better. And yes, it was better in later versions in many situations. Sure, not only Atari did so in that time, it was usual with all more complex computers, OS.
But, as with all good intentions it may have some bad side effects (not sure that it is good to call it so) - maybe SW authors should be more cooperative and do some new versions of their SW too . Happened only in rare cases. And there were other things, factors which made problems - lack of all possible RAM in programmers computers, not enough testing, not enough detailed DOCs from Atari ...
So let's see most common Atari ST TOS version related SW running problems:
Game (SW) runs well under TOS 1.00 but not with later versions. Mostly, the reason is to use in SW some specific addresses and/or function parameters present in TOS 1.00, which are not declared as some system variables, addresses - they are just result of coding, compiling. And even differ in different language versions. As extreme example I know GFA Artist - it is German program, and works only in German TOS 1.00 . Why ? - They used some direct calls in TOS address space - which have different address in even different lang. versions.
OK, maybe did not care about other lang. versions, but what about later TOS versions ?
Well, not only address changes causing problems. But I saw (and fixed) other similar case: Tracker (Rainbird 1987) - using direct addresses of TOS 1.00 mouse reading code - they changed in later TOS versions, and even are not same in all lang. versions. Sure, it may be problem of not enough detailed TOS DOCs by Atari .I was able to fix it many years later, thanx to much more details about how TOS mouse (and other input devices) code works.
Different TOS (in ROM) start address: TOS 1.00-1.04 starts at address $FC0000, while TOS 1.06, 1.62, 2.06 starts at $E00000 . If some SW does direct read at presumed TOS start address it will cause address error crash if it is not address of TOS start in machine where running SW . Yeah, it is because SW coders were not aware about possible change of it - and it can be done better - if know details how all it works - there are system variables to see what is TOS start address. Still, do not blame only SW authors - Atari should be aware of possible problems, and warn SW authors.
This is pretty specific, and not so spread: TOS function calls (mostly Trap #1) save CPU registers D4-D7, A3-A6 - so they will be same after call ending. That helps code using them - but there are some differences even with it in TOS versions - so in earlier, like 1.00, 1.02 some of registers in range of D0-D3, maybe A0-A3 will not be different after returning of Trap call . And it is case with game Prince of Persia - good with TOS 1.00, 1.02 - not with later . It needs patch to work with 1.04 and later. What I did . Now real question is - why they did coding so ? Not having enough detailed TOS DOCs, or just it was how it worked good in their testings ? Yeah, maybe this is the essence of whole this thing - we just can not blame one side, as all it is too complex, no enough details of how it all happened then ... OK, the point is not to blame someone - the point is to learn from all it - and that would be: take care about details, do OS that handles as much situations well as possible - and that stands for all social, political situations too !
TOS 2.06 compatibility problems: this TOS v. has improved Desktop with more functions, support for HD floppies, 68010 CPU ... Because improved Desktop it uses more RAM, so starting address of SW ran is higher some 20 KB than in 1.04 - and that may be too much for some SW, especially games.
Floppy code is changed (because HD support) and it uses Timer-C for time-out detection - as it is set at boot. But if some SW changes Timer-C parameters, code for floppy read/write will fail. And it is case with many games - they use Timer-C for own purpose, with own parameters, code. I made special fix for such case, what makes floppy access working with TOS 2.06 even when Timer-C is changed from start setting .
And of course TOS v. incompatibility has influence to running SW from hard disk too. However there is something what can help for both: running from hard disk (now rather SD card) and TOS v. problems: running specific TOS version in high RAM . So, we can choose TOS v. best for that purpose, and run all what can work with it - may need some corrections, but that will be good then for all configs with diverse TOS versions - so corrections for only 1 TOS v. Sure, that needs more RAM in computer, but with hard disk run more RAM is already needed, and that plus 90-180 KB RAM is no problem - there is enough space in 1 MB for game run: 512 KB, then for saving machine state at game start (usually some 150 KB) and extra code needed for specific hard disk run operations (including state saves, hard disk aceess ...). If game needs 1 MB RAM for floppy run 2 MB RAM is needed. For very RARE games needing 2 MB RAM for floppy run 4 MB is needed - not real problem today.
Some smartheads wrote around 2009 that most of Atari ST games had direct floppy access code , and that don't use TOS function calls. And they did not make 'patching' of TOS using games at all (Klaz did some with own code for it) . Total count of such 'patches' is under 400 . I myself did over 2700 . And percentage of TOS using games is actually some 65-70% . What I knew even at 2009, when all it was relative new for me. And that was reason why I developed systems for running TOS in RAM, hard disk access during game play and other things. Will not go here in details - can see about on same pages on this site. Just this: first version was for games starting from AUTO folder PRG - then needs only GEMDOS part of TOS (about half) . Which TOS v. ? Of course 1.04 (UK) - latest v. for unmodded ST machines , and it can work well with STE machines too (in RAM) .
Count of games using AES is much lower, but there is lot of good ones - so made full TOS 1.04 in RAM too. And in latest years even 1.62 in RAM because some games needed it (really only few) .
And one more good thing too : as my adapts normally have simple exit to Desktop and state saves - activating them by simple key press - TOS in RAM helps in it too - if game using TOS for keyboard read then implementing it is really simple (with little help added to TOS in RAM) - if game uses own code for such read then need to trace it, understand how works and add some changes in game code - well, better said some hooks to achieve additional key press detections.
#9
General chat / Happy New Year 2026 :-)
Last post by Petari - 01-01-2026, 13:17:38 Not much good y. 2025 is behind us. I hope things will go better in many aspects this year. In Atari ST waters I would like to see more serious approach from many people, thinking more about what is good for community, users - instead self praising, interests - what goes often with shallow opinions about others, their work - and in extreme cases blatant lies.
And to add: our Atari STs (and compatibles) are now really old - some may be 40 years old, and all originals are over 30 years old (as latest manufacturing was in 1993). That means more and more reliability problems, some SW not working well because weakened components, and like. So, all it needs more care, some repairing, component replacements. Storage is where is lot of problems - with floppy drives, disks in first place. But old hard disks go bad too a lot. Luckily SD cards are now really cheap, with lot of capacity. And there are diverse adapters for them for Atari ST..(s) . What is needed is to make old good SW working with such config. Yes, in most of cases some corrections are needed in SW to achieve it. And it is not simple converting, patching, cracking . Even listing all cases would be too long. Plus, need TOS version compatibility problems fixing, finding good versions of game floppy images - and there are still some bad cases.
At atarimania is Wall Street (En + De v.), and 2 STX images - but they are same - STX called 'Disk 2 of 2) is 100% same as STX of Disk 1. And nobody noticed it except me (about week ago) ? Really shallow. I will write to Marakatti about .. And there is more ..
And need to make list of all similar problems, games without image(s) available ...
And to add: our Atari STs (and compatibles) are now really old - some may be 40 years old, and all originals are over 30 years old (as latest manufacturing was in 1993). That means more and more reliability problems, some SW not working well because weakened components, and like. So, all it needs more care, some repairing, component replacements. Storage is where is lot of problems - with floppy drives, disks in first place. But old hard disks go bad too a lot. Luckily SD cards are now really cheap, with lot of capacity. And there are diverse adapters for them for Atari ST..(s) . What is needed is to make old good SW working with such config. Yes, in most of cases some corrections are needed in SW to achieve it. And it is not simple converting, patching, cracking . Even listing all cases would be too long. Plus, need TOS version compatibility problems fixing, finding good versions of game floppy images - and there are still some bad cases.
At atarimania is Wall Street (En + De v.), and 2 STX images - but they are same - STX called 'Disk 2 of 2) is 100% same as STX of Disk 1. And nobody noticed it except me (about week ago) ? Really shallow. I will write to Marakatti about .. And there is more ..
And need to make list of all similar problems, games without image(s) available ...
#10
Software / Re: The Final Battle?
Last post by Ronald J. Hall - 17-12-2025, 19:20:08Still working on it - let me get back to you.
Sorry, life got in the way.
Sorry, life got in the way.