ZX Spectrum > SOFTWARE

Moje STARTy / menu dyskowe.

(1/16) > >>

Phonex:
Już kilka razy obiecywałem, że wyślę moje starty (menu dyskowe). W końcu postanowiłem wysyłać je po jednym co jakiś czas, w miarę poprawiania. Jest ich kilkanaście, mając na początku kilka/kilkanaście dyskietek miałem chyba  ambicję by na każdej był inny ;) Niektóre mogą się spodobać, ale nie wiem czy komuś się przydadzą - na ogół nie są automatyczne. Czyli tytuły trzeba wpisać.
Powstały głównie na na stację OPUS Discovery, więc przewidują 10-znakowe nazwy, powstały dla standardowego napędu (178K), więc jest miejsce tylko na cztery lub pięć tytułów gier. Można to oczywiście zmienić: zmienić długość ładowanej nazwy i ilość tytułów - trzeba by zmienić rozmiary tablic, parametry PLOT, DRAW i pętle. Zmiana długości tablic nie jest konieczna, jest tylko zabiegiem estetycznym. Ja na początku po przejściu z Opusa na FDD3000 dopisywałem "TO 8" - LOAD a$(TO 8 ), ale niepotrzebnie - TOS ignoruje spacje za nazwą. Wpisując do startu prawdziwe nazwy z dyskietki nie spowodujemy błędu, o ile nazwy są bez rozszerzeń. Z rozszerzeniami mogą się nie zmieścić.
W części startów, żeby zmienić rozmiary okienka będzie potrzebna ingerencja w asembler. Jak będzie potrzeba, podam pod jakim adresem dokonać zmian.

Starty nie są automatyczne, bo tak jest szybciej, odczyt z dysku zabiera dodatkowy czas. Poza tym na początku założenie było takie, że raz nagrane na dysk gry zostną tam już na zawsze. Trzecim argumentem jest to, że można wpisać tylko część nazw i w wybranej kolejności.
Miejsca na dysku było mało, stąd kompresor obrazków, potem filecompressor, stąd też optymalizacja startów pod względem długości: liczby są zapisywane jako VAL "n", lub CODE "x", zero jako NOT PI, itd. W Opusie jednostka alokacji=sektor, a sektor ma 256 bajtów. Często udało się zmieścić start w 3 sektorach, a parę razy nawet w dwóch.
Ponieważ od czasów któregoś-tam-Apple jestem fanatykiem okienek, w każdym możliwym miejscu je stosuję :D
Napisałem nawet kiedyś "Windows Designer" - programik pod Beta Basic, który po podaniu rozmiaru i treści sam generował linie BASICa rysujące okienka.
Dlatego każdy mój start to okienko plus coś ;)
Teraz pewnie dopisałbym wybór klawiszami 1-4.

Starty będę prezentował w kolejności w miarę chronologicznej, widać w nich rosnący udział asemblera :D
Obsługa joystickiem Kempston (góra/dół/fire) lub klawiszami kursora (na gumiaku również same "5" i "6" bez shifta) i ENTER/"0". Obsługa joystickiem jest, bo Opus ma wbudowany interfejs Kempston ;)
Wysyłam je w trybie taśmowym, żeby wszyscy mogli obejrzeć bez komunikatu o błędzie. Przed nagraniem na dysk należy dopisać rozszerzenie dyskowe po LOAD (na ogół w przedostatniej linii). Dla FDD3000 ma być: "LOAD *", dla Opusa: "LOAD *1;".
Nagrywać na dysk SAVE *"START" LINE 1 dla FDD3000, lub SAVE *1;"RUN" LINE 1 dla Opusa.
W czasach gdy powstawały mało kto je widział, bo stację dysków miałem tylko ja, potem doszedł Bill Gilbert, następnie Kicia, itd. Oczywiście chwaliłem się stałym bywalcom giełdy ;) Mogło to mieć wpływ na wygląd starta, którego napisał Bzyk (i zdaje się jest dołączony do TOS A.4).

Phonex:
1. Gry s1

Cztery gry. Długość 752 bajty.
W asemblerze jest tu tylko odczyt klawiszy/joysticka i efekt. Cała reszta, łącznie z przesuwaniem paska, jest w BASICu. Oglądając teraz program w asemblerze zauważyłem, że program sprawdza więcej klawiszy: również Q, A, i M. Możliwe, że był przed tym jakiś inny start (bez efektu), a potem został zastąpiony. Możliwe że nie i od razu chciałem żeby wygląd był bardziej atrakcyjny, godny nowej stacji dysków ;)
Jeżeli chodzi o efekt, to tylko pomysł jest mój: przesuwać w lewo, potem w prawo. Sama procedura przesuwania nie jest moja, pochodzi prawdopodobnie z programu "Supercode" - skroll poziomy o 1 pixel.
Wtedy nic na ten temat nie wiedziałem, teraz prawdopodobnie dorobiłbym synchronizację z ramką. Spróbowałem - wygląda ładniej (drugi plik).
Ponieważ prawie cały jest w BASICu, nie ma problemu z przerobieniem np. na większą ilość gier. Z asemblera wychodzi jak naciśnie się istotny klawisz, może zwrócić trzy wartości: 1-naciśniety ENTER/fire, 0-w górę, 2-w dół. Widać że miałem wtedy szacunek dla programów w Asemblerze, bo potem z tych liczb obliczam przesunięcie d=2*(USR adr-1), zamiast zmienić wartości wyjściowe na 2, 0, 4 i uprościć obliczenie na d=USR adr-2.

ZX Freeq:

--- Cytat: Phonex w 2018.08.10, 19:10:06 ---Miejsca na dysku było mało, stąd kompresor obrazków, potem filecompressor, stąd też optymalizacja startów pod względem długości:

--- Koniec cytatu ---

Normalka. Jak przenosiłem gry z taśm na FDD3000 też tak robiłem. A jak wmontowałem napęd 3.5 cala, nawyk i tak pozostał :)
Dzięki za starty, fajnie jest zobaczyć jak to robili inni ;)

Phonex:
2. Gry s5

Cztery gry. Długość 759 bajtów.
W asemblerze jest tu... nic. Może to był pierwszy start, pomimo nazwy?
Inna jest obsługa: dowolnym klawiszem zmiana na następną grę, ENTER - wybór. Nie ma możliwości cofania, trzeba przelecieć całą listę. Uruchomienie też wyjątkowo jest od linii 100 (SAVE "start" LINE 100), żeby kluczowa dla szybkości działania linia (linia 4) była blisko początku programu.
Zmiana kolorów napisu zrobiona jest jedną instrukcją PRINT z wpisanymi kodami kontrolnymi pozycji zamiast PRINT AT, tylko w celu oszczędności miejsca. Szybkości działania to nie zmienia. Dla wiersza 13 i 14 nie da się tak zrobić, bo powoduje błąd. Za to spowalniają wykonanie te wszystkie VAL "nn", więc w kluczowych miejscach ich nie ma.
Efekt powiększonego PRINTa jest zrobiony dzięki sztuczce - przestawienie adresu wydruku dla instrukcji LPRINT na ekran ;) A że linie na ekranie nie są kolejno - napis wychodzi rozstrzelony w pionie. Wystarczy teraz wykonać to 8 razy, z kolejnymi liniami.
Najłatwiej tu powiększyć ilość gier, wystarczy w ostatniej linii dopisać nowe, nie ma potrzeby zmieniania żadnych innych parametrów.

Phonex:
3. Gry s2

Pięć gier. 699 bajtów.
W końcu pasek wyboru jest w asemblerze!
Działa szybko, jest krótszy, a po wyjściu do BASICa zwraca wybrany numer, bez konieczności dzielenia czy dodawania :) Cały łącznie z efektem jest napisany przeze mnie. I chyba już dowiedziałem się że część pamięci jest wolna, bo procedura od efektu jest przerzucana pod 50000. Albo pisałem pod ZEUSem.
Jak zwykle kod jest w REM, ale tu są dwie linie z kodem: w pierwszej jest odczyt klawiszy/joysticka i wyświetlanie paska, a w drugiej efekt. Dzięki temu łatwo zmienić efekt.
Oczywiście obecność kodu w REM, przez to że są niedrukowalne znaki, powoduje zawieszanie BASICa 128. Ponieważ nie miałem ZX 128K, widzę teraz, że dopiero w jednym z ostatnich startów - przypadkiem - wpadłem na rozwiązanie tego problemu. Można na 128 używać, ale edytować - tylko w BASIC 48.
Jeżeli nawet już wiedziałem o szybkiej i wolnej pamięci, to nie do końca: w linii 10 jest CLEAR 29000, więc obszar stosu znajduje się jednak w wolnej pamięci, a w programie jest kilka CALLi. Można łatwo zobaczyć wpływ tego na szybkość zmieniając na CLEAR 35000. Także na stodwudziestceósemce efekt chodzi szybciej.
Ponieważ nie dało się skrócić poniżej 512 bajtów (2 sektory na Opusie), nie było potrzeby optymalizacji długości. Wszystkie liczby są więc wpisane  normalnie, bez VAL.
Zdaje się, że byłem optymistą jeśli chodzi o powiększanie liczby gier. Tu też efekt obejmuje konkretną liczbę wierszy, dla innej liczby trzeba będzie dobierać opóźnienie, bo nie jest zsynchronizowany z ramką.
Przy okazji przyjrzałem się efektowi i doszedłem do wniosku że przypadkiem wyszedł mi multicolor :D

Nawigacja

[0] Indeks wiadomości

[#] Następna strona