- Welcome to 8BitChip Forum.
Recent posts
#11
FAQ / Finally some intelligent threa...
Last post by Petari - 26-01-2026, 18:59:46TOS boot disk talk
Yeah, adding cartridge (normal capacity is 128 KB) - sure, that's what average user does - order (buy) some cartridge to make his not so cheap computer working well ? Sorry, I named this 'intelligent thread' - and yes, there are some such posts. If you are interested really, please read all it carefully, and most important think about it really carefully. We can easily blame people for some mistakes, but without knowing details all it is just shallowness, and often with really bad conclusions.
Tramiel was good, surely not perfect, made many mistakes, but that's the price of doing something new - there were mistakes with C64 too, still, it was most sold 8-bit home computer. ST was good idea, and pretty well sold. ST means compromise between 16 and 32 bits - and I think that it was done very well, if not best in those years (1985-1989) .
Yeah, adding cartridge (normal capacity is 128 KB) - sure, that's what average user does - order (buy) some cartridge to make his not so cheap computer working well ? Sorry, I named this 'intelligent thread' - and yes, there are some such posts. If you are interested really, please read all it carefully, and most important think about it really carefully. We can easily blame people for some mistakes, but without knowing details all it is just shallowness, and often with really bad conclusions.
Tramiel was good, surely not perfect, made many mistakes, but that's the price of doing something new - there were mistakes with C64 too, still, it was most sold 8-bit home computer. ST was good idea, and pretty well sold. ST means compromise between 16 and 32 bits - and I think that it was done very well, if not best in those years (1985-1989) .
#12
News / STE or not STE compatible
Last post by Petari - 24-01-2026, 18:56:21Judge yourself: Are they awake ?
Atari STE deserves better. Or maybe, those who made it STE compatible deserve better.
Atari STE deserves better. Or maybe, those who made it STE compatible deserve better.
#13
News / More useless threads at ataria...
Last post by Petari - 24-01-2026, 13:31:52Look this one: aage is aged
At atarimania can see some details: amania is not aged
Anyone said: devil is in details ?
From my own experience: using STE DMA audio instead PSG (partially) digitized sound may improve graphic frame rate little. But it depends from other things too - how video displaying code is done.
Well, usual advice is: believe own eyes instead what you can read on Internet. Or it was same some 30-40 years ago, except instead 'Internet' it was TV or press :-)
At atarimania can see some details: amania is not aged
Anyone said: devil is in details ?
From my own experience: using STE DMA audio instead PSG (partially) digitized sound may improve graphic frame rate little. But it depends from other things too - how video displaying code is done.
Well, usual advice is: believe own eyes instead what you can read on Internet. Or it was same some 30-40 years ago, except instead 'Internet' it was TV or press :-)
#14
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.
#15
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.
#16
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 ?.
#17
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.
#18
Rules and announcements / Re: Server Maintenance
Last post by msolajic - 11-01-2026, 03:00:49Maintenance was completed at 03:00, January 11th 2026.
#19
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
#20
Software / Re: TOS versions incompatibili...
Last post by Ronald J. Hall - 09-01-2026, 16:37:38Good summary, Peter. Thanks! 