Nie trolluj, to nie ma sensu, bo kiedy zmieni się strona, i tak przekleję post 759 na nową.

W poście 759 jest rozwiązanie, które nie wymaga przekształcenia prostej, mikroskopijnej binarki w jakieś dziwaczne monstrum. I owszem, sądzę, że wątek o xbiosie jest jak najlepszym miejscem do prezentowania rozwiązań alternatywnych, jeśli są lepsze niż proponowany przez ciebie xbios.

To nie jest patch, to jest nowy kompilat. I bez wątpienia lepiej jest trzymać plik o wielkości 268 bajtów zamiast dużo większego ATR-a zawierającego niepotrzebne śmiecie. Ale, oczywiście, przymusu nie ma.

xxl, po pierwsze: to jest kod LINKERA, który linkuje z biblioteką programy skompilowane w TBXL. Więc autor (linkera) nie może sobie "nie życzyć zakończenia programu", poniewaz nie jest w stanie przewidzieć, czy kompilowany program się nie kończy.

Po drugie, nawet gdybym tego nie sprawdził, sama logika nakazuje przypuszczać, że inicjalizacja po resecie jest przedłużona pod "zapamiętany" (jak napisałem wyżej) adres DOSINI, gdyż inaczej każdy reset kasowałby z pamięci DOS.

Po trzecie, nie zaśmiecaj wątku.

Moim zdaniem jest to nie tyle "przypadłość", co zupełnie prawidłowa reakcja na ustawiony w krzaki, ważny wektor. Zostaw tak wektor VBL-a ustawiony w obszar, gdzie MyDOS ładuje DUP.SYS, po wyjściu z programu będzie zwis: nazwiesz to "przypadłością MyDOS-a"?

Oczywiście, nie ma większego problemu ze zresetowaniem DOSINI przez DOS po wyjściu z programu, tylko dlaczego nie robi tego sam program (skoro i tak zapamiętuje poprzednią wartość wektora)?

Tak, bardzo podobnej, zwłaszcza jeśli do SIDE ma się też U1MB w kompie. Różnią się nieco poszczególnymi ficzerami, ale generalnie chodzi o to samo: twardy dysk do Atari.

Nom, podeślij. Z opisu wynikają różne rzeczy.

W przypadku PBI nie ma czegoś takiego, jak "ograniczenia OS", chyba że zlekceważyło się nietykalność DCB. Jeśli tak, to mamy do czynienia z ograniczeniem, ale chyba akurat nie ze strony OS-u.

Dla muzyczek i obrazków podczas ładowania nie ma żadnych przeszkód, no chyba że AŁTOR(YTET) się uprze, żeby DL albo player umieścić akurat pod $D800-$DFFF. Ale na to też jest proste lekarstwo: do rozwiązania problemu zaleca się wtedy użycie komendy SDX brzmiącej "DEL nazwapliku".

A to toto cały czas nie działa z PBI?

Every solution has disadvantages:

a) absolute sector addresses make such copying more difficult, but not impossible: it is a question of subtracting a constant at the source place and adding another constant at the destination, to every sector address used in the APT partition container (or, to use FBSD terminology, slice). That's not difficult, especially for a PC program.

b) at the other hand, relative sector addresses add overhead to the code initializing partition table on Atari: the CPU time consumption is of course negligible, but the ROM space, especially in older devices (such as IDEa) may be crucial.

c) next, relative sector addresses add much complication to the matter, if you want to have a pointer inside the APT container, pointing outside the APT container - and this is exactly the case when a FAT partition is to be visible and accessible from both sides, i.e. PC and Atari.

The "c)" is the exact reason why I insisted on using absolute sector addresses when the APT drafts were being prepared, despite strong opposition.

Ja bym się też pisał na takie rozszerzenie do mojego 65XE, jeśli jest ono wersją rozwojową znajdującego się tam prototypu.

Z tym że, ponieważ ten komputer ma 65C816, jeśli jest taka opcja, pozostałbym przy następującej konfiguracji:

1) PORTB: wybieralne do 1 MB (chyba że problemy zgodnościowe z 2 MB już zostały rozwiązane) plus 2 MB liniowej.

2) Axlon: 2 MB plus 2 MB liniowej.

4 mega w bankach mnie niezbyt interesuje, MapRAM też nie. Jeśli natomiast wersja rozwojowa nie oferuje takiej opcji, to nie reflektuję. Czyli: zapisałbym się warunkowo.