atarionline.pl ATRsd2CAR - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorZenon
    • CommentTime29 Jul 2022
     
    W każdym pomyśle jest prawda. Nie bez znaczenia jest ilość połączeń, po co się męczyć jak są gotowe rozwiązania.
    Do 74138 doprowadzasz tylko sygnały, gotowe masz na wyjściu, tylko je pobrać
    Plątanina połączeń jest już w scalaku zrobiona. A do wygenerowania impulsu zapis, odczyt dla pamięci wystarczą tylko trzy bramki NAND. Jak się pomyśli to tylko dwie. Nie znam prostrzego rozwiązania.
    Na diodach? Można, tylko po co. Jest technika TTL, po co wracać to ECL, żaden zysk.
    • 2:
       
      CommentAuthorjhusak
    • CommentTime29 Jul 2022
     
    Jeszcze CEMI zreaktywują :)
    • 3:
       
      CommentAuthorMq
    • CommentTime29 Jul 2022
     
    Zenon, z tymi powrotami do starszych technologii to żartujemy sobie, z racji dyskusji o tym co znika z rynku.

    Kuba, może i CEMI by zreaktywowali, ale dziś, to my co najwyżej byśmy tam byli robotnikami, a zarząd (i pieniądze) by należał do anglosasów pewnie.
    • 4:
       
      CommentAuthorgienekp
    • CommentTime29 Jul 2022
     
    :) Fajna dyskusja się zrobiła no i wyszło, że jak będzie trzeba to damy radę i z tranzystorami... Tak ostatecznie to ja się na tym GALu zatrzymam :) Jak co to Kuba ma bramki ;)

    Skoro sama procedura Write jest już znana, to ja się skupię nad wtopieniem kodu ATR2CAR z systemem/zapisem. Na razie to ja sobie wezmę RAMCARTa bo tam zapis to LDA STA (i mogę to robić w niskończoność w testach). Jak zaskoczą procedury OSa i przynajmniej jednego DOSa no to będzie z górki. Bo już docelową procedurę zapisu to się podlepi w zależności od carta i pamięci wlutowanej.

    Plan jest taki, że najpierw wygeneruje byczego ATRa (ja mam RamCarta 4MB). Wgram tam DOSa i jakieś toolsy/gry xexy itp. Potem wygeneruje obraz BIN dla RamCARTA z tego ATRa. A potem konwersja BIN na xex wgrywający bajt po bajcie do ramcarta.

    Jeżeli po czymś takim dos wstanie, będzie można kopiować pomiędzy cartem a portem szeregowym to zadanie wykonane.

    Pytanie czy RamCarta można w jakimś emulatorze udawać? Jak nie to w sumie nie potrzeba bo przecież RAM emuluje jeden bank RAMcarta.
    • 5: CommentAuthorZenon
    • CommentTime29 Jul 2022
     
    Do testów polecam program MOJCARTRIDGE.
    Jager stworzył takie ładne coś co zgrywa zawartość Ramcarta do pliku by tym czymś zaprogramować EPROM.
    Moja prośba była taka. Procedurę, program testuję na ramcarcie. Jak błędy wychwycone i ładnie działa, trzeba to zgrać by ostatecznie zaprogramować EPROM. Odpisał... Twoja prośba jest rozkazem i zrobił. A ja polecam to Tobie.
    • 6:
       
      CommentAuthorgienekp
    • CommentTime29 Jul 2022
     
    @Zenon
    Gdzieś mi się coś obiło o uszy, żeby przy resecie atari w ramcarcie wcisnąć/wycisnąć(?) RW? Bo coś tam się może skasować... Czy jednak coś majaczę.
    • 7: CommentAuthorZenon
    • CommentTime29 Jul 2022
     
    Jest tak by przełączeń Zapis\Odczyt dokonywać pod kontrolą procedury do tego przygotowanej.
    Gdy koniec zabawy i trzeba całość wyłączyć dobrą praktyką jest by pod kontrolą tejże przełączyć na Odczyt. W tej pozycji przełącznika wejście Zapis (WE/) pamięci jest podciągnięte do Vcc, czyli zablokowane.
    Po ponownym włączeniu zasilania czasami generują się dziwne impulsy które przy otwartej pamięci mogą coś nadpisać i kart nie trzyma tego co było.
    To potencjalne niebezpieczeństwo, a ramcart nie ma w tym temacie żadnych zabezpieczeń, zastosowana jest najprostsza ale najmniej skuteczna metoda.
    Ale działa. Więcej razy przytrafiło mi się coś przez nieuwagę "skopać" niż zatracić przez samoistne nadpisanie.
    • 8:
       
      CommentAuthorgienekp
    • CommentTime29 Jul 2022
     
    RamCart to sporo pamięci, więc mogę zrobić tak, że po skończeniu zostawiam go na ReadOnly i Banku 0. A dla pewności trzymać kopię banku 0 w banku następnym. Przy starcie można raz dwa sumę policzyć i jak coś nie gra to odtworzyć Bank 0 który jest dość krytyczny.
    • 9: CommentAuthorZenon
    • CommentTime29 Jul 2022
     
    Bank0 ma taki sam priorytet jak inne.
    Jedyne co go wyróżnia to tu znajduje się nagłówek by zbootował moduł.
    Jak to nie jest konieczne to bez różnicy.
    Jego "wadą" jest też to że po włączeniu zasilania właśnie on się podstawia w miejsca banku pamięci Atari i jak dojdzie do nadpisanie czegoś to właśnie tu.
    Ale.... nie znam urządzenia które pracuje doskonale. Jak to mówi Kiepski. Na tym świecie dzieją się rzeczy które fizjonomom się nie śniły.
    Słowem, każdy pomysł dobry który rozwiązuje problem.
    • 10:
       
      CommentAuthorMq
    • CommentTime29 Jul 2022
     
    Fizjologom :-)
    • 11:
       
      CommentAuthorgienekp
    • CommentTime29 Jul 2022 zmieniony
     
    Nagłówek na "końcówce" musi być w każdym banku taki sam, atr2max już tak robi i przeznacza na to 256 ostatnich bajtów. Dzięki temu, jakiś głupi reset w czasie gdy inny bank był aktywny i trwało kopiowanie nie zawiesi systemu. W nagłówku krótka pocedurka, włączenia banku 0 i skoku do 0 i ewentualnie jakiegoś kodu testującego. W ATR2CAR jest np. robiona kopia ROM do RAM i małe oszustwo przy bocie, że niby mamy NoweUrządzenie. To już działa i oszukuje i K-File i dosy i wiele gier itd. Potem programy zwykle przywracają ROM więc podmienane są wektory DOSa itp. Dzięki temu SIO zawsze wróci choć na chwilę do carta.

    Jak programy chcą czytać dyskietkę to zanim poleci read zwykle robią STATUS. No i tu dodam sprawdzenie, czy bank 0 i bank 1 jest identyczny. Jeżeli nie to zostanie policzona suma obu i ten bank który jest niepoprawny zostanie odnowiony (tym drugim). Odrzucam statystykę, że oba banki się sypną. To raczej nie wystąpi. Raczej zaśmieci się ten bank, który był włączony przed zakłóceniem. Jeżeli zakłóci się jakiś zwykły bank z danymi to zakładam, że DOS jakoś sobie ogarnie BAD SECTOR.

    Tak mi się marzy, żeby
    RAMCART był jak HD
    Zwykły MAXFLASH był jak CDROM
    A MAXFLASH z zapisem był jak CDROM-RW z tym że nie do końca cały trzeba kasować. Natomiast w tej tablicy sektorów to ja bym dodał bit, informacja czy sektor odpowiadający flash jest pusty (same FFy).

    Czyli generalnie wszystko na jedno kopyto robię :) i może to wyglądać jakbym o d..y strony robił :) ale całościowo to ma mieć sens.
    • 12:
       
      CommentAuthorjhusak
    • CommentTime30 Jul 2022
     
    Mi się też tak marzyło… Ech marzenia…

    Ale czasem są spełniane przez osoby drugie.
    • 13:
       
      CommentAuthorgienekp
    • CommentTime19 Aug 2022 zmieniony
     
    Czy jest tu ktoś co ma działający najnowszy emulator z GitHuba Atari800 z kernelem co obsłguje:
    | 75 | 800/XL/XE | 1024 | Atarimax 1 MB Flash cartridge (new)
    ?

    Miałbym prośbę o info czy ruszy mu CAR z testowym SeaWolfemII.
    • 14:
       
      CommentAuthorjhusak
    • CommentTime20 Aug 2022 zmieniony
     
    Nie ruszyło. SelfTest.
    Ty masz Maca, nie?
    • 15:
       
      CommentAuthorgienekp
    • CommentTime20 Aug 2022 zmieniony
     
    Tak mam maca a w wirtualnej maszynce XP. Chwilowo nie mam dostępu do Ubuntu i nie mam jak sprawdzić tego CAR. Bo BINy na Altirze śmigają. Więc teoretycznie nagłówek i po sprawie. Ale zawsze diabeł siedzi w szczegółach.

    Tak czy siak oficjalny ATR2JAC dla J(atari)Carta na razie w trybie ReadOnly jest tu ->link<-

    poprzednio w "beta" był mały błąd i sektory 256 mogły się sypać. Teraz powinno być OK.

    Z wiersza poleceń:
    atr2jac file.atr file.car [-c] [-d] [-128|-256|-512]

    -c podmienia skoki do JDSKINT / DSKINT gdy program "pstryka" PORTemB
    -d robi mały upgrade dla DOS II+/D bo ten coś robi jakiś myk przy detekcji wielkości sektora i na dyskietce DD upiera się że to SD
    -128 wymusza produkcję pliku BINARNEGO do zaprogramowania kostki flash 128kB
    -256 wymusza produkcję pliku BINARNEGO do zaprogramowania kostki flash 256kB
    -512 wymusza produkcję pliku BINARNEGO do zaprogramowania kostki flash 512kB
    Jeżeli nie ma -128 -256 -512 to robi CAR z kodem 75 o pojemności 1MB (8Mbit) , który wymaga jeszcze testów... Zakładam, że 1MB CARa to już sobie każdy ogranie, gdy ma wersję np. 2x512 itp.

    Edit.
    Acha. Dyski ATR mogą być mutantami o większym rozmiarze. Przykład poniżej dla kostki 512kB. Można tam nawkładać normalnych plików dosowych i zrobić sobie binarke do przeflashowania.
    • 16: CommentAuthoremka
    • CommentTime20 Aug 2022 zmieniony
     
    Nie śledzę twojego wątku, ale odpalenia takiego CARta to chwila moment. U mnie poszło, przynajmniej do czołówki. Pograłem kilka minut i jest OK. Jeżeli chodzi o jakieś inne testy to powiedz. Mam DEBIANA 10 i5-4460. Chyba że chodzi o UBUNTU na MACu, to nie pomogę.
    Pozdrawiam.
    • 17:
       
      CommentAuthorgienekp
    • CommentTime20 Aug 2022
     
    @emka
    DZIĘKI!

    jhusak sprawdź proszę jaką wersje masz emulatora. Może jest jeszcze coś czego nie wiemy.
    • 18: CommentAuthorpin
    • CommentTime11 Sep 2022
     
    czy jest gdzieś dostępna skompilowana wersja pod windę? (np. 64bit, win 7)??
    • 19:
       
      CommentAuthorgienekp
    • CommentTime12 Sep 2022
     
    Tak na GitHubie w Release jest kompilacja Win, Ubuntu, MacOS Intela i M1.
    ->link<-
    • 20:
       
      CommentAuthorjhusak
    • CommentTime12 Sep 2022
     
    @gienekp, atari800 jedna z nowszych wersji, wersja commandline.
    • 21:
       
      CommentAuthorgienekp
    • CommentTime12 Sep 2022 zmieniony
     
    @jhusak
    Mi na MacOS w końcu udało się przez HomeBrew zainstalować 5.0.0 na Intelu i na drugim M1.
    ->link<-
    I na obu ten CAR poszło mi od kopa. Natomiast na wcześniejszej wersji 4.cośtam był SelfTest.

    Może Twoja wersja nie ma wkompilowanego 75?

    EDIT Ale najważniejsze to poszedł BIN na przeflashowanym carcie z rzeczywistym ATARI. Czyli wszystko działa jak należy.
    • 22:
       
      CommentAuthorjhusak
    • CommentTime12 Sep 2022 zmieniony
     
    4.2.0
    75 jest jako ostatni...
    Coś tam mrugnie i selftest. Ale jeśli działa z real hw - to miodzio. Zapewne jest jakiś błąd związany z tym kartridżem w 4.2.0.

    Dziwne, przekompilowałem 5.0.0 i też self test (widać, że coś się dzieje, ale jednak kończy się selftestem), usunąłem konfigurację, żeby wykluczyć, ale nie chce działać :(

    Na masterze podobnie... ciekawe, co tu jest źle, skoro działa na HW

    A na AVGCART type 75 nie działa (mówi, że nie obsługuje), a type 42 działa :D

    Coś z tymi kartridżami pod atari800 nie halo.
    • 23:
       
      CommentAuthorgienekp
    • CommentTime14 Sep 2022
     
    Chyba mam. :) Puściłem na Windowsie10 w maszynie wirtualnej i SelfTest. Skopiowałem mój konfig i działa. Porównałem configi i:
    problem jest w opcji
    ENABLE_SIO_PATCH=0

    Jak jest 1 to emulator wprowadza jakąś zmianę w ROMie. W każdym razie u mnie jest tak, że jak wystartuje cart to kopiuję ROM do RAM i robię subtelną zmianę, która udaje, że wstało NoweUrządzenie gotowe na boot. Cart wraca do systemu i dalej bootowanie prowadzi system ATARI, który nie wie, że żadnego nowego urządzenia nie ma :)
    Jeżeli Emulator SIO_PATCH robi jakoś podobnie na tych procedurach odczytu (a coś musi tam mieszać) to się to gryzie.

    W każdym razie sam 75 jest poprawnie zrobiony. BIN też. Realne ATARI działa (przynajmniej u mnie).
    A co zrobić z tym SIO_PATCH to szczerze mówiąc nie wiem.
    • 24:
       
      CommentAuthorjhusak
    • CommentTime14 Sep 2022 zmieniony
     
    Nic nie robić - jest to problem atari800, a nie ATRsd2CAR. Ale wielkimi bykami napisać winstrukcji, że jeśli nieoryginalny/modyfikowany SO, to może nie odpalić (w szczególności dotyczy emulatorów)
    • 25: CommentAuthoremka
    • CommentTime17 Sep 2022 zmieniony
     
    Programy komputerowe pod fachowym nadzorem nie wykazują błędów. Ja to jednak fachowcem nie jestem. Próbowałem utworzyć taki CART ze zwykłego dysku z DOSem DOSII+D6.4 który powinien działać (co widać kilka postów wcześniej).
    U mnie CART utworzył się prawidłowo wczytał DOS, wszystko pięknie, ale poza samym DOSem i katalogami nic nie można wczytać. Problem występuje tylko w gęstości DD. Po przekopiowaniu na MD wszystko (odczyt) działa prawidłowo.
    W załącznikach ATRy z których zrobiłem CARTa i gotowe CARTy
    P.S. Załączone programy wykorzystują pamięć pod systemem dlatego przed wczytaniem należy wykonać RESET. pod emulatorem atari800 F5
    • 26:
       
      CommentAuthorgienekp
    • CommentTime17 Sep 2022 zmieniony
     
    @emka
    robiłeś atr2car czy atr2jac? Bo w tym drugim dodałem opcję "-d", która robi małą modyfikację w DOS II+D dla DD. Nie wiem czemu ale sam dos wczytuje się w DD a potem jak ma czytać coś z dyskietki to wysyła mi do funkcji, że chce czytać sektor w trybie 128. I tylko ten DOS taki numer wycina.

    Jak znajdę chwilkę to i atr2car dostanie "-d" (tzn źródła już mają ale nie release). Tymczasem sprawdź czy atr2jac zrobi dobrze.
    • 27: CommentAuthoremka
    • CommentTime17 Sep 2022 zmieniony
     
    dziękuję za szybką odpowiedz korzystam z ->link<- Nic nie wiem o atr2jac, możesz podać jakiś link
    pozdrawiam
    • 28:
       
      CommentAuthorgienekp
    • CommentTime17 Sep 2022 zmieniony
     
    Zaraz porobię wszystkie release.
    Ale nie wiem czy ten ATR Ci ruszy w całości.

    Tylko Basic poszedł.
    • 29: CommentAuthoremka
    • CommentTime17 Sep 2022
     
    EASMD i ACTION! też pójdzie tylko do przełączania system/RAM używają INC $D301 i DEC $D301 dlatego należy włączyć ROM (użyć RESET F5 w EMU.) przed wczytaniem.
    • 30:
       
      CommentAuthorgienekp
    • CommentTime17 Sep 2022 zmieniony
     
    No faktycznie wszystko działa.
    Jest tylko jeden problem. ATR2CAR powstawał dla gierek, gdzie zapis jest mniej ważny. Ty będziesz chciał zapisać dzieło. ATR2CAR siedzi na wszystkich Dx bo obsługi numeru dysku nie zrobiłem. Więc np. SAVE "D2:costam.abc" nie zadziała.

    EDIT.
    Przekompilowałem release dla ATR2CAR i ATR2MAX
    ATR2JAC jest tu: ->link<-

    ATR2JAC też zrobi Ci CAR ale w kodzie 75. Zadziała tylko na najnowszym emulatorku atari800, no i oczywiście na real ATARI z cartem MaxFlash8Mbit i z pamięcią przynajmniej 512kB.
    • 31: CommentAuthoremka
    • CommentTime18 Sep 2022
     
    Gratuluję niezłej roboty.
    Ja dopiero zaczynam odkrywać świat cartridge'y
    pozdrawiam i dobranoc
    • 32: CommentAuthoremka
    • CommentTime22 Sep 2022 zmieniony
     
    @gienekp Zgłaszając problem nie o to mi chodziło. Miałem nadzieje na zmianę drivera z uwzględnieniem statusu dysku. Patchowanie DOSa nie jest najlepszym pomysłem. DOSII+/D nie uruchamia się z powodu zbyt dużego uproszczenia twojego drivera. Połączyłeś $E453 z $E459 w jedną funkcję i status dysku nic nie robi tylko melduje poprawne wykonanie operacji. Rozdzielenie tych funkcji zwiększania kompatybilność z prawdziwym napędem.
    Twoja funkcja z uwzględnieniem statusu dysku może wyglądać tak
    ;---------------------------------------------------
    ; RELOC CODE FOR RAMPROC

    DVSTAT = $02ea

    ZEROCP lda VCOUNT
    LICNT cmp #$52 ; $52->NTSC $77->PAL
    bne ZEROCP
    ldy #$7F
    sty $D500
    jmp AROUND

    lda DCMND ; $010F
    cmp #$53
    bne ZEROCP
    lda #$20 ; Status dysku DD
    sta DVSTAT
    ldy #$01
    sty DSTATS
    rts

    To oczywiście najprostszy sposób pokazujący jedno z wielu rozwiązań. Rozbudowane procedury powinny być w ROM i powinny uwzględniać STATUS dla $E459 również.
    P.S Program Patchujący musi teraz oddzielić $E459 od $E453.
    Patch $e453 musi wskazywać na $010f.
    pozdrawiam.
    • 33:
       
      CommentAuthorgienekp
    • CommentTime22 Sep 2022
     
    Tak dokładnie :), Status, Format i Write zostało wyczyszczone do zera. Bo obsługa DOSów nie była celem. A to dlatego, że generalnie jak coś rusza z pod DOSa tzn, że to jest plik XEX/COM. A na wczytywanie tych plików z cartridgea jest sporo innych metod dużo lepszych. Natomiast jak masz gry całodyskowe to one zwykle ładują się bezpośrednio z sektorów, korzystając wyłącznie z SIOINT. Kłopot w tym, że takie gry panoszą się po całej pamięci i to co jest na stronie pierwszej, też jest zagrożone. I kod tam musi być minimalny. Więc jeżeli już to cały kod Status/Format/Write trzeba wciskać gdzieś do CARTa. Ale trzeba się pilnować, bo włączenie banku carta wyłącza pamięć ram pod cartem i trzeba się jakoś minąć.

    Żeby poszedł BOOT ATARI to ja tam robię taki trik, że ustawiam PDVMSK ([Zientara] $0247 - PDVMSK - maska obecności nowych urządzeń). SIOINT pierwsze co robi to sprawdza PDVMSK i leci do carta. Teoretycznie takie coś powinno załatwić sprawę raz na zawsze. Jest nowe urządzenie ma ustawiony status i to DOS jakby powinien się do tego ustosunkować. Ale DOSy to olewają bo one były pisane w innej koncepcji...

    I teraz tak. Są dwie drogi. Pierwsza modyfikować DOSy lub pisać nowy (jak SpartaDos) lub driverdos (ramdysk itp), tak żeby widziały jak gadać z czymś nowym. I tak robią ludzie co piszą nowe gry. Świadomie budują kod, który zadziała i z carta i ze stacją dysków. No ale ze starymi grami to nie przejdzie. Druga metoda to rozbudowywać interfejs emulujący prawdziwą stację. I tu jest mała pułapka. Co emulować? Na pewno można by dodać wykrywanie numeru dysku. Ale D1 D2 D3 to raczej DOSowe sprawy, więc skaczemy do zagadnienia poprzedniego. Format/Write? Raczej tylko do cartów co mają zapis (lub RAMcarta), sprawa nie jest prosta, bo na zapis sektora flash trzeba bufor w ram. Ale gdzie go dać, bo przecież stary program tego nie przewidywał? Przykład SilentService przewiduje zapisanie stanu. Ale bez szans, żeby znaleźć miejsce w RAM na przeflashowanie. Gra siedzi wszędzie. No i na koniec status. Jedno LDA/STA sprawy nie załatwi, bo tam stacja ma zwrócić blok danych, gdzie kolejne bajty coś znaczą. Można wyłapać co jest kluczowe i podnieść skuteczność konwersji o kilka procent. I fakt będzie to kolejne kilka procent. Jednak jak bawiłem się z różnymi przypadkami i np. jak mi jakaś gierka nie szła, to szybciej wyłapałem w debugerze kod "na skróty" gierki, który rozwiązywał problem, niż zrobić coś co by było uniwersalne.

    Tak jak napisałem gdzieś na początku. Współczynnik automatycznej konwersji ATR do CAR to obstawiam, że max 50%. Czyli 50% plików ATR z AOL poleci jako CAR. :) Nawet AVGCart w ostateczności daje kabelek. Po prostu ATARI zupełnie inaczej wyobrażało sobie użycie cartridgea a zupełnie inaczej urządzeń SIO. Widać to od pierwszych instrukcji startu ATARI, gdzie na każdym kroku "sprawdzenie obecności cartridgea->przekazanie mu pracy". Tu trzeba udawać, że carta nie ma. Gdy podmienimy ROM z RAM, to gierka przełączy PORTB i już tracimy kod. A robią to nagminnie. Więc jedyna nadzieja to modyfikowanie samej gry/dosu/programu tak, żeby nie robił rzeczy sprzecznych z ideą ATARI carta.

    Kod jest otwarty więc wszelkie dodatki proponuję ładować do części w carcie:
    ;-----------------------------------------------------------------------		
    ; AROUND SIO INTerface

    AROUND lda DCMND
    cmp #$52
    beq SECREAD
    cmp #$57
    beq STATOK
    cmp #$50
    beq STATOK
    cmp #$53 <- TUTAJ STATUS JEST
    bne UNKWCMD
    STATOK ldy #$01
    sty DSTATS
    UNKWCMD jmp RAMPROC+BACK-ZEROCP
    SECREAD ...


    :)
    • 34: CommentAuthoremka
    • CommentTime22 Sep 2022
     
    Dotarło
    Ale jak byś chciał podnieść procent automatycznie konwertowanych ATRów to stacje dysków DD/SD mają pewną właściwość którą próbowałeś zaemulować. Chodzi o to że pierwsze 3 sektory dyskietki DD mogą być czytane jako 128B i 256B ale wszystkie inne są czytane jako 256B pomimo ustawienia DBYT na $80. Twój program pozwala wczytać wszystkie sektory DD jako 128B i gubi się na pewnym mikroloaderze. Sektory 1-3 jako 128B wczytuje prawidłowo pod adres $0700-$0880 ale następne powinny być 256B a Twój program wczytuje je tylko do połowy (do sprawdzenia pod EMU).

    P.S. Ze względów komercyjnych 99% procent gier jest zapisane na dyskach SD/MD dlatego rozumiem niski priorytet DD.

    pozdrawiam
    • 35:
       
      CommentAuthorgienekp
    • CommentTime23 Sep 2022
     
    @emka
    No masz rację. ;) prawie :)
    Normalnie każdy program do SIO wysyła info jaki chce czytać sektor, czy 128 czy 256. I na tej podstawie ja kopiuję dane do bufora. Ale z jakiś powodów DOSiiD mimo, że po 3 sektorach sam woła o 256 to jak się już wczyta i ma załadować program to wysyła żądanie 128. A skoro żąda 128 no to nie mogę mu ekstra dać 256 bo najprawdopodobniej coś nadpisze poza buforem.
    Trzeba by go dobrze przedebugować, bo przed odczytem wysyła STATUS. I jest duże podejrzenie, że jak nie zobaczy "czegoś" to przechodzi na 128 i tutaj pchanie mu 256 na siłę nic nie da.
    Z kolei żeby zrobić STATUS to niestety trzeba już będzie rozplątać całe DSKINT bo jak słusznie zauważyłeś teraz wszystko idzie do jednego worka. A że to rozplątanie musi być w RAM to na stronie 1 już się nie zmieści. A jak tam się nie zmieści to sypną się gry całodyskowe/całopamięciowe.
    Sytuacja patowa.

    Temat zaczął się od formatu SD (jak tytuł wątku). DD doszło potem, jak w ATARI. W praktyce SD i DD to są zupełnie osobne programy sklejone jak jeden.

    Ale projekt nie jest zatrzymany, coś się pewnie wykombinuje, a pomysły są ;). Tylko prawdopodobnie S-XEGS wyleci a zostanie tylko MAXFLASH NEW... i będzie i READ i WRITE I STATUS i FORMAT ;)
    • 36: CommentAuthoremka
    • CommentTime26 Sep 2022 zmieniony
     
    @gienekp Zainteresowałem się twoim programem ponieważ w ten sposób można małym kosztem pracy wczytać prawie każdy DOS do każdego ramcarta. Chyba że już powstał taki DOS a ja jestem trochę nie w temacie.

    "gienekp":

    prawdopodobnie S-XEGS wyleci a zostanie tylko MAXFLASH

    Trochę szkoda S-XEGS jest cartem możliwym do wykonania w domowych warunkach bez uciekania się do GAL'i.

    "gienekp":

    żeby zrobić STATUS to niestety ... na stronie 1 już się nie zmieści.

    Na 1 stronie musi być tylko procedura włączająca carta i skok do niego. Cała reszta może być na carcie, tam miejsca jest sporo. Pozwoliłem sobie sprawdzić jak to będzie działać. Na razie z dość uproszczonym statusem na emu.
    Ktoś świeży ma zawsze trochę inne spojrzenie. Jeżeli coś z moich pomysłów uznasz za warte włączenia do twojego programu to fajnie. Bazowałem na wersji ATR2CAR-20220404 .
    Dodałem status
    Ograniczyłem program tylko do D1:
    Zmieniłem procedurę wywoływania carta na bazującą na stosie.
    Po zabootowaniu włączyłem ROM systemu. Ta pamięć jest potrzeba programom.
    P.S.
    Program może mieć błędy używasz na własną odpowiedzialność. Fajnie by było je wyłapać.
    • 37:
       
      CommentAuthorjhusak
    • CommentTime27 Sep 2022 zmieniony
     
    jatari cart ma tylko 3 scalaki - no GAL onboard. Nie to, żebym reklamował, ale nadmieniam, ze po prostu jest.
    • 38:
       
      CommentAuthorgienekp
    • CommentTime29 Sep 2022
     
    @emka
    dobry patent! Postaram się to dodać we wszystkich wersjach.

    Co do tych cartów to te i te można i na galach i ttelach. Natomiast S-XEGS ma to do siebie, że włącza od razu 16kB i przy sektorach 256 to nie idzie wyrobić i jeżeli obraz jest pod cartem to będzie to migać. Jak jest 8kB to szanse mniejsze.

    Natomiast są przygotowania do zapisu, a tutaj tylko w zasadzie MaxFlash potrafi to ogarnąć. Natomiast to co jest wspólne przy odczycie to raczej tu i tu będzie.
    • 39:
       
      CommentAuthorgienekp
    • CommentTime6 Oct 2022 zmieniony
     
    Upgrade:
    - dodano obsługę statusu według patentu emki, opcja "-d" nie jest już potrzebna i wyleciała
    - dodano obsługę numeru dysku, teraz cart to D1, jeżeli jest odwołanie do D2,D3,itd to procedura skacze do oryginalne funkcji SIO, a więc można używać carta i stacji w miksie
    - zrezygnowano z PDVMSK bo i tak nikt nie przestrzega "Nowych Urządzeń"
    - napisano nową procedurę kopiującą ROM do RAM bo tamta była zaczerpnięta z wiki i była jakaś dziwna
    - działa DOS II+/D bez kombinowania, co może być użyteczne na wypadek robienia różnych własnych carto-dyskietek
    - działa ChaosLoader więc można sobie robić takie carty z wybieraniem
    - działa k-file, więc najprostsza metoda dla XEXów
    - jeżeli PORTB nie jest ruszany to powinno wszystko śmigać, jeżeli jednak program przełącza ten port to trzeba się ratować opcją "-c"

    Skompilowane wersje dla MACOS, Ubuntu i Windows są na GitHubie
    ATR2CAR ->link<-
    ATR2MAX ->link<-
    ATR2JAC ->link<-

    Co może nie działać
    - gdy program zajmie za dużo stosu
    - gry program przełączy PORTB a następnie skacze przez DSKINT bez podania DDEVIC, z oszczędności DSKINT przy "-c" kierowany jest do SIO, ale DSKINT przewiduje różne kombinacje uruchomiania, więc bez zrobienia kopii tej procedury nie da rady, może w przyszłości coś się wymyśli, żeby mało stosu brało
    - inne DOSy, które zachowują się jakby były same i na siłę pchają się do portu szeregowego
    - używanie pod emulatorem z SIO PATCH, emulator robi wtedy przekręt "czasowo-przestrzenny", wstawia nieistniejącą instrukcję skoku, którą ekstra wykonuje po swojemu poza emulowanym ATARI.
    • 40:
       
      CommentAuthorjhusak
    • CommentTime6 Oct 2022
     
    Będzie testowane :)
    • 41: CommentAuthoremka
    • CommentTime6 Oct 2022
     
    No to testujemy.
    Kilka rzeczy które na początek rzucają się w oczy.

    1. Twoja procedura FINAL ustawia RAMTOP na $C0 ale zostawia otwarty edytor na $7C20. Programy które nie otwierają edytora (np. chaos loader) pracują na $7C20 a nie $BC20. Przydało by się zamknięcie i otwarcie edytora z nowym RAMTOP.

    2. Na emulatorze po pierwszym uruchomieniu pamięć pod CARTem jest czysta, jednak na prawdziwym sprzęcie tak dobrze nie jest (u mnie jest ustawiona na $FF) i system czyści ją tylko do $8000. Po podniesieniu RAMTOP i ukryciu CARTa dobrze by było ją wyczyścić.

    3. Systemowa procedura JDSKINT ($e453) rozpoczyna się od ustawienia DDEVIC na $31. (Pierwsze dwa rozkazy) Twój zamiennik opuszcza to ustawienie. Widać to na DOS II+/D po resecie kiedy cart musi korzystać z opcji -c. Twoja procedura oczekuje tam $30-$3F a znajduje $00

    P.S. Na razie tyle. To ciekawy program warty rozwijania. powodzenia.
    • 42:
       
      CommentAuthorpirx
    • CommentTime7 Oct 2022
     
    chciałbym, żeby emka testował/a/ moje programy
    • 43:
       
      CommentAuthorgienekp
    • CommentTime8 Oct 2022
     
    @emka
    DZIĘKI za test! :) Spojrzenie z boku jest mega cenne!

    Ad.1 Tak, to jest od początku dylemat. Czy Emulacja ATR powinna uwzględniać klawisz OPTION po włączeniu. Teoretycznie nie powinienem ruszać RAMTOP. I ruszyć ATR albo z BASICem albo bez. Z drugiej strony głupio tak jak się ma carta, trzymać jakiś OPTION. No więc Basic jest wyłączany i odtwarzany RAMTOP. NA SKRÓTY. Dla gierek to nie ma znaczenia. No ale jeżeli już mamy coś tam robić to pytanie czy zrestartować edytor, czy może skoczyć w odpowiednie miejsce procedury boot tak, żeby OS przeprowadził poprawnie resztę procedury (czyli nie ma carta jest stacja dyskietek)? Sprawa jest do przemyślenia, bo dodać łatwo, ale czy potem nie będzie z tego dalszych konsekwencji "ślepej uliczki"...

    Ad.2 Hmm, a po co? Może tylko dokończyć boot w wersji bez carta?

    Ad.3 Tak i o tym ograniczeniu pisałem w poprzednim poście. Początkowo ATR2CAR podstawiał się tylko pod DSKINT. Bo tak nakazywała logika. Mało tego według Zientary można skoczyć do DSKINT i wtedy OS ustawi $31 albo można skoczyć do DSKINT+2 [Zientera - Procedury wejścia/wyjścia - str 93] i wtedy samemu trzeba dać np. lda #$32. Czyli mamy 2 opcje wywołania procedurki. Okazało się jednak, że o ile system i parę programów ładnie korzystają z drivera OS tak wiele innych pakuje się na żywca w SIO. Nawet nie ustawiają wszystkich parametrów. Działa to takim fuksem, z założeniem, że wcześniej było OK. No więc odpuściłem DSKINT i podmianka poszła w SIOINT. No i wszystko jest cacy do czasu jak jakiś program nie włączy z powrotem ROM. Wtedy cały upgrade znika i koniec. Pozostaje tylko opcja "-c", która na chama pozamienia skoki w programie na dysku ATR. Jeżeli nie było obsługi D2,D3,D4, to pal licho, DSKINT i SIOINT można do jednego worka dać. Ale jeżeli już mamy patrzeć na D1 a i na D2, to nie da rady tego opędzić jedną procedurą (tak jak jest teraz). Niestety muszą być trzy. Wersja SIOINT, wersja DSKINT i DSKINT+2 (druga i trzecia daje się uwspólnić). Dwa pełne wejścia zajmą nam kolejne bajty na stronie pierwszej. Ale co zrobić. Nie da się inaczej. I z jednej strony podnosimy poziom emulacji a z drugiej obniżamy, bo zabieramy pamięć. Nie wiem czy czasem nie powinno być to na opcjach typu "-c" "-s" itp. że wybieramy co idzie do podmianki. No ale z automatu robi się coraz więcej kombinowania manualnego. I nie wiem czy o to chodzi. Bo manualnie można wziąć dany program na warsztat i zrobić go tip-top pod klucz jako cart.

    Pomysł, który wstępnie testowałem i "działa" to:
    0100 lda #$31
    0102 sta DDEVIC
    0105 sec
    0106 bcs STOREC
    0108 clc
    STOREC php
    ZEROCP lda VCOUNT
    (...) dalej po staremu


    I teraz opcja "-c" wszędzie gdzie jest (J)DSKINT zamienia na $0100, wszędzie gdzie jest DSKINT+2 zamienia na $0102, a wszędzie gdzie jest (J)SIOINT zamienia na $0108. Cały trik zawiera 10 bajtów ekstra. Natomiast procedura carta (gdzie mamy duuużo miejsca) ściąga ze stosu rejestr status, patrzy na bit C i jeżeli jest 1 to robi AROUND DSKINT a jeżeli 0 to AROUND SIOINT. No oczywiście jeszcze trzeba zrobić powrót z carta, ale to jest proste. Czy można jakoś inaczej podmienić JMP/JSR i rozróżnić SIOINT i DSKINT? Nie wiem. Jak ktoś ma jakiś pomysł na mniej niż 10 bajtów to chętnie zaimplementuję. ;)
    • 44: CommentAuthoremka
    • CommentTime9 Oct 2022 zmieniony
     
    W punkcie 1 i 2 chodziło mi oto że system nie czyści pamięci pod CARTem i otwiera edytor poniżej $8000. Jeżeli ukryjesz CARTa to system już nie wyczyści tej pamięci i edytor zostanie tam gdzie był otwarty. Niektóre gry przy starcie zakładają że ta pamięć jest czysta.
    Nigdy nie widziałem programu wchodzącego w DSKINT+2. Wywołanie DSKINT powinno byś przez JDSKINT a do zmiany numeru należy użyć DUNIT. Na razie zostawiłbym je na sam koniec lub zignorował.
    Jest jeden sposób rozróżnienia DSKINT od SIOINT. Obie procedury kończą się DSTATS = $01 lub numerem błędu >$80. Program który korzysta z SIOINT musi ustawić ten bajt na $40 (odczyt) lub $80 (zapis). ponieważ CART jest tylko do odczytu interesuje nas tylko $40. W skrócie twoja procedura AROUND na początku sprawdza DSTATS gdy = $40 to dalej pracuje jako SIOINT w przeciwnym jako DSKINT.
    P.S.
    AROUND jest na CARTcie i ograniczenie 10 bajtów nie obowiązuje.
    • 45:
       
      CommentAuthorgienekp
    • CommentTime9 Oct 2022
     
    Te 10 bajtów musi być w RAM, bo tam trzeba zdecydować co dalej. Cała reszta będzie w carcie i wielkość nie ma za bardzo znaczenia.

    Z tym $40 muszę sprawdzić. Interesujące to jest, bo jeżeli byśmy nie wracali do oryginalnego SIO to kłopotu nie ma. Natomiast jak wracamy, to jest dylemat, czy wrócić do DSKINT, który ma podmieniony SIOINT lub może nie mieć podmianki jak ktoś włączy ROM. Trzeba te wszystkie kombinacje przeanalizować, żeby program dwa razy do siebie nie skakał. Ale trop dobry.

    Na razie walnąłem do źródeł
    AROUND  lda DDEVIC
    cmp #$00
    bne D0
    lda #$31
    sta DDEVIC
    D0 and #$F0
    clc
    adc DUNIT
    cmp #$31
    beq D1
    ...

    i MyDOS wstał :)
    Czyli potencjał jest.

    Z edytorem to za bardzo nie widzę problemu, skoro się otworzył na jakimś tam adresie to i na takim jest wyczyszczony. Ale to poboczny problem, można go kiedyś tam doszlifować.
    • 46:
       
      CommentAuthorgienekp
    • CommentTime28 Jun 2023 zmieniony
     

    Pawex:

    Super, może w końcu uda się przekonwertować z .atr i uruchomić Acid800 z carta i zdiagnozować komputer nie bootujący z SIO.

    Acid800 coś tam gmera na $0100 więc wersja z przesuniętym kodem obsługi carta.