Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Outline 2025 - invitro na Atari ST Paradox i Havoc/Lineout wydali invitro na Outline 2025 dla Atari STf z 1 MB RAM.
Nowe postacie w Street Fighter 2 Vega dodaje kolejne postacie do portu SF2 na Atari 8-bit. Zobacz nowy film z rozgrywką.
ATasm v1.30 ATasm v1.30 to assembler dla procesora 6502 działający z poziomu wiersza poleceń, zgodny z oryginalnym Mac/65 od OSS.
ugBASIC v1.17.2 Wszechstronny język programowania BASIC oraz cross-kompilator pozwalający na tworzenie programów na różne platformy 8-bitowe
Zapraszamy do artykułów na atari.area! Szukasz różnorodnych materiałów na temat Atari? Koniecznie odwiedź dział artykułów.
atari.area forum » Posty przez mono
A nie o DACe mi chodzi - chodzi mi o syntezę FM.
Edit: A konkretnie o modulacje: http://amigadev.elowar.com/read/ADCD_2. … e0012.html (nie wiem czemu zawsze myślałem, że Paula ma w sobie kawałek syntezatora FM). Czy te możliwości były dostępne w jakimkolwiek oprogramowaniu na A=?
A czy ktoś przyglądał się może możliwościom syntezy dźwięku przez Paulę? Mam mgliste wrażenie, że blisko jej do SID-a...
W Atari nie ma alta i A= :) Lepszy do porównań wizualnych byłby model 1200XL.
Oczywiście. Polecam SDX manual rozdziały "6.3.6: Set File Position - POINT" s. 150 oraz "6.3.7: Get Current File Position - NOTE" s. 152.
mono napisał/a:upraszcza to w niektórych sytuacjach sposób adresowania choć marnują się cenne komórki RAM
Upraszcza nawet znacznie: można zapisać cień i odpowiedni rejestr sprzętowy przy użyciu tego samego podprogramu.
Prawda. Można też np.
icl 'vbxefx.icl'
VBXEBASE smb 'VBXEBASE'
VBXEFXS smb 'VBXEFXS'
lda VBXEBASE+COLDETECT
...
...
sta VBXEFXS+VIDEO_CONTROL
sta VBXEBASE+VIDEO_CONTROLlub też
icl 'vbxefx.icl'
VBXEBASE smb 'VBXEBASE'
VBXEFXS smb 'VBXEFXS'
org $80
vbxead .ds 2
fxsad .ds 2
vbxebase .word VBXEBASE
vbxefxs .word VBXEFXS
ldx vbxebase
ldy vbxebase+1
stx vbxead
sty vbxead+1
ldx vbxefxs
ldy vbxefxs+1
stx fxsad
sty fxsad+1
...
ldy #COLDETECT
lda (vbxead),y
...
...
ldy #VIDEO_CONTROL
sta (fxsad),y
sta (vbxead),yDrac030 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 ;$D20EDzię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 bajty32 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_CONTROLlub 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),yi nie muszą bawić się w samodzielną detekcję - w CONFIG.SYS należy tylko załadować odpowiednie drivery:
DEVICE VBXE
DEVICE VBXEFXSi 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.
Tak. Wersja 1.10 jest dostępna do ściągnięcia. Usunąłem support dla _RAWCON, bo support dla FXS jest w zupełności wystarczający do poprawnego działania z VBXE. Wieszać się już nie powinno.
Ponadto ponowne załadowanie plemnika umożliwia wyświetlenie aktualnie ustawionego czasu, po którym plemnik się uaktywnia, a dodatkowe podanie parametru "/D sec" pozwala zmienić ten czas w już zainstalowanym wygaszaczu.
Dzięki Draco!
Edit: Zapomniałem - plemnik nabrał nieco wyrazu, bo wykorzystałem tryb 15 ANTIC-a (8 OS) z włączonym GTIA i VSCROLL (dzięki czemu zrobił się tryb o rozmiarze piksela 4x9). Przedtem wykorzystany był tryb 13 ANTIC-a (7 OS) co powodowało, że jasności były nieco przyciemnione (taki defekt na linii ANTIC-GTIA). Poza tym gad łazi teraz po szerokim ekranie.
Jeśli dostępne jest urządzenie _RAWCON, wtedy plemnik na każdym VBLKD odwołuje się do RC_SHUTOFF lub RC_ACTIVATE zależnie od tego czy ma się on pokazać czy nie. Implementacja S2: zapisuje tam odpowiednią daną do VIDEO_CONTROL: 0 jeśli VBXE ma być wyłączone (czyli kiedy plemnik ma się pokazać), inną wartość kiedy VBXE ma być włączone (czyli kiedy plemnik nie ma być widoczny). Ponieważ dzieje się to co każdą ramkę to nie ma możliwości żebym zapomniał wyłączyć/włączyć VBXE bo robi to driver _RAWCON. Ta procedura dzieje się od chwili zainstalowania plemnika do końca świata.
Kiedy nie ma _RAWCON nie dotykam w ogóle VBXE.
sidplay nie dotyka w ogóle VBXE (psgplay również, a i neoplay też tego robił nie będzie) a to z tego powodu, że wyszedłem z założenia że jeśli się da to lepiej zostawić ekran użytkownikowi. VBXE nie zabiera czasu procesorowi więc wyświetlanie jego obrazu nie jest blokowane - blokowany jest tylko ANTIC. Jeśli odpalasz ekran 40-znakowy generowany przez ANTIC, no to on zniknie. A skoro pojawia się tam ekran VBXE, to prawdopodobnie znaczy że S2: coś nie tenteges.
Świetne! A ja polecam sikorowe "Prima Aprilis Compo" :)
- edycje 2007 i 2010: http://www.atari.org.pl/forum/viewtopic.php?id=4872
- edycja 2011: http://www.atari.org.pl/forum/viewtopic.php?id=8666
- edycja 2014: http://www.atari.org.pl/forum/viewtopic.php?id=12110
Na potwierdzenie tezy, że w BASIC-u się da.
A 1 IV nieubłaganie się zbliża ;]
Wielkie dzięki - porządny raport. SC dość intensywnie pracuje z dyskiem przy uruchamianiu aplikacji. Plemnior siedzi sobie w extramie i operuje w przerwaniach. Możliwe, że to szkodzi. Zmierzymy się z problemem i poinformujemy :)
@pin: A czy ty przypadkiem używasz starego DracOS-a?
A wszelkie podobieństwo do postaci realnych jest czysto przypadkowe i niezamierzone.
A u mnie poszło. Trzeba było tylko zmienić nazwę na WORM.SYS i odpalać np. przez
DEVICE WORM /D 60 /FMa, tylko trzeba trafić :P
Całkiem fajny pomysł, ale chyba na zupełnie nowy projekt. Powiem może jaki jest pomysł na mój wygaszacz i czemu powstał.
Pierwowzorem jest plemnik JBWa pod DOS-a (pecetowego). Widziałem go w redakcji Tajemnica Atari i tak mi się spodobał, że pomyślałem że może da się coś podobnego zrobić na Atari.
Wygaszacz ekranu na Atari (nie widziałem czegoś takiego w systemach na inne platformy 8-bit) ma za zadanie doprowadzać do równomiernego wypalania luminoforu telewizora w przypadku kiedy na dłużej nie dotykamy komputera i na monitorze znajduje się ciągle ten sam obraz (widziałem kiedyś zezłomowany monitor jakiegoś pecetowego terminala, na którym widniał pięknie wypalony prompt :]). Dlatego w systemie została przewidziana procedura, która po upływie ok 11 minut (256*128 ramek) odwraca cyklicznie kolory. Odbywa się to na przerwaniu VBLKI. Zaletą takiego podejścia do rzeczy jest to, że system nie zajmuje czasu procesora jakimiś czasochłonnymi działaniami dzięki czemu program użytkownika, który się w międzyczasie wykonuje, ma dla siebie praktycznie całą moc CPU.
Plemnik powstał z inspiracji i ze znurzenia systemowym trybem przyciągania uwagi. Stwierdziłem też że fajnie by było, gdyby nie trzeba było na niego czekać 11 minut, ale powiedzmy 3 (i taki właśnie był czas jego aktywacji w opublikowanej w TA wersji - taki czas zresztą jest nadal ustawiony domyślnie, choć w wersji dla SDX doszła parametryzacja). Miał za zadanie malować coś ciekawszego na ekranie nie obciążając zbytnio procesora tak, żeby program działający na komputerze nadal miał maksimum mocy obliczeniowej. Udało się to zrealizować w ten sposób, że cała procedura wygaszacza działa na dwóch przerwaniach: VBLKI mierzy jak dotąd czas bezczynności i ustawia krótszy czas oczekiwania przy opuszczeniu trybu, a na VBLKD realizowana jest procedura włączenia własnego ekranu ANTICa i skonfigurowanie GTIA tak, żeby pokazywał obraz z plemnikiem. Rysowany jest oczywiście tylko obraz składający się z 5 wierszy ekranu - reszta to puste linie dzięki czemu ANTIC przez większość czasu rysowania ekranu nie blokuje CPU. Ustawiane są wyłącznie rejestry sprzętowe dzięki czemu działanie plemnika jest niezauważalne dla pozostałych elementów systemu.
Twoje idea wygaszacza polegająca na uruchomieniu programu, który zajmie całkowicie procesor (mamy system jednozadaniowy) nasuwa mi na myśl program również autorstwa JBW, mianowicie XL Friend (popularnie zwany XLF a wchodzący w skład pakietu Quick Assemblera). XLF czekał na wciśnięcie klawisza SHIFT+CONTROL+1/2/3/4, zamrażał stan systemu i uruchamiał program przypisany do odpowiedniej kombinacji klawiszy - edytor, mapę znaków, kalkulator lub wglądownicę. Po skorzystaniu z programu stan systemu był odtwarzany i procesor wracał do wykonywania programu użytkownika. O ile XLF był bardzo przydatny i używałem go z DOS 2.5 i QA na porządku dziennym, o tyle wygaszacz ekranu zrealizowany w ten sposób (aktywowałby się oczywiście automatycznie po upływie wymaganego czasu bezczynności) zabierałby czas programowi użytkownika nie robiąc jednak nic konstruktywnego. No chyba, że zamierzasz wspomóc projekt SETI :) albo innego raka.
Nie zniechęcam jednak i gdybyś chciał coś takiego sam napisać służę pomocą.
@Yansen: A co taki loader miałby robić?:
- Instalować wygaszacz w systemie (różne rodzaje pamięci)? Robi to sama SDX.
- Podpinać go na VBLK(I/D), DLI, IRQ? To zależy od samego wygaszacza.
Mógłby uaktywniać i dezaktywować wygaszacz, ale to jest raptem kilka linijek kodu...
Też tak myślę.
Edit: Tym bardziej, że programowanie 816 to jak programowanie 6502C z nielegalami - nowy zestaw instrukcji i nowe możliwości do wykorzystania :]
Byłoby. Obecnie 286 bajtów zajmuje dlist i ekran. Kod w pamięci bazowej to 98 bajtów, w pamięci dodatkowej 313. DLPTR ma rejestr cień, GTIACTL i DMACTL też.
Gdyby wykorzystać sprajty pojawia się problem odtwarzania wartości rejestrów GTIA bo nie mają cieni w systemie dzięki czemu może to kolidować z innymi programami (wygaszacz działa przecież niejako "w tle"). Poza tym wygaszacz ma wygaszać obraz :) a nie malować niewiadomoco :] Obszar sprajtów w najmniejszej konfiguracji to $280 bajtów, które powinny być w podstawowym RAMie (ext nie da się użyć bo RAMBO nie pozwala na oddzielne adresowanie ANTICa i CPU, poza tym nie można zagwarantować, że na całym ekranie będzie włączony odpowiedni bank pamięci). Można zapisywać GRAFPx/M ręcznie, ale trzeba synchronizować się z rastrem co zabierze czas CPU. Jeśli użyjesz DLI, to trzeba analizować displaylistę i ją odpowiednio modyfikować. Same problemy.
Można zrobić wygaszacz dla VBXE - wtedy praktycznie cały kod może być ulokowany w pamięci VBXE (nie mówiąc o grafice).
Wersja 1.09 (.zip, .atr, .arc, .atr.bz2).
Dodałem obsługę sterowników _RAWCON (S_VBXE.SYS, RC_GR8.SYS) więc poprawnie działa już z VBXE.
Niedobry monitor, brzydki, tfu, tfu.
Ale to załaduje tylko jeden bajt, czy następne, w np. 130 XE też?
Podejrzewam, że dodatkową pamięć musisz sobie obsłużyć samodzielnie, aloader po prostu zawinie się wokół 64K i dalsze bajty będzie ładował od początku pamięci (ZPG).
Co kto lubi. O ile długość ma znaczenie :P
MyDłOS - czysta przyjemność.
atari.area forum » Posty przez mono
Wygenerowano w 0.112 sekund, wykonano 18 zapytań