To była karta MMC 16 MB, więc nie dziwię się, że nie zadziałała. U mnie działają microSD w adapterze sformatowane na FAT32.

1. AdamK
2. Sikor
3. Jesionen
4. pin
5. perinoid
6. AtariGamer
7. Bachoo
8. Eagle
9. alexthissen
10. voy
11. Drupi77
12. dragmar
13. Jaybezeone
14. laoo/ng

Tylko nie mówcie żonie.

Następny ficzer użyty i następny błąd znaleziony :)

    .segdef seg $4000 $4000 R bank 

    .segment seg
l    nop
    .endseg
    
bank = $15

generuje mi błąd:

mads.exe test.asm
l       nop
test.asm (5) ERROR: Label L declared twice (BANK=21)

Eksperymentując odkryłem, że można go obejść na dwa sposoby: ustawiając numer banku w .segdef jako liczbę, albo definiując etykietę bank przed .segdef

Te obejścia są bezproblemowe, więc to nic pilnego, ale zgłaszam, bo to nie jest zachowanie, którego bym się spodziewał.

Przy okazji odkryłem, że kuleje trochę ustalanie, czy segment ma być read-only. Taki kod:

bank = $15

    .segdef seg $4000 $4000 R bank 

    .segment seg
v    equ $80

l    sta v
    .endseg

Generuje mi ostrzeżenie

test.asm (9) WARNING: Label V is only for READ

a listing ma w tym miejscu taki wpis:

     7 = 15,0080        v    equ $80

Nie znam wnętrzności madsa, ale widać, że definiowanie etykiet wewnątrz segmentu o wartościach spoza segmentu jest problematyczne. Prawdę mówiąc przypisanie tej etykiety do banku $15 też nie jest czymś, co bym się spodziewał i chyba tu tkwi problem i może rozwiązaniem byłoby, żeby do banku segmentu zaliczać tylko te adresy, które się w tym segmencie zawierają.

Dzięki chłopaki! Bardzo wiele mi się rozjaśniło.
W kwestii ew. wyjaśnień, to oczywiście nie chcę sam wydawać żadnych kartridży, tylko potrzebuję jednego flaszującego stricte do celów developerskich. I oczywiście że będę uruchamiał grę na emulatorze, ale nie mogę sobie pozwolić, żeby nie testować jej równolegle na prawdziwym hw.
Z tego co przetrawiłem, to na moje potrzeby najlepszy byłby albo AVGCart, albo Ultimate Cart z tego względu, że można na nich "montować" pliki *.CAR z karty SD, co jest idealnym przypadkiem użycia dla mnie. The!Cart ma tę wadę, że wymaga wgrania pliku przez Atari za pomocą np SIO, co znacznie utrudnia pracę. Kwestia jest tylko taka, że The!Cart można kupić zdaje się od ręki, a jak wygląda sprawa z AVGCart i Ultimate? Widzę na AtariAge jakieś stare wątki z preorderem, co nie wróży dobrze. Ktoś coś wie? Jest jakiś wtórny rynek może?
A może ewentualnie ktoś byłby skłonny pożyczyć na parę tygodni swojego gdzieś na wiosnę jak już będziemy mieć coś działającego na emulatorze? Tak ad maiorem dei gloriam? ;)

Dzięki chłopaki za odzew :)
@grzybson: Myślałem o bankowaniu po 8kB ze względów oszczędnościowych - rozmiary buforów jakie używam lepiej dałoby się poupychać w takich bankach i ostatecznie zająłbym mniej pamięci, ale po przemyśleniu to rzeczywiście nie jest chyba warte włożonego wysiłku i lepiej od razu nastawić się na 1 MB ROMu bankowane po 16 kB.
@inni_pytający_się_o_wersję_plikową_PORTB: Jak najbardziej chcemy wypuścić wersję plikową, ale tutaj w grę wchodzi kwestia... hmm... "polityczna", bo jakie były reakcje na party version? "A dlaczego to hur wymaga tyle ramu dur!!1", "E tam, tak to każdy potrafi. Wyczynem to byłoby zmieścić się w 64 kB tak jak na komodore" i tego typu dyrdymały. Więc ja wiem już teraz, że wersja, która będzie wymagała czegoś więcej niż stock atari na bank spotka się z krytyką. Oczywiście można machnąć na to ręką, ale włożyliśmy w projekt na tyle dużo wysiłku, że chcemy zrobić to porządnie, stąd pomysł wersji kartridżowej (chociaż pewnie kartridż 1MB też będzie krytykowany, bo komodorowski zajmuje mniej), a w drugiej kolejności, na bazie wersji kartridżowej wersja plikowa na dodatkową pamięć. Nie jestem pewien jeszcze ile, ale w 512 kB zmieścimy się z zapasem, nie wiem tylko o ile da się zejść mniej (liczba roboczych banków wymagających do działania silnika nie jest duża, a resztę danych można albo doczytywać, albo trzymać spakowane).
W celach deweloperskich w sumie nie potrzebuję emulować pełnego kartridża 1 MB, bo do testów przecież nie trzeba mieć na pokładzie wszystkich poziomów i wszystko da się przetestować jak będą powiedzmy trzy. W tej chwili mam w atari Ultimate 1MB. Da się nim udawać jakieś kartridże i jeśli tak, to jakie duże? A SIDE2? Tam da się udawać kartridż 256 KB, czy coś źle rozumiem? Ewentualnie z innych proponowanych co można w miarę bez problemu nabyć? Na www.mega-hz.de widzę że The!Cart można kupić za 60 euro... w sumie źle to nie wygląda.

No i o to chodziło. Żeby maszyna pomagała, jak człowiek zrobi jakąś wierutną głupotę, bo nie wiem jak inni, ale ja nieomylny nie jestem. Dziękować!

A to to ja wiem, że zrobiłem bład, zgłaszam tylko, że mads ten kod zaakceptował jako poprawny.

Zasadniczo...

Ale zagadnienie wygląda mi na skomplikowane, bo jednak organizacja pamięci video w snesie i jego scrolling wydaje się bardziej przewidywalne niż w Atari. Chyba raczej trzeba byłoby pójść w analizę kolejnych klatek wychwytując podobieństwo w postaci przesunięć - tak jak robią do kodeki.

Zanim kupiłem konwerter z pierwszego posta (na szczęście umówiłem się ze sprzedawcą że będę mógł oddać), testowałem urządzenie kolegi:

Ono działa poprawnie. Jakość dla mnie była zadowalająca. Od biedy dałoby się stosować je jako przejściówkę HDMI, bo ma takież wejście. Cena tylko sporo większa. I gabaryty.

Konwertery, jeśli ktoś chciałby kupić, żeby nie wszedł na minę, bo nigdzie nie piszą, czy konwerter konwertuje RGB czy tylko composite.

Zaczynanie tego wątku było błędem, bo skoro nawet Fox nie zrozumiał intencji, a ludzie zaczynają narzekać dlaczego vbxe niem ma obrotów i skalowania, to wnioskuję, że w naszym światku nie ma jednak gruntu na merytoryczną dyskusję na ten temat.

Tego się spodziewałem, ale tak jak napisałem na początku, chciałem się spytać, bo nie jestem na bieżąco, a przebrnąć przez kilkuletnie zasoby forum mi się nie udało. Nie wiedziałem też, jak bardzo upchany jest rdzeń, bo skądinąd wiem, że rdzeń Rapidusa zajmuje tylko ułamek zasobów.
No i TeBe nie bulwersuj się tak, bo to przecież oczywiste, że nie chodziło mi o przyjazność dla programisty, która jest rewelacyjna, bo prościej oprogramować się tego nie da, tylko o przyjazność dla CPU, aby miał mniej danych do przewalenia
generując jakąś zawartość.

Udostępnij takiego zepsutego ATRa to będzie można myśleć co się zepsuło i ew. odzyskać pliki, jeśli to możliwe. Przy raportowaniu błędów do podstawowa sprawa, bo samo powiedzenie, że jest błąd niewiele niestety mówi.