Trafiłeś w sedno (zresztą, nie pierwszy raz).

Atarka z Rapidusem pod względem fajności zjada ST na śniadanie. ;) Motorola 68k ma swoje zalety i przewagi (np. rozkazy mnożenia i dzielenia, wizjonerska architektura itp.), ale 65C816, mimo że o generację starszy, jest po prostu fajniejszy.

PS. Nie to ładne, co ładne, tylko co się komu podoba.

Trzeba sobie na te bolączki skopiować z Toolkita program XVER.COM, wrzucić do $PATH, a potem, w razie rozterek, uruchamiać. :)

A, fakt. Poplątałem wątki :)

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).