LOADER "ukryty" BAS pytanie jak edytować? :-)

[michalh]

Ładuję sobie na ZX Spectrum +3 loader PACMANIA by spróbować przerobić to na nazwy konkretnych plików na dyskietkę CF2 jak wcześniej udało się z BOMB JACK.
( https://www.speccy.pl/forum/index.php?topic=732.msg105586#msg105586 )
Ale mam tu taki "zaszyfrowany" kod w linii 2,
myślałem, że sprytnie to zapiszę na esxDOS na SD i podejrzę, ale tu z kolei jest to "spakowane" jako "PLUS3DOS..."

Jak się dawniej wchodziło w taką "ukrytą" edycję na Spectrum ? 
Wejście w Basic 48k linię 2 ciemność widzę.
A wchodzenie w +Basic, że może lepsza edycja... no cóż, tam chyba nie ma odczytu MERGE"" z TAPE Domaga się wtedy dyskietki w napędzie.

Albo jak przekonwertować na PC plik PLUS3DOS... z esxDOS na czytelny BAS i w drugą stronę?

[steev]

PLUS3DOS to nagłówek pliku.
Właściwy program znajduje się tuż za nim.

[michalh]

Ok, ale i tak nie jest to "czysty" basic

Na razie mam pewien postęp, przeniosłem loader z tape na dyskietkę (programikiem Tapedisc.tzx) i w +3 BASIC widać to sensowniej, chociaż nadal nic z tego co widzę nie rozumiem, chyba tego loadera łatwo nie "shakuję" na CF2, żadnego jawnego LOAD"" :-)

[steev]

Przypuszczam, że pierwsza linia zawiera kod maszynowy loadera.
Disassembler w dłoń, sprawdź co to to robi, może się uda zamienić na LOAD*

[michalh]

Ok, trafiłem na zwykły loader w pliku DSK :-)
https://worldofspectrum.org/archive/software/games/pac-mania-grandslam-entertainments-ltd
Widać to co wcześniej miałem to tych wersji jest tyle przerobionych, że szkoda studiować co autor miał na myśli :-)

W zasadzie to też zamyka temat robienia dyskietek CF2 z menu na kilka gier, jedzie już do mnie emulator FDD CF2 Zaxona - mam nadzieję nie spalę, kable do DISK B: zamówione i ruszy produkcja gier na dyskietkach ;-)

[Thompson]

Linia BASICa z "wszczepionym" asemblerem nie jest bezpośrednio edytowalna. Zwykle robi się ją tak:

Kod: [Zaznacz]

10 REM xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxi tyle 'x' ile potrzeba by zmieścić kod maszynowy loadera, czy tego co tam ktoś sobie zamierzył. Sam kod przepisuje się (albo basikiem, albo asemblerem) do pamięci bezpośrednio po słowie kluczowym REM w miejsce iksów, bazując na znajomości mapy pamięci Spectrum, w szczególności gdzie zaczyna się w pamięci program w BASICu i ile miejsca potrzeba  na numer linii i słowo kluczowe REM. Stąd biorą się potem "krzaczki" przy wyświetlaniu takiego kodu z BASICu.
Z kolei co robi kod schowany po REMie, to już zależy od fantazji twórców. Może to być fajny efekt, może być loader. Na pewno to nie jest jakiś skomplikowany programik, bo Spectrum ma ograniczenie na długość linii kodu w BASICu, więc za wiele nie da się tu zmieścić (choć można się pobawić w kod asemblera rozłożony na kilka linii kodu w BASICu, co czasami się zdarzało).

[michalh]

Dzięki za wyjaśnienie, przymierzę się do Asemblera również 

[matofesi]

Na pewno to nie jest jakiś skomplikowany programik, bo Spectrum ma ograniczenie na długość linii kodu w BASICu, więc za wiele nie da się tu zmieścić

A możesz to rozwinąć? Skąd niby to ograniczenie? Poza - oczywiście - niemożnością wpisania z ręki linii dłuższej niż jeden (niecały) ekran?

Pomijam oczywiście sensowność umieszczania w taki sposób większego kodu - musi być relokowalny i ma jeszcze trochę innych ograniczeń, ale skąd ograniczenie długości?

[ZorrO]

Na CPC też sie podobne cuda robi, w dowolnej linii po apostrofie który działa jak REM, za pomocą POKE wstawia sie kod zero co sprawi że reszta linii z kaszanką nie będzie wyświetlona przy listowaniu. Widziałem też program z kodem w ostatniej linii. Jej numer zmieniono na 0 przez co nawet nr linii nie jest listowany, i choć edytor nie pozwala na tworzenie dłuższej linii Basica niż 255, to w pamięci jej długość jest zapisywana dwoma bajtami więc POKE może ją dowolnie wydłużyć, potem zapisać na dysku a dopiero edytorem dyskowym zmienić jej nr na 0, bo jeśli będzie taki przed komendą SAVE to tej linii z kodem nie zapisze. No i biada jeśli zmienisz długość którejkolwiek wcześniejszej linii to nawet jeśli kod jest relokowalny to początek kodu sie przesunie i wszystkie adresy w nim też. Więc takie rzeczy robi sie raczej w skończonym programie.

[steev]

Na pewno to nie jest jakiś skomplikowany programik, bo Spectrum ma ograniczenie na długość linii kodu w BASICu, więc za wiele nie da się tu zmieścić

A możesz to rozwinąć? Skąd niby to ograniczenie? Poza - oczywiście - niemożnością wpisania z ręki linii dłuższej niż jeden (niecały) ekran?

Pomijam oczywiście sensowność umieszczania w taki sposób większego kodu - musi być relokowalny i ma jeszcze trochę innych ograniczeń, ale skąd ograniczenie długości?

BASIC lines
Each BASIC line is stored as:

• 2 byte line number (in big-endian format)
• 2 byte length of text including NEWLINE (in little endian format, length "excludes" the line number and length, i.e. to skip between lines you add "length of text" +4 bytes.
• text (BASIC tokens)
• NEWLINE (0x76 on ZX80/81, 0x0D on Spectrum)

Czyli linia programu nie może przekroczyć, hmmm, 65531 bajtów?
Natomiast nie wiem czy nie ma jakichś ograniczeń w samym interpreterze...

[matofesi]

@steev Z czasów jak przeglądałem TCSRD nie przypominam sobie żadnych ograniczeń - jeśli siedzi w pamięci i jest poprawne to interpreter sobie poradzi. Zwłaszcza z REMem, bo to jest prosty search albo skip do następnej linii.

Teoretycznie można zrobić pewnie 40 kilo REMa i zapakować do niego np. grę plus kawałek kodu, który ustawi stos, przeniesie kod w docelowe miejsce i odpali. I masz wtedy grę w BASICu

[Thompson]

Na pewno to nie jest jakiś skomplikowany programik, bo Spectrum ma ograniczenie na długość linii kodu w BASICu, więc za wiele nie da się tu zmieścić

A możesz to rozwinąć? Skąd niby to ograniczenie? Poza - oczywiście - niemożnością wpisania z ręki linii dłuższej niż jeden (niecały) ekran?

Pomijam oczywiście sensowność umieszczania w taki sposób większego kodu - musi być relokowalny i ma jeszcze trochę innych ograniczeń, ale skąd ograniczenie długości?

Gwoli wyjaśnienia. Formalnie na wprowadzaną linię BASICa jest tyle miejsca ile jest bajtów między zmienną systemową E_LINE, a WORKSP -1 i tyle teoretycznie można wprowadzić z edytora. W praktyce edytor zatrzymuje się po 22 liniach znaków i więcej się nie da  wklepać z palca.

Grzebiąc w pamięci można pewnie skonstruować linię dłuższą, ale nie robiłem eksperymentów, czy interpreter nie robi wtedy jakiś problemów z takimi liniami.
Natomiast dwuliniowe wstawki po REM kiedyś spotkałem, robiły skok względny JR pod koniec linii.

[matofesi]

@Thompson No to ja ci mogę odpowiedzieć - BASICowi (czyli interpreterowi w ROMie) nie robi różnicy jaka długa jest linia jeśli tylko zachowane są wszystkie znaczniki itp. Możesz mieć dowolnej długości linię o ile jesteś w stanie ją "wygenerować" - kiedyś było to bardziej skomplikowane, dzisiaj możesz sobie taki kod wygenerować którymś z konwerterów z tekstu do np. programu w BASICu w TAPie.

[matofesi]

Tak dla testu zrobiłem coś takiego jak w załączniku... Manic Miner w BASICu

Kod gry to równe 32 kilo do tego kilkadziesiąt bajtów "startera" - musiałem tylko wyjaśnić zmakebas'owi, że ma używać bufora większego niż 512 bajtów i bez problemów skompilował stosowny plik z odpowiednią liczbą spacji. Potem tylko edytor binarny i copy-paste bloku binarnego. Potem już nie chciało mi się kombinować z sumami kontrolnymi w TAPie (bo oczywiście wyskakuje "tape loading error") więc po prostu save z emulatora i w załączniku właśnie wynik tego save'a

Oczywiście jakby się komuś chciało, to w prosty sposób da się tą procedurę zautomatyzować - zmakebas jest otwarty więc można mu dorobić wciąganie bloków binarnych prosto do REMa itp.

Ale ja chciałem tylko sprawdzić, czy to co pisałem wcześniej jest prawdą. Jest

edit : I jeszcze ciekawostka... takiego programu nie da się wczytać przez MERGE... Procedura dołączania nowego kodu wymaga odpowiedniej ilości miejsca, żeby zmieścił się stary i nowy program i tutaj oczywiście wyskakuje "Out of memory"