Przerwanie w trybie tekstowym wykonuje się w ostatniej linii wiersza.
"DLI wywołane od środka linii" to uproszczenie - procedura wywołuje się jak zawsze, ale na jej początku znajduje się opóźnienie.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Posty przez mono
Przerwanie w trybie tekstowym wykonuje się w ostatniej linii wiersza.
"DLI wywołane od środka linii" to uproszczenie - procedura wywołuje się jak zawsze, ale na jej początku znajduje się opóźnienie.
Nosty - musisz zrozumieć, jak sprajty są rysowane na ekranie, żeby je multiplikować. Właściwie całą zasadę da się ująć w kilku zdaniach:
1. GTIA decyduje NA BIEŻĄCO o narysowaniu sprajta na podstawie zawartości rejestru HPOSPx/Mx.
2. Odrysowanie zawartości sprajta następuje na podstawie zawartości rejestru GRAFPx/M, SIZEPx/M, COLPMx, GTIACTL (priorytet).
3. Rejestr GRAFPx/Mx może być wypełniany przez DMA raz na linię (jest to dyktowane specyfiką pracy ANTICa) jeśli jest włączone w DMACTL (VBLKD przepisuje tam wartość z DMACTLS oczywiście jeśli jest włączone) - dane są pobierane z pamięci odpowiednio do stanu rejestrów PMBASE i VDELAY oraz rozdzielczości liniowej ustawionej w DMACTL.
Nikt nie zabrania zapisywania dowolnego rejestru GTIA w dowolnym czasie. Z ANTICem jest nieco inaczej - rejestry możesz zapisywać dowolnie, ale on sam pobiera dane w określonych chwilach.
Widoczność sprajtów na ekranie jest konfigurowana za pomocą PMCNTL.
Najprostsza multiplikacja sprajta wymaga jedynie szybkiej zmiany rejestru HPOSPx/Mx. Jeśli chcesz mieć inną treść to musisz zapisać GRAFPx/M, jeśli rozmiar to SIZEPx/M, kolor to COLPMx, itd.
Pożegnaj się z jakimikolwiek manipulacjami w pierwszej (lub ostatniej? - nie pamiętam) linii każdego wiersza trybu tekstowego, bo ANTIC bierze wtedy dane pamięci ekranu i kształtu sprajtów do bufora. W trybach graficznych tego problemu nie ma.
Edit: Drobiazgi.
Ej, Sikor! Poczekaj z koronacją aż ankieta się zakończy. Albo osiągniesz przynajmniej progonozowany sukces.
Dziękuję - dotarło.
No ja chętnie wezmę te, co zamawiałem - czyli L i S.
Potestowałem nieco PCLinka na SDX 4.43RC2. No i muszę powiedzieć, że przy ustawionym HSINDEX=3 (a jest to najszybszy, jaki aktualnie działa z SDX) NEOPLAY załadował mi JSETNEO (90kb) w 10s, a GEBOFONa w 40s (250kb). Wszystkiemu towarzyszył wysoki gwizd. Jeśli ktoś nie ma IDEA/KMK, to można to śmiało polecić PCLINKa do użytkowania :)
Note: Eksperymentalnie do SIO2BSD zostało wprowadzone ustawienie prędkości transmisji za pomocą HSINDEX (wartość wpisywana w Atari do POKEYa). Aby to uruchomić należy ustawić parametr -b 0 i podać -i HSINDEX (w tym przypadku 3 - taka wartość brana jest zresztą domyślnie):
$ sio2bsd -b 0 -i 3 ./pcl1_mapped_dir/
po wykonaniu polecenia:
D1: DIR PCL1:
widać ładny katalog z PieCeta.
Oczywiście przed wykonaniem tych czynności należy załadować sterownik PCLINK.SYS.
PCLINK chwilowo konfliktuje z RAMDISK.SYS więc do testów należy go odinstalować - RAMDISK.SYS jest już poprawiony przez Draco i pojawi się w nowym release SDX.
Edit: Chwilowo HSINDEX działa tylko na Linuxach.
Z biblioteką obsługi VBXE jest jak z OSem - co nas obchodzi jak ona to zrobi? Wywołujesz funkcję i ma działać. Martwimy się jak OS ładuje dane z C:? Nigdy. Kwestia napisania odpowiedniej biblioteki/rozszerzenia OSu.
IMHO taka biblioteka pozwalająca na zarządzenie rdzeniami w VBXE mogłaby być przydatna koderom każdego rodzaju aplikacji do określenia konfiguracji sprzętu. Widziałbym to, jako rozszerzenie OS tak, żeby aplikacje miały dostęp zawsze do aktualnej wersji biblioteki w systemie, a nie do tego z czym aplikacja była skompilowana.
A skoro tak, to deklarowałbym się jako chętny do stworzenia takiego rozszerznia, oczywiście o ile Candle i Electron wyrażą zgodę. Potrzebowałbym jeno konsultacji oraz sugestii ze strony ludzi używających/piszących pod VBXE co mogłoby być w takiej bibliotece potrzebne. Uprzedzam z góry, że do tej pory nic, ale to nic nie napisałem dla VBXE.
Razem z zawartością VRAM-u? :P
Ale ok, jeśli wypracuje się system, w którym przełączanie się między rdzeniami będzie w miarę automatyczne, tj. rozpoznanie bieżącego rdzenia, wybór wymaganego, boot, a potem przywrócenie i boot poprzedniego przed wyjściem z programu (ewentualnie rebootem), to nie miałbym zastrzeżeń.
Może w większości przypadków wystarczyłoby tylko skasować zawartość VRAM i zbootować. W końcu rdzeń musi umieć pracować na jakiejś początkowej zawartości VRAM.
Jest jedno ale: programiści mają problem z zapisaniem i przywróceniem wektora VBL - to sądzisz, że ci sami programiści nie będą mieli problemu z przywróceniem rdzenia VBXE?
Ci co mają problem z wektorami to pewnie nie :) Ale inni...
Ale przecież FC jakoś potrafi zbootować wybrany rdzeń? Slotów jest 4 (VBXE1) i 13 (VBXE2) więc oprogramowanie, które chciałoby użyć konkretnego rdzenia mogłoby sprawdzić czy takowy jest dostępny, po czym go łaskawie włączyć, a po zakończeniu działania przywrócić stary. Jak user zaś nie ma rdzenia, to ERROR! i dziękujemy.
Edit: ...lub też "ERROR! Proszę załadować wymagany rdzeń", lub jeśli sami go dostarczamy z aplikacją, znajdujemy wolny slot i pakujemy do VBXE. Mogłaby przecież być biblioteka do takich rzeczy dostępna.
Właściwie to najprostszy CPU to taki, co potrafi przesłać z pamięci do pamięci i w przestrzeni adresowej ma:
- program counter,
- rejestr(y) realizujący jakiś operator - najprościej A NAND B bo ono tworzy system funkcjonalnie pełny (za jej pomocą można zrobić każdą operację), choć wygodnie byłoby mieć też A NOR B, A ADD B i A MUL B.
@xxl: Nie chodziło mi o upublicznienie źródeł - chodziło mi o postaranie się o nie i własnoręczne eksperymentowanie. Źródła są własnością Autorów i są prywatne.
Nie jestem przeciwnikiem zmian - sam chętnie widziałbym w VBXE np. skalowanie i obroty sprzętowe sprajtów oraz ekranu, ale niestety każdy ma tylko 24h na dobę i obecnie nawet gdybym napisał, że nauczę się VHDLa i wprowadzę modyfikacje które chciałbym mieć (oczywiście o ile Electron i Candle daliby mi dostęp do źródeł), to i tak nie mam kiedy tego zrobić. Może to temat na później, a może ktoś to za mnie zrobi wcześniej :)
Ależ Panowie (i Panie). Jeśli ktoś chce zmian w rdzeniu, to sprawa jest prosta (i chyba jedynie taka opcja wchodzi w grę).
Należy pójść do Electrona i Candle, porozmawiać z nimi i przekonać do dwóch rzeczy:
1. Że znamy się na VHDL/Verilog (nie znam się).
2. Że źródło rdzenia nie wycieknie do osób postronnych.
Następnie zmontować sobie zestaw developerski do testowania własnych zmian w rdzeniu, no i implementować co tam sobie kto chce.
Oczywiście, że nie zrobi tego KAŻDY (w końcu Autorzy też mogą powiedzieć "nie, bo nie" i nic nikomu do tego), ale oczekiwanie, że nasze zachcianki zrealizuje Candle lub Electron przy braku oprogramowania i jakichkolwiek inicjatyw niestety są niepoważne, bo oni też mają ograniczoną ilość czasu do zainwestowania w swoje pasje, a przecież nie muszą być przekonani do naszych pomysłów.
Jest też inna droga (jeśli sami nie znamy się/nie umiemy/nie chcemy się znać na VHDL/Verilog) - przekonać jakiegoś developera żeby wydobył rdzeń od Candle i Electrona i wprowadził zmiany, które chcemy zobaczyć.
Edit: A jeśli ktoś sądzi, że to niewykonalne to niech sobie wyobrazi że chciałby wprowadzić zmiany w kernelu M$ Windowsa. W przypadku VBXE ma przynajmniej dostęp do Autorów...
Ja też przyjadę.
Wszystkiego dobrego i pomyślności.
Ruscy nas zestrzelą :D Ja tam bym polatał taką maszyną.
Hahaha. BCM, ale co najmniej stówa...
Ja również 1 sztuką (jeśli jeszcze jest).
No to za rączkę i do knajpy ;>
Taśmą przezroczystą samoprzylepną ;>
START i włączenie kompa też ci da beep. OPTION służy do wyłączenia BASICa (o ile nie masz na pokładzie QMEGa - z niewiadomych przyczyn tam działanie OPTION jest odwrócone), START służy do bootowania z kasety wpp boot odbywa się z dysku. Kombinacje tych klawiszy dają umożliwiają odpowiedni boot zależnie od tego, jaki program chcesz załadować (korzystający z BASICa czy nie) i z czego (kaseta/dysk).
Czyli niech z kodu lecą same wyjątki!
Albo w NFZecie - oni chyba do dzisiaj wymagają sprawozdań na dyskietkach.
Wszystkiego najlepszego.
A to może Panowie Krytykanci napiszą jak wyobrażają sobie komunikację Atari z dowolnym innym systemem? Przecież mapowanie katalogów PC jako wirtualny ATR już było i więcej z tym kłopotu, niż pożytku. A tu jest mechanizm pozwalający na prostą, szybką (!) wymianę danych z innym kompem.
atari.area forum » Posty przez mono
Wygenerowano w 0.087 sekund, wykonano 16 zapytań