Pozwolę sobie zaproponować dokonanie następującego zabiegu na procedurze deinicjowania VBXE:

; Disable VBXE display
reset_vbxe
    ldy    #$5d    ; MEMB
    mva    #0    (fx_ptr),y
    ldy    #$40    ; VIDEO_CONTROL
    mva    #0    (fx_ptr),y
;    mva    #$22    $22f    ; normal screen
;    mva    save_colbak    $2c8

    ldx #$00
    lda #$0c
    jsr xcio

    lda #<ename
    sta $0344,x
    lda #>ename
    sta $0344+1,x
    lda #$0c
    sta $034a,x
    lda #$00
    sta $034b,x
    lda #$03
xcio    sta $0342,x
    jmp $e456

ename    .byte 'E:',$9b 

Program wtedy wychodzi gładko do trybu konsoli niezależnie od tego, jaki on (ten tryb konsoli) był w czasie uruchamiania.

Składnia MADS (MAC/65).

Fox, masz rację, przy wybraniu konfiguracji 64k program działa. Więcej powiem, przy wybraniu konfiguracji sprzętowej z dowolną ilością pamięci Ext, ale wymuszeniu konfiguracji SpartaDOS X takiej, żeby DOS załadował się pod ROM, program również działa. Zatem mamy pewnie do czynienia z konfliktem pomiędzy VRAM-em (pamięcią VBXE) a pamięcią Ext (na PORTB). Nie zbadałem jeszcze, co Twój program robi, ale załadowanie danych wprost z pliku do pamięci VBXE pod SpartaDOS X nie jest możliwe ze względu na wyżej wspomniany konflikt i chwilowo podejrzewam, że to może być przyczyną (SDX nie ma wiedzy o pamięci VBXE, więc nie wie, że jest ona np. w danej chwili podłączona, i nie wie też, że dostęp do pamięci kontrolowanej przez PORTB jest w danym momencie zablokowany sprzętowo).

Może czegoś nie wiem, ale runext ma jakieś ograniczenia? Bufor na definicje jest chyba tylko ograniczony ilością dostępnej pamięci: kiedy się wyleje z ext, od razu to będzie widoczne, bo memlo poleci wysoko do góry i większość programów przestanie działać :)

Przeglądarkę odpalę w domu, ale wygląda obiecująco.

Tak ogólnie przeczuwałbym, że mapa pamięci + wskaźniki powinny dać radę :)

To nie skrypt lecz program w asemblerze. Na filmie możesz go zaobserwować w działaniu, bo wmontowałem go do mojego emulca ZX Spectrum.

Natomiast jeśli chodzi o oddzielny player, jeszcze się rodzi :) Na pewno efekt emulacji AY na takowym byłby dużo lepszy zresztą, bo można wtedy przeznaczyć cały czas CPU na granie, a nie tylko parę linii skaningowych na ramkę. Mgliście przypominam sobie również, że ktoś oferował się podesłać jakieś ciekawe utwory na AY/YM w postaci plików zawierających strumień wartości rejestrów (jak *.PSG), ale dotąd niczego takiego nie dostałem.

Przy przeglądaniu paczki voya (raczej pod kątem tego, co nie działa), znalazłem kawałek na AY, który nieźle brzmi na Pokeyu:

https://youtu.be/3fFgO1lssns

Tak po prawdzie, wyrabia się to nawet na 3,54 MHz (na 1,77 już niestety nie wchodzi w ramkę, a szkoda).

PS. Fajna, komiksowa kreska na grafice.

PS.2. Zerknąłem tez na samą gierkę. Chodzi w niej o to, że wąż ma zjeść jabłko i nie zabić się przy tym. :)

@pasiu: po namyśle dochodzę do wniosku, że chwilowo bez takiego licznika można się obyć, skoro zapis/odczyt rejestrów I/O synchronizuje CPU do zegara 1,77 MHz (taki wsync, tylko z większą granulacją).

Natomiast coś w rodzaju koproca robiącego 32-bitowe mnożenie/dzielenie fixed point w parę cykli to nadal byłaby fajna rzecz, myślę :)

@tebe: a gdyby użyć STA w trybie adresowania zp zamiast abs, nie zwiększyłoby to częstości zmian koloru w linii? Bo rejestry GTIA można zapisywać przez STA zp, wystarczy tylko wcześniej ustawić rej. D na $D000 (lda #$d000 / tcd albo pea $d000 / pld).

Z tego, co pamiętam, próbowałem Autora na taki rejestr namówić, ale jakoś bez powodzenia. Można próbować użyć timerów Pokeya, rzecz w tym, że są mało precyzyjne (1 cykl pracy Pokeya = 11,277478987237277030143573584987 cykli pracy CPU Rapidusa).

Część ułamkowa w powyższym nawiasie sygnalizuje, że ułożenie się jednego zegara względem drugiego może być mało deterministyczne. To czyni cyklowanie trudnym nawet w sytuacji, kiedy wszystkie Rapidusy pracują z zegarem 20 MHz (dla rozwiania wątpliwości: karty produkcyjne działają na 20 MHz, 16 MHz miały tylko starsze prototypy).

Włącza się przez INI.

Muszę (i chętnie to robię) dodać, że widniejący na filmie układ kolorów dla SC został wynaleziony przez Pinokia(tm).

Pewnie się nie znam, ale należałoby chyba te testy zrobić na PAL-u. Bo rozwinięcie skrótu NTSC chyba wszyscy znają: Never The Same Colour ...

Jeśli dostajesz się do SIDE nie przez PBI BIOS, to znaczy, że używasz sterownika SIDE.SYS i to pewnie on jest winien (brak protokołu adresowania sektorów powyżej 65535).