Moim zdaniem nie ma, bo p. Rusinek nie odżegnuje się od słowa samego w sobie, a tylko - tak mi się zdaje - od jego niewłaściwego (chamskiego) użycia. Dajmy na to, jeśli ktoś, hipotetycznie :), napisałby e-mail do pana premiera zaczynający się od słów "Ty ryży nieudaczniku", a ktoś inny miałby mu to za złe, to przecież ten krytyk nie odżegnywałby się od słów jako takich czy samego sformułowania, a jedynie od jego użycia nie pozostającego w zgodzie z konwencjami takiej korespondencji.

Podobnie p. Rusinek zapewne nie ma za złe nikomu, że słowo "Witam" istnieje albo że jest w użyciu, ma tylko za złe jego niezbyt grzeczne nadużycie. Czy reakcja w postaci nieodpowiadania na tego typu maile jest właściwa (i grzeczna), można wątpić. Pewnie należałoby jednak odpowiedzieć, tylko z reprymendą.

Ale nie jest publicznie dostępny, zostanie wypuszczony dopiero z SDX 4.47 (wg obecnych ustaleń, w sierpniu br).

EDIT: dodam, że oczywiście z SDX 4.46 i wcześniejszymi po prostu nie będzie działał.

Myślę, że byłoby o wiele jaśniej, gdybyś napisał coś o ogólnych założeniach. Domyślam się, że chodzi o przełączanie całych (lub prawie całych) obszarów podstawowej pamięci 64k, dzięki czemu można mieć jakby kilka komputerów w jednym i przełączać się pomiędzy nimi po prostu przez przełączenie banków. A poza tym z poziomu programu działającego w aktywnym banku można podglądać, co mamy w innych - taki frezer/monitor/debugger. Tak?

Nie widzę chwilowo przeciwwskazań, żeby coś takiego można było zbudować i dla Atari, z jednym tylko zastrzeżeniem: na Atari rozszerzenia pamięci są używane od dawna i dość powszechne, a minimum to jakieś 320k. Wobec tego, wydaje mi się, żeby takie urządzenie jak Twoje było czymś więcej niż ciekawostką, jeden "bank" powinien obejmować oprócz podstawowych 64k jeszcze jakieś 256k rozszerzenia.

O ile mi wiadomo, nie było nigdy niczego takiego jak "rzymskie rydwany wojenne".

U mnie ten loader chodzi z D3 i nie a z nim problemów. Mapowanie nie rzutuje, loader jest programem dosowym, liczą się tylko dyski wg tego jak są przypisane/widoczne w SDX.

Ale jakie są objawy tego niedziałania? Może by tak poza tym o nich powiadomić autora? :P

FDISK FJC korzysta w 100% z interfejsu SIOV. Eddy też. Jeśli w Eddym działa funkcja Edit device i możesz nią czytać, modyfikować i zapisywać sektory dysku (tylko uwaga, bo to daje dostęp do całego dysku, nie tylko do jednej partycji), to FDISK FJC też powinien to umieć, a jeśli nie umie, to wina autora. CBDO :)

W trakcie kopiowania nie ma działać. Niektóre tagi znikają, bo odrysowuje się część ekranu przykryta okienkiem COPYING.

Hmm. Będę musiał to spróbować odtworzyć. Może uda mi się znaleźć jakieś uszkodzone dyskietki ;) Opisywanie zachowanie jest nieco dziwne i może być to błąd w SC, ale może też i w np. COPY (bo SC nie ma własnej procedury kopiowania plików, w celu zrobienia copy albo move uruchamia COPY.COM).

Krótko mówiąc: czy podobny efekt występuje też przy kopiowaniu tych samych plików z tej samej dyskietki przez COPY, czy tylko w przypadku użycia SC?

Poza tym: która wersja SDX, która wersja SC, jak wygląda CONFIG.SYS?

PS. Co do XEP, sterownik cały czas "jest w planach", ale póki co niezrealizowanych. Czy SC będzie na XEP-ie używalny, trudno powiedzieć, ale "częste odświeżanie" nie jest wymagane, ogólnie przemalowywane jest tylko to, co niezbędne: swego czasu zoptymalizowałem SC właśnie pod kątem XEP-a, żeby nie przemalowywał elementów ekranu, których przemalowywać nie trzeba. Np. na VBXE ponowne namalowanie ramki robi różnicę trudną do zauważenia, na XEP-ie pewnie byłoby inaczej.

Program:

        blk reloc main

start   nop
        rts

        blk reloc $42

ext     nop
        rts

        .ds $0200

Generuje coś takiego:

     1  FE FF 01 00                     blk reloc main
     2
     3 0000,0002> EA            start   nop
     4 0001 60                          rts
     5
     6 0002 FE FF 02 42                 blk reloc $42
     7
     8 0002,0002> EA            ext     nop
     9 0003 60                          rts
    10
    11 = 0004                           .ds $0200
    12
    12 0004 FE FF 03 C2 04 00 + BLK EMPTY

Nagłówek wygenerowany przez .ds ma ustawiony bit 'page align' ($C2 = %11000010), dziedziczy go po ostatniej dyrektywie blk reloc. Bug polega na tym, że nie ma (chyba?) sposobu na uniknięcie tego dziedziczenia, tzn. jeśli chcę, żeby blok binarny był wyrównany do granicy stron, a późniejszy .ds nie, nie mogę tego zrobić[1].

[1] oprócz stosowania średniowiecznej metody liczenia offsetów na palcach od dyrektywy blk empty, co w przypadku skomplikowanych programów, mających dziesiątki pól .ds, po prostu nie wchodzi w rachubę.

Ano, też jestem tego zdania. Pewne rzeczy, których nie da się blitterem zrobić za jednym zamachem, da się właśnie - czego świetny przykład dałeś - załatwić paroma kolejnymi blitami.

Ale jest jedna dziwna rzecz w tym boosektorze: bajty 14-15 (licząc od zera) zawierają wartość $0004. To jest liczba sektorów zarezerwowanych. Microsoft twierdzi, co następuje:

Nie jestem pewien, czy stara wersja sterownika (czyli ta, którą masz) nie wymaga, żeby tam było właśnie 1.

Daj X EDDY.EXE