126

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@Polar Pierre: No dobra, dorzucam na razie samą wersję .XEX ... niebawem jak dopiszę "readme" to wrzucę też i źródła. Prawdę mówiąc mam dość już tej gry ;D nie wiem czy ona nie jest napisana w jakimś języku, bo kod w tej grze to jakieś dziwne bagno jest, w dodatku gra ma masę błędów :D poprawiłem błędne wyświetlanie "game over" w przypadku wyboru opcji gry na dwóch graczy.

Wersję z "trainerem" robiłem z wersji kasetowej, bo wersja dyskowa ma doczytywaną każdą planszę po przejściu poprzedniej. W dodatku gra w wersji dyskowej ma o wiele więcej plansz. Ta wersja ma ich mniej, w dodatku zajmują te plansze również obszar aż do $BEFF, a więc pakuje się to w obszar ekranu ($BC20-$BFFF), ale dlaczego o tym piszę? Bo gra jest "odporna" na RESET i po jego wciśnięciu startuje ponownie, jednak w tym wypadku ostatnia plansza dostępna w grze która znajdowała się w obszarze $BC00-$BEFF zostaje zniszczona, gra po wciśnięciu RESET ma jakby o jedną planszę mniej, ale to chyba i tak nie ma znaczenia, ponieważ gra i tak nie ma zakończenia i po przejściu ostatniej dostępnej planszy startuje niejako od poziomu #1.

Jak pisałem wcześniej, dorzucę później źródła gdyby kogoś interesowało "jak to zostało zrobione", dla nie lubiących kompresji (dłuższy czas oczekiwania po wczytaniu) ostrzegam iż ta wersja została spakowana PACK-ICE 2.40 (z ATARI ST), więc dekompresja trochę trwa ;-) Źródła niebawem będa dostępne więc jeżeli ktoś będzie chciał, będzie mógł bardzo łatwo zrobić sobie wersję bez dekompresji :)

127

(115 odpowiedzi, napisanych Software, Gry - 8bit)

x_angel napisał/a:

A w "Moon Patrol color fixed" wstawiłeś poprawioną wersję? Bo nie widzę różnicy między "przed" a "po" :)

No wersja z tego postu: http://www.atari.org.pl/forum/viewtopic … 98#p302698

jest na 100% poprawiona, własnie sprawdziłem, wygląda tak:
http://seban.pigwa.net/aa/moon_patrol_color_fixed.png

przed poprawką było tak:
http://seban.pigwa.net/aa/moon_patrol_color_bad.png

128

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@x_angel... pewnie że rzucę okiem, ale powiedz mi proszę czy "to tak ma być"? ... tzn. chodzi mi o to, że gdy wybiorę grę na dwóch graczy i na planszy pojawia się JACQUES, to zamiast jego wyniku, liczy żyć, etc. od razu pojawia się napis GAME OVER, próbowałem wersję dyskową i kasetową z atarimania i obie wersje mają tą samą wadę/błąd... czy to zawsze w tej grze tak było? (prawdę mówiąc to nie pamiętam jak było w wersji którą miałem na kasecie w Turbo 2000).

129

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@pustak: tak, faktycznie... ta gra ma w sobie coś że chce się grać i grać ;-) Nie dłubałem w tym zbyt długo, więc nie ma trainera, ale dodaję do załącznika wersję z nieśmiertelnością zrobioną na szybko.

Gra przechowuje aktualną liczbę pozostałych żyć pod adresem $0615, pod adresem $58D2 znajduje się instrukcja DEC $0615, którą reprezentuje ciąg bajtów $CE $15 $06, w pliku zamieniłem zatem ciąg $CE $15 $06 na $2C $15 $06 co odpowiada instrukcji BIT $0615, co powoduje że komórka $615 nie jest już zmniejszana,  instrukcja BIT w tym wypadku "robi" za dwu-bajtowego NOP-a.

Co prawda gra po pierwszej "śmierci" gracza znika jedną z kulek reprezentujących liczbę żyć (tak napisano kod gry i nie chciało mi się tego poprawiać), ale od tego momentu liczba "kulek" nie będzie już ulegała zmianom :)

130

(14 odpowiedzi, napisanych Programowanie - 8 bit)

No to mamy nowego króla wydajności (pomijając LUT na który trzeba zmarnować 256 bajtów pamięci :P)

http://seban.pigwa.net/aa/parity_bench2.png

ja metodę xor-based znałem ze świata HDL-owego (dlatego pisałem o tym że HDL-owo się zrobiło jak ją Willy zaprezentował), tzn. stosowałem ją np. w kodzie verilogowym dla SlightSID-a, tyle że w verilogu to jeszcze prościej, w przypadku rej. konfiguracyjnego SlightSID-a musi się zgadzać parzystość danych, tylko wtedy rej konf. będzie "zaktualizowany":

inout [7:0]            ata_DAT;            // ATARI data bus
...
...
if (atr_str[7:0]==8'h41 && ~(^ata_DAT)) cfg_reg  <= ata_DAT;

a więc jak widać całe "obliczenie" parzystości sprowadza się do wykonania operacji XOR na wszystkich bitach i zanegowaniu wyniku:

parity = ~(^ata_DAT)

I to jest własnie piękno "języków opisu sprzętu!" :D

W sumie po tych moich przygodach z parzystością na początku lat '90 nigdy potem nie miałem potrzeby obliczania parzystości na 6502 i zaprezentowałem te moje wykopalisko z przeszłości bez większego zastanawiania się nad problemem, nawet nie chodziło mi o żaden wyścig na cykle, a temat potraktowałem jako ciekawostkę, która koniec końców dzięki waszym postom przekształciła się całkiem ciekawy wątek. W dodatku QbaHusak zainspirował mnie to optymalizacji i napisania tego mini-bechmarka, wiem że nie jest on doskonały ani jakiś "pro", ale mniej więcej spełnia swoje zadanie pozwalając zweryfikować czy każda z procedur działa poprawnie i ile czasu się wykonuje.

Ostatni kod zaprezentowany przez Willy-iego (ten z 6502.org) pokazuje jak bardzo ekstremalnie można zoptymalizować każdy problem! :) To się nazywa pomysłowe wykorzystanie dostępnych instrukcji CPU aby osiągnąć efekt końcowy :D Ten fragment kodu w zestawieniu z verilogową implementacją bardzo fajnie pokazuje jak rozbić problem natury typowo równoległej na coś co da się wykonać etapami, i co ciekawe nie krok po kroku (metodą zliczania poszczególnych jedynek) ale jak wykorzystać możliwości prymitywnego ALU którym dysponuje 6502 do "zrównoleglenia" operacji.

@marok: dzięki za miłe słowa, jednak uważam że nie robię nic wyjątkowego, a to że czasami mi coś wyjdzie można chyba tłumaczyć tylko tym że jak mnie jakaś rzecz zainteresuje to staram się poznać dany temat jak najlepiej, czy też na tyle na ile pozwala moja możliwość percepcji. Sądzę że inni są o wiele bardziej sprawni w różnych kwestiach. Dla mnie niektóre rzeczy są po prostu poza zasięgiem bo wymagają jakiegoś mega abstrakcyjnego myślenia, co w moim przypadku jest chyba jakimś problemem... mój mózg działa chyba w ten sposób że wszystko dla niego musi być logiczne i wytłumaczalne w prosty sposób, jeżeli problem jest natury abstrakcyjnej trudno zainteresować moją mózgownicę tego rodzaju problemami, tak już mam i nic na to nie poradzę :D

Grzegorz,

Dzięki za linki i fotki, dzięki Twoim wykopaliskom wiadomo chociaż że na takim carcie był standardowy i typowy soft dla Blizzarda, dobrze że wiedzieć że nie trzeba poszukiwać kolejnego "artefaktu z przeszłości", jeden problem mniej na głowie :D

A dla zobrazowania jak wygląda ładowanie przykładowej gry z magnetofonu Yolk-a... z użyciem podobnego softu jaki znajdował się na carcie "Blizzard Megasoft", wrzucam to video: (zgrane z realnego sprzętu, w roli głownej magnet Yolka, jeden z cartów od uicr0Bee-iego oraz kaseta nagrana z pomocą Turgena od Baktra):

132

(6 odpowiedzi, napisanych Bałagan)

drobne uściślenie, Archer Maclean nie zmarł w wigilię, w/g informacji na Wikipedii: https://en.wikipedia.org/wiki/Archer_Maclean lub tutaj: https://fusionrgamer.com/2022/12/25/arc … s-left-us/

zmarł on 17 grudnia 2022 przegrywając długą walkę z nowotworem. Pokłony dla mistrza. Niech spoczywa w pokoju. Dropzone było i nadal jest naprawdę niesamowitą grą.

133

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Oczywiście że wszystko można, nawet zrobić benchmark tak aby faworyzował dany algorytm, zresztą to i tak nie istotne... willy zapodał taki algo który nie zależy od ilości zapalonych/zgaszonych bitów. Zresztą każdy może powalczyć, do tego posta dodaję źródła na prędce skleconego "benchmarka"... to czy liczymy wszystkie wartości ($00-$FF) czy też sekwencję pseudo-losową ($D20A) ma niewielkie znaczenie, tzn. nie zamienia miejsc na liście w tym moim pseudo-benchmarku ;D

Jeżeli chodzi o ten mój ślimakowaty algo bazujący na pomyśle Kernigana, to podobało mi się w nim to że nie był zależny czasowo od wartości, np. czas wykonania obliczeń zarówno dla wartości $AA,$55,$0F,$F0 będzie identyczny... tzn. pętla skończy się po 4 przebiegach ... Zresztą różnice (w porównaniu z Twoją implementacją) są niewielkie... i całe te nasze wyścigi są czysto "akademickie", to takie udowadnianie wyższości jednych świąt nad drugimi ;-)

http://seban.pigwa.net/aa/parity_bench.png

EDIT: Wyniki w tabelkach się nieco zmieniły (na wyższe) ponieważ w stosunku do wersji pierwotnej przybyło kodu w pętli pomiarowej, a nie chciało mi się już bawić w kompensację tegoż, gdyż wszystkie algo zostały ponownie uruchomione w "nowych warunkach". Drastycznie przybyło czasu dla wersji LUT, ponieważ proste LDA parity_table,X zostało zastąpione skokiem do procedury (a jak wiadomo JSR/RTS kosztują sporo czasu ;P)

134

(14 odpowiedzi, napisanych Programowanie - 8 bit)

hi hi hi... wiedziałem że to się tak skończy :D nie wklejałem swojego wiekowego kodu aby udowadniać jaki jest szybki... to tak jak pisałem "kalka" algorytmu Kernigan-a przepisana bez jakichś specjalnych optymalizacji, bo i tak użycie LUT o wielkości 256 bajtów jest nie do pobicia, ale skoro zaczyna się "walka na cykle", to ja będę uparty jak osioł :D tzn. będe obstawał przy swoim (żartuję oczywiście), ale w ramach eksperymentu myślowego wyobraźmy sobie następującą procedurę testową:

st      sei
        inc    $d40e
        lda    $d40b
        bne    *-3
        sta    $d400

m_loop  lda    $d40b
        bpl    *-3
        lda    $d40b
        bmi    *-3
        lsr    $d01a

        ldx    #$00
l1      txa

        jsr    parity

        inx
        bne    l1

        inc    $d01a
        lda    $d40b
        cmp    vc_max
        bcc    l_nup
        sta    vc_max

l_nup    jmp    m_loop

A więc synchronizujemy się z VBL (powrót pionowy), obliczamy parzystość dla wszystkich bajtów od $00 do $FF, po czym odczytujemy wartość vcount ($D40B) sprawdzamy czy jest ona mniejsza czy większa niż poprzednio odczytana i zapamiętujemy ową wartość tylko jeżeli jest większa niż poprzednio odczytana (czyli zapamiętujemy najbardziej pesymistyczny przypadek)... i tak pętlimy w kółko (wartość vc_max) można odczytać pod debuggerem/emulatorem.

I teraz skoro już mamy procedurę testową zaproponuje swoje "zoptymalizowane" rozwiązanie, skoro użyłeś rej. Y (moja stara procka nie używała rejestrów X,Y, tylko A i lokacji na stronie zerowej) to zakładam że również mogę a więc:

parity  sta    v
    
        ldy    #0
    
        ora    #0
        beq    endp

loop    iny
        sec
        sbc    #1

        and    v
        sta    v
        bne    loop
    
endp    tya
        lsr    @
        rts

^^^ a więc tak jak u Ciebie, wejście rej. A, wyjście C.

I teraz prezentacja wyników: (mniej --> lepiej)

     LUT: $0D
   willy: $40
lizard_1: $6A
   seban: $6F
lizard_2: $78
qbahusak: $85

nie sądziłem że wyjdą z tego wyścigi na cykle! Ale skoro się zaczeło to czemu nie! Na pewno wyjdzie z tego coś fajnego! :)

EDIT1: o widzę że szybko się dzieje, willy dopisał wersję xor-based :D że tak powiem mocno HDL-owo się zrobiło! i szybko! :D uzupełniam zatem tabelkę.
EDIT2: dodałem do tabelki wyniki procek zaproponowanych przez Lizarda.

135

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Kiedyś... dawno, dawno temu... w czasach gdy na ziemi jeszcze pamięci FLASH nie było i gdy mikrokontrolery (MCU) miały okienko do kasowania promieniami UV, a 6502 było całkim szybkim CPU parzystość liczyłem w ten sposób:

parity  sta    v
    
        lda    #0
        sta    p
    
        lda    v
        beq    endp

loop    inc    p
        lda    v
        dec    v
        and    v
        sta    v
        bne    loop
    
endp    lda    p
        and    #1
        rts

a jak trzeba było mieć wynik ultra-szybko to się robiło look_up_table (LUT):

        ldy    #0

l0      tya
        jsr    parity
        sta    p_lut,y
    
        iny
        bne l0

i potem obliczenie parzystości danego bajtu było trywialne i szybkie, bo wystarczyło sięgnąć do tabelki.

Aby uzyskać wzór który wygenerował marok wystarczy albo skorzystać z p_lut, albo skorzystać z procedury parity:

        ldy    #0

l1      tya
        lda    p_lut,y

;       jsr    parity         ; --> gdy nie chcemy korzystać z look-up-table

        lsr    @
        ror    @
        sta    ($58),y
    
        iny    
        bne    l1

        lda    #$21
        sta    $22f

Jeżeli nie używamy LUT, to czas wykonania procedury "parity" jest oczywiście zależny od liczby "ustawionych" bitów w bajcie.

Oczywiście pomysł algorytmu nie był mój, podpatrzyłem go w jakimś artykule o programowaniu w C i przeniosłem sobie ten kod na assembler 6502. O ile dobrze pamiętam to powyższy algorytm bazował na sposobie liczenia bitów zaproponowany przez Brian-a Kernigan-a, a tenże algorytm (zliczania bitów) był opublikowany w książce "C Programming Language 2nd Ed." (by Brian W. Kernighan and Dennis M. Ritchie). Książka pochodziła chyba z okolic 1988 roku.

136

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Yolk napisał/a:

Musiałeś coś jeszcze naprawiać w tym magnetofonie żeby całość ruszyła?

No trochę tego było:

  • wymiana głowicy; nie wiem skąd była ta zamontowana w magnecie, ale po pierwsze miała zamienione przewody po drugie nie była możliwa prawidłowa regulacja skosu, gdy chciało się prawidłowo ustawić głowicę ta gniotła taśmę.

  • wymiana rolki dociskowej; ta była "jajowata" więc nie było mowy o równomiernym prowadzeniu taśmy.

  • wymiana paska napędowego; ten był na granicy swoich możliwości, końcówka kasety i pasek potrafił się już ślizgać na rolce napędowej od silnika

  • wymiana silnika; ten zaczął mi rzęzić i piszczeć po paru testach, po rozebraniu silnika (destrukcyjna operacja) okazało się że nie dość że łożysko ślizgowe było wytarte i suche to jeszcze szczotki (tzn. miedziane blaszki) które miały kontakt z komutatorem, były praktycznie przetarte do cna.

  • dołożenia paska od licznika (tego brakowało w magnetofonie po jego otwarciu)

po tych operacjach magnet zaczął działać całkiem sprawnie :D

137

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Yolk ... a jednak Blizzard... Blizzard uA741 ;-)

Hej!

Dawno nie pisałem w tym wątku, ale w końcu coś się ruszyło i walczą dalej... co prawda nie będzie to dziś wpis z cyku "z kolekcji uircr0Bee", a tym razem będzie dotyczył tego co znalazłem w magnetofonie Yolk-a. Jakiś czas temu Yolk poprosił o identyfikację turbo w magnetofonie który posiadał, jego pytanie padło w tym wątku: Prośba o identyfikację Turbo w magnetofonie", a ja podąrząjac drogą rutynową oczywiście wypaliłem (sądząc po ilości i rozmieszczeniu elementów) że jest to kolejny klon czeskiego turbo 2000, zastanawiała mnie co prawda pr-ka na płytce, ale reszta się zgadzała i mogło by to być kolejne wcielenie czeskiego turbo 2000 i sprawa pewnie nie została by dokładniej zbadana, gdyby nie to że Yolk nie mógł doprowadzić tego magnetu do działania... zaproponował że wyśle go do mnie i że będę mógł się temu przyjrzeć... i chwała mu za to iż to uczynił bowiem okazało się że to turbo w jego magnetofonie nie jest żadnym klonem czeskiego Turbo 2000... a dość specyficzną wersją Turbo Blizzard, piszę specyficzną ponieważ nie widziałem wcześniej takiej wersji... może na początek wkleję zdjęcia PCB:

http://seban.pigwa.net/Yolk/blizzard_uA741/photos/blz741_pcb_top.jpg
^^^ górna warstwa PCB, oczywiście napisy ze scalaków starte, jednak można się od razu domyślić że 8-nóżkowy scalak to zapewne uA741, a 14-nóżkowy scalak to komplet czterech dwu-wejściowych bramek NAND z których zbudowano multiplekser pozwalający przełączać tryb pracy interface z normal na turbo.

http://seban.pigwa.net/Yolk/blizzard_uA741/photos/blz741_pcb_bot.jpg
^^^ tutaj widzimy spód płytki drukowanej, na podstawie własnie tego układu ścieżek można było przystąpić do odtworzenia schematu tego co znajduje się na płytce.

Początkowo, jak pisałem już wcześniej sądziłem ze jest to kolejny klon czeskiego turbo 2000, jednak tym razem podczas odtwarzania schematu okazało się że niewiele z czeskim turbo 2000 ma ten układ wspólnego, ale aby nie przedłużać wkleję po prostu schemat tego co udało się przerysować ze wzoru ścieżek na płytce:

http://seban.pigwa.net/Yolk/blizzard_uA741/sch/blizzard_ua741.png
^^^ otwórz obraz w nowej karcie aby uzyskać większą rozdzielczość, lub pobierz wersję wektorową, o tutaj: Blizzard uA741 version (plik w formacie PDF).

Przyznam że początkowo się zdziwiłem gdy zobaczyłem co narysowałem i nie dawało mi to spokoju, bo jak się okazało jest to dość "uproszczona" wersja układu który miałby realizować funkcjonalność interfejsu dla Blizzard Turbo, i zastanawiałem się czy aby na pewno ma prawo ona poprawnie działać, bowiem brakowało w niej stopnia wejściowego który zapewniłby dość duże wzmocnienie sygnału, więc zacząłem również analizować dokładniej płytkę magnetofonu. Bardzo szybko okazało się że płytka jest zmodyfikowana w taki sposób, aby dostosować już istniejący na płycie magnetofonu wstępny wzmacniacz i ogranicznik sygnału do wymogów jakie stawia torowi odczytu Blizzard Turbo, zmodyfikowano więc obwód ogranicznika, (zmodyfikowano pętlę sprzężenia zwrotnego), zwiększono wzmocnienie przedwzmacniacza, usunięto większość kondensatorów odcinających wyższe częstotliwości, zwiększono jeden z kondensatorów separujących sekcje przedwzmacniacza z ogranicznikiem. Listę zmian i modyfikacji umieściłem na schemacie powyżej. Bazowałem na schemacie magnetofonu XC12 narysowanym przez Jer-a (Jerzego Sobolę). Aktualna wersja schematu znajduje się na jego stronie www (schemat XC12).

Jak zatem widać czasami zdarzają się perełki w różnych magnetofonach, ta wersja w/g nadruku na PCB powstała w '91 roku i jest sygnowana przez Megasoft (ktoś kojarzy może tę nazwę? skąd pochodzili, etc?). Także dzięki uprzejmości Yolka, udało się zarchiwizować kolejną mutację/wersję Blizzard Turbo.

Testowałem ten interface za pomocą plików wygenerowanych przez Turgen-a od Baktra, po uruchomieniu magnetofonu i przywróceniu go do działania, udawało się bez najmniejszego problemu wczytać pliki zapisane w formacie Blizzard. Jedyne co zauważyłem to że ten interface nie lubi kaset nagranych z poziomem 0dB, idealne warunki dla niego to kasety zapisane z poziomem -3dB lub mniej, zresztą z podobnym poziomem nagrywa również ten magnetofon.

Zatem kończę już ten wpis nie przedłużając zbytnio i nie zanudzając was kompletnie :)

ps1) @piguła: dzięki za kolejne dumpy!

Podziwiam determinację i zacięcie! Pełen szacunek za wykonaną robotę! I ogromne uznanie za to że dzielisz się wiedzą i wszystko co robisz ma status "Open Hardware". Jest nadzieja w narodzie że będzie jeszcze dobrze! :) Serce rośnie człowiekowi jak widzi że kolejny artefakt z przeszłości udało się uratować od zapomnienia i udokumentować wszystko co się dało! :)

140

(9 odpowiedzi, napisanych Sprzęt - 8bit)

Przyszło mi do głowy jeszcze jedno, możesz z poziomu BASIC-a (bez carta turbo) wpisać:

POKE 54018,56:POKE 54016,96:POKE 54018,60:POKE 54016,0

to powinno włączyć silnik magnetofonu w przypadku poprawnego działania interfejsu KSO Turbo 2000 (taśma powinna się zacząć kręcić po wciśnięciu PLAY)

141

(9 odpowiedzi, napisanych Sprzęt - 8bit)

marmazzaa napisał/a:

Nic się nie dzieje, ekran jest niebieski a taśma się nie kręci :(

A to jest zastanawiające, oryginalnie ekran powinien być szary, być może to modyfikacja softu, albo jakieś uszkodzenie zawartości EPROM, jeżeli przekłamaniu uległa zawartość pamięci EPROM (i stąd niebieski kolor) mogło się również zdarzyć że fragment kodu odpowiedzialny za sterowanie silnikiem uległ uszkodzeniu. Ale to dość mało prawdopodobne aby takie przekłamania nie uszkodziły na tyle kodu żeby się wszystko nie zawiesiło. Zobacz czy z tej pętli (z niebieskim ekranem) da się wyjść wciskając OPTION+SELECT+START.

142

(9 odpowiedzi, napisanych Sprzęt - 8bit)

Tak jak już pisali wcześniej koledzy, cart i soft są poprawne jeżeli chodzi o pracę z interface który masz w magnetofonie (podłączany do drugiego portu joysticka).

Tak jak pisze Baktra w przypadku KSO Turbo 2000, silnikiem dodatkowo steruje się (oprócz portu SIO), jednym z sygnałów z drugiego portu joysticka, na schemacie JER-a widać tranzystor QA który jest podłączony do pinów 7 (+5V) oraz 2 (BACK1, bit #5 układu PIA) ... te dwa połączenia są konieczne do tego aby tranzystor QA mógł wystawić sygnał +5V który po pierwsze zasili płytkę interfejsu turbo (a dokładnej układ 4069) a także wysteruje linię MOTOR_CONTROL włączając tym samym silnik magnetofonu gdy pracuje on w systemie turbo.

Należałoby sprawdzić poprawność tychże połączeń, a jeżeli one są OK, to trzeba by zweryfikować czy ów tranzystor sterujący jest sprawny.

143

(9 odpowiedzi, napisanych Sprzęt - 8bit)

Jaki soft na carcie? (zdjęcie, albo jakieś informacje jak się przedstawia menu carta po uruchomieniu).

144

(28 odpowiedzi, napisanych Sprzęt - 8bit)

No nie ma łatwo, ale tak... i magnetów i pozostałych cartów z Twojej kolekcji.

145

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Yolk napisał/a:

Seban, a co powiesz na to, żebym Ci wysłał ten magnetofon z tajemniczym Turbo?

Oczywiście przyjrzę się temu magnetofonowi. Jest to jakaś inna/nietypowa/nieznana mi wersja, więc warto ją zachować/zarchiwizować.
Wysłałem e-mail via forum ze szczegółami dotyczącymi przesyłki.

146

(28 odpowiedzi, napisanych Sprzęt - 8bit)

No jasne, myślę że to dobry pomysł... skoro jest popularny "nośnik" (tzn. SIC! Cart) to myślę że większego problemu nie będzie aby popełnić jakąś większą składankę.

147

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Hej!

W mojej wersji też był "RAMDASK", więc pewnie tak było "firmowo" chociaż też podejrzewałem "sypiący" się EPROM. Jeżeli chodzi o drugą część carta to:

ad 1) Microloader 2.7 ---> wychodzi do BASIC-a jeżeli uruchomi się komputer bez trzymania OPTION, z BASIC-a do loadera można przejść pisząc DOS (tyle że BASIC będzie włączony)
ad 2) Jeżeli będziesz miał ext ram to się najpierw zapyta "Install RAMDASK in" ... "additional banks", jak nie to "RAM under OS", a jak masz włączony BASIC to zobaczysz też "RAM under BASIC". Odpowiadasz klawiszami Y lub N.
ad 3) jeżeli włączyłeś komp bez OPTION to przejdzie do BASIC, wtedy do loadera wchodzisz pisząc DOS z linii komend BASIC-a. Jeżeli włączysz komp z OPTION to od razu przechodzi do loadera (SHORT KOS 1.0 by KNS CORP.)
ad 4) to program którzy znajduje i wypisuje nazwy zbiorów zapisanych na kasecie, wypisuje na starcie "I'm Looking !", a potem po wciśnięciu dowolnego klawisza przechodzi do poszukiwania nazw zbiorów na kasecie.

Co do narzędzie to oczywiście dopiszę odpowiedni kod aby dało się zrzucać również 16kB carty, więc daj spokój z wypruwaniem EPROM, szkoda ryzykować, będziesz go pruł jak się okaże że zawartość EPROM jest przekłamana i będzie trzeba go wypalić na nowo. Mam nadzieję że mając drugą kopię (od Ciebie) uda się złożyć całość lub zweryfikować poprawność danych.

Za opóźnienie nie ma co przepraszać, fajnie że znalazłeś czas i chęci aby tym pogrzebać! Dzięki! :D

148

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Dzięki! :D

ew. jak będzie problem, to dopiszę do Simple Cart Dumper-a opcję zgrywania cartów 16kB.

149

(28 odpowiedzi, napisanych Sprzęt - 8bit)

A masz możlwiość wykonania "zrzutu" zawartości ERPOM-u tego carta? Pytam ponieważ egzemplarz którym dysponowałem już "umierał" (jeżeli chodzi o zawartość pamięci EPROM) i nie mam pewności czy zrzut jest prawidłowy (mimo ręcznych poprawek). Gdyby była możliwość porównania tego zrzutu z innym źródłem byłaby pewność co do poprawności zawartości obecnego "zrzutu".

150

(28 odpowiedzi, napisanych Sprzęt - 8bit)

a ten Twój cart to coś podobnego do tego --> http://www.atari.org.pl/forum/viewtopic … 25#p246825