laoo: nie taki format miałem na myśli, kod, który jest sam z siebie position-independent, nie potrzebuje żadnego specjalnego formatu. Raczej chodziło mi o coś w rodzaju tego, co jest opisane w instrukcji od madsa - czyli niby jest, nie wiem tylko, na ile to praktyczne i przetestowane (z binariami SDX mads miewał jazdy).

Jak pisze syscall, wiele rzeczy zostało już wymyślone, wystarczy poczytać dokumentację, zamiast kolejny raz przebijać się przez ścianę obok otwartych drzwi.

lda.b $00 = lda <$00

lda.w $00 = lda !$00

lda.l $00 = lda >$00

Z tego oczywiście pierwszy i ostatni przykład jest nie do zastosowania w madsie, jak mi się zdaje, bo tebe strzelił sobie w stopę przyjmując z rzyci wyciągniętą składnię QA za "standard".

Co do skoków JSL, wystarczy 24-bitowe adresowanie etykiet, które ma już MAE. Dużo gorszy jest brak zunifikowanego systemu ładowania czegokolwiek do wysokiej pamięci, kod i dane trzeba przepisywać i ewentualnie relokować "ręcznie", co jest uciążliwe. Natomiast format pliku sam w sobie istnieje, wzmankowany jest np. tutaj http://atariki.krap.pl/index.php/COM#AlfAssembler - nb. ten cały AlfAsm też może być jakimś punktem zaczepienia, jakkolwiek nie używałem go nigdy.

Że 65C816 z wiadrem fastu to "nie Atari", to się zgodzę - na pewno nie jest to Atari jakie znamy. Techniki programowania są zupełnie inne, i mnie się to akurat podoba, bo pokazuje to inną stronę procesorów 65xx, i czegoś trzeba się nauczyć, zamiast mielić w kółko te same zgrane od 30 lat schematy, ale też inne fajne rzeczy można robić (albo te same, tylko inaczej).

Tak, to niekonsekwentne. Możesz poprawić.

@gorgh: Ale ja biorę _wygodę_ pod uwagę: nie napisałem, że na Atari "można kodować", tylko że "można WYGODNIE kodować". I również z marszu, u mnie atari jest "gotowe do kodowania" jakieś 15 sekund od włączenia zasilania (licząc włącznie z czasem potrzebnym na wczytanie MAE).

Dziwaczny może dlatego, że w sumie na Atari już teraz można wygodnie kodować, wprawdzie nieco rozszerzonym (VBXE dla 80 kolumn tekstu, twardy dysk, SDX), ale chyba po to się właśnie montuje rozszerzenia? MAE ma bardzo wygodny edytor i szybki kompilator (nie tak szybki jak MAC/65, ale wystarczająco), nie mówię, że wszystko, ale sporo da się zrobić na Atari, a tego, czego się nie da, częściowo nie da się nie z powodu obiektywnej "niemożności", tylko z braku odpowiednich narzędzi.

Podchodząc maksymalistycznie, pewnie "w dzisiejszych czasach" nie da się "pracować" - jeśli przez "pracę" rozumiemy prowadzenie księgowości dużej firmy, napisanie habilitacji, montaż audio-video i co tam jeszcze ludzie na komputerach dzisiaj robią. Ale przy wykorzystaniu tych narzędzi, które istnieją, można spokojnie "pracować" w zawężonym, ośmiobitowym, kanciastym, pikselowym, brązowo-fioletowym mikro-sensie o rozdzielczości 3x5. Przykład: piszę program pod MAE, testuję go na Atari (bo i gdzie indziej), potem pod Last Wordem piszę doca, z całości robię paczuszkę *.ARC przy użyciu ARC.COM pod SDX, a pecet służy mi tylko do tego, żeby to ewentualnie wrzucić do internetu.

Da się? Da się. Dziwaczne? Nie :P

Może:

mount -t msdos /dev/fd0 katalog

gdzie 'katalog' to katalog, w którym będzie widać pliki znajdujące się na dyskietce.

Zamiast 'msdos' możesz musieć podać 'msdosfs'.

Do formatowania nie potrzebujesz dyskietki montować, wystarczy ją włożyć do stacji i zadać:

fdformat -f 720 /dev/fd0

Powinno pójść (mimo że komendy są z FreeBSD, a nie Linuxa). Potem jeszcze (zapomniałem) będziesz potrzebował zainicjować system plików, np. tak:

newfs_msdos /dev/fd0

I dopiero jak to się uda, możesz montować.

Coś, co wygląda na błąd w madsie. Program przykładowy:

;
LINES = 20

          org $80

dupa    .ds 2

          blk reloc main

start     lda #<(LINES-1)*40
          sta dupa
          lda #>(LINES-1)*40
          sta dupa+1
          rts

Program powinien obliczyć wartość (LINES-1)*40 = 19*40 = 760, oraz umieścić ją jako młodszy i starszy bajt pod adresem "dupa" i "dupa+1".

Przy próbie asemblacji wyskakuje komunikat:

start   lda #<(LINES-1)*40
dupa.s (10) ERROR: Value out of range

Tymczasem Value nie jest out of range, bo operatory '<' i '>' są (albo: powinny być) brane pod uwagę jako ostatnie. Powinno mu zatem wyjść $F8 z pierwszego wyrażenia i $02 z drugiego (mł. i starszy bajt wartości $02F8 = 760).

Ale to nie koniec.

Powyższy program poprawiamy tak, żeby się kompilował, tzn. w linii, gdzie wyskakuje błąd, dodajemy nawiasy:

;
LINES = 20

          org $80

dupa    .ds 2

          blk reloc main

start     lda #<((LINES-1)*40)
          sta dupa
          lda #>(LINES-1)*40
          sta dupa+1
          rts

Błąd nie wyskakuje, co dziwne, bo powinien się pojawić dokładnie taki sam dwie linijki niżej. Listing:

mads 1.9.4
     1                          ;
     2 = 0014                   LINES = 20
     3
     4                                  org $80
     5
     6 = 0080                   dupa    .ds 2
     7
     8 0082 FE FF 01 00                 blk reloc main
     9
    10 0000,0009> A9 F8         start   lda #<((LINES-1)*40)
    11 0002 85 80                       sta dupa
    12 0004 A9 00                       lda #>(LINES-1)*40
    13 0006 85 81                       sta dupa+1
    14 0008 60                          rts

Pierwsza linijka skompilowała się dobrze, jest LDA #$F8. Co do drugiej, co prawda komunikatu o błędzie nie ma, ale kod jest zły, bo zamiast LDA #$02 w kodzie wynikowym jest LDA #$00.

Cały soft działa świetnie z KERN_SECURITY_LEVEL=1 (tzn. o ile ktoś czegoś tam nie popsuł pod moją nieobecność). Ustawienie 1 chroni np. przed sytuacją, kiedy user nie będący rootem (i np. zalogowany zdalnie) uruchamia sobie program wywołujący Rwabs() i zamazujący zawartość dysku.

Oczywiście Krollowi być może nie jest to potrzebne (bo nie ma innych kont poza swoimi), chciałem jednakże zwrócić uwagę na to, że to ustawienie nie "w teorii miało mieć możliwość", ale że ma dość praktyczne znaczenie.

Na pewno? Coś mi się wydaje, że to tylko zmienia działanie ochrony już włączonej przez bootmenu.

Ano jest, nazywa się NUL:

Patch do Karinki, jak już napisał Stryker, jest prymitywny, ale na źródłowanie tego ROM-u po prostu nie mam czasu. Wyszedłem z założenia, że lepsze to niż nic.

Trzeba dodać, że błąd w romie karinki. Co do patcha, pod adresem $d819 jest taki kod:

    ldx #'N
    ldy #<$e48f
    lda #>$e48f
    jsr $e486 ;pentv czyli jnewdevc

    lda #$80
    sta $0247

Zamiast dwóch ostatnich rozkazów powinno być:

    lda $0247
    ora $0248
    sta $0247

Tak wstępnie, nie bardzo jest gdzie te dodatkowe 4 bajty zmieścić. Oczywiście zawsze można coś wywalić, jak na przykład znajdującą się wyżej instalację urządzenia "N:" w CIO i związane z tym procedury. Może znajdzie się chętny na porządne zeźródłowanie całości i wprowadzenie poprawek, 2k to znowu nie jest tak dużo ;)

Wersja 1.6 z poprawionym błędem powodującym niedziałanie v.1.5 bez VBXE, o tu:

http://drac030.krap.pl/d2d6502.arc

Pinokio dawno już to zgłaszał (dzięki!), ale ja dopiero od niedawna jestem posiadaczem alternatywnego Atari bez VBXE i mogłem to sprawdzić. No i oczywiście, w kluczowej procedurze brakowało 1 rozkazu. Teraz już powinno działać, w każdym razie SOA#1 (zarówno na 130XE z 6502 i VBXE, jak i na 65XE z 65C816 i bez VBXE).

Jeśli ktoś ma wersję starszą od 1.6, producent zaleca uaktualnienie.