c64scene.pl

W związku z pojawieniem się fajnej możliwości uruchamiania demek z SD2IEC https://www.c64scene.pl/viewtopic.php?f=2&t=3953 wymyśliłem sobie program w basicu który odczyta mi z katalogu z demami listę demek się tam znajdujących a następnie losowo wybierze jedno z nich i je uruchomi.
Wszystko pięknie się udało z wyjątkiem szybkości działania tego programu
Odczytywanie katalogu w basicu osiąga prędkość około jednego wpisu na sekundę co przy 20+ demkach robi się nurzące.
Zna ktoś jakiś sposób na przyśpieszenie tego procesu?

Widzę, że masz podobny problem jak ja. Z tego co wiem C64 już tak ma, że ręczne ładowanie listy plików w BASICu trwa wieki.
Ale widzę, że to i tak jest spory postęp na SD2IEC: tylko 1 sekunda na 1 program. W czym problem chciałoby się rzec, przecież to bardzo szybko. W moim TRIANGULAR μOS na C64 to mieliło gdzieś z 10 sekunda jeden program (bez turbo loadera). Na C128 z 1581 już trochę lepiej, bo 5s.

Jeśli masz w miarę stałą listę dem w katalogu to może niech ten program ma dwie opcje: odczytywanie katalogu i wybieranie dema z listy dem. Po odczytaniu zapisze sobie listę dem z tablicy fi$ do pliku SEQ i przy kolejnym uruchamianiu programu niech wczytuje ją do tablicy z tego pliku - powinno być dużo szybciej. A jak coś tam dodasz to niech ci zrobi nową listę dem. A jak nie to to obawiam się, że tylko asembler Ci pomoże.

Spróbowałem zrobić kompilacje jakimś online-owym narzędziem (https://jpct.de/mospeed-server/?route=) ale bez rewelacji. Wygląda, że odrobinę szybciej działa ale po wylosowaniu dema ma problem z jego uruchomieniem
Ktoś poleci jakiś inny kompilator basica?

Możesz spróbować najpierw załadować całe DIR do pamięci na raz, i stamtąd pobierać po wylosowaniu jakiś tytuł.
sys57812"$",8:poke147,0:poke780,0:poke781,0:poke782,16:sys65493 (ładuje od $1000)
W ten sposób DIR z 100. wpisów ładuje się w około 6sek.
Limitem jest dostępna pamięć.

jeżeli zawartość karty SD jest w miarę stała to może zrobić dir do jednego pliku o ustalonej z góry nazwie i później wczytywać tylko ten plik do losowania?

Na początek spróbuj zoptymalizować swój program.
1. Usuń wszystkie spacje.
2. Dodaj może jakiś zgodny turbo loader.
3. Spróbuj kompilatora dla BASIC.
https://commodore.software/downloads/ca ... -compilers
https://www.c64-wiki.com/wiki/MOSpeed
https://jpct.de/mospeed-server/?route=

Największe spowolnienie twój program ma na kolejnym odczycie pozycji z DIR.

Najwygodniej będzie stworzyć dwa programy:

Pierwszy program (uruchamiany sporadycznie i ręcznie, tylko przy zmianie zawartości katalogu) automatycznie przeskanował by zawartość katalogu i utworzył plik SEQ o przykładowej strukturze:
- pierwszy rekord w SEQ zawierałby liczbę, ilość wszystkich kolejnych rekordów z nazwami plików,
- drugi rekord i kolejne rekordy to już nazwy plików.

Drugi program (ten właściwy -losujący) odczytywałby na początku pierwszy rekord z tego SEQ.
A potem losował które demo ma być uruchomione
i odczytywał właściwą nazwę z SEQ.

Niestety odczyt pliku SEQ polega na odczycie wszystkich rekordów po kolei,
nim "dokopiemy" się do tego wybranego. Ale i tak będzie to zdecydowanie szybciej.

Aby odczytywać dowolny rekord potrzebny plik typu REL, ale ten typ pliku chyba na sd2iec nie działa.




przykładowo zapis w pierwszym rekordzie liczby 100 a następnie kolejne rekordy to 100 kolejnych nazw plików
(;i za nazwą pliku jest tyko po to żeby nazwy w tym przykładzie były różne) przykładowo odczyt pierwszego rekordu a następnie dokopanie się do nazwy pliku nr 99

hobocti77x_ dokładnie.

To co w moim doświadczeniu przyspiesza programy BASICa to (benchmarki są wykonane przeze mnie):
- Usuwanie spacji i REM
- Używanie zmiennych zmiennoprzecinkowych zamiast zmiennych całkowitych (jak A%) daje 50% szybsze obliczenia a używanie zmiennych zmiennoprzecinkowych zamiast stałych (2*3) daje spory wzrost szybkości obliczeń, szczególnie przy ułamkach (ponad 4 razy przy operacji na 2 ułamkach) i złożoności obliczeń (5-6 razy i więcej przy czterech i więcej argumentach). Co ciekawe używanie stałych w instrukcjach FOR, TO i NEXT nie ma to znaczącego wpływu na szybkość tej pętli.
- Jednoliterowe zmienne, szczególnie w przypadku wymagających szybkości części kodu.
- Kropka . zamiast zera (w samym zerze a nie np. 2.. - dwieście)
- Gdzie się tylko da komendy w jednej linii programu przedzielone : dwukropkiem
- Jak najmniejsze numery linii (0, 1, 2, 3.... a nie 10, 20, 30 itd.). Do tego najbardziej wymagające przyspieszenia części powinny być z przodu programu (mieć jak najmniejsze numery linii).
- Jeśli to możliwe wpisywanie samego NEXT bez nazwy zmiennej daje do 25% w przypadku pustych pętli, realnie około 1-2%.
- Przy programach obfitych w zmienne inicjowanie krytycznych zmiennych jako pierwsze to naprawdę dobry pomysł. Przy programie z ponad 100 zmiennymi i 7 ponad 1000 elementowymi tablicami (BASIC RAM tak dopchany, że łącznie po uruchomieniu programu zostało 5 bajtów z 38 KB) kod: A=INT(RND(.)*16):POKE1024+A,64 wykonuje się ponad 50% szybciej, gdy zmienna a jest zainicjowana na początku a nie jako ostania. Przy złożoności obliczeń i ilości argumentów to się nakłada tak, że C=B/A jest ponad 3 razy szybsze gdy te zmienne są deklarowane jako pierwsze a nie ostatnie. Deklarowanie tablic jako ostatnie przyspiesza dostęp do zmiennych. Deklarowanie dużej ilości zmiennych zalecam robić sposobem DIM A,B,C,D,... zamiast A=.:B=.:C=.=.:...., bo zajmuje trochę mniej miejsca i jest 2x szybsze. Jeśli początkowa wartość inicjowanej zmiennej ma być inna niż 0 (zero) to drugi sposób jest konieczny (A=8).

dekanex: Mam potencjalnie fajne rozwiązanie twojego problemu, choć nie bez wad.
A co jakby zamiast jednego pliku SEO dać osobny do każdego dema?
Program katalogujący najpierw przeczesuje folder i zbiera listę elementów. Po każdym elemencie kolejno produkuje plik SEQ pod nazwą plik 001,plik 002,... a nich nazwę elementu. Na końcu dodaje plik 000 z liczbą elementów znalezionych podczas tego przeczesywania.
Wykonać to można tak: i dalej: Program wczytujący demo wczytuje liczbę elementów z plik 000 i generuje losową liczbę od 1 do liczby elementów, następnie ładuje nazwę z plik _liczna losowa_ i ładuje demo. Cała filozofia i prawie natychmiastowa egzekucja. Minus to baza danych złożona z dużej ilości mikro-śmieci na dysku/folderze. Można opracować program do wywalania ich od pliku 000 do pliku _liczba w pliku 000_

radius75 pisze: ↑

21 lut 2024, 10:22

sys57812"$",8:poke147,0:poke780,0:poke781,0:poke782,16:sys65493

To jest najbardziej obiecujące, lecz potrzebna mi jeszcze informacja gdzie jest zapamiętywana ilość wczytanych danych lub ich końcowy adres?
Szukanie końca, to dla basica znowu powolne zadanie, więc nie tędy droga.

sys65493 to $FFD5. A ta kernalowa funkcja zwraca końcowy adres w X i Y:

Output: Carry: 0 = No errors, 1 = Error; A = KERNAL error code (if Carry = 1); X/Y = Address of last byte loaded/verified (if Carry = 0).

Pod $030D (781) masz X, a 782 - Y.

dekanex pisze: ↑

21 lut 2024, 22:40

radius75 pisze: ↑

21 lut 2024, 10:22

sys57812"$",8:poke147,0:poke780,0:poke781,0:poke782,16:sys65493

To jest najbardziej obiecujące, lecz potrzebna mi jeszcze informacja gdzie jest zapamiętywana ilość wczytanych danych lub ich końcowy adres?
Szukanie końca, to dla basica znowu powolne zadanie, więc nie tędy droga.

W tej chwili używasz GET# i pobierasz dane znak po znaku, weryfikujesz żeby odfiltrować i odczytać nazwy.
Skompilowanie tego z Basic na ML niewiele daje bo prędkość odczytu z napędu pozostaje raczej ta sama.
Jeśli załadujesz całe DIR do pamięci to będziesz pewnie używał PEEK żeby osiągnąć to samo.
To nadal może być sporym spowolnieniem.
Będziesz mógł przyspieszyć ten program kompilując go przez Blitz! czy inny kompiler. Ale nie ma gwarancji że po kompilacji taki program z Basic na ML będzie tak samo w stanie uruchomić zamontowany .d64

Użycie pliku SEQ pozwala ci pozostać przy Basic gdzie wiadomo że to już działa.
Dlatego zaproponowałem dwa programy, ten który ma utworzyć plik SEQ będzie działał najdłużej ze względu na to GET# i odczyt nazw z DIR.
Ale używasz go tylko wtedy gdy dodasz lub usuniesz d64 w tym folderze.
Mając już utworzony plik SEQ ten drugi program dosyć szybko wykona losowanie i odczyta całą nazwę przez INPUT# , nie będzie musiał odwoływać się do katalogu, tylko do przygotowanych danych.

Po dopracowaniu udało się w ten sposób: Na pewno nie jest to optymalne (ale działa w parę sekund), więc na razie tylko do testów. Jak znajde chwilę to spróbuje to dopieścić
Dzieki wszystkim a w szczególności radius75 za pomoc.

Super.
BTW, run w lini 190 jest zbędny. Basic sam przeskakuje do pierwszej linii po wykonaniu LOAD. A pierwszą linią będzie już wtedy pewnie jakiś SYS xxxx z załadowanego dema.

Pytanie pomocnicze. Jak najłatwiej/najszybciej ściągnąć z csdb wszystkie dema z top100?

Assembly 64

Znalazłem chwile czasu i zerknąłem na to.
Piękny kombajn
Mam dwa zastrzeżenia (pewnie czegoś nie wiem lub nie umiem)
1. Dlaczego niektóre kategorie są zablokowane ikonką kłódki i nie można ich zainstalować?
2. Jeśli zainstaluje taką którą się da, to robi niemalże to co potrzebuję czyli pobiera pliki z tej kategorii do odpowiedniego folderu. Niestety zapisuje je w formacie:
01. Tytuł1
02. Tytuł2
03. Tytuł3
i problemem są te kropki. SD2IEC interpretuje to chyba jako rozszerzenie i nie można tam przejść komendą CD
Musiałem hurtem pozmieniać nazwy katalogów i wtedy poszło. Co dziwne, jakieś menadżery plików pod c64 nie miały z tym problemów ale sama komenda CD której używam w programie nie jest w stanie przenieść mnie do katalogu z kropką.

Ktoś zna głębiej genezę tych problemów?

Znalazłem trochę czasu aby nad tym posiedzieć. Pierwszy problem nadal bez rozwiązania
Drugi okazał się prozaiczny i sprowadza się do dodania po komendzie CD dwukropka
CD: przechodzi do katalogu z kropką a CD nie.
Wyskoczył natomiast nowy problem który jest dla mnie dziwniejszy niż poprzednie.
Z racji wrodzonego lenistwa, aby nie wywoływać uruchamiania kolejnego dema przez wracanie do głównego katalogu, zapisałem sobie ten program na partycji flash SD2IEC pod nazwą "2" i elegancko uruchamiałem poleceniem ↑2:2
Oczywiście apetyt rośnie w miarę jedzenia i zechciałem pójść o krok dalej upraszając to jeszcze bardziej. Wymyśliłem sobie, że zrobię obraz do EasyFlash który po resecie załaduje mi ten program z partycji flash. Napisałem więc program i przeniosłem go na obraz EF. Program startuje, ładuje wskazany plik i tu zaczyna się problem, gdyż załadowany plik jest poucinany/uszkodzony
Zacząłem więc drążyć temat i doszedłem do wniosku, iż BASIC jakoś dziwnie ładuje inne programy w basicu. Przejdę od razu do sedna. Tworzymy dwa programy w BASIC zapisujemy na dysku pod nazwą "A"
zapisujemy na dysku pod nazwą "B"
Następnie przechodzimy do testów, czyli piszemy kolejne programy które załadują powyższe. zapisujemy jako "1"
zapisujemy jako "2"

Teraz ładując i uruchamiając program "1" wszystko jest ok. Program ładuje "A", uruchamia i jego listing jest taki jak zapisaliśmy.
Natomiast ładując i uruchamiając program "2" już nie jest tak słodko. Program ładuje "B" i uruchamia, lecz nic nie wyświetla gdyż jego listing zawiera tylko linię 10 (linia 20 znika) Gdy w ten sposób ładowałem swój program do uruchamiania dema to w nim z kolei pojawiały sie dodatkowe nieistniejące linie np 68 na których program się zatrzymywał. Co dziwne próba usunięcia tej lini zawiesza komputer

Co jest nie tak z programem "B" (i moim), że nie jest ładowany tak jak program "A"
Zaznaczam, iż do testów nie używałem żadnych modyfikacji komputera (c64 bez carta i vice w domyślnej konfiguracji)

Ładowanie programów z programu w BASICu może czasami przysparzać nie lada kłopotów (przez wskaźniki programu i zmiennych, dużo zależy też od tego czy ładujesz mniejszy program po większym czy na odwrót).

Ja generalnie używam jako panaceum na te rozterki następującego loadera: Powyższy kod najpierw czyści ekran i wypisuje LOAD"A",8 (chr$(34) wyświetla znak "). Następnie czyści bufor klawiatury oraz wpisuje do niego 6 klawiszy za pomocą READ/DATA. Na koniec NEW kasuje stary program i oddaje kontrolę BASIC-owi, a że mamy napisane LOAD"A",8 to wtedy wykonuje się te 6 klawiszy tj: klawisz Home by przejść do pierwszej linii, następnie klawisz Return sprawia, że program się wczytuje. Po READY. w buforze jest jeszcze RUN i Return co uruchamia nowy program.
Jedyny minus to kasowanie zmiennych (ja to omijam w moim systemie poprzez zapisywanie ważnych zmiennych w "Rejestrze systemu", który jest umiejscowiony w buforze Datasette - tam jest dość dużo miejsca, bądź w plikach SEO).

Napisz czy to ci pomogło

W vice działa
Wieczorkiem sprawdzę na prawdziwym sprzęcie
Trochę zmieniłem kod bo nie mieścił się w linii i dodałem detekcję nr napęduDzięki wielkie

No i na prawdziwym sprzęcie też działa elegancko.

Szczyt lenistwa osiągnięty
Naciskam reset i za chwilę oglądam losowe demo. Jak się skończy lub mi się znudzi to reset i kolejne.

Dziekuje wszystkim za pomoc w osiągnięciu tego "szczytu".