@Grey, poka co napisali o tych jedenastu neue Lynx-Spiele, a szczególnie o takiej jednej...

2

(29 odpowiedzi, napisanych Zloty)

NG jedzie IC 6501 a wraca IC 5602, no jakżeby inaczej?

3

(5 odpowiedzi, napisanych Software, Gry - 16/32bit)

Nie znam się na dużym Atari, ale Grafika/muzyka super, tylko bardzo widać, że to BASIC, bo intuicyjnie wydaje mi się, że ST nie może być aż tak wolne smile

4

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

Schodzimy już na eschatologiczne tereny, ale dużo w tym racji. Aczkolwiek nie wydaje mi się, żeby rozwianie mitu AMY było jakoś bardzo traumatycznym doświadczeniem i może jednak plusów czegoś trochę lepszego od POKEYa, ale czegoś co można oprogramować byłoby więcej niż minusów z niespełnionych oczekiwań. Bo jednak na scenie są ludzie, którzy lubią wyzwania i mieć robotę do wykonania.

PS Candle - dostałeś ode mnie maila z forum? Odezwij się proszę do mnie, bo mam sprawę odnoście VBXE.

5

(58 odpowiedzi, napisanych Scena - 8bit)

Przypomniał mi się motyw z przekładem baśni braci Grimm. W Polsce nie ma jeszcze przekładu pierwszego wydania z powodów trudności w oddaniu niuansów językowych. I tłumaczka, która się tym zajmuje, odkryła, że jakieś wydawnictwo krzak wydało ten przekład. Po dochodzeniu doszła do tego, że to przekład z... angielskiego. Jak wytknęła sprawę i zrobiło się głośno, to wydawca tłumaczył się, że zaszło karygodne niedopatrzenie, że do drukarni poszedł nie ten plik co trzeba i wydrukowano roboczy przekład angielskiej wersji, a nie ten ich prawdziwy z niemieckiego...

6

(58 odpowiedzi, napisanych Scena - 8bit)

Też coś czuję, że można spaść z rowerka próbując wydać taką grę. To było praktycznie pewne, że Cię oleją, ale jakbyś wydał, to pismo dostaniesz.

Marchewka robi swoje smile

8

(12 odpowiedzi, napisanych Programowanie - 8 bit)

I podjął wg mnie słuszną decyzję

9

(12 odpowiedzi, napisanych Programowanie - 8 bit)

No to może znalazłeś buga - można wpisać issue: https://github.com/KarolS/millfork/issues

Niech się facet cieszy, że community przygląda się jego projektowi smile

10

(12 odpowiedzi, napisanych Programowanie - 8 bit)

Intuicyjne to nie jest, ale na moje oko wszystko dzieje się poprawnie. Pętla "to" liczy do góry aż napotka docelową wartość.

11

(12 odpowiedzi, napisanych Programowanie - 8 bit)

Badał ktoś ten projekt?

https://github.com/KarolS/millfork

Ja z definicji jestem bardzo sceptyczny odnośnie kompilatorów dla 6502, ale na pierwszy rzut oka ten wywarł na mnie bardzo pozytywne wrażenie.

Nie ma żadnego przykładu dla atari, ale generyczne przykłady po prostu działają:

// memorize this code for your next interview for a Millfork developer position

import stdio

void main() {
    byte i
    for i,1,to,100 {
        if i %% 15 == 0 {
            putstrz("fizzbuzz"z)
        } else if i %% 3 == 0 {
            putstrz("fizz"z)
        } else if i %% 5 == 0 {
            putstrz("buzz"z)
        } else {
            putword(i)
        }
        putchar(' ')
    }
    while(true){}
}
millfork.exe -t a8 -o out.xex fizzbuzz.mfk

12

(1,583 odpowiedzi, napisanych Fabryka - 8bit)

No ale zaraz... Nie wiem czy rozumiem. Czy rozmawiamy tu o plikach ładowalnych AtariDOS? Nagłówek $FFFF itd? Bo z dyskusji wnoszę, że tworzony jest tu niekompatybilny format pliku ładowalny tylko przez xBios. Jeśli tak, to nie powinien być to *.XEX, tylko jakiś powiedzmy *.XBS i wtedy XXL nie musiałby ograniczać się do tego formatu i mógłby zamieszczać w nim jeszcze jakieś metadane i inne miodności jak format kompresji itd. Nie jestem jednak za tym, aby ten format "udawał" standardowe pliki XEX, skoro nie załaduje się z żadnego DOSa.

13

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

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.

14

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

Uff... już myślałem, że mamy następnego buga do kolekcji wink

15

(25 odpowiedzi, napisanych Konsole)

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.

16

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

Szybkość przyrostu tej listy jest motywatorem, żeby jednak pojawić się na zlocie smile

17

(58 odpowiedzi, napisanych Programowanie - 8 bit)

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

    .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ą.

18

(2 odpowiedzi, napisanych Konsole)

Cześć.
W przypływie wzmożonego szaleństwa (aczkolwiek nie posądzałbym żadnego z bywalców tego forum o zdrowie psychiczne) naszła mnie niechcąca się odeprzeć chęć spróbowania się z kodowaniem na Atari 7800.
Chciałbym sobie kupić jakąś, ale naszła mnie równocześnie myśl, że w dzisiejszych czasach nie jest do końca oczywistą decyzja, czy lepiej kupić konsolę w wersji PAL, czy NTSC. Pod względem podłączenia jej do czegoś to nie ma znaczenia, ale pod względem liczby potencjalnych konsumentów treści, to środowisko amerykańskie zdaje się być wielokrotnie bogatsze od europejskiego (nie mówiąc o polskim, gdzie 7800 praktycznie nie istniała).
Czy zatem jest jakaś przesłanka nad preferowaniem w poszukiwaniach wersji PAL, czy może lepiej szukać NTSC?

19

(35 odpowiedzi, napisanych Programowanie - 8 bit)

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? wink

20

(35 odpowiedzi, napisanych Programowanie - 8 bit)

@Mq oczywiście gra nie będzie dedykowana na flashowalnego kartridża. O flaszkach mówiłem tylko w kontekście deweloperskim, żebym sam mógł ją na czymś testować, a widzę, że taki The!Cart potrafi emulować bardzo wiele typów, więc póki co skłaniam się ku niemu. Docelowo chcę wybrać jakiś typ kartridża 1 MB (bo różnią się sposobem bankowania) i przygotuję obraz CAR, który będzie można sobie sflaszować jak ktoś chce, ale oczywiście głównym celem jest, aby zrobić jakąś małą edycję kilku sztuk i zasadniczy sens mojego pytania był taki, jaki rodzaj kartridża opłaca się wybrać, żeby łatwo dało się go flashować oraz żeby był łatwy w produkcji właśnie dla tej małej serii dedykowanych kartridży (podobnie jak było z TP).
@Sikor: myślimy o doczytywaniu. To czy to da się zrobić na 130XE to kwestia wymagań silnika gry, jak bardzo da się zoptymalizować, ale prawdę mówiąc zamiast żyłować wersję plikową na 130XE wolałbym zrobić kartridżową na 65XE oraz plikową na coś większego - kwestia włożonego wysiłku, a może i fizycznych możliwości jak bardzo da się zejść, a aż tyle czasu na optymalizację nie wiem czy mam.

21

(35 odpowiedzi, napisanych Programowanie - 8 bit)

Dzięki chłopaki za odzew smile
@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.

22

(35 odpowiedzi, napisanych Programowanie - 8 bit)

Na SV 2018 pokazaliśmy plikówkę party version naszego Flimbo's Quest. Gra to jednak nie demo i musi działać na jakiejś sensownej konfiguracji, stąd pomysł, aby wersję finalną przygotować na kartridżu, żeby działał na stockowym 65XE.
I stąd pytanie do kolegów biegłych w programowaniu kartridży, jak to ugryźć, bo sam tego nie robiłem? Kryteria, nad jakimi się zastanawiam, to:
- Rozmiar to co najmniej 512 kB, ale raczej 1 MB (banków romu nie da się ponownie użyć, wszystko musi być już rozpakowane i gotowe do użycia, a sama implementacja paralaksy potrafi pożreć nawet 64 kB danych, nie mówiąc o soft-sprite'ach; gra ma 7 poziomów, więc można sobie przemnożyć),
- najefektywniej pamięciowo byłoby, gdyby miał bankowanie po 8 kB,
- łatwość developowania to chyba nie problem, bo wystarczy pewnie przygotować odpowiedni plik car i emulator chyba łyka go bez problemu,
- przyjazność dla użytkowników.

No i najbardziej martwi mnie ten ostatni punkt, bo wiadomo, że wszystkim atarowcom z natury rzeczy się nie dogodzi, a chciałbym zminimalizować liczbę tychże wieszających na nas psy. Wiadomo, że jak "ktoś" wyda taki kartridż, to można będzie go kupić i odpalić, ale jak wygląda kwestia emulacji na jakichś urządzeniach flaszujących? Jakie tutaj są ograniczenia, czy wytyczne, których warto się trzymać? Jakie są popularne rozwiązania? Pytam się także w kontekście uruchamiania tego przez nas, bo fajnie byłoby gdybym miał możliwość odpalenia karta na prawdziwym sprzęcie, a nie tylko na emulatorze, więc jakiś flaszer by się przydał. W ogóle nie pi*ę głupot i warto zawracać sobie głowę takim zagadnieniem?

Czy wybór kartridża Typ 38 (Switchable XEGS 1 MB cartridge) byłby dobry?

23

(58 odpowiedzi, napisanych Programowanie - 8 bit)

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ć!

24

(58 odpowiedzi, napisanych Programowanie - 8 bit)

   434
   435 A01C            backgroundCharsSrc .wo
   436 A01C 00 00        backgroundScrollDiff .wo 0
   437

Chyba za bardzo ufam, że mads zgłosi błąd przy niepoprawnym kodzie. I kosztuje mnie to wiele godzin szukania nie tam gdzie trzeba sad

25

(58 odpowiedzi, napisanych Programowanie - 8 bit)

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