Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
zeST 20250627 - Atari ST w FPGA z turbo! Nowa wersja zeST z trybem turbo 50 MHz i poprawkami Shiftera i MFP
UltraSatan - firmware 1.30 Nowa wersja firmware dla UltraSatana wspiera nowoczesne karty SDHC i SDXC
53 lata marki Atari 53 lata od założenia Atari - firmy, która odmieniła świat gier i komputerów.
Odtwarzanie układów z Atari Falcon Trwa zbiórka na odtworzenie chipów Videl, Combel i SDMA z Atari Falcon
onEscape extEnded and reWorked Poison prezentuje rozszerzoną i poprawioną ścieżkę dźwiękową z gry onEscape.
atari.area forum » Posty przez Fox
Piotr456: Podejrzyj źródło tego HTMLa. Przeglądarka pewnie Ci pokazuje "Ldx Dlist", a powinno tam być:
Ldx <DList
Ldy >DList- to oczywiście wpadka tego, co robił tę stronę.
Lizard: to był fragment listingu - zawartość linii obcięta po plusie a 0027 to nr linii.
Twój sposób nakłada na dostęp do każdego bajtu narzut: przesunięcie bitowe, odczyt z tablicy i and (x86 mają indeksowanie z dodawaniem dwóch rejestrów). Anda możnaby uniknąć odpowiednio modyfikując wartości w tablicy. Popatrz na mojego posta #23: dodatkowe operacje są dla każdego bajtu kodu 6502 i nie możesz używać
dostępu 16-bitowego (czyli zamiast instrukcji wczytującej 16 bitów mamy dwie instrukcje czytające po 8,
przesunięcie i dodanie).
Wygląda na to, że mój sposób 2 da się zrealizować przy pomocy funkcji mmap(). Wg wstępnych prób dopał nie jest powalający (ten mmap trochę trwa).
Nie, zmieniliśmy temat na przyspieszenie emulacji przełączania dodatkowej pamięci.
alex: Ja tu nie widzę żadnego uproszczenia.
W Atari800 wiekszosc dostepu do pamieci jest opakowana makrami zdefiniowanymi w memory.h, wiec zmiana organizacji pamieci nie powinna nastreczac wiekszych problemow. Nalezy tylko osobno uwzglednic dostep do kodu 6502 w cpu.c oraz dostep do roznych rodzajow danych w antic.c.
Swego czasu w Atari800 bylo tzw. Paged Memory, gdzie dla kazdej strony przestrzeni adresowej (256 bajtow)
byly wskazniki: funkcja odczytujaca, funkcja zapisujaca, wskaznik na pamiec. Obecnie mozna sobie przekompilowac Atari800 tylko z Paged Attrib, gdzie mamy funkcje: odczytującą i zapisującą dla każdej strony pamięci, które to tablice zastępują normalnie używaną tablicę attrib[65536] zawierającą wartości: RAM, ROM, HARDWARE.
Moje pomysły są dwa:
1. Dostęp do danych w dodatkowej pamięci zrobić przez funkcje, podobnie jak dostęp do chipów.
Możnaby użyć tego zarówno z Paged Attrib jak i bez. Kod w Anticu już uwzględnia inne od 6502 ustawienie dostępu do $4000-$7fff dla danych ekranu, wystarczy tam więc mała przeróbka. Stosunkowo niedawno dorobiłem możliwość kompilacji cpu.c tak, aby zamiast adresu PC trzymany był wskaźnik do pamięci.
O dziwo testy wykazały, że nieco spowalnia to emulację. Jednak przydałoby się, gdyby ustawiać ten wskaźnik
tak, aby wskazywał na pamięć rozszerzoną.
2. Użyć sprzętowego mechanizmu stronicowania, który powszechnie występuje w nowoczesnych prockach. Istnieje możliwość mapowania przestrzeni adresowej w pamięć fizyczną stronami o wielkości zazwyczaj 4 KB. A więc tutaj pasowałoby w sam raz. Niestety nie słyszałem, aby jakikolwiek system operacyjny (DOS nie jest systemem operacyjnym) był na tyle wspaniałomyślny, aby dawać procesowi użytkownika możliwość modyfikowania tablicy stron. Trzebaby więc wykombinować albo znaleźć jakieś dodatkowo instalowane sterowniki, które taką możliwość dadzą. Nie muszę chyba dodawać, że jest to rozwiązanie całkowicie nieprzenośne między systemami operacyjnymi i architekturami sprzętu.
Nie zrozumiałem, co chcesz osiągnąć przeznaczając $10000 na każdy bank zamiast $4000.
Myślę, że Atari800 powinien pójść (patrz inny topic) - odpalisz sobie w nim sapemu.
Problem w tym, że nawet sprytne indexowanie nie będzie efektywne przy dostępie do kodu 6502,
którego jest kilkakrotnie więcej, niż dostępu do danych - wystarczy spojrzeć na:
lda #0
sta $600- 5 bajtów kodu i tylko jeden danych. Jeśli nie chcesz przepisywać z dodatkowej pamięci
do tablicy memory[], to nie tylko każdy dostęp do kodu musi być przez wskaźnik,
ale nie możesz też używać 16-bitowego dostępu w przypadku procków little-endian łykających
niewyrównane dane (w szczególności x86). W przypadku dem wykonujących rozpętlony
kod w dodatkowej pamięci będzie więc spory spadek wydajności, to samo we wszystkich programach
wykorzystujących tylko 64 KB.
Drac030: pewnie tak, ze względu na to, że wykonuje je część procka od generowania adresów, a nie ALU.
Alex: pewnie napisałeś do Stehlika, który czasem bywa zajęty;
http://cvs.sourceforge.net/viewcvs.py/* … TALL.wince
Jeśli chodzi o "3)" to raczej pobożne życzenia (czytaj: jeśli uda się wam to zrobić, to pogratuluję).
jellonek: dłuższy rozkaz na pewno trudniej załadować, w dodatku taki, który ma parametr
czy MFC jest zaleznoscia atari800 w wypadq wersji PocketPC
Nie jest.
Jeśli chodzi o trudność w określeniu timingów, to cecha procków superskalarnych i/lub z kieszeniami, więc prawdopodobnie również nowych ARMów.
Offtopic: GCC 4.0 generuje np. "lea eax, [eax+1]", ktoś wie dlaczego nie po prostu "inc eax" ?
jellonek: w tym poście jest mowa o Atari800 a nie o Atari800Win PLus. Biblioteka na WinCE ZTCW obejmuje MFC, brakuje natomiast całkiem podstawowych funkcji libc w rodzaju strdup().
ARMy mają świetny zestaw instrukcji, jednak przewagami x86 mogą być superskalarność (nie wiem jak z tym w ARMach), zmienny przecinek (ZTCW ARMy zwykle go nie mają) oraz dostęp do niewyrównanych słów i "mała indiańskość", co przydaje się przy emulacji 6502.
Alex: jedyną osobą odpowiedzialną za Atari800/WinCE jest Kostas Nakos i odpowiada on na maile z szybkością błyskawicy, oczywiście pod warunkiem, że napisze się po angielsku. Jeśli chodzi o zaśmiecanie
forum, to raczej zaśmiecasz je nie podając opisu problemu.
nosty: procek 200 MHz powinien spokojnie wystarczać niezależnie od rodzaju (chyba że to Z80 ;-) ).
Możliwe przyczyny to ślimaczący się dostęp do ekranu (wtedy trzeba przestawić refresh)
i brak sprzętowego FPU (wtedy trzeba wyłączyć HiFi Pokey). Kostas wspominał też coś o spadku
wydajności po użyciu menu Atari800 do ok. 50%, więc sprawdź, czy to to.
Aha: nie ma też zipa i gza.
(a komodziarze zipa ponoć mają - i co?)
Jak to co? Portuj:
http://www.cs.tut.fi/~albert/Dev/puzip/
No to rzeczywiście świeża jak piwo otwarte 3 lata temu.
Może jednak lepiej zrobić tak, jak napisałem wyżej.
A poza tym nie wkleiłeś błędów, które się pojawiają, nie napisałeś, której wersji Visuala używasz,
nie wiadomo jakie błędy w GUI masz na myśli - jakiej pomocy więc oczekujesz?
Alex: co rozumiesz przez "najnowszą wersję Atari800" ? Jeśli Ci się mocno nie spieszy, to zaczekaj na 1.4.0, które wyjdzie wkrótce. W przeciwnym przypadku ściągnij sobie źródła z CVSa i ew. mailnij człowieka obecnie odpowiedzialnego za wersję WinCE.
Nosty: refresh na 3, ew. wyłączyć "HiFi Pokey" i może ew. użyć wersji nowszej od 1.3.6.
Jak sam zauważyłeś, PocketC64 jest komercyjny i pewnie nie odpala wielu demek (w odróżnieniu od Atari800).
Mi działa.
Ta, generalnie organizacja compo byla taka, ze no szkoda gadac. Wszystkie przekrety na wszystkich party o jakich slyszeliscie razem wziete to nic. To, co napisal Andreas w tym topicu to nieprawda - tak oficjalnie twierdzi ABBUC. Poczekamy jeszcze troche i zobaczymy. Jeszcze nic pewnego, ze napijemy sie z Epim za ich kase.
... oraz stopniowe wersje zrodel efektow, zeby bylo wiadomo, ze kod nie jest np. zwalony z komody. ;)
A tak powaznie, to jesli chodzi o grafike Anj zglosil swietny pomysl.
To znaczy jak? (Sorry. 6 lat temu może bym skumał od razu, ale nie teraz. Czy chcesz w każdej linii odpalić DLI i podciągnąć obraz VSCROLLEM o 3 linie? Czy VSCROLL nie ma jakiegoś górnego limitu podkręcania po którym licznik się przekręca?)
Opis jest w "Atarynce". W skrocie chodzi o to, ze VSCROLa zwiekszasz i zmniejszasz, a jednoczesnie wlaczasz i wylaczasz w DL.
a robie to dlatego, że chce zobaczyć coś więcej... Poza tym, w kweswtii tego "zbliżania" się; ile nowości można było zaobserwować w latach 95-97, a ile 98-2k3? Z jakiegoś powodu jest ich mniej; a co do osiągnięcia wszystkiego?
Jak pisałem, to problem nietechniczny.
SIKOR -"Ale - znacznie szybszy w przetwarzaniu rozkazów, nieprawdaż?"
Ano, tak się składa, że odpowiedź brzmi: NIEPRAWDAŻ - w trybie emu 65c02 wszystko wygląda identycznie jak w przypadku 6502 - wyłączając z tego nielegale' o czym już chyba pisałem.
65c02 ma w pojedynczych przypadkach rozkazy szybsze o cykl. Tak wiec kod wycyklowany dla 6502 moze nam sie rozjezdzac z obrazem. Poprawna obsluga nowych prockow to nie tylko nieuzywanie nielegalnych instrukcji. W Numenie nic sie nie kaszani na 65816?
trudno na ekranie 80x25 zmieścić tyle informacji.
To przyznam sie, ze dawno temu mialem pomysl pisania swojego programu muzycznego z trybem tekstowym 40x40. Font 8x5 + puste linie. Organizacja pamieci normalna + trzeba odpalic DLI. Ew. znaki 8x6 bez pustych linii.
Jedynym slusznym emulatorem malucha na wszystkie platformy jest Atari800. Jeśli dla kogoś jest zbyt wolny, to są trzy rozwiązania:
1. Nauczyc sie go dobrze konfigurowac.
2. Dolozyc staran, zeby byl lepszy, czyli dolaczyc do projektu. Nie trzeba umiec programowac, od lat projekt czeka po prostu na dobra dokumentacje.
3. Nie uzywac emulatora.
Z emulatorem jak z zegarkiem - ma byc dokladny, a nie szybki.
Trzeba wiec podejsc do sprawy filozoficznie, mowiac 'sral to pies' i pic dalej.
Mojej filozofii blizej do 'nie bedzie lamer plul nam w twarz'. Bardzo dobrze, ze Pinokio powiedzial, co mysli. Czekam na odpowiedz Mariusza, do ktorego osobiscie nic nie mam.
Jak dla mnie mogą zajmować nawet 6 stron. Jeśli komuś brakuje flopek, to ja mam w nadmiarze. :)
Efekty na 6502 są z pewnością baaardzo git, lecz jak wykazuje praktyka ostatnich lat wymyślenie na w/w czegoś nowego zaczyna stwarzać coraz większe "problemy".. chodzi o fakt powolnego zbliżania się do "granic" możliwości sprzętowych
Dodajmy: bardzo powolnego i jesteśmy jeszcze bardzo daleko.
Chyba, że ktoś jest już blisko, to niech się ujawni.
Nie jestem przeciwnikiem 65816, ale nie rozumiem jak koder może powiedzieć, że będzie pisał na 65816, bo na 6502 już wszystko osiągnięto. Problemy są nietechniczne: wkrótce większość scenowców osiągnie wiek Vasca, gdy był już stary. :)
atari.area forum » Posty przez Fox
Wygenerowano w 0.067 sekund, wykonano 24 zapytań