Niezalogowany (Zaloguj się)

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.

ATRsd2CAR

Od 1 do 50 z 146

- 1:
  
  CommentAuthorgienekp
- CommentTime28 Mar 2022 zmieniony
ATRsd2CAR

Kasety się starzeją, dyskietki padają, pozostaje utrwalać dane na cartach.

O ile pliki XEX (COM) idzie jakoś przenieść na pamięć flash to już z obrazem ATR nie jest tak prosto.
A jeżeli obraz repzrezentuje dyskietkę jakąś niestandardową to już robi się problem.

Mi się zachciało przenieś na cartridge grę Silent Service. Kłopot w tym, że taka pełna wersja, gdzie maluje się statek z uszkodzeniami to istnieje tylko w wersji dyskowej.

Z całego tego galimatiasu zrobiło się narzędzie ATRsd2CAR, które załatwia sprawę automatem. Wiem, że niektóre zaawansowane carty coś tam potrafią, ale z Silent Service to tylko przez kabel SIO szło.

W skrócie, konwerter leci z wiersza poleceń.
Cały projekt ze wszystkimi kodami jest tu:
->link<-

Gdy wklepiemy:
```
atrsd2car SilentService.atr SilentService.car
```
Wyskoczy nam informacja o potencjalnie niebezpiecznych skokach do DSKINT
```
Possible calls:
 JSR JDSKINT ; 0x0000C6 20 53 E4 -> 20 00 01
 JSR JDSKINT ; 0x000412 20 53 E4 -> 20 00 01
 JSR JDSKINT ; 0x003A0D 20 53 E4 -> 20 00 01
 JSR JDSKINT ; 0x003DA3 20 53 E4 -> 20 00 01
 JSR JDSKINT ; 0x0080B5 20 53 E4 -> 20 00 01
```
No i jako rezultat mamy gotowy "SilentService.car". Można sobie to potem zamienić na BIN i zaprogramować flash.

Jeżeli ATR jest jakiś wredny (szczegóły dalej), to lepiej jest uruchomić z opcją "-c", czyli:
```
atrsd2car SilentService.atr SilentService.car -c
```
Automat podmieni wszystkie skoki do DSKINT. Bez "-c" to trzeba ręcznie w HEX-edytorze wcześniej w ATR grzebać.

Tyle w skrócie a teraz szczegóły techniczne.

Program buduje obraz dla "SWITCHABLE XEGS CARTRIDGE". Ma to trzy zalety. Pierwsze, to jest to standard dość dobrze opisany na tym forum i wiadomo o co chodzi. Po drugie, dostępne są w sprzedaży elementy do tego. Po trzecie, ten standard dość dobrze nadaje się do emulowania dyskietki.

Podstawowy cart S-XEGS ma 128kB. Bank ostatni siedzi zawsze na $A000-$BFFF i dla niego napisałem "starter.asm", który załatwia całą robotę. Rejestr $D500 przełącza bankiem na adresie $8000-$9FFF. Tam też jest podkładany obraz ATR.

Program działa dla dyskietek SD. Ich pojemność to 720sektorów x 128 bajtów, czyli 92160bajtów. Taka wielkość spokojnie zmieści się w obrazie flash.

Po uruchomieniu ATARI leci procedura RESETWM. W połowie uruchamiany jest skok "INITCART". Tutaj nic nie robimy (rozkaz RTS). Po zakończeniu procedury RESETWM system skacze do CARTRUN. I tu siedzi cała kombinacja wirtualnego dysku.

W pierwszym etapie kopiowany jest ROM do RAM i wyłączany BASIC. Następnie nadpisywana jest procedura bazowa DSKINT. Tutaj wciśnięty jest kod, który zamiast odczytu sektora z dyskietki, czyta sektor z CARTa. Bo to nie jest tak, że do obsługi dysku potrzeba DOS. W ATARI jest taka jedna procedura właśnie DSKINT, która załatwia odczyt sektora. I teraz uwaga. DOS może to robić po swojemu i nasz ATR pewnie nie będzie działał. Ale znowu jak jest dyskietka DOSowa to prawdopodobnie wyciągniemy XEX i kłopotu nie ma. Natomiast jak jest jakaś franca nietypowa, jak SilentService to taka podkładka pod DSKINT jest poprawna. No więc teoretycznie pozostaje wywołać "jeszcze raz" procedurę BOOT. Tym razem oszukany system zacznie bootować z CARTa jak z dyskietki. No i jest normalnie... prawie.

"SWITCHABLE XEGS CARTRIDGE" ma to do siebie, że jak ustawimy bit 7 w $D500 to odłączy nam całkiem carta (dlatego jest SWITCHABLE). Super sprawa bo mamy do dyspozycji cały RAM. No ale jak odłączymy to pojawia się sprzętowa reakcja, jakbyśmy wyciągnęli carta. Dlatego przy takich numerach należy ogłupić system, aby nie zważał na różnice pomiędzy TRIG3 i GINTLK.

Dodatkowo jak wyłączymy CARTA to podetniemy gałąź na której siedzimy i wysypie nam się nasza procedura. Więc przed samym uruchomieniem powtórnego BOOT kopiujemy małą procedurkę do RAM, który wyłączy CARTa i skoczy do BOOT. Tym sposobem BOOT zaczyna jakby nie było żadnego CARTa, natomiast podmieniona DSKINT włączy sobie banki pamięci CARTa kiedy trzeba.

Czyli podsumowując do tego miejsca. ROM siedzi w RAMie, podmieniona procedura DSKINT i oszukana RESETWM i WAIT. Na czas odczytu sektora włączana jest pamięć CARTa, pobieramy bajt, wyłączamy CART i zapisujemy bajt tam gdzie trzeba. Odczyt sektora po $82 lini VCOUNT żeby nie migało. Teoretycznie to załatwia wiele rożnych ATRów. No ale nie SilentService, które panoszy się po całej pamięci i mało tego używa danych pod ROMem (!), więc po przełączeniu PORTB zasłoni nam nasze triki i klops.

SilentService tak szaleje po całej pamięci, że ani pod ROMem nie ma spokoju ani w całym zakresie od $0400 do $BFFF. Aby temu zaradzić, jest przygotowana druga sprytna procedura DSKINT. Nowa DSKINT jest dość długa, dlatego cześć jej siedzi w pamięci CARTa. A część wymagana w RAMie na stronie 1 (tam gdzie stos procesora). Teraz jeżeli wyjątkowo oporny program, który miesza ROMem, szaleje po RAMie chce skoczyć do DSKINT czyli poprzez adres JDSKINT ($E453) do DSKINT ($C6B3), to trzeba mu "ręcznie" podmienić te skoki na $0100... i mieć nadzieję, że za bardzo nie męczy stosu procka.

I to właśnie robi opcja "-c". Jeżeli teraz ATRsd2CAR wykryje w binarce:
```
JSR JDSKINT ; 0x000412 20 53 E4 -> 20 00 01
```
Tzn, że w ATR znaleziono ciąg bajtów, który może sugerować na skok do DSKINT. Równie dobrze mogą to być dane. Jeżeli gra nie miesza ROMem to można to olać. Ale jeżeli gra włączy nam ROM (albo przełącza banki w 130XE) to niestety ale trzeba zamienić w ATR 0x53 0xE4 na 0x00 0x01. Wtedy bezpiecznie poleci odczyt przez $0100 do CARTa.

Jak widać zrobienie CARTa z ATR to nie takie proste. Jest cała masa pułapek, które mogą spowodować, że to nie będzie działać. Przedstawione narzędzie raczej skupia się na tych wrednych binarnych ATRach, więc do gierek powinno być OK.

Na zakończenie poniżej wersja dyskowa Silent Service na cartridge.

pzdr

P.S Jak komuś wyjdą jakieś ciekawostki to niech napisze, bo liczba kombinacji "niedziałania" jest ogromna. Ja wracam do kończenia softu dla RAM-CARTA, bo tak naprawdę to był powód powstania tego toolsa.

EDIT: Aktualne źródła oraz kompilacje na GITHUBie ->link<-
- 2: CommentAuthorPawex (RTG)
- CommentTime28 Mar 2022 zmieniony
Super, może w końcu uda się przekonwertować z .atr i uruchomić Acid800 z carta i zdiagnozować komputer nie bootujący z SIO.
- 3: CommentAuthorpajero
- CommentTime28 Mar 2022
Pięknie opisane. Podziwiam za czas spędzony. Efekty zapewne zrekompensowały mozolne wdrożenie do Release. Nabyta wiedza zaprocentuje.

Wada - zapisu niet.

ps. coś podobnego, choć bez przerabiania plików, od strony sprzętowej robi AVGcart z kablem SIO. ATRy na carcie wczytują się przez SIO.
- 4:
  
  CommentAuthorgienekp
- CommentTime28 Mar 2022
Tak mam AVGcarta z kabelkiem. Ten cart ratuje się obsługą sprzętową i "ogonkiem" do SIO. No i działa :)

Czysto programowe podejście niestety daje jakieś 30% sukcesu. Natomiast różne podejścia do konwersji ATR->CAR zwiększają szansę na ten sukces.

Projektanci ATARI nośniki jak kaseta, dyskietka czy cartridge wymyślili jako uzupełniające i każdy ma zupełnie inną koncepcję programowo-sprzętową. W sumie to dobrze, bo wszystko ma jakieś plusy. Ale konwersja full automat jest dość trudna.

Powiem szczerze, że w te kilka sekund po włączeniu ATARI kiedy jeszcze jest czarny ekran, to naprawdę to co się tam dzieje to robi wrażenie bo jest niezwykle spójne.
- 5:
  
  CommentAuthorjhusak
- CommentTime28 Mar 2022 zmieniony
Gratulki. Niedawno coś takiego próbowałem zrobić, ale nie chciało mi działać i zarzuciłem.
Pobawię sie twoim kodem i spróbuję to namówić do współdziałania z AtariMax, czy Jcart.

Ak od siebie dodam, że ten programik build.c duplikuje świetny i znany swiss-army-knife xxd z opcją -i

czyli:
xxd -i starter.bin >starter.h

Xxd jest chyba w każdej dystrybucji linuksa jako standardowy tool.
- 6:
  
  CommentAuthorKaz
- CommentTime28 Mar 2022
Gienekp - gratulacje, fajna rzecz!
- 7:
  
  CommentAuthorgienekp
- CommentTime29 Mar 2022 zmieniony
A od siebie dodam, że ten programik build.c duplikuje świetny i znany swiss-army-knife xxd z opcją -i

Faktycznie :) Dzięki. Ja jestem z epoki "stdio", czyli że nic nie ma i trzeba wszystko samemu zrobić.

Poszła mała poprawka kodu. Niektóre ATR nie trzymają standardu ale można je upchać.

Popularny k-file robi po swojemu. Po wczytaniu loadera olewa DSKINT i skacze od razu do SIO. Wiadomo, że z k-file'a można xexa wyciągnąć i zrobić inną metodą. Ale to też daje wskazówkę na kolejny upgrade gdzie należałoby się bardziej wtopić w system.
- 8:
  
  CommentAuthorjhusak
- CommentTime29 Mar 2022
xxd to naprawdę mocarz - używam go baardzo często:
- w vimie do porównywania plików binarnych
- do edycji plików binarnych (opcja -r - reverse)
- do parsowania i grepowania plików binarnych (-c 1 - w jednej kolumnie)
- do ogarniania grafiki bitmapowej surowej
- do ogarniania sampli raw, np. konwersja 8/16->4 bity to pikuś.
- do liczenia rozkładu bajtów (wraz z sort i uniq)

I jeszcze inne się pewnie znajdą zastosowania :)
- 9: CommentAuthormrk
- CommentTime29 Mar 2022
@jhusak dzięki za info, *nix'ów używam ~25 lat a xxd nie znałem :)
- 10:
  
  CommentAuthorgienekp
- CommentTime29 Mar 2022
@jhusak

no genialny jest ten XXD. Już podmieniłem źródła żeby bazowały na XXD.

Dodałem też obsługę JSR JSIOINT. Dzięki temu k-file zaczęły działać. Przykład poniżej z "Sea Wolf II".

acid800 nadal stawia opór :/
- SeaWolfII.car
- 11:
  
  CommentAuthorjhusak
- CommentTime29 Mar 2022 zmieniony
Fajny ten patent z czytaniem sektora podczas wygaszenia. Ale z tego, co wiem, to ANTIC przestaje działać po 248 linii, czyli trzeba poczekać do 124 linii vcount.

Może to mieć znaczenie przy NTSC, gdzie czasu poza anticem jest mniej. Ale i tak to daje 6400 bajtów na sekundę (128*50)
- 12:
  
  CommentAuthorgienekp
- CommentTime29 Mar 2022 zmieniony
[EDIT]
No w NTSC faktycznie jest inaczej. I chyba nawet vcount inaczej zlicza. No więc może nie działać super.

Wygląda na to, że kopiowanie sektora trwa około 19 linii vcount. Ostatnia wartość z jaką można sprawdzić w NTSC to jest $82. Taką przyjąłem bo z PAL też zadziała. 19 linii to tak naprawdę chyba 38. Więc raczej może gdzieś tam coś mignąć, jeżeli akurat gra podłożyła ekran pod bank CARTa. No bo to kopiowanie trochę trwa :/
[/EDIT]

Dumam teraz nad "nowym urządzeniem". Tam są w OS gotowe procedury praktycznie do wszystkiego. Wydaje się, że nie potrzeba by nawet robić kopii ROM do RAM.

Bo ja podłożyłem się pod DOSINI, która to skacze do SIOINI a w niej jest, że albo leci na klasyczne urządzenia SIO albo jeżeli PDVMSK(Parallel DeVice MaSK $0247) jest nie zerem to rusza obsługa urządzeń "równoległych". Sprawdzałem, że po inicjalizacji CARTa jeżeli coś tam ustawie to nie znika. Więc za każdym razem odwołanie do SIO sprawdza czy nie potrzeba coś tam zrobić...

Ja nie znam żadnego urządzenia równoległego. Może ktoś się z tym spotkał?

W każdym razie w systemie jest gotowiec na to i jakby się tu jakoś podłożyć to by kompatybilność bardzo ale to bardzo wzrosła.
- 13:
  
  CommentAuthorjhusak
- CommentTime29 Mar 2022 zmieniony
Ponieważ rozkminiałem ostatnio movplayera, piszę:
- vcount 0-3 - 8 pustych linii nad obrazem.
- vcount 4-123 - obraz.
- vcount 124 - 130(1) - ntsc
- vcount 124 - 155(6) - pal

Pętli przepisującej sektor można ukręcić ca 512 cykli, czyli prawie 5 linii ekranowych :)
```
;
                ldy #$7f 
                ldx #$ff 
                lda #124
LOOP            cmp VCOUNT
                bne LOOP                 
CPYSECT         lda TMP+4 
                sta $D500 
                lda (TMP),Y 
                stx $D500 
                sta (TMP+2),Y 
                dey 
                bpl CPYSECT 
```
co daje 28 cykli na obrót, czyli 4 bajty na linię, co daje 32 linii, czyli 16 vcountów. Tak czy inaczej pod NTSC będzie mrygać. Można jeszcze trochę ukręcić stosując absolutne indeksowane (2 cykle) i lda TMP+4 zamienić na lda# i wtedy 3 cykle na plus. Można też stosować dwie różne procki, do przepisywania pod kartridż jw i poza kartridż bez żonglowania D500, wtedy 10-11 cykli gratis. A wtedy to zajmie 17 cykli na bajt, czyli 10 vcountów, co się akurat zmieści poza obrazem w NTSC.
- 14:
  
  CommentAuthorgienekp
- CommentTime30 Mar 2022 zmieniony
@jhusak

podobają mi się te triki :) Poszedł upgrade...

Zrobiłem wersję z adresowaniem natychmiastowym (podmienia się zmienna). Dodałem też procedurę przy starcie CARTa co sprawdza do ilu zlicza VCOUNT. Jeżeli osiąga $8D tzn. że jest PAL i taką wartość nadpisuję. Jeżeli "nie" to znaczy, że jest NTSC i wtedy zlicza do $70. W obu przypadkach kończy się na lini $02, więc np. Silent Service nie miga ani w wersji PAL ani w wersji NTSC.

Zrezygnowałem z DSKINT na rzecz SIOINT. Skoro DSKINT skacze do SIOINT tzn, że jest to lepsze miejsce. Ale podmiana jest minimalna bo "oszukuję" system, że mam Nowe Urządzenie.
```
lda #$01
sta PDVMSK
```
i potem podmiana w ROM na
```
; SIO INTerface

	org $C933

CRITIC  = $42
DSTATS  = $0303
DUNIT   = $0301
GETLOW  = $C9AF
PDIOR   = $D805
PDVMSK  = $0247
PDVREG  = $D1FF
PDVRS   = $0248
SIO     = $E971

	lda #$01
	sta CRITIC
	lda DUNIT
	pha
	lda PDVMSK
	beq FOUND
	ldx #$08
NEXT 	jsr RAMPROC	; jsr GETLOW
	beq END 	; beq FOUND
	txa
	pha
	jsr PDIOR
	pla
	tax
	bcc NEXT
	lda #$00
	sta PDVRS
	sta PDVREG
	beq END
FOUND 	jsr SIO
END 	pla
	sta DUNIT
	lda #$00
	sta CRITIC
	sty DSTATS
	ldy DSTATS
	rts
```
gdzie prawdziwa zamiana to:
```
jsr GETLOW -> jsr RAMPROC
beq FOUND  -> beq END
```
i teraz w zasadzie jak ATR nie miesza PORTB to nie potrzeba dawać opcji "-c"
- 15:
  
  CommentAuthorjhusak
- CommentTime30 Mar 2022
Jest rejestr określający, czy to pal:
pal equ $d014

"
53268 D014 COLPM2

(W) Color and luminance of player and missile 2 (706).

PAL

(R) Used to determine if the Atari is PAL (European and Israeli
TV compatible when BITs 1 - 3 equal zero) or NTSC (North
American compatible when BITs 1 - 3 equal one; 14 decimal, $E).
European Ataris run 12% slower if tied to the VBLANK cycle (the
PAL VBLANK cycle is every 50th second rather than every 60th
second). They use only one CPU clock at three MHZ, so the 6502
runs at 2.217 MHZ -- 25% faster than North American Ataris.
Also, their $E000 and $F000 ROMs are different, so there are
possible incompatibilities with North American Ataris in the
cassette handling routines. There is a third TV standard called
SECAM, used in France, the USSR, and parts of Africa. I am
unaware if there is any Atari support for SECAM standards.

PAL TV has more scan lines per frame, 312 compared to 262.
NTSC Ataris compensate by adding extra lines at the beginning
of the VBLANK routine. Display lists do not have to be altered,
and colors are the same because of a hardware modification.
"
- 16:
  
  CommentAuthorgienekp
- CommentTime30 Mar 2022 zmieniony
Jest rejestr określający, czy to pal:
pal equ $d014

To prawda. Jednak na "sąsiednim" forum znalazłem dyskusję na temat jakoby ludzie przelutowywali ANTIC i GTIA i wychodzą różne numery. I że najbezpieczniej to sprawdzić co jest naprawdę.
- 17: CommentAuthormono
- CommentTime30 Mar 2022 zmieniony
PAL lub PALNTS pokazuje _wyłącznie_ jaki jest generowany kolor.
Natomiast jak się chce wiedzieć ile jest linii w ramce czyli jakie jest odchylanie pionowe - 50 czy 60 Hz - to trzeba sobie policzyć linie.
Za to detekcja SECAM-u jest trudniejsza i trzeba mieć cartridge jakiś, albo kombinować z przyciskami joysticka - czyli czytać rejestry TRIGx, bo w PAL/NTSC ustawiane są natychmiast, w SECAM-ie natomiast zawsze z początkiem linii skanningowej.
- 18:
  
  CommentAuthorjhusak
- CommentTime30 Mar 2022 zmieniony
Aha, rozumiem. Ale podejście "ktoś sobie coś zmodyfikował i ma mu działać" nie działa na dłuższą metę. Już wyobrażam sobie te kilobajty kodu sprawdzającego, jaka jest konfiguracja, a potem warianty kodu dla różnych konfiguracji...

Nie tędy droga. Atari to system dobrze określony i program na stockowym kompie musi dobrze działać, na rozszerzonym już niekoniecznie. Każde rozszerzenie czy modyfikacja powinny zapewniać tryb zgodności, jeśli ją psują. Jeśli tak nie jest, to one nie są dobre.

Dlatego jednak ograniczył bym się (perfidnie) wyłącznie do sprawdzania PAL, na stockowych zawsze działa. A jak będziemy sobie te linie liczyć, to twórcy sprzętu się tego nauczą i bez sensu.

Twórca każdego sprzętu powinien uruchomić wszystkie programy jakie są i wszystkie powinny działać. A jeśli nie działają to z powodu błędów, które się nie objawiły.
- 19: CommentAuthormono
- CommentTime30 Mar 2022
Niestety testując rejestr PAL nie da się wykryć komputera z SECAM bo dobrze zdefiniowane Atari zapomniało poinformować użytkownika że w komputrze jest FGTIA i trochę inny kwarc.
Ogólnie masz oczywiście sporo racji, bo inaczej trzeba by poprawiać tony już napisanych programów po pojawieniu się nowego sprzętu albo modyfikacji. Chociaż ja osobiście lubię sobie wykryć w miarę możliwości co tam u użyszkodnika drzemie pod maską i odpowiednio zareagować. A co! Niech sobie nie myśli. No bo co w końcu.
- 20:
  
  CommentAuthorgienekp
- CommentTime30 Mar 2022
Z tego co wyczaiłem to $d014 jest rejestrem GTIA więc pewnie pokazuje jaki mamy GTIA. VCOUNT zlicza ANTIC, a o niego bardziej chodzi bo w końcu VCOUNT będzie wykorzystywane.

Jakby kod miałby być w RAM (którego zawsze mało) to narzuciłbym PAL i niech NTSCowcy ogarniają temat skoro wymyślili sobie taki system. :) A że kod siedzi we flash (którego zawsze jest sporo) to można dodawać wodotryski. W końcu to tylko parę bajtów.

Ale też jestem wyznawcą stockowej konfiguracji. Z tym, że mnie nawet drażni 130XE ze swoją dodatkową pamięcią :)
- 21:
  
  CommentAuthorjhusak
- CommentTime30 Mar 2022 zmieniony
130 XE i jego rozszerzenie to majstersztyk. Oddzielny dostęp procka i Antica to mistrzostwo świata. Ale fakt, że liczenie max VCOUNT nie jest jakoś tam skomplikowane, to parę bajtów.

A konia z rzędem temu, kto ma Atari SECAM.
- 22:
  
  CommentAuthorgienekp
- CommentTime30 Mar 2022
130 XE i jego rozszerzenie to majstersztyk. Oddzielny dostęp procka i Antica to mistrzostwo świata(...)

Ale jak ANTIC idzie z innego banku to też zatrzymuje procka? Tzn, czy w 130XE jest ekstra magistrala?
- 23:
  
  CommentAuthorPeri Noid
- CommentTime30 Mar 2022
Nie jest.
- 24:
  
  CommentAuthorgienekp
- CommentTime30 Mar 2022
1. Świat stacji dysków jest mi zupełnie obcy, dlatego może zadam śmieszne pytanie, ale czy jest jakiś program, narzędzie, który po uruchomieniu dysku wyświetliłoby takie menu gdzie wyskoczy lista plików COM i np. naciskam A i wczytuje pozycję pierwszą. Albo coś podobnego.

Bo klasycznie z DOSem II+ to działa.

2. Jaki DOS potrafiłby obsłużyć 4032 sektorów po 128?
- DOS_II.car
- 25:
  
  CommentAuthorpirx
- CommentTime30 Mar 2022
na pewno możesz to zrobić za pomocą micro sparta dos (msdos hehehe), jest też taki inicjalizer do MyDos, ale nie znam nazwy.
- 26:
  
  CommentAuthormav
- CommentTime30 Mar 2022
Ja mam całą kolekcję dyskietek "z epoki", które mają coś podobnego, a było to utworzone Chaos Loaderem, aczkolwiek (chyba) trzeba było to ręcznie wbijać?
- 27: CommentAuthormono
- CommentTime30 Mar 2022
jhusak:
A konia z rzędem temu, kto ma Atari SECAM.
Hie, hie. Szykuj konia z rzędem. I to niejednego, bo niestety jest nas więcej :)
- 28: CommentAuthorkkrys
- CommentTime30 Mar 2022
Mój kolega ma 800XL w Secam-ie
- 29:
  
  CommentAuthorgienekp
- CommentTime31 Mar 2022
Pytanie do użytkowników stacji dysków, czy ktoś wie może jak to jest, że system operacyjny podczas bootowania zakłada, że sektor ma 128 bajtów, a przecież fizycznie może być dyskietka z sektorem 256. Tam są jakieś przełączniki? Czy normalnie pakuje się dyskietkę bez zastanowienia a to stacja dysków robi jakieś podmiany?
- 30: CommentAuthormono
- CommentTime31 Mar 2022 zmieniony
Procedura BOOT zakłada że sektory ładowane do pamięci komputera są zawsze 128-bajtowe. Ładowanie następuje począwszy od sektora nr 1, wtedy wg nagłówka odczytywane są pozostałe sektory również o wielkości 128 bajtów.
Pierwsze 3 sektory dyskietki zawsze będą mieć 128 bajtów. Sektory o większych rozmiarach obsługuje się w ten sposób, że w pierwszych 3 sektorach mieści się loader, który załaduje pozostałe sektory w odpowiednim rozmiarze.
Tak samo dzieje się kiedy rozmiar ładowanego programu przekracza 255 sektorów 128-bajtowych - zazwyczaj procedura inincjalizacyjna (BOOT+6) doładowuje resztę programu.
Z twardymi dyskami jest nieco inaczej, bo tam wszystkie sektory dysku mogą mieć rozmiar np. 512 bajtów.
Spotykane są też dyskietki systemu CP/M gdzie wszystkie sektory mają rozmiar 256 bajtów.

Edit: Pomocny może się okazać opis przebiegu procedury BOOT ->link<-
- 31:
  
  CommentAuthorgienekp
- CommentTime31 Mar 2022
No to chyba jest ściana, której nie przeskoczę. Bo chciałem dodać obsługę ATRów z sektorem 256. Ale plik ATR ma dane ciągłe. Mimo, że w nagłówku jest 00 01 to poukładany jest jak dla 128 bajtów. A teoretycznie pierwsze sektory powinny być niepełne.
Mało tego, zmienne o wielkości sektora:
DSCTLN ($02D5) $80
DSCTLN+1 ($02D6) $00
DBYT ($0308) #80
DBYT+1 ($0308) $00
przed wywołaniem SIOINT nie wskakują na 00 01. Sprawdzam emulatorem różne DOSy, pozakładałem breakpointy i coś jest niezrozumiałego dla mnie :/

Albo ATR i emulacja olewa to, albo wszystko leci na 128bajtach a stacja dysków sama to podmienia, albo nie wiem.
- 32: CommentAuthormono
- CommentTime31 Mar 2022 zmieniony
To czy pierwsze sektory są pełne czy nie rozpoznaje się po długości pliku .atr ->link<- i informacjach w nagłówku.
Na pewno komunikacja nie leci samymi 128-bajtowymi sektorami, a stacja niczego sama nie zmienia.
- 33: CommentAuthormrk
- CommentTime31 Mar 2022
@gienekp możesz podrzucić jakiś przykład ATR'a z sektorem 256, najlepiej z bazy AOL? Jakiś czas temu robiłem obsługę tego w swoim emulatorze (jako SIO patch) przetestuję czy u mnie działa i może będę mógł coś pomóc.
- 34:
  
  CommentAuthorgienekp
- CommentTime31 Mar 2022 zmieniony
Weźmy "DOS II+ D 6.4.atr" z AOL. Wersja tego DOSa na dyskietce SD śmiga z CARTa.

Nagłówek ma 96 02 E8 2C [00 01] - czyli 256 bajtów na sektor.
Wielkość pliku 183952 bajtów.
Czyli wszystko czytelne.

Po 3 blokach łapię na breakpoincie i widzę coś dziwnego, bo:

DSCTLN ($02D5) 80
DSCTLN+1 ($02D6) 00

DBYT ($0308) 00
DBYT+1 ($0309) 01

Według "Zientary" to DSCTLN (Disk SeCTor LeNgth) powinien pokazywać co ma być. A tu jest jakiś "bypass" i wprost przywalone do DBYT. No ale to jest akceptowalne.

Standardowo system liczy od 1 (nie wiem czemu nie od 0).

No to jak liczona jest podwójna gęstość? Czy 1 sektor w podwójnej gęstości to jest 1 w pojedynczej? Dlaczego akurat po 3 blokach jest zmiana. Przecież loader mógłby mieć równie dobrze 7 bloków. To czy bez debugera można stwierdzić jak liczyć DD sektory?

Czy da się napisać równanie przeliczające adres z SD na DD?

Że jak poleci "zapotrzebowanie" na 20 sektor DD to np. offset będzie jak XYZ dla SD, no i potem kopia 256 bajtów.

Bo taki przelicznik dodałbym do procedury CARTa i zrobiłaby się obsługa DD. No bo podmiana kopiowania 128 bajtów na 256 jest już łatwa.
- DOS II+ D 6.4.atr
- 35: CommentAuthormono
- CommentTime31 Mar 2022
DSCTLN ($2D5) ustawia się używając JDSKINT ($E453). Kiedy używasz JSIOINT ($E459), wtedy używasz wyłącznie bloku DCB ($300-$30B).

Pierwsze 3 sektory na dysku elastycznym będą mieć zawsze 128 bajtów - tak sobie wymyśliło Atari. Więc każda stacja Atari sformatuje dysk w podwójnej gęstości tak, że pierwsze 3 sektory będą mieć po 128 bajtów, następne po 256.

W .atr również zapisuje się tylko zawartość sektorów, a więc pierwsze 3 po 128 bajtów, kolejne po tyle ile jest w nagłówku.
Można jednak zapisać dysk CP/M z pełnymi pierwszymi 3-ma sektorami. Wtedy wszystkie sektory a dysku mają po 256 bajtów.
- 36: CommentAuthormrk
- CommentTime31 Mar 2022 zmieniony
gienekp:
Czy da się napisać równanie przeliczające adres z SD na DD?

Nie wiem czy dokładnie tego potrzebujesz, ale w swoim emulatorze pozycję sektora w obrazie ATR wyliczam tak: ->link<- Sprawdziłem jeszcze dla pewności z podlinkowanym ATR, działa. Zaimplementowane dokładnie tak jak opisał @mono - trzy pierwsze sektory w ATR mają zawsze wielkość 128 bajtów, potem tak jak w nagłówku ATR'a
- 37:
  
  CommentAuthorgienekp
- CommentTime31 Mar 2022 zmieniony
@mono
tutaj wpadłem w pułapkę, bo początkowo pracowałem na JDSKINT a potem przeszedłem na JSIOINT. Nie zauważyłem, że tam leci tylko na DCB

@mrk
dzięki! o to właśnie chodzi :)

DD polecą już na pamięci flash 512kB. A że tutaj jest sporo miejsca to organizuje to tak:

0 xx - Sektor 0 - nie ma takiego ale zapchaj dziura
0 xx - Sektor 0 - zapchaj dziura
1 128 - Sektor 1
1 FF - Sektor 1 - zapchaj dziura
2 128 - Sektor 2
2 FF - Sektor 2 - zapchaj dziurq
3 128 - Sektor 3
3 FF - Sektor 4 - zapchaj dziura
4 256 - Sektor 4
5 256 - Sektor 5
...

Dzięki temu (numer sektora)+$80 to starszy bajt adresu CARTa
Młodszy ma zawsze $00

A numer banku to numer sektora "shifnięty"
- 38:
  
  CommentAuthorgienekp
- CommentTime31 Mar 2022 zmieniony
No działa :)

Źródła ->link<-

Przykład DOSa poniżej
- DOS II+ D 6.4.car
- 39:
  
  CommentAuthorjhusak
- CommentTime31 Mar 2022
No i git!
- 40: CommentAuthormrk
- CommentTime1 Apr 2022 zmieniony
@gienekp przydałoby się README.md w repo, możesz po prostu skopiować treść pierwszego posta z wątku :)
EDIT: widzę że zrobiłeś oddzielne projekty dla wersji SD i DD - chyba sensowniej było by zrobić pojedynczą wersję atr2car z autodetekcją formatu ATR'a

I gwiazdkujemy projekt, choć taka skromna zapłata za poniesiony trud i otwarcie źródeł: ->link<- :)
- 41:
  
  CommentAuthorKaz
- CommentTime1 Apr 2022
mrk:
I gwiazdkujemy projekt, choć taka skromna zapłata za poniesiony trud i otwarcie źródeł: ->link<- :)

O! Nie zauważyłem wcześniej, że taka funkcjonalność tam jest. No to idą gwiazdki. Także do Twojego projektu mrk :)
- 42:
  
  CommentAuthorsun
- CommentTime1 Apr 2022
zrobione :)
- 43:
  
  CommentAuthorgienekp
- CommentTime1 Apr 2022 zmieniony
widzę że zrobiłeś oddzielne projekty dla wersji SD i DD - chyba sensowniej było by zrobić pojedynczą wersję atr2car z autodetekcją formatu ATR'a

Takie coś będzie :) i będzie mieć GUI i będzie na Windowsa, Maca, Ubuntu, Android i rPI... i już powoli jest ;)

Musi być GUI bo jest różna liczba kombinacji: sektor 128 i 256. Pamięć flash 128kB, 256kB i 512kB. No i konfig na którą linię VCOUNT czekamy, bo zdarzyć się może, że program włączy ROM i procedura przerwania systemowego sprawdzi nam podmianę CARTa akurat podczas kopiowania i zrobi nam zwis. Więc operator jakąś wajchę musi mieć, żeby poeksperymentować.

Będzie też opis szczegółowy bo obiecałem "pewnemu Panu" takie cosik wyskrobać. :)

Ale najważniejsze, to już ostatnia prosta dla RAM-CARTa, bo tak naprawdę to to zadanie wyskoczyło przy okazji. ;)
- 44: CommentAuthormrk
- CommentTime1 Apr 2022
@gienekp Z wersji CLI bym nie rezygnował, ma czasami spore zalety w stosunku do wersji klikanej (na przykład robienie konwersji atr2car jako jeden z kroków większego skryptu), konfigurację można ogarnąć argumentami linii poleceń.
- 45:
  
  CommentAuthorjhusak
- CommentTime1 Apr 2022 zmieniony
I jeszcze trzeba koniecznie dodać obsługę kartridża AtariMax 1MB bądź 128k dla wersji SD.

Na szczęście źródła są otwarte i każdy może dodać coś od siebie. Ja np. jak się soft ustabilizuje, mogę dodać obsługę AtariMax, albo JatariCart wraz z zapisem :) Mam na to patent już :)
- 46:
  
  CommentAuthorgienekp
- CommentTime1 Apr 2022
Tak.

To uporządkuję wszystko do ATR2CAR w wersji CLI, żeby to była baza do dalszego rozwoju.
- 47:
  
  CommentAuthorpirx
- CommentTime1 Apr 2022
dykłydnie, GUI może być zupełnie oddzielne, tak będzie najlepi
- 48:
  
  CommentAuthorgienekp
- CommentTime1 Apr 2022 zmieniony
Dobra, uporządkowałem. Jest jeden atr2car ->link<- (stare zostawię historycznie). Teraz testy czy tam czasem nie wślizgnął się jakiś bug. Startery nie ruszałem. Ale kod C jest przygotowany na przyszłe rozwiązania. Raczej będzie wiadomo jak to rozbudowywać.

Starter dla 128 i 256 ma blok kompilacji ASM na 1024 bajty, teoretycznie by 512 starczyło (ale to na styk). Teraz można coś dopisywać. Czyli pozostałe 7168 bajtów w banku $A000 jest wolne. Można w przyszłości jakie obrazki dać.

Dodałem opcję: -128 lub -256 lub -512, która narzuca jaka pamięć flash będzie "lutowana" w CARcie bo czasem plik ATR z grą ma np.: 133136 bajtów co by sugerowało, że potrzeba pamięci 256kB. Ale ostatnie sektory są puste, więc gra tego nie czyta. Zapis i tak nie działa, więc się nie wysypie.

Przykład "World Karate" poniżej co teoretycznie w 128kB by się nie zmieścił.

Edit
Taka ciekawostka, na AVGCARTcie przykładowy ATR z SilentService i WKC bez kabelka nie zadziała. Ale wersja zrobiona ATR2CAR śmiga :) Ciekawe czy dało by się zaimplementować ATR2CAR do AVGCARTa żeby zamieniało "w locie"?
- WorldKarateChampionship.car
- 49:
  
  CommentAuthorKaz
- CommentTime10 Apr 2022
No to mamy w archiwum trzy gry od GienekP w formacie CAR (dzięki!):

- World Karate Championship
- Solo Flight II
- Silent Service
- 50:
  
  CommentAuthorgienekp
- CommentTime19 Jul 2022
Atarimax 128 KB Flash cartridge to cart gdzie mamy przełączany tylko obszar $A000-$BFFF. Z jednej strony jest to zaleta, bo za dużo nam się danych nie przełącza (mniejsze szanse na migotanie obrazu), no ale z drugiej strony trzeba jakoś się zmieścić z danymi i kodem obsługi carta. Kopiowanie procedur do RAM nie wchodzi w grę, bo zwykle tego miejsca nie ma. Dlatego maksymalnie dużo trzeba ogarnąć w pamięci carta.

W przykładzie Bank 0 jest uprzywilejowany. Zawiera procedurę startową i mapę sektorów. Każdy inny bank zawiera sektory oraz 256 blok na końcu z kodem obsługi. Kod obsługi wszędzie jest taki sam, więc jest odporny na przełączanie banków.

Ponieważ liczba sektorów w banku nie jest wielokrotnością dwójki, to żeby się doliczyć gdzie są dane to albo trzeba zrobić skomplikowaną procedurę dzielenia modulo, albo stablicować.

Do budowy tablicy przygotowano specjalny programik SectorMap. Buduje on mapę sektorów dla wersji 128 i 256 bajtów na sektor. Ostatecznie jest to podłączane do ASM i dwa startery są kompilowane.

Finalny konwerter to atr2max.c z dwoma inkludami: "starter128m.h" i "starter256m.h".

Wszystko Open, można robić z tym co się chce.
Źródła ->link<-

W praktyce Maxflash 128kB da radę obskoczyć tylko dyski SD. Ale w przyszłości pojawi się MaxFlash 128kB PLUS oraz SimpleCART obsługujący flashe do 512kB i do tego już został konwerter dostosowany. Natomiast MaxFlash 1MB to zupełnie inna bajka...

Przy okazji walcząc z rewelacyjna gierką BubbleShooter odkryłem, że DOS II+/D odwala jakiś numer z sektorami 256. Wczytuje się wszystko zgodnie ze sztuką. Ale jak potem ten DOS ma coś uruchomić to wywołuje procedurę carta w trybie 128sektorów. Z jakiś powodów stwierdza, że dyskietkę ma SD. Przed odczytem wysyła zapytanie (kod $53) o STATUS. Tego nie obsługuję, więc może tam jest coś ukryte, że dyskietka jest DD. Więc w przyszłości to jest do poprawy.

Jak przyjdą mi płytki od chińczyka to jeszcze pociągnę wątek Maxflasha bo w tej chwili testowałem tylko na emulatorze. Na ten moment "Da się", jak wszystko na ATARI ;).

Od 1 do 50 z 146