Jak w temacie, chętnie kupię:
Atari 1040STE (najchętniej angielska klawiatura ale nie jest to na 100% konieczne)
Atari 7800 (najlepiej z cartami)
Może ktoś ma i chce zamienić na polskie złote ... ?
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 electron
Jak w temacie, chętnie kupię:
Atari 1040STE (najchętniej angielska klawiatura ale nie jest to na 100% konieczne)
Atari 7800 (najlepiej z cartami)
Może ktoś ma i chce zamienić na polskie złote ... ?
Ja chcę i Candle ! Na 100% !
Czyli 2 osoby na 2 noce : piątek/sobota/niedziela
A ja mogę ?
W tej chwili rdzeń VGA zrobiony został dla VBXE2 bo Candle ma większe szanse go sprawdzić, mi brakuje monitora itd.
Dla VBXE1 taki sam funkcjonalnie rdzeń można zrobić jak najbardziej, potrzebne są nieco inne przeróbki sprzętowe:
VBXE2:
- nowy rdzeń,
- podłączyć SYNC VGA do LED i RDY na płytce VBXE2,
- zmienić kwarc na płytce VBXE2 z 14 na 28 (z groszami) MHz
- sygnał zegarowy do FREDDIE podłączyć w innym miejscu na płytce VBXE2
VBXE1:
- nowy rdzeń,
- podłączyć SYNC VGA jeszcze nie wiem gdzie, ale RDY chyba odpada, bo trudniej odłączyć od płyty Atari, coś wymyślę
- wstawić nową płytkę PCLK (tą przy Freddie) aby wytworzyć zarówno 28 jak i 14 MHz,
To wszystko jest w miarę proste i jak najbardziej wykonalne dla obu wersji VBXE.
Taktowanie jest teraz 28 MHz i jest specjalna wersja rdzenia oczywiście.
Jeszcze łyżka dziegciu.
Z powodu braku zasobów rdzeń FX VGA został odrobinkę "przycięty":
- zamiast 4 palet są 2 palety (0 i 1)
- nie działa detekcja kolizji rastrowych overlay<->playfield/pmg (kolizje blittera działają)
- nie działa dodatkowy 1 bitowy overlay w hires (ten robiony przez mapę koloru)
Ilość palet ... no trudno, ponad 3/4 programów na vbxe używa do 2 palet, zabrakło RAMu w FPGA z powodu konieczności zmieszczenia sporego bufora linii.
Pozostałe braki: nikt nie używał dotąd tych funkcji - ich wycięcie jest wymuszone koniecznością znalezienia miejsca na logikę VGA w układzie.
Oczywiście te ograniczenia są tymczasowe i wynikają z braku zasobów układu FPGA EP1K50. VBXE3 będzie miało nowe dużo nowocześniejsze i większe FPGA i standardowo wyjście VGA.
Głos Pina w tle zapowiadający różne głupoty bardzo zawsze mi pasował, nie ma powodu do zmian. Co do wszelakich Crazy Compo itd to podzielam zdanie Draco - to nie przedszkole ani kolonia dla czternastolatków, obejdzie się.
Według mnie przy zapisie to jednak jest "pip.. pip.. prrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr" przynajmniej przy sio x3.
XXL i JACQUES - macie vbxe na D6xx czy D7xx ?
(Ja mam na D6xx i u mnie ta wersja nie działa - resetuje vbxe).
Program resetuje FPGA na VBXE. Rdzeń znika i zostaje czysta matryca, bez żadnej przypisanej funkcji..
Hm .... chciałbym zareklamować swój fileselektor, który użyty jest w FC.com / DCFG.COM (utilsy VBXE) oraz w przeglądarce BMP-ków (też pod VBXE).
Dostępny jako żródło do MADS. Wymaga ekranu zgodnego z GR.0. Działa i jest dość wygodny IMO.
obsługuje maski, wpisywanie własnej nazwy, zmiany "w locie" napędów / urządzeń itd.
Acha - póki co nie obsługuje podkatalogów.
A co to znaczy "resetować włącznikiem ON/OFF" ? Pstrykasz ? 15 milisekund ?
Daj mu czas. 30 sekund pomiędzy wyłączeniem a ponownym włączeniem. Powinno być OK. To normalne.
1. użyj CSYNC ale daj go przez rezystor 100 omów szeregowo
2. Dodatkowo można zbuforować nieużywaną bramką w 4050 - sam tak robiłem w kilku atarkach.
Generalnie w standardzie SCART jako źródło synchronizacji w trybie RGB służy sygnał CVBS (Composite Video) więc nie tylko bezpieczniej ale i zgodnie ze standardem by było.
Prawda jest jednak taka, że podłączając CSYNC do SCART obciążasz je impedancją 75 Omów czyli typową dla CVBS ... To mało i mocno daje w kość układowi 4050. Podłączenie oprócz tego S-Video już tu nic nie zmienia.
podłączaj - nic nie padnie - jak masz sygnał rgb podłączony ? używsz csync czy composite jako synchronizacji ? Jaki monitor ?
Brawo Simius, niezła "rzeźba". Ilość SO14/16 imponująca :)
Jakiś schemacik ?
Candle mnie męczy abym dodał scandoubler 31kHz/50Hz do rdzenia VBXE - zrobię to chyba, ale niestety tylko w przypadku rdzenie GTIA emu - w FX nie ma już miejsca.
No i Candle nie wytrzymał, musiał się pochwalić. A tak poza tym - na tym (pokey) się nie skończy.
Kasowanie jakkolwiek, ale podstawą by było zrobić double buffering ...
Zbędny i zawodny. Takie dane łatwo ulegają uszkodzeniu. Walczyłem kiedyś z podtrzymywaniem bateryjnym SRAMU - i tylko kłopoty z tym były - ale to było jeszcze w czasach przed-flash więc wówczas tak można było się bawić. Dzisiaj to pomyłka.
Na VBXE (na v1 jak i również na v2) siedzi ANTIC - więc gila mnie co Ty potem zrobisz z sygnałami ANx - bo mam je pierwszy - bezpośrednio od ANTICa. Pod warunkiem oczywiście, że nie przeciążysz ich jakoś za bardzo i nie zmienią się timingi.
W ogóle ls nie powinieneś używać, ze względu na znaczne wnoszone obciążenie magistrali ANx.
Nie używaj tego bo to do niczego nie podobne i na przyszłość tylko kłopot będzie, ale to moje zdanie.
Brawo Panowie. Naprawdę ekstra.
A teraz do koszy, szukać wywalonych GTIA.
A ja mam uwagę:
Co to są standardowe banki 130XE ? Bo wg mnie nie ma czegoś takiego.
Czy w 130XE jest jakaś różnica, czy wpiszę do PORTB np. $80 czy $c0 ?.
Ale wybieranie banków tak czy siak jest bez sensu - powinien być automat i tyle.
Oczywiście robiąc tak jak opisuje to Candle pozbywamy się problemu całkowicie.
Odpowiedź moja jest taka - przy projektowaniu nowych MEMAC a/b założyłem, że może zaistnieć sytuacja, w której programista otworzy bufor znajdujący się częściowo w RAM a częściowo przykryty przez (włączony) ROM komputera. (np. okno 16K począwszy od $9000 - wówczas obszar $c000-$cfff pokrywa się z ROMem). Rozwiązaniem nieuniknionego konfliktu jest monitorowanie CASINH - a więc przylutowanie kabelka, które uznaję za obowiązujące wszystkich użytkowników vbxe. Bez tego kabelka nastąpi konflikt na szynie danych przy dowolnym odczycie obszaru $c000-$cfff - komputer się prawdopodobnie zawiesi.
podsumowując
- może być memac i włączony rom (OS/BASIC) (w tym samym miejscu)
- przykryty przez ROM obszar okna MEMAC nie nadaje się do użycia (jest tam tylko ROM)
- należy pamiętać, że o ile ROM (OS/BASIC) kontrolujemy, to CARTA już nie - tym bardziej jest konieczne przylutowanie kabelka - co prawda naszemu programowi to nie pomoże, ale komputer nie ucierpi od kolizji na szynie danych.
atari.area forum » Posty przez electron
Wygenerowano w 0.029 sekund, wykonano 33 zapytań