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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorxeen
   • CommentTime14 Dec 2015 22:12

    
   Przeglądam sobie manuala do KICK assemblera i twierdzę, że feature opisany w punkcie 10.7 byłby bardzo wygodny przy współpracy grafik - koder jeżeli grafik preferuje np. grafx2
   
   ->link<-
   
   Zakładam wątek - może ktoś ma inne przemyślenia co by jeszcze można dodać.
2. • 2: CommentAuthorbob_er
   • CommentTime14 Dec 2015 22:12

    
   Hmm... Nie widzę tam punktu 10.7.
3. • 3:
      
     CommentAuthorxeen
   • CommentTime14 Dec 2015 22:12

    
   10.7Converting Graphics - na stronie 49
4. • 4: CommentAuthorbob_er
   • CommentTime14 Dec 2015 22:12

    
   U mnie w spisie treści jest '9.7 Converting Graphics', ale ok :).
5. • 5: CommentAuthortebe
   • CommentTime14 Dec 2015 23:12

    
   mads używa tylko biblioteki 'system' czyli jedynie podstawowej
   
   wczytywanie bmp bez kompresji jest możliwe, napisanie makra robiącego z taką bmpą coś więcej też
   
   w przykładach są makra dokonujące relokacji RMT, MPT, CMC bez potrzeby zapisywania modułów przez dedykowane trackery
6. • 6: CommentAuthorilmenit
   • CommentTime13 Jul 2021 15:07

    
   MADS posiada świetny system definiowania segmentów i można np. zdefiniować sekcje jak w kompilatorach: CODE, DATA, BSS czy ZEROPAGE, BANK, gdzie asembler pilnuje przekraczania sekcji i nadpisywania innych danych.
   
   Co byłoby przydatne, to:
   - możliwość definiowania segmentów mających kilka obszarów np. jeden segment CODE $2000 do $4000, ten sam segment $8000 do $D000, ten sam segment od $D800 w górę.
   - automatyczne przydzielanie pamięci do takich kilku segmentów minimalizujące liczbę dziur (uwzględniające .align) gdy się użyje .segment CODE
   
   W ten sposób można by się pozbyć ręcznego zarządzania pamięcią (aktualnie trzeba samemu definiować co do którego segmentu ma iść, gdy się nie mieści) a może by też zoptymalizowało generowane pliki dla Mad Pascala?
   Zakładam, że można by do tego wykorzystać jakieś gotowe rozwiązanie dla problemu plecakowego ->link<- (PL) lub ->link<- (ENG)
7. • 7:
      
     CommentAuthorlaoo
   • CommentTime13 Jul 2021 16:07 zmieniony

    
   Też bym chciał to mieć bo także mi to zaczęło doskwierać. I to na tyle mocno, że pracuję na boku nad narzędziem rozwiązującym ten problem (a nawet powinno rozwiązać kilka problemów więcej jak przydzielenie różnym zmiennym automatycznym z innych funkcji tej samej lokacji na zp). W ogólniejszej formule to nie jest do końca problem plecakowy, ale myślę że da się to ogarnąć systemem więzów (pisałem z więzów magisterkę, niech się na coś to przyda ;)).
8. • 8: CommentAuthorilmenit
   • CommentTime13 Jul 2021 17:07 zmieniony

    
   też w aktualnym projekcie używam zmiennych lokalnych typu:
   

   .proc zrob_cos
     ...kod...
     rts
   zmienna_lokalna_byte .byte 0
   zmienna_lokalna_word .ds 2
   .endp
   

   
   i rzeczywiście data reuse by się przydał (choć to może ze 100 bajtów oszczędzone na cały projekt), ale do tego asembler by musiał generować drzewo wywołań i cały kod by miał mieć gwarantowane, że nie będzie dziwnych skoków (które akurat u mnie dla optymalizacji są).
   No i takie zmienne lokalne, które aktualnie nie mają reuse bardzo pomagają debugować kod - mogę zobaczyć co było w jakieś procedurze długo po jej wykonaniu, w momencie wykonywania innego kodu.
   Ogólnie fajnie, jakby takie zmienne niezaincjowane .ds można przenieść automatycznie do jakiejś sekcji BSS, albo wybrać, czy mają być lokalnie w kodzie przy procedurach, czy nie (gdy np. chcemy taki kod przenieść do ROMu).
   
   O systemie więzów muszę przeczytać, ja zakładałem, że to ->link<-
9. • 9:
      
     CommentAuthorlaoo
   • CommentTime13 Jul 2021 18:07 zmieniony

    
   "Data reuse" ma sens tylko w przypadku strony zerowej i to zawsze powinna być opcja - jeśli jakiś wskaźnik czy licznik jest wybitnie tymczasowy to można jego adres współdzielić z innymi tego typu zmiennymi.
   Na wykrywanie co można współdzielić mam chyba dobry patent - wystarczy odkryć wszystkie zależności pomiędzy segmentami i jeżeli dwa segmenty kodu nie mają żadnej relacji z wyjątkiem takiej że ktoś inny je woła, to segmenty danych tymczasowych do jakich się odwołują mogą zajmować te same adresy. Jasne, że zawsze można robić jakieś krzywe skoki, ale wtedy można systemowi pomóc dodając zależności ręcznie.
   Przykład, który podałeś to problem plecakowy, ale z tego co widzę, to jest rozwiązywany ogólnym solverem do więzów, czyli takim jakiego ja używam. Nawet używam tej samej biblioteki - googlowe OR-Tools to state of the art w dziedzinie (przynajmniej wśród darmowych pakietów). Poczytaj sobie o "Programowaniu z więzami".
   Ogólnie zdecydowałem się na taką armatę, bo ja uogólniłem problem także w kwestii czasu - u mnie różne segmenty mogą być w pamięci w różnych momentach działania programu i pozwalam na tranzycje pomiędzy tymi konfiguracjami (np podział na menu/levele/hi-score/ending w grze czy różne fragmenty dema). Zresztą nie ma co zaśmiecać tego tematu bo to jest o madsie, a nie o moich fanaberiach, których mogę nigdy nie skończyć :)
10. • 10: CommentAuthorilmenit
    • CommentTime14 Jul 2021 10:07

     
    takie rozważania są ciekawe, bo mogą przynieść też pomysły do MADSa :-)
    Odnośne reuse zmiennych lokalnych (np. na ZP), to gdy są naprawdę lokalne, to zmienną typu zp_local1, zp_local_ptr1 można zdefiniować raz i potem używać wszędzie bez obawy, że coś przestanie działać. Problem jest z zapewnieniem czytelności kodu, ponieważ taki zp_local_ptr1 to "ogólna nazwa", gdy chcielibyśmy lokalnie używać nazwy src_ptr. Wciąż da radę to zrobić w MADS stosując aliasy nazw:
    
    

    .struct @ZP
    	local1 .byte
    	local_ptr1 .word
    	local_ptr2 .word
    .ends
    ;;; Define segment
    ZP_START  = $80
    .segdef seg_zp ZP_START $100-ZP_START
    
    CODE_START = $2000
    BANK_ADDRESS = $4000
    .segdef seg_first CODE_START BANK_ADDRESS-CODE_START
    ;;; Put data into segment
    .segment seg_zp
    	.var zp @ZP
    .endseg
    
    .segment seg_first
    DATA_SIZE = 64
    data .ds DATA_SIZE
    
    .proc copy_data (.word src_ptr .word dst_ptr .byte size) .var
    	; set local variables
    	size = zp.local1
    	src_ptr = zp.local_ptr1
    	dst_ptr = zp.local_ptr2
    
    	ldy #0
    copy_loop:
    	lda (src_ptr),y
    	sta (dst_ptr),y
    	iny
    	cpy size
    	bne copy_loop
    	rts
    .endp
    
    main:
    	copy_data #$C000 #data #DATA_SIZE
    	jmp *
    .endseg
    	RUN main
    

    
    
    Choć "ładniej" by było zadefiniować:
    

    .proc copy_data (.word src_ptr .word dst_ptr .byte size) .var
    ; local variables on zp
    size .zp_ds 1
    src_ptr .zp_ds 2
    dst_ptr .zp_ds 2
    

    
    i nie przejmować się gdzie na ZP to będzie.
    
    Dlatego o ile reuse nie jest dla mnie aż takim problemem, większym jest zarządzanie pamięcią z punktu widzenia rozbicia jednego segmentu na kilka obszarów. Niestety pamięć w Atari ma dwie główne dziury - jedną dla banku (od $4000 lub $8000), a drugą dla sprzętu (od $D000), przez co do wykorzystania są 3 niezależne segmenty na pamięć podstawową gdzie trzeba "ręcznie" wrzucać kod i dane i przesuwać między tymi segmentami, gdy się któryś przepełnia.
11. • 11:
       
      CommentAuthorlaoo
    • CommentTime14 Jul 2021 11:07

     
    Generyczne miejsca na stronie zerowej i aliasy do nich to oczywiście rzeczy, które się stosuje i to nie jest coś złego. Z doświadczenia jednak wiem, że przy naprawdę dużym projekcie, który ledwo mieści się w pamięci (albo nie mieści i trzeba go optymalizować pamięciowo, żeby dodać coś nowego), jeżeli nie pisze się w pojedynkę, to ogarnięcie co gdzie jest i gdzie mamy jakieś wolne bajty, jest dość dużym wysiłkiem. Mieliśmy już kilka takich projektów. W TP literalnie zostało kilka wolnych bajtów, o których wiem. Wydaje mi się jednak, że gdyby tą pamięcią zarządzał automat, to zrobiłby to o wiele lepiej, a człowiekowi byłoby o wiele lżej. Decydowanie, w który z trzech obszarów pamięci Atari (które opisałeś) wrzucić kod, czy dane, też jest pewnym wysiłkiem. A co dopiero decydowanie o bankach i pamiętanie co w którym jest. Mnie tak jak w Twojej dewizie z Adam is Me - [...] exploring capabilities of augmenting retro-programming with power of the modern computers - dziwi po prostu, że przez tyle lat nikt nie napisał takiego automatu zarządzającego pamięcią i wiem, że bez niego wyżej już trudniej mi się wspiąć, bo za dużo energii poświęcam na houskeeping.
12. • 12: CommentAuthorilmenit
    • CommentTime14 Jul 2021 11:07

     
    Też tak uważam. MADS czy KickAss mają wiele bajerów bardzo ułatwiających pisanie "wysokopoziomowo", ale wciąż trzeba samemu zajmować się rolą linkera.
    Z drugiej strony pytanie ile osób coś takiego potrzebuje i lubi. Ja lubię mieć w kodzie porządek i lubię czytelny kod, ale nawet w naszej grupie są tacy, dla których to zbędne wymysły, bo to asembler i nawet używają konkretnych adresów typu $E0 na ZP czy $D301 zamiast tekstowych odpowiedników ;)
    Piszesz swojego asemblera czy jakiś dodatkowy preprocesor? Własny asembler to maaasa pracy, aby dobić do poziomu MADSa.
13. • 13:
       
      CommentAuthorlaoo
    • CommentTime14 Jul 2021 12:07 zmieniony

     
    Pisałem już preprocesor dla madsa - asemblowałem fragment kodu raz pod jakiś adres, określałem jego rozmiar, przydzielałem adres i asemblowałem drugi raz już pod docelowy adres i jakoś to działało. Tak teraz powstają nasze kody pod Lynxa. Ale szybko doszedłem do wniosku że to zbyt zagmatwane i mało elastyczne, więc zacząłem pisać coś innego, co nie jest stricte asemblerem, a jeśli już, to w innym znaczeniu słowe "assemble", czyli "składać", bo jest to narzędzie, które operuje segmentami generowanymi na różne sposoby (np przez kod lua), a jednym z generatorów może być prosty asembler 6502, więc nie mam zamiaru dobijać do poziomu madsa, bo mads jest tylko jeden i nie potrzeba drugiego :) a z drugiej strony nie potrzebuję - wszelkie dane mogę generować zewnętrznie, a asemblerem tylko prosty kod. Każdy segment musi eksportować jakieś symbole i może importować jakieś inne z innych segmentów. Ostatecznie dostaję graf zależności, odrzucam segmenty do których nie można dojść z segmentu startowego, nakładam więzy na adresy tych segmentów, tu dzieje się magia, po czym constraint solver powinien mi wypluć adres każdego z nich. Potem już tylko złożyć to w plik wynikowy. Tyle teorii.
    Z ciekawostek jednym z generatorów segmentów jest u mnie importer ELFa, więc czekam na mos-llvm :)
14. • 14:
       
      CommentAuthorpirx
    • CommentTime15 Jul 2021 15:07

     
    ja myślałem o czymś prostszym, może do dość łatwego zrobienia - przy okazji walki z kilkuset stronami z zajętymi 160 bajtami myszlałem o jakiejś metodzie zaznaczenia w madsie bloków, które ma omijać. w kodzie niekrytycznym czasowo wystarczałoby, żeby kompilator na końcu takiej dziury do wykorzystania skakał do następnej dziury zwykłym jmp.
    Z takim rozwiązaniem nie bolałoby nawet zrobienie ekranu graficznego z 40 bajtami na stronę.
15. • 15: CommentAuthorilmenit
    • CommentTime15 Jul 2021 16:07 zmieniony

     
    @pirx - to, o czym piszesz, to trochę inny problem, choć zakładam, że po zaimplementowaniu "problem wielu plecaków" do rozmieszczania kodu, by sie i to automatycznie rozwiązało, gdyby asembler automatycznie wrzucał kod/dane w takie dziury na końcu stron. Ale przy pełnej automatyzcji organizacji pamięci przez asembler nie byłoby gwarantowane, że linie ekranu by były przydzielane na kolejnych stronach, więc trzeba by robić tablice wskaźników do linii w stylu:
    
    

    SCREEN_WIDTH = 40
    SCREEN_LINES = 24
    .rept SCREEN_LINES, #
    .align $100
    screen_line:1 .ds SCREEN_WIDTH
    .endr
    
    screen_ptr_lo
    .rept SCREEN_LINES, #
    .byte #<(screen_line:1)
    .endr
    screen_ptr_hi
    .rept SCREEN_LINES, #
    .byte #>(screen_line:1)
    .endr
    

    
    Co się nie różni wiele od ciągłego obszaru danych i wskaźników do poszczególnych linii dla (ptr),y
16. • 16:
       
      CommentAuthorlaoo
    • CommentTime15 Jul 2021 18:07

     
    @ilmenit wyobrażam sobie, że można byłoby mieć taki język "życzeń" co do allokacji pamięci, w którym dałoby się wyrazić, żeby pamięć ekranu zajmowała poczatki 20+ kolejnych stron. Ogólnie super pomysł to co podrzucił Pirx, że segment wcale nie musi być ciągły, a może mieć wręcz dziury i nawet automat mógłby rozlewać kod po takich dziurach kontynując go automatycznie wstawionymi jumpami. Dzięki! :)
17. • 17: CommentAuthortebe
    • CommentTime15 Jul 2021 20:07

     
    w Mads jest dyrektywa .zpvar alokująca zmienne na stronie zerowej, można ją zapisywać i odczytywać
    
    

    .zpvar = $80
    .zpvar .word tmp
    .print .zpvar        ; = $82
    

    
    
    przykład procedur i alokacji zmiennych na stronie zerowej
    

    .proc pr1
    
    .zpvar = $80
    
    .zpvar .word ala
    
    zpmax = .zpvar     ; dodatkowa etykieta z informacją o
                       ; maksymalnym adresie na stronie zerowej
    .endp
    
    
    .proc pr2
    
    .zpvar = $80
    
    .zpvar .long tmp
    
    zpmax = .zpvar
    .endp
             .print pr1.zpmax    ; = $82
             .print pr2.zpmax    ; = $82
    

    
    
    można też uzależnić adres początkowy .zpvar od adresu z którego korzysta inna procedura, brakuje tylko możliwości wybrania MAX w przypadku kilkunastu procedur korzystających ze strony zerowej w ten sposób
    
    

    .procedure ...
    .zpvar = proc_name.zpmax
    
18. • 18: CommentAuthorilmenit
    • CommentTime15 Jul 2021 21:07 zmieniony

     
    O, dzięki Tebe, zerknę jak można to wykorzystać. Można to też wrzucić jakoś do segmentu lub inaczej kontrolować zakres, aby ustalić jakieś maksymalny rozmiar takiej alokacji np. od $80 do $B0?
    
    A co myślisz o takim zarządzaniu pamięcią, poprzez szukanie optymalnego rozmieszczenia obszarów kodu/danych (nawet bez wspomnianego dzielenia kodu i JMP) i/lub wieloobszarowych segmentach?
    
    @Laoo - a jak jest z szybkością tego OR-Tools? Jest na tyle szybkie, że można by wykorzystać w procesie kompilacji bez denerwującego spowolnienia?
19. • 19:
       
      CommentAuthorlaoo
    • CommentTime16 Jul 2021 06:07 zmieniony

     
    @ilmenit Mamy teraz takie czasy, w których nasze komputery są zmuszone do robienia takich bzdur, że zapominamy jakie one są cholernie szybkie. OR-Tools jest zaprojektowany do rozwiązywania prawdziwych "inżynieryjnych" problemów na miliony więzów, podczas gdy nie wiem, czy w największym projekcie atari będzie więcej niż kilkaset segmentów, więc zakładam, że czas rozwiązywania tego powiedzmy tysiąca więzów byłby niezauważalny. Problem pojawi się dopiero, gdy w pamięci zrobi się bardzo ciasno - wtedy backtracking da o sobie znać, więc trzeba byłoby się zabezpieczyć, żeby algorytm niepotrzebnie nie przeglądał wszystkich możliwych kombinacji. Ale ogólnie jestem dobrej myśli - powinno się dać to zaprogramować tak, żeby wynik był "od ręki".
20. • 20:
       
      CommentAuthorYosh
    • CommentTime17 Jul 2021 18:07 zmieniony

     
    Masoni...
    
    mi tam by wystarczyło działające zagnieżdżone .rept
    

    mads 2.1.3
    Source: f.asm
         1 					opt h-
         2 					org 0
         3 				.rept 2
         4 				.REPT 3
         5 					DTA #
         6 				.ENDR
         7 				.REPT 1000
         8 					DTA $10+#
         9 				.ENDR
        10 				.ENDR
        10 				.endr
    Source: REPT
        10 				.endr
    Source: REPT
         5 0000 00				DTA #
         5 0001 01				DTA #
         5 0002 02				DTA #
    Source: f.asm
         5 				.endr
    Source: REPT
         5 0003 00				DTA #
         5 0004 01				DTA #
         5 0005 02				DTA #
    Source: f.asm
         5 				.endr
    Source: REPT
         5 0006 00				DTA #
         5 0007 01				DTA #
         5 0008 02				DTA #
    Source: f.asm
         5 				.endr
    Source: REPT
         5 0009 00				DTA #
         5 000A 01				DTA #
         5 000B 02				DTA #
    Source: f.asm
    Source: f.asm
        11
    
21. • 21: CommentAuthorilmenit
    • CommentTime17 Jul 2021 22:07 zmieniony

     
    @Yosh - ale tam już byliśmy ->link<- , teraz mame inne problemy, na które natrafisz ;)
22. • 22:
       
      CommentAuthorYosh
    • CommentTime18 Jul 2021 14:07 zmieniony

     
    Do licznika potrafię się dobrać, chodzi o to że drugie zagnieżdżone .rept "przejmuje" cały kod pierwszego.
    
    No ale to bug a nie masońskie życzenie, więc podesłałem na aa.
    
    Co do alokacji to kibicuje laoo, ale boję się że więzy powiedzą "nie da się" i będę szukał w 2342521 propozycjach która była "najbliżej"
    
    ja sobie radze makrami
    
    

    at - czy uwazam ze jestem tam gdzie jestem
    atmost - nie przelecialem
    

    
    
    i plikiem atdbg którym symuluje atrybuty stron z dużych platform
    
    

    bx "write>=main_f and write<main_t and write!=m_dliy and write!=m_dlia and write!=m_dlix and write!=m_markerrrr and write!=m_marker_s_x and write!=wiper.m_exit_column and (write<wiper.fill_s or write>=wiper.fill_e)"
    

    
    wygenerowana grep-em sekcja "read only" dla kodu (poza miejscami gdzie kod zmienia się dynamicznie)
    
    albo - na razie definiowana bardziej ręcznie
    
    

    bx "pc>=charFiller_f and pc<charFiller_t and (write>=$100 and write<chardata_f)"
    

    
    
    To powoduje, że elementy które ja wkładam do plecaka są bardzo wybredne i nie dają się tak łatwo zrzucić sobie na stopę.
    
    Naszczacie 'dziurek' na kod zostaje mi na tyle mało, że jeszcze przeżyje :) Ale segmenty 'execute only(z wyraźnym zaznaczeniem ze etykiety m_ są zapisywalne) / read only / write only definiowane w mads + rozszerzenie Altirry które to ładnie zgłasza to bym przytulił
23. • 23:
       
      CommentAuthorjhusak
    • CommentTime3 Dec 2021 14:12 zmieniony

     
    Zauważyłem że z kodu zniknęła obsługa .db . W dokumentacji natomiast cały czas jest. Da się poprawić?
24. • 24: CommentAuthormrk
    • CommentTime25 Jan 2022 13:01 zmieniony

     
    Przydało by się wsparcie dla formatu ELF :)
    EDIT - właśnie czytam dokumentację ->link<- - chyba zrobię na szybko jakiś konwerter :]
25. • 25: CommentAuthorilmenit
    • CommentTime25 Jan 2022 13:01

     
    Niektóre asemblery 6502 mają dodatkową składnię dla kodu samo-modyfikującego się, w taki sposób:
    lda param:#$FF
    lub
    lda val_b:#$4321,y
    i potem np.:
    ldx #0
    sta param
    
    Nie jest oczywiście problemem zrobić:
    opcode_a equ *+1
    lda #$FF
    
    ale taka rozszerzona składnia wg. mnie jest całkiem fajna.
26. • 26: CommentAuthorflashjazzcat
    • CommentTime26 Jan 2022 12:01

     
    Different (native MADS) relocatable segment types in the same object file, as per the SDX relocatable binary format (i.e. 'main', 'extended', etc) would be nice. The MADS relocatable format is ostensibly intended for use with the linker, but I wrote a symbolic linking loader for it, and it would be nice to have - say - a driver which can relocate one segment to MEMLO and another to somewhere in extended memory, with fixups bridging the two. SDX format allows this, but symbol names are limited to 8 characters there, and lo/hi fixups are not supported.
27. • 27: CommentAuthortebe
    • CommentTime29 Jan 2022 12:01

     
    .reloc 0..255
    
    create you own 'reloc' block
28. • 28: CommentAuthortebe
    • CommentTime31 Jan 2022 23:01

     
    Niektóre asemblery 6502 mają dodatkową składnię dla kodu samo-modyfikującego się, w taki sposób:
    lda param:#$FF
    lub
    lda val_b:#$4321,y
    i potem np.:
    ldx #0
    sta param
    

    
    
    nowa wersja Mads-a na githubie ->link<-
    
    dodane etykiety automodyfikacji ->link<-
29. • 29:
       
      CommentAuthorjhusak
    • CommentTime20 Feb 2022 13:02 zmieniony

     
    Po ":" w powyższym kodzie nie może być spacji. To jest tak specjalnie? Czy przeoczenie?
30. • 30: CommentAuthortebe
    • CommentTime21 Feb 2022 10:02

     
    po porawce, ->link<-
    
    teraz może być po ':' dowolnie dużo "białych" znaków
31. • 31:
       
      CommentAuthorjhusak
    • CommentTime21 Feb 2022 11:02

     
    Dzięki :)
32. • 32:
       
      CommentAuthorjhusak
    • CommentTime21 Feb 2022 13:02 zmieniony

     
    Aha. Jeszcze w związku z parametrami i składnią przydało by się móc zdefiniować minimalną wersję; np. MINIMAL_MADS_VERSION="2.1.5", i to by się w środku parsowało i porównywało. Było by to elegantsze, niż teraz, że się wywala na składni, oraz, co gorsza, możliwy jest przypadek, że coś się źle skompiluje/zassembluje w wyniku zmian.
33. • 33: CommentAuthorilmenit
    • CommentTime21 Feb 2022 16:02

     
    @jhusak - MADS chyba nie miał problemów ze wsteczną kompatybilnością, więc potencjalnie można zakładać, że użyszkodnik powinien używać najnowszej wersji ;)
34. • 34:
       
      CommentAuthorjhusak
    • CommentTime21 Feb 2022 17:02 zmieniony

     
    Potencjalnie. Słowo klucz.
    Sytuacja - ściągasz jakiś asm i Ci się nie kompiluje, wywala jakieś błędy. A gdyby wypisał: "Minimalna wymagana wersja 2.1.5; zainstalowana zbyt wczesna wersja: 2.1.3. Program zakończony." to byś się obraził? :)
35. • 35:
       
      CommentAuthormgr_inz_rafal
    • CommentTime21 Feb 2022 17:02

     
    Zdarzają się problemy z kompatybilnością wsteczną. Nadziałem się kiedyś na nie, choć oczywiście nie pamiętam już szczegółów. W skrócie, po updacie wersji mads-a któraś z gierek gdzieś tam mi się zaczęła wywalać. Pewnie po prostu moja implementacja "polegała na bugu" w mads, którego Tebe poprawił, a mi już się nie chciało grzebać i poprawiać, więc wrzuciłem sobie konkretną wersję madsa do repo i nim kompilowałem.
36. • 36: CommentAuthorilmenit
    • CommentTime21 Feb 2022 21:02

     
    @jhusak - jeżeli nie można zakładać kompatybilności wstecznej, to takie sprawdzenie nie zagwarantuje działania w nowszej wersji, którą może mieć użytkownik (np. 2.1.6) ;)
37. • 37:
       
      CommentAuthorjhusak
    • CommentTime22 Feb 2022 01:02

     
    W sumie racja.
38. • 38:
       
      CommentAuthorpirx
    • CommentTime22 Feb 2022 03:02

     
    czyli trza zapisywać, jakego madsa się używa. o mamciu, paczę, że mam jakieś przedpotopowe wersje...
39. • 39: CommentAuthortebe
    • CommentTime22 Feb 2022 10:02

     
    cały czas testuję mads-a dokonując assemblacji starych projektów, jeśli były potrzebne zmiany w projekcie to dotyczyły potrzeby dodania znaku komentarza, była zmiana sposobu odczytu długości STRUCT, usunięcie dyrektyw .DB, .DW
    
    to te trzy zmiany miały najczęściej wpływ na jakiekolwiek problemy
40. • 40: CommentAuthorilmenit
    • CommentTime22 Feb 2022 10:02

     
    @tebe - dzięki za MADSa, to jeden z najlepszych asemblerów jakie powstały.
41. • 41:
       
      CommentAuthorjhusak
    • CommentTime22 Feb 2022 13:02

     
    No masz! 16000 linii nie w kij dmuchał :)
42. • 42:
       
      CommentAuthorpirx
    • CommentTime22 Feb 2022 13:02

     
    bez madsa i tebe
    chybabym gryzł glebe
43. • 43: CommentAuthormono
    • CommentTime22 Feb 2022 14:02

     
    Potwierdzam. Najlepszy. Dzięki Tebe!
44. • 44:
       
      CommentAuthorgienekp
    • CommentTime22 Feb 2022 16:02 zmieniony

     
    Czy jest taka funkcja (a jeżeli nie to "bardzo prosić"), żeby od zadanego miejsca MADS zaczął kompilować kod jakby był od nowego adresu, ale żeby nie wymuszał FFFF w XEX, tylko traktował jakby dane. ORG tego nie ogarnia.
    
    

    ORG $2000
    
    LDA #<SRC
    STA SKAD
    LDA #>SRC
    STA SKAD+1
    JMP COPY
    
    XYZ $0600 ; tutaj coś co by zamarkowało nowy adres
    
    SRC
    LDA RANDOM
    STA COLBAK
    JMP SRC
    

    
    
    Kod górny powinien kompilować się normalnie. To co po XYZ to tak jakby było od adresu $0600 (czyli JMP $0600), ale żeby z punktu widzenia XEX to były zwykłe dane.
45. • 45: CommentAuthortebe
    • CommentTime22 Feb 2022 18:02

     
    XXL ostatnio zadał podobne pytanie, ->link<-
46. • 46:
       
      CommentAuthorgienekp
    • CommentTime22 Feb 2022 19:02

     
    Czyli jak chce mieć (np. w pamięci cartridgea) kilka ALTERNATYWNYCH funkcji, które potem będą kopiowane do RAM i tam uruchamiane to mogę pisać:
    
    

    ORG $A000
    
    nop
    ;jakiś kod
    nop
    rts
    
    .local ver1,$0600
    lda #1
    rts
    .end
    
    .local ver2,$0600
    lda #2
    rts
    .end
    

    
    
    ?
47. • 47:
       
      CommentAuthorjhusak
    • CommentTime22 Feb 2022 19:02

     
    Tak.
48. • 48:
       
      CommentAuthorsun
    • CommentTime22 Feb 2022 21:02

     
    Najbardziej bym chciał, żeby się dało w prosty sposób piosenkę pana Koracza o zdrowiu wygenerować w MADsie :)
    Super asm, w połączeniu z MADPascal - duet nie do zajechania.
49. • 49: CommentAuthorflashjazzcat
    • CommentTime22 Feb 2022 22:02

     
    .reloc 0..255
    
    create you own 'reloc' block
    

    
    
    I'm sorry - I don't know how to use this and if I put more than one '.reloc' in a file, even using the latest version of the assembler, I get an 'Org specified at Reloc block' error.
50. • 50:
       
      CommentAuthorjhusak
    • CommentTime24 Feb 2022 11:02

     
    Warto byłoby wyczyścić warningi, hinty i notesy podczas kompilacji.