Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
MadPascal 1.7.3 już dostępny Nowa wersja kompilatora MadPascal przynosi poprawki i optymalizacje
atari.area forum » Posty przez mono
2) ściągnąć sobie dump dysku do pliku, przeswapować samemu (napisać do tego program), <ciach>.
$ dd if=in.img of=out.img conv=swabJa postaram się również przybyć. Liczę na to, że tym razem nic mi nie przeszkodzi.
5.50... Kolekcjonerzy jeszcze nie znaleźli.
Ale poziom wyżej jest coś takiego: http://www.puisoft.co.uk/atari/ataricx8 … fnotes.zip
Jeśli o mnie chodzi, to ja się dostosuję - jeśli nie styczeń, to może być też luty.
Asie. Pisałem o tych konwerterach tu. Problem jest taki, że nie wszystkie myszy USB działają (być może zmienił się protokół). Moja Logic M-1 kupiona ze 3 lata temu działa, ale już Modecom też M-1(wygląd identyczny) kupiona rok temu nie.
No gra bardzo dobrze (wyżej u mnie jest jeszcze świetnie i doskonale ;]). Kto robi player do .sid'ów?
Tak więc możesz sobie włączyć rysowanie sprajtów przez GTIA i DMA dla sprajtów w ANTICu a wyłączyć DMA dla dlisty, bo można tym sterować osobno.
Skąd kod wie, że jest rysowana linia? Bo wystąpiło przerwania DLI (o ile ustawiłeś je w odpowiedniej linii ekranu) i właśnie CPU w nie wszedł. To którą linię aktualnie rysuje ANTIC/GTIA masz w VCOUNT.
Poziomej pozycji nie ma, ale nietrudno ją wyliczyć (w pamięci) wiedząc w którym cyklu koloru zgłaszane są przerwania DLI i ile cykli koloru trwa jeden takt CPU (trwa 2). Cykl koloru to szerokość jednego piksela w trybie OS 15 (2 pikseli w OS 8).
Tak więc jeśli w przerwaniu masz instrukcje:
pha
pla
rtito możesz na początek założyć, że Twoja procedura wykona się w 7+3+4+7=21 cyklach CPU a więc w czasie rysowania 42 pikseli GR.15.
7 pierwszych taktów to przyjęcie przerwania przez CPU (odłożenie adresu powrotu + rejestru znaczników na stos, i skok pod adres zawarty w NMIVEC), 3 cykle to pha, 4 cykle to pla, 7 cykli to rti. No i tak dalej.
Ponieważ NMI są obsługiwane przez OS to opóźnienie wynikłe z wykonania rozpoznania źródła przerwania i skoku do wektora DLIV wyglądające tak:
bit NMIST
bpl jvblk
jmp (dliv)
jvblk:
... ;to nas nie interesuje
zabiera jeszcze 4+2+5=11 cykli CPU.
A co wpisałeś do PMGCTL? Jeśli ustawiłeś tam wyświetlanie sprajtów, to GTIA będzie rysowało na ekranie zawartość rejestrów GRAFPx/M. Bity w DMACTL ustawiają tylko DMA ANTICa dla sprajtów (czyli automatyczne przepisywanie zawartości kawałka pamięci do rejestrów GRAFPx/M co linię/dwie).
Edit: Właśnie dzięki temu możliwa jest multiplikacja sprajtów.
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...
atari.area forum » Posty przez mono
Wygenerowano w 0.115 sekund, wykonano 15 zapytań