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 Cyprian
pięknie dziękujemy MQ
dla zainteresowanych:
BigPEmu (plik BigPEmu_v1092.zip):
https://www.richwhitehouse.com/jaguar/i … t=download
Noesis (plik noesisv4472.zip)
https://richwhitehouse.com/index.php?co … project=91
https://www.youtube.com/watch?v=S_RvqVq6N-U
Swoją drogą, BigPEmu od wersji 1.09 ma możliwość grania w paru graczy:
"...a to było tak"
do wczoraj byłem pewien że to tu wrzucałem.
Wracając do tematu, kto mógłby to urządzenie zrobić
z tego co wiem to ET4000 dopiero od wersji W32 na PCI ma akcelerację.
Ta zwykła do ST to tylko framebuffer.
1) VLX - 1 szt.
2) Cyprian - 1 szt.
3) Adam Klobukowski - 1 szt.
4) uicr0Bee - 1 szt.
więcej nagrań:
https://forums.atariage.com/topic/30892 … nt-5104437
Wydaje mi się że jest to zwykłe zasilanie Arduino.
tematu nie porzucaj, wrzuć może zajawkę na Atari-forum.com, tam odezwie się pewnie więcej osób.
Co do fpga, nie ma potrzeby emulacji ET4000, VDI tej karty nie dotyka sprzętu (oprócz rejestrów koloru) a jedynie pamięci ekranu. Emulator.prg inicjuje kartę i ustawia parametry grafiki, w przypadku FPGa z ustaloną rozdzielczością to nie było by potrzebne. Tak więc, dla VDI ET4000 jedynie trzeba by wystawić bufor ekranu pod konkretny adres ekranu oraz dodać obsługę rejestrów kolorów.
też przytulę sztukę
Fajny pomysł, ale czy nie taniej było by zbudować taką kartę na FPGa?
link do dokumentacji:
https://docs.sidecart.xyz/
O, widzę że gosciu rozkmnia mikrokod T414 i T800.
Tutaj jest fajny opis jak ziomek wydobywa mikrokod z tych transputerów:
https://sites.google.com/site/transpute … -ucode-rom
Biorę:) A którą?
Transputer INMOS T414 dla zwykłego ST - KMAX do Kuma.
W źródłach systemu operacyjnego Helios dla transputerów z Atari ATW 800 widzę jakieś wsparcie dla interfejsu Kuma, ciekawe czy to ten sam interfejs:
https://www.stcarchiv.de/stc1987/09/kmax
Tu jest więcej: https://www.stcarchiv.de/stc1988/06/ata … ter-hellos
--dopisek--
tak dla potomności:
https://web.archive.org/web/20180922042 … ransputer/
https://web.archive.org/web/20160823121 … manual.pdf
https://web.archive.org/web/20160823133 … s_eval.pdf
Pliki zostały udostępnione na Gicie:
https://github.com/harbaum/MiSTeryNano
Co na dzień dzisiejszy już jest:
Atari ST:
Complete Atari ST chipset
Cycle exact 8 MHz 68000 CPU
4MB RAM
PAL color video via HDMI
YM2149 sound via HDMI
Blitter
Supports 192k PAL TOS:
Tested with german TOS 1.04
Mouse via IO pins of Tang Nano:
Full IKBD implementation
Single floppy disk image directly mapped to SD card
Czego brak:
Support for keyboards
Support for NTSC color and monochrome video
Support for multiple ST floppy disk images stored on FAT formatted SD cards
User interface (OSD)
Full STE chipset support
Support for 8 MBytes RAM as available on the Tang Nano 20k
Floppy disk write support
@tOri: No właśnie mnie to zastanawia dodatkowo, że ktoś robi robotę z zaimplementowaniem całego Atari w jeden scalak, a nie ma nikogo, kto by zrobił np. WD1772 w fpga z otwartym źródłem na jakiś tani fpga, albo cpld i w sposób taki, żeby jak najmniej trzeba było lutować i każdy mógł sobie to w domu poskładać?
takie coś będzie ok https://github.com/Torlus/firebee-fpga/ … FDC1772_IP ?
Wiadomix, co prawdziwe Atari to jednak prawdziwe.
To jest rozwiązanie dla tych którzy chcą MiSTera, ale nie mają ochoty wydawać 1000PLN. W sumie to pierwsze nagranie ma dopiero 5 dni, więc na razie są to nieśmiałe przymiarki.
tak sytuacja
Atari ST na Tang Nano 20k za $28
https://www.youtube.com/watch?v=qndojsbH9jw
https://www.youtube.com/watch?v=yLxXRR_04UE
https://www.youtube.com/watch?v=9wFxQvKtOY8
więcej tutaj:
https://atari-forum.com/viewtopic.php?t=43080
---poprawka---
wszystkie pliki udostępnione na Gicie:
https://github.com/harbaum/MiSTeryNano
tak na szybko moje uwagi:
- jak wybiorę Nową grę to klawisz "ESC" cofa mnie do głównego menu, ale jeśli jestem w "Opcjach" to nie cofa mnie do głównego menu tylko zamyka grę;
- za każdym razem zastanawiam się które opcje są zaznaczone a które nie,
- przydała by się podpowiedź czego dotyczy hasło.
- nie zawsze podkreśla na czerwono wybraną błędną literkę.
Przydało by się więcej fajnych piosenek na YM
teraz robiony jest drugi rzut, więc coś jest pewnie poprawione, no ale patrząc na uwagi na Atari-Forum pewnie będą zmiany.
Tak czy siak, zapisałem się na ten rzut bo cena jest bdb: €22.50 / €37.50 a potem €30 / €50
Cyprian, ale z tymi przyciskami myszy, to nie jest że gry nie ogarniają, tylko Eiffel nie ogarnia. Standardowo sprzętowo w Atari połączony jest na sztywno prawy przycisk myszy i fire w drugim porcie joya. W oryginalnym Atari bez względu na to czy wciśniesz prawy przycisk myszy czy fire w joy w drugim porcie, to dla Atari nie robi różnicy, bo to jest ten sam przycisk fizycznie. W Eifflu natomiast zostało to rozdzielone, a nie do końca obsłużone i dlatego są kłopoty.
A taki "tryb zgodności" jak piszesz, to dało by się zrobić jako jakiś program rezydentny, który by w grach ten fire dodatkowo z prawego przycisku myszy czerpał? Jeśli tak, to by też rozwiązało problem dla wszystkich gier od razu.
chodziło mi o to by bezpośrednio w Eiffel by wybór: albo zwykłe działanie ST - tak "tryb zgodności", albo "nowe" czyli to które teraz jest. A może nawet rozszerzyć to które jest do obsługi trzech przycisków.
Z obrazem właśnie nie jest tak jak piszesz, bo przerwania generowane są odrębnym zegarem. Jak zmieniamy podstawowy zegar, to ilość linii się nie zmienia, ilość ramek na sekundę też nie, natomiast zmienia się ilość cykli procesora w linii. I z tego robią się problemy z tzw. docyklowanymi demami, gdzie programiści przewidzieli, że mają określoną ilość cykli, a jak dajemy minimalnie wolniejszy zegar, to tam się robią jakieś pojedyńcze cykle w linii mniej, zaczyna ich brakować i program się sypie.
No chyba, że coś źle zrozumiałem, ale z moich obserwacji wynika, że tak właśnie jest.
Jak budowałem teraz generator z kwarcem z płyty oryginalnym, to potwierdziło się to co mówię. Kwarc przez przypadek wzbudzał mi się na niższej częstotliwości (3x niższej, bo to kwarc tzw. overtonowy i trzeba go odfiltrować, żeby wzbudzał się na 3x wyższej częstotliwości, co już naprawiłem nawiasem mówiąc). No i jak się kwarc wzbudzał na 3x mniejszej częstotliwości, to obraz wyglądał jak na załączonym zdjęciu. Ilość linii obrazu, częstotliwości przerwań synchronizacji poziomych i pionowych się zgadzają, bo inaczej obrazu by w ogóle nie było na monitorze. Natomiast zawartość leci trzy razy wolniej, przez co jest wszystko trzy razy większe i oczywiście jest dodatkowo bajzel. Startujące na tym zdjęciu Atari nie uruchamia żadnych procedur synchronicznie do przerwań, więc nic się nie wysypuje, a komputer normalnie wstaje, tylko wyświetla to co wyświetla. Jednak jak w demach jakieś procedury mają się odpalać zgodnie z przerwaniami, to zaczyna się to sypać, bo procedura nie zdąży wykonać się w całości przed wystąpieniem następnego przerwania.
Sygnały (i przerwania dla procesora) Vsync i Hsync generowane są przez GLUE który jest taktowany zegarem głównym. Ma on wewnętrzne zegary które na sztywno zliczają cykle i generują sygnały H/V i DE (display enable). Więc jeśli nie zaingerujemy procesorem (np. otwieranie ramek) to ilość cykli procesora per linia i linii per ramka obrazu zawsze są takie same. Dodatkowo SHIFTER też jest taktowany zegarem głównym, więc PixelClock - w tym przypadku ilość pikseli w linii jest stała w stosunku do Hsync ("50Hz":512/1024, "60Hz":508/1016, VGA: 896).
MFP ma osobny zegar, z tym że układ ten generuje przerwania wyłącznie dla procesora i nie biorą one udziału w generowaniu obrazu. Jeżeli jednak demo liczy cykle i przerwanie wypadnie w innym miejscu niż procesor się spodziewa (bo zegary są inne niż fabryczne), to otwieranie ramki, czy sync-scroll się posypią.
myślę że zamiast zamiany sposób działania przycisków myszy/dżoja można by dodać tryb zgodności dla niektórych gier które nie ogarniają.
swoją drogą to klawiatura MSTE/TT obsługuje myszy 3 przyciskowe
Poza tym jakichś wielkich różnic nie zaobserwowałem, obraz nie przesunął się i na oko ma takie same rozmiary na obu generatorach. Gry, które testowałem działały na obu kwarcach w zasadzie tak samo. Krótko mówiąc generator 32MHz z grubsza spełnia swoją rolę i można tak Atari odpalić.
obraz nie przesunął się bo jest on zależny od tego właśnie zegara, czyli niezależnie czy będzie to 32MHz czy 25MHz, obraz zawsze ma 313 linii i 512 cykli procesora dla trybu "50Hz". Jedynie ilość ramek na sekundę będzie inna.
jest moc!
Pojawiło się nowe ciekawe urządzenie - kartridż z RP2040.
Działające (przygotowywany jest właśnie drugi rzut, pierwszy był dla twórców), otwartoźródłowe i oparte o RP2040.
Może działać jako:
1. Zwykły ROM : 64KB / 128KB ładowane z pliku z karty SD lub poprzez WiFi.
2. Dowolne urządzenie we-wy (bo daje możliwość oprogramowania ), np. zegar czasu rzeczywistego, twardy dysk, emulacja kluczy (np, Cubase), stacje dyskietek, klawiatura, mysz itp itd
Cena to €30 bez RP2040 lub €50 z RP2040
Wątek na Atari-Forum: https://atari-forum.com/viewtopic.php?p=451216
Strona projektu: https://sidecart.xyz/
Zapisy na drugi rzut karta (do 25 września): https://mailchi.mp/290579c00c14/sidecart-waiting-list
Coś do poczytania:
https://sidecart.xyz/blog/2023/09/02/wh … -sidecart/
https://sidecart.xyz/quickstart
Programowanie urządzenia (GitHub): https://sidecart.xyz/coding sidecart.xyz/coding
Tak jak pisał wyżej x_angel, nie miałem generatora takiego jak kwarc w ST, więc na pałę dałem zwykły 32MHz. Na takim kwarcu wszystko działa, odpalają się programy, odpalają się gry i dema. Czytałem gdzieś na forum zagranicznym, że jak się da inny kwarc niż być powinien, to się może coś tam wywalać w tzw. "docyklowanych demach", bo tam przypada inna ilość cykli w linii, czy tam inna ilość cykli w stosunku do cykli zegara od RS232, a stamtąd jest też pobierany czas do jakichś obliczeń czy coś... Nie znam się na tym:-).
MFP (Timery/Przerwania/Port B/RS232) ma własny kwarc, więc jeśli procesor ma niestandardowy zegar to docyklowane dema które używają zegarów/przerwań, mogą (ale nie muszą) się wyłożyć.
Z tym że jest światełko w tunelu - Atari stosowało ze trzy różne kwarce dla procesora (jeden w STE i ze dwa w ST), dema zazwyczaj sprawdzają który kwarc jest użyty, wiec może którychś z nich jest dostępny.
---dopisek---
32.0424 MHz - wczesne STF, również NTSC
32.04245 MHz - Mega ST
32.084988 MHz - PAL ST, STE
32.215905 MHz - NTSC STE
32.028400 MHz - wczesne ST: https://www.atari-forum.com/viewtopic.p … 758#p75758
Widzę że Centurion ma jeszcze 32.084988 MHz https://centuriontech.eu/product/falcon_oscillator_pal/
dzięki tOri.
Tak sobie teraz myślę czy dało by radę zrobić taki kart który miał by zaczarowany przełącznik - Notator/Creator/Cubase 3.x/Cubase Audio/itp
atari.area forum » Posty przez Cyprian
Wygenerowano w 0.134 sekund, wykonano 14 zapytań