SedecarTrigde and hard disk adapted games

[Petari]

  There is new mass storage (with optional other functions) adapter for Atari ST - SidecarT or SidecarTridge.
And of course, it goes in ST cartridge port. It seems that sells well. I need here to write about it's limitations and why it is not so good for hard disk gaming.
 Actually, I wrote it already today for this page:
  Hard disk adapted games, page 1
 On top of page text .
To add that it can not use existing hard disk drivers, and even if someone would want to write driver for it, so in some way for cartridge port, it will not work with it - as it has own kind of driver, in it's RP2040 .
Part of it's description:  "and provide a near-accurate imitation of GEMDOS, thereby rectifying common TOS filesystem bugs." - it admits that is kind of near-accurate imitation . And there is a problem - there is SW what works well only with TOS-es filesystem and usual hard disk driver SW .
 There are actually no some serious TOS filesystem bugs. It works pretty reliable, even in older TOS versions. Surely, not with things which appeared many years later (like LFN - long file names) .
 Will add just this:  there is kind of bug in Dekstop code in versions 1.xx - will crash, show garbage if there is some file with size over 10 MB on drive, in textual mode, as code is not ready for so large numbers. I corrected it in my iTOS, btw. Need to take care about it when works with Steem .
  Basically it has same problems as EmuTOS - what was written to fix TOS errors, bugs. But SW is made for original TOS versions, and lot of it just works not under EmuTOS, especially games.  So, no SidecarT, no EmuTOS if want to play good old Atari ST(E) games - not with emulators too - with them use regular TOS version - like 1.04, and real hard disk emulation - with hard disk image file.

[Petari]

 I was thinking about how to make this so called GEMdisk drive emulation more compatible with real hard disk work way for Atari ST, emulators.  Made little tests:  function Get BIOS parameter block (BIOS #7) will return error if is called for non existing real drive - despite sys var for disks has set bit for that logical drive, because there is no MBR (master boot record) and other what goes with real hard disk usage. Sys var is set because otherwise could not open that drive in Desktop.
 And there are some games with option for hard disk install - and they use often exactly Get BIOS P.B. to see is there hard disk, and it is called not only by install, but during gameplay to detect is it running from hard disk or floppy - normally install goes to C:   . So, that will not work under SidecarT and ACSI2STM gemdrive.  And there are other solutions for hard disk detection, install in some games, and all it is about 30 years old.
 How to solve this problem ? Simple: do not use such adapters :-)  Sure, many will not like it . I was thinking about giving some typical BPB instead error when Get BPB is given for 'GEMdrive' . But it will not solve other checks, and especially not RWABS calls.   Now I think that only good and practically complete solution is:
When DIR for Atari is selected on host computer, or on SD card in case of sidecarT or ACSI2STM  then just copy all from it to then empty partition on host - what is in image of TOS compatible hard disk, so with MBR, partition with regular FAT, ROOT DIR ...  So, there should be at least one such on host storage - and size can be even like 30 MB . That should be enough for 99.9 %  of SW. Can be larger ones too, of course - capacity is not problem now.
Under 32 MB size has advantage that can use regular sectors and not large sectors needed for partitions over 32 MB - less RAM usage, simpler driver . And compatible with TOS 1.00-1.02 too.
 So, when all is copied, of course with converting possible LFN filenames to 8.3 ones then just boot from that image placed on host storage - what needs of course regular hard disk driver for usual way of TOS work. And that will be pretty good emulation of real work . What will not work is for instance: direct ACSI port access from SW on non ACSI adapters . But I did not see such thing in games.
 And yes, same thing can be added to emulators - Steem, Hatari (will they even consider it ?) .
You know that Steem sources are published. Myself did some changes earlier. Now my C knowledge is pretty rusty, and was never big.  Of course there is Don Megacool (Steem SSE) too .
 And it is not only because my old adapts which manipulate installed drivers (Gamex, before 2012), but for my later systems which increase speed  -  as wrote: for games with own hard disk installer, and there may be some other cases when 'GEMdrive' is not good enough to run some SW what runs from regular hard disk (system) .
So, I will contact sidecarT author in days. And probably some others. Well, some may think that I just overcomplicate things and want to destroy people's data on computers :-) At least that's how some of 'great' atariage members think, write on that shit place.
 Funny thing is that even now, some 20 years since it was made in Steem we can do something new with it ....

[Petari]

 I wrote e-mails about this to some people, which worked about hard disk way of storage   implementation for Atari ST machines and emulators.  I intentionally did not use term 'GEMdrive' - because it is just wrong. What abbrev GEM is ? - Graphics environment manager . So, basically part of TOS what activates later, and is for such SW . Hard disk filesystem activates of course earlier, before AUTO folder run - and SW what starts from AUTO folder does not use GEM, as it is not activated then. Advantage of it is less RAM usage by TOS, so more space for user SW . And such SW can not use TOS-es WIMP - Windows, icons, menus, pointers . If you see such, it is in that SW code.
 I got reply so far only form Diego from Gooddata Labs, and it was really not something different from approach of most people doing some development in Atari ST waters. Basically pretty sarcastic, and similar to Exxos approach: you are not manufacturer, so do your own 'enterprise' - we manufacturers know all it better, as we work for money - yeah, that's my interpretation of text what is similar in it's fashion to product names - must sound good, but not much connection with reality. Are they aware about TOS/DOS compatible partitioning ?
SidecarT TOS emulator - it is not emulator, it is only TOS version switcher. Could give more examples.
Instead it, better read this:   https://atari.8bitchip.info/ASTfamMS.html

Now I think that sidecarTridge for mass storage is just not good buy. Instead it get rather ACSI2STM .
It has so called gemdrive mod too, but it can work with regular hard disk drivers for ACSI port too. And is faster, especially in write.  Btw. both use same microcontroller. Is it responsible for slower work (transfer rates) than by UltraSatan, SD4ST ? Or firmware ?
 
 It would be good to see what I proposed in my first reply here to emulators - will make easier usage of real hard disk emulation and file transfers related with it.  But who I'm to suggest something ... I'm just someone who spent looot of time with storage for Atari ST serial, starting with it in 1987 - then made some floppy SW, EPROM programmer for cartridge port . Little later went in hard disk area, designed IDE adapter . And so on ... 
Well, today humankind is in serious crysis, I would say - most care is about profit, getting attention, presenting own work as something exceptional, best in that area, and like. Best can be only one, not hundreds , thousands ... And I see in later months, couple years really shallow WEB sites, with missing relevant details, some errors, but what not missing are adverts and self praising. No wonder in this corrupt society. Only way that things start to be better is fight against it, against bad people, liars, thiefs ....  Or will be more and more war and killed innocent people, less optimism considering future.
Lot of people think, act now as there is no future.  It is on us, will it be future with humans or cockroaches  (may be two legged ones too).

[Petari]

And something what everyone who deals with, using computers should know: even smallest error at some point can make whole thing not working well, or even at all . Yeah, probably most known is error in code. But same is with usage of it - despite measures in OS, GUI - if user's whole approach is wrong (based on own low knowledge, or bad advices, sites and like) it will fail.
And I dare to say that those who do SW, HW development - well, part of them does same mistake - just ignoring some details, and that results in product being not so useful. Of course, they ignore negative comments too. As we know word negative is not always negative - Covid test negative - that's positive thing :-) Writing about errors of someone - may be helping act. Grow up 'geniuses' !