ten kto nie ma Rapidusa, może użyć Altirry, System -> Cpu Options... -> 65C816 (21.48 MHz) i będzie miał efekt Rapidusa 20 Mhz
więc można pisać pod Rapidusa przy pomocy Altirry
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNetChat: Nowy klient IRC dla Atari Pierwsza publiczna wersja alfa FujiNetChat, nowoczesnego klienta IRC wykorzystującego interfejs FujiNet.
Gearlynx 1.2.2 Gearlynx doczekał się aktualizacji. Wprowadzono podgląd SCB, wyszukiwanie w pamięci oraz poprawki.
Wyniki FujiCup 2025 Poznaliśmy najlepsze gry na 8-bitowe Atari wydane w 2025 roku według jury oraz publiczności.
Wyniki konkursu i gala FujiCup 2025 Poznaj zwycięzców dorocznego turnieju FujiCup 2025 wspierającego twórców gier na Atari XL/XE.
Fujisan 1.1.8 Nowa wersja emulatora Fujisan przynosi wsparcie dla FastBasic oraz poprawki błędów w obsłudze dźwięku.
atari.area forum » Posty przez tebe
ten kto nie ma Rapidusa, może użyć Altirry, System -> Cpu Options... -> 65C816 (21.48 MHz) i będzie miał efekt Rapidusa 20 Mhz
więc można pisać pod Rapidusa przy pomocy Altirry
Z tego co wiem, większość Rapidusów wyjechała do zachodnich krain, w Polsce pewnie z ~5 użytkowników można znaleźć, jeśli są to inne szybkości zegara, to raczej Antonia i inne pochodne. Szybkość zegara można odczytać, procka Draco jest m.in. w paczce do MadPascala (lib\misc.pas, DetectCPUSpeed). Skoro znamy szybkość zegara i wiemy że większość użytkowników ma np. 14MHz to możemy pod taki standard pisać.
Rocky ma Rapidusa, nie ma VBXE :) a jest zainteresowany zwiększeniem możliwości graficznych przy użyciu większej mocy CPU. Wyobrażacie sobie edycję programu rastra z 44 pozycjami ;) masochizm.
p.s.
Ilmenit mógłby dodać taką możliwość do RastaConvertera, więcej, gęstszych zmian w linii.
zastanawialiście się ile zmian w linii można uzyskać dzięki szybkości Rapidus-a ? Test dotyczy pamięci konwencjonalnej, a nie liniowej Rapidus-a. W Altirrze można włączyć CPU 65816 na 21MHz i uzyskamy ten sam efekt jak na prawdziwej dopałce.
Zmiany przeprowadzane są w "prostacki" sposób, lda#, sta colbak. Zmiany są szersze z lewej strony ekranu jednak ta szerokość jest stała, druga połowa ekranu (prawa) to zmiany co bajt. Ogólnie zmian w linii jest 44, to oznacza że z ledwością mieścimy się w pamięci $800..$BFFF dla 200 linii obrazu. Zdecydowanie takie zabawy wymagają dodatkowej pamięci liniowej Rapidusa. Mapa kolorów bez udziału VBXE jest teraz możliwa :)
ten SC kolorujący pliki/katalogi to jakaś nowa wersja ? czy w pliku INI się to włącza ?
z włączonym Rapidusem czy wyłączonym Pin-ek ?
Rocky ma takie "Atari" ;)
tak, 2 kolorowy obrazek na VBXE :)
a wiecie już że w 2017 listonosz będzie sprawdzał czy macie oryginalne GTIA, będzie mógł donieść na Was, na Policję :P
a nie lepiej tak przy okazji zaimplementować układ MARIA z Atari7800, będzie można bawić się zmianami rastra do woli :D
p.s.
i to jest pomysł na nowy rdzeń do VBXE :)
i dlatego Simius nie powinieneś tu zaglądać, tylko zrobić to "po swojemu" i oznajmić kiedy będzie już gotowe, na końcu i tak się dowiesz że ludzie chcieliby VBXE tylko o połowę tańszego
Pang 4.5, po poprawkach, wystawiony na http://madteam.atari8.info/index.php?prod=gry
zmiany w porównaniu do wersji zaprezentowanej na Silly Venture 2016:
- tryb PANIC na początku charakteryzuje się większą liczbą bonusów (serduszko, tarcza), potem jest tych bonusów coraz mniej
- po przejściu 9 poziomu trybu PANIC zobaczymy ekran z gratulacjami
- dodany datamatrix, można zapisywać wyniki high_score na stronie XXL-a
- możliwość podejrzenia najlepszych wyników, klawisz HELP (potem trzeba wybrać TOUR, PANIC)
- obsługa ruchów joysticka "na ukos", teraz nie będzie blokowany ruch postaci
- możliwość wyłączenia muzyki podczas gry, to dla tych z NTSC
- gra sprawdzona pod Rapidusem, wszystko działa oprócz tytułowego obrazka, gdzie wykorzystane są zmiany rastra
- różne inne poprawki zauważonych błędów, testował do oporu TDC :)
nie tylko opis, ale i działający efekt wykorzystujący ten bug, napisany przez Phareon-a
VBXE nie obsługuje buga z rozszerzeniem pocisku/gracza na całą szerokość ekranu
Simius będzie to dodane ?
oficjalnie stwierdzam, po poprawce Pasia, KMK + Rapidus śmigają aż się uszy trzęsą ;)
cyt: "Nie znam dokładnie powodu, ale ta konkretna płyta Atari wymagała lekkiego opóźnienia tego sygnału EXTSEL."
bez tej poprawki cokolwiek włożone do slotu carta + ECI powodowało zwis w obecności Rapidusa
:) w moim konkretnym przypadku wartości 6,7,8,9 sprawdzają się najlepiej, pozostałe zrywają synchronizację linii
zależnie od kierunku scrolla, wartości 0-1-2-3, lub 3-2-1-0, najczęściej używa się stałego bufora na scroll, a nie przeznacza n-KB, przesuń poprzez rejestr HSCROL, a następnie przesuń zawartość bufora np. w lewo, na ostatniej zwolnionej pozycji dopisz nowy znak
można też przez ring-buffer, masz 256 bajtów jako bufor scrolla, ustawiasz wyświetlanie na początek takiego bufora, przesuwasz przez HSCROL o jeden znak, następnie zerujesz HSCROL + zwiększasz młodszy bajt adresu w DISPLAY LiST Antic-a, co spowoduje że napis przesunie się w lewo, teraz kończysz wstawiając nowy znak tylko że na pozycji X i pozycji X+40, gdzie X oznacza aktualna pozycję w buforze (40 oznacza szerokość wyświetlanego tekstu), taka organizacja jest najszybsza, nie wymaga przepisywania zawartości bufora
tutaj więcej przykładów http://codebase64.org/doku.php?id=base:demo_programming
z tym że najczęściej te przykłady odnoszą się do tej wersji z przepisywaniem znaków w buforze
stary wątek z przykładem efektywnego scrolla dla ring-buffer
bierzesz pod uwagę to że dla włączonego HSCROL-a masz szerszy obraz? dla ekranu wąskiego (32 bajty) włączenie HSCROL spowoduje że wiersz ma już 40 bajtów szerokości
HSCROL zwyczajowo ustawiasz 0..3, potem zmiana adresu wiersza, można inaczej 3..6, można 0..15 tylko potem adres wiersza o 4 bajty zamiast 1
niskie wartości HSCROL zajmą mniej czasu, wyższe więcej, ale w normalnym użyciu jest to bez znaczenia
może przełącznik, tyle że przełącznik który wymusi pozostanie w trybie VBXE, bez przełącznika czyli w 99% przypadków wyłączy VBXE i włączy tryb standardowy 40-o kolumnowy
takie małe pytanko, kiedy jesteśmy w trybie 80 kolumn VBXE i próbujemy odpalić cokolwiek nie powinna pytać się Sparta o przejście w tryb 40 kolumn (z wyłączeniem VBXE włącznie), obecnie uruchomienie czegoś z włączonym Overlayem VBXE powoduje misz-masz i takie laickie istoty jak ROCKY walą bluzgi gdy coś takiego zobaczą
Użycie znaku podziału wiersza "\" po wywołaniu procedury z parametrem generuje niespodziewany kod:
po poprawce
mads 2.0.5 http://mads.atari8.info
tak, blitter VBXE pozwala na takie cuda, tyle że REU było dużo wcześniej przed VBXE
zaraz jakiś ortodoks stwierdzi że VBXE to nie Atari, a REU powstało w czasach kiedy Commodore żyło, więc jest OK
https://www.youtube.com/watch?v=9BJvH9Z92uk
http://codebase64.org/doku.php?id=base:reu_programming
bo ma "blitter", który pozwala kopiować zadany blok pamięci pod wskazany adres poprzez DMA, podobnie jak blitter VBXE
animacja w stylu TIPAnimatora będzie wydajniesza na REU, TIPAnimator musi włączyć odpowiedni bank, potem z udziałem CPU dokonać kopiowania wybranego bloku pamięci pod nowy adres pamięci obrazu, na REU robi to tenże "blitter"
cytat - "Due to the fast DMA this is about 5 times faster than copying memory with machine language instructions."
p.s.
tyle rozszerzeń pamięci na XE/XL a dla żadnego nie pomyślano o czymś podobnym jak ma REU
w sumie, racja
już można kupować, ogólnie to audio LINE IN w ECI / PBI fajna sprawa, tylko po co komu 1 kanałowy Covox
nawet Lotharek pojechał na wakacje, gość nie ma obowiązku być przyspawanym do krzesła, telefonu, czy kompa
atari.area forum » Posty przez tebe
Wygenerowano w 0.102 sekund, wykonano 21 zapytań