No i potem pęla sprzężenia zwrotnego
"uruchom to w emulatorze i sprawdź czy działa"
Ładuję skill AltirraSDL, żeby uruchomić program przez AltirraBridge i zrobić zrzut ekranu.
● Skill(altirra-sdl-engineering)
Successfully loaded skill
Ran 4 shell commands
Uruchamiam emulator headless i piszę skrypt testowy: breakpoint na $2000, boot XEX, zaśmiecenie ekranu, zrzut "przed", wznowienie, zrzut "po" i sprawdzenie pamięci obrazu.
Read 1 file, ran 3 shell commands
● Background command "Run breakpoint-based clear-screen test for both XEX files in the emulator" failed with exit code 144
Ran 2 shell commands
Stary proces emulatora się zawiesił; ubijam oba i startuję na czysto.
Ran 3 shell commands
Klucz to PC wielkimi literami; breakpoint już trafił. Poprawiam skrypt i puszczam oba testy.
Read 2 files, ran 5 shell commands
Widzę, że zrzuty "po" pokazywały loader Altirry, bo program po RTS wraca do niego i podmienia display listę. Zmienię adres powrotu na stosie na pętlę jmp *, żeby wynik został widoczny na ekranie.
Read 2 files, ran 2 shell commands
Oba programy działają poprawnie w emulatorze AltirraSDL (headless, przez AltirraBridge). Zrzuty ekranu leżą w /tmp/ll/cls/ jako przed.png, po_cio.png i po_fast.png.
Jak testowałem. Breakpoint na $2000, boot pliku XEX, a po zatrzymaniu wypełniłem całe 960 bajtów pamięci obrazu (pod adresem z SAVMSC, czyli $BC40) znakami i inwersami, zrobiłem zrzut, potem wznowiłem program i zrzuciłem pamięć obrazu oraz ekran ponownie. Adres powrotu na stosie podmieniłem na pętlę w nieskończoność, bo inaczej po RTS loader Altirry wstawia własną display listę i zrzut "po" pokazywał ekran loadera, a nie efekt programu.
Wyniki:
┌──────────────┬────────────────────────┬──────────────────────────┬───────────────────────────────┐
│ Program │ Przed │ Po │ Pamięć poniżej/powyżej ekranu │
├──────────────┼────────────────────────┼──────────────────────────┼───────────────────────────────┤
│ cls_cio.xex │ 960 bajtów niezerowych │ 1 bajt: $80 na pozycji 2 │ nietknięta │
├──────────────┼────────────────────────┼──────────────────────────┼───────────────────────────────┤
│ cls_fast.xex │ 960 bajtów niezerowych │ 0 bajtów niezerowych │ nietknięta │
└──────────────┴────────────────────────┴──────────────────────────┴───────────────────────────────┘
- Wersja CIO czyści ekran i zostawia kursor OS-u w wierszu 0, kolumna 2. Ten jeden bajt $80 to właśnie kursor edytora E: na lewym marginesie (LMARGN = 2). To jest poprawne i oczekiwane zachowanie polecenia CLEAR, na zrzucie widać niebieski ekran z kursorem w lewym górnym rogu.
- Wersja szybka zeruje dokładnie 960 bajtów i ani bajtu więcej. Na zrzucie jest czysty niebieski ekran bez kursora, bo ta wersja nie przechodzi przez OS.
Dwie rzeczy, na które natknąłem się po drodze w samym mostku, żebyś wiedział na przyszłość: po trafieniu breakpointu komenda FRAME blokuje się na zawsze, więc trzeba odpytywać REGS z opóźnieniem zamiast stepować klatkami, a słownik z REGS ma klucze wielkimi literami (PC, nie pc).