Drac030 w wątku obok wspomniał o FXS. Opiszę może ocb i po co to wszystko.
Większość rejestrów VBXE to rejestry dostępne tylko do zapisu. Ich wadą jest to, że nie ma żadnej możliwości odczytu wartości z takiego rejestru (np. VIDEO_CONTROL=$D640 lub XDL_ADR=$D641..3). Często pod jednym adresem znajdują się tak naprawdę dwa rejestry sprzętowe - jeden tylko do zapisu (np. IRQ_CONTROL=$D654) i jeden tylko do odczytu (IRQ_STATUS=$D654).
W oryginalnym hardwarze Atari sytuacja jest identyczna i poradzono sobie z problemem w ten sposób, że wprowadzono tzw. rejestry-cienie (ang. shadow registers) - przykładowo IRQEN=$D20E ma swój cień w IRQENS=$10. Zasada jest taka, że chcąc zapisać coś do rejestru sprzętowego programista jest zobowiązany do zapisu również rejestru-cienia, tak więc chcąc odblokować przerwanie TIMER1 POKEY-a robimy:
lda #%00000001
ora IRQENS ;$10
sta IRQENS ;$10
sta IRQEN ;$D20E
Dzięki temu pozostałe elementy systemu (np. procedura detekcji źródła IRQ) wiedzą co w rejestrze IRQEN zostało faktycznie ustawione. Analogicznie np. w ANTIC-u DLPTR=$D402..3 ma swój cień w DLPTRS=$230..1, DMACTL=$D400 ma cień w DMACTLS=$22F, w GTIA GTIACTL=$D01B ma cień w GTIACTLS=$26F, itd. Niestety nie wszystkie rejestry w hardwarze mają swoje odpowiedniki i dotkliwie można to odczuć np. na NMIEN=$D40E, czy większości rejestrów GTIA.
Oczywiście jeśli pisze się program przejmujący kontrolę nad światem problem jest marginalny i w razie potrzeby taki cień można sobie samemu w kodzie zorganizować, ale jeśli chciałoby się napisać jakiś programik rozszerzający możliwości OS-a, zainstalować TSR-a w systemie i wrócić do shella, wtedy niestety krótkowzroczność projektantów systemu daje popalić.
Zrobiłem więc sterownik dla SDX, który wydziela 40-bajtowy obszar w pamięci RAM przeznaczony właśnie na cienie dla rejestrów VBXE. Obszar ten dostępny jest przez symbol VBXEFXS i wygląda tak:
OFFSET NAZWA TYP OPIS
$00: VIDEO_CONTROL byte : kontrola video
$01: XDL_ADR long : adres listy wyświetlania
$04: CSEL byte : wybór koloru w palecie
$05: PSEL byte : wybór palety
$06: CR byte : składowa R
$07: CG byte : składowa G
$08: CB byte : składowa B
$09: COLMASK byte : maska dla kolizji
$0A: COLCLR byte : reset kolizji
$0B: - byte : zarezerwowane
$0C: - byte : zarezerwowane
$0D: - byte : zarezerwowane
$0E: - byte : zarezerwowane
$0F: - byte : zarezerwowane
$10: BL_ADR long : adres programu blittera
$13: BLITTER_START byte : start blittera
$14: IRQ_CONTROL byte : kontrola przerwań IRQ
$15: P0 byte : priorytet overlay/playfield 0
$16: P1 byte : priorytet overlay/playfield 1
$17: P2 byte : priorytet overlay/playfield 2
$18: P3 byte : priorytet overlay/playfield 3
$19: - byte : zarezerwowane
$1A: - byte : zarezerwowane
$1B: - byte : zarezerwowane
$1C: - byte : zarezerwowane
$1D: MEMAC_B_CONTROL byte : kontrola okna MEMACB
$1E: MEMAC_CONTROL byte : kontrola okna MEMACA
$1F: MEMAC_BANK_SEL byte : wybór banku MEMACA
$20: VBLIT word : wektor przerwania blittera
$22: VMEMLO long : pierwszy dostępny adres VRAM
$25: VMEMHI long : ostatni dostępny adres VRAM
Oznaczenia:
- byte - 1 bajt
- word - 2 bajty
- long - 3 bajty
32 pierwsze bajty to cienie dla sprzętu (dla wygody offsety cieni są identyczne, jak rejestrów sprzętowych - upraszcza to w niektórych sytuacjach sposób adresowania choć marnują się cenne komórki RAM), prócz tego dodatkowo zdefiniowane są:
- VBLIT - wektor obsługi przerwania od blittera VBXE. Procedura detekcji włączona jest w ciąg obsługi przerwań IRQ na najwyższym priorytecie (ograniczenie OS-a) i testuje IRQ_STATUS bazując na ustawieniu cienia IRQ_CONTROL, potwierdza jego przyjęcie po czym przekazuje sterowanie do procedury obsługi użytkownika wektoryzowanej przez VBLIT. Procedura użytkownika powinna na końcu wykonać PLA, RTI (jak większość innych przerwań IRQ).
- VMEMLO - wskazuje najmniejszy dostępny wolny adres VRAM,
- VMEMHI - wskazuje największy dostępny wolny adres VRAM. Jej początkowa wartość zależy od tego jaki rdzeń mamy włączony - z emulacją RAMBO czy bez.
Z tego właśnie sterownika (w starszej wersji) korzysta np. Tomek-8 demo dla VBXE.
Wymaganiem do działania FXS jest obecność w systemie symbolu VBXEBASE, który jest instalowany przez sterownik VBXE.SYS. Podejmuje on detekcję karty VBXE, wyświetla informacje o rdzeniu, wersji i obecności emulowanego rozszerzenia RAMBO i zostawia w pamięci tylko symbol VBXEBASE wskazujący na adres rejestrów sprzętowych karty (czyli $D640 lub $D740).
Dzięki temu programy pisane dla SDX mogą po prostu odwoływać się do żądanych zasobów za pośrednictwem symboli
icl 'vbxefx.icl'
VBXEBASE smb 'VBXEBASE'
lda VBXEBASE+COLDETECT
...
...
sta VBXEBASE+VIDEO_CONTROL
lub też
icl 'vbxefx.icl'
VBXEBASE smb 'VBXEBASE'
org $80
vbxead .ds 2
vbxebase .word VBXEBASE
ldx vbxebase
ldy vbxebase+1
stx vbxead
sty vbxead+1
...
ldy #COLDETECT
lda (vbxead),y
...
...
ldy #VIDEO_CONTROL
sta (vbxead),y
i nie muszą bawić się w samodzielną detekcję - w CONFIG.SYS należy tylko załadować odpowiednie drivery:
DEVICE VBXE
DEVICE VBXEFXS
i Wioletta. Analogicznie rzecz się ma z rejestrami-cieniami (odpowiedni .icl w załączniku).
UWAGA! Załadowanie sterownika S2: czyli S_VBXE.SYS powoduje, że nie jest wymagane ładowanie dwóch poprzednich (VBXE.SYS, VBXEFXS.SYS), bo odpowiednia funkcjonalność została tam przez Drac030 zaimplementowana.
Dodatkową zaletą jest również to, że S2: prócz wielu funkcji jak zarządzanie paletami kolorów, obsługa dodatkowych trybów graficznych i tekstowych czy operacje rysowania punktu, linii i okręgu posiada również mechanizmy zarządzania pamięcią VRAM dzięki czemu wskaźniki VMEMLO i VMEMHI będą wskazywać zawsze aktualny stan (sam VBXEFXS.SYS takich mechanizmów nie zawiera więc tylko inicjalizuje odpowiednio wskaźniki podczas procedury RESET).
Opisane sterowniki będą włączone do następnej dystrybucji SDX (4.47).
Gdyby ktoś chciał się pobawić cieniami załączam sterowniki, manuale i pliki do zainkludowania do madsa.