wychodzi ze ACE jest 2x szybszy od SDX
I znowu bzdury. ACE nie może być szybszy od SDX, bo to nie SDX rysuje ekran, tylko sterownik ekranu uruchomiony pod SDX :)
.. a że szybszy - to świetnie!
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Sprzęt - 8bit » Tryb 80 kolumn, RC_GR8, ACE-80, SDX itp.
Strony Poprzednia 1 2 3
Zaloguj się lub zarejestruj by napisać odpowiedź
wychodzi ze ACE jest 2x szybszy od SDX
I znowu bzdury. ACE nie może być szybszy od SDX, bo to nie SDX rysuje ekran, tylko sterownik ekranu uruchomiony pod SDX :)
.. a że szybszy - to świetnie!
a moj sterownik E80 - zajmujacy 2 strony pamieci :-) gdzie nie ma mowy o optymalizacji pod wzgledem szybkosci wyciaga...
4:05 ( 3:57 ) hehehe
30 bajtow wiecej i:
3:47 - przy czym korzystam z systemowej procedury konwersji adresow, podejrzewam ze 100 bajtow wiecej i mialbm wynik systemowej procki 40 znakowej :-)
chcialem sprawdzic jak sobie radza sterowniki z obliczaniem adresow - tu nie bedzie scrolla
i wychodzi na to ze wszystkie obliczaja adresy - zaden nie tabelaryzuje?
wiem ze zostane posadzony o stronniczosc bo znowu SDX wychodzi najgorzej (naprawde chcialem mu dac fory bo myslalem ze skoro ma tyle ramu to bedzie tabelaryzowal) ...
test:
10 f.x=1 to 1000
20 a=rnd(0)*70
30 b=rnd(0)*20
40 pos.a,b
50 ? "atari";
60 n.x
70 gr.0
ACE80: 0:54
SDX80: 0:58
i dla jaj.. moj 2 stronicowy + 30 bajtow sterownik E80
E80: 0:52
najszbszy, a przypominam ze korzystam z systemowej procedury CONVERT ...
taka sytuacja
No to policzmy.
Jak się wywali z kodu linie 20 i 30 (czyli random) a ustawi współrzędne na stałe, np. (10,40), to ten sam kod na SDX wykonuje się ok. 16s (z jedną współrzędną obliczaną to ok.37s czyli jeden RAND, mnożenie i przypisanie daje narzut 21s). Czyli można założyć, że w twoim przypadku będzie to 10s. OK. Czyli 0.01s na jedno pozycjonowanie+wydruk+obrót pętli. W przypadku SDX będzie to 0.016s. W porządku, obiektywnie rzecz biorąc, SDX jest w tym punkcie zauważalnie gorsza. Szacun dla ciebie.
Ale zaraz, zaraz... Programy tekstowe, mówisz... Czyli użytki, nie gry. Jak często w takim programie trzeba przeliczać pozycję, żeby coś narysować? E... rzadko? Bo w zasadzie tylko przy, powiedzmy, wyświetlaniu okna musisz je narysować, przy czym tutaj będzie tych operacji kilka na okno? Ale potem user sobie wprowadza dane na pewno w tempie mniejszym od jednego znaku na 0.01s. Reasumując - masz szybciej, tylko to takie pyrrusowe zwycięstwo jest.
Nie wydaje mi się, żeby ktokolwiek dał radę pisać z prędkością 100 znaków na sekundę na atarowskiej klawiaturze. Ba, nawet 10.
Bez związku. Kulą w płot.
Ciekawe testy.
@mono: ale ten "myk" ze zgrubnym scrollem pewno nie działa w takim SC, kiedy scrolluje się tylko pół ekranu - pół w sensie w pionie, czyli 1 okno SC. I tu widać jak się to ryyyyysuuuje (atari rapidusless :) ).
Zakładam, że RC_GR8 sobie generuje drugie połówki fontu a nie robi przesunięć w trakcie rysowania znaku?
bardzo ciekawe z tymi fontami, tak sprawdzmy czy sterowniki wykonuja scroll fonta oczekuje wnikow takich, ze te ktore nie scrolluja beda mialy podobne czasy w put char na parzystych i nieparzystych wspolrzednych oraz jesli przechowuja fonty w zestawach 1kb to beda znaczaco szybsze
---
program testowy: raz sprawdzimy pozycje 0,0 pozniej 1,0
10 FOR X=1 TO 10000
20 POSITION 0,0: REM POSIOTION 1,0
30 ? "A";
40 NEXT X
50 GRAPHICS 0
wyniki:
ACE: 0:51 i 0:57
SDX: 1:06 i 1:11
E80: 0:52 i 0:58
napisalbym kasliwa uwage ze sdx przegrywa juz nawet z driverem pisanym na kolanie dwa dni.. ale sprawa staje sie zenujaca...
@xxl: Narzekasz - raptem 10 sekund :)
@sun: myk nie działa z SC bo musisz skrolować cały wiersz; tak, RC_GR8 generuje drugie połówki.
przekaz zespolowi sdx, ze sterowniki powinny byc zgodne z systemem :-) dla trybow znakowch (nawet 80 znakowc) programy powinny "myslec" ze pracuja w trybie znakowm - tak, niektore sprawdzaja :-) atari wprowadzilo pewne reguly dla zmiennych systemowych, po co je lamac... beda wiedziec o czym mowie.
sprawa dwa, wydajniej jest sprawdzic tryb na wektorze put - nigdy nie zaskoczy nas np takie cos:
GR.9+16 (ok.)
GR.9 (nie ok.)
@xxl:
1. To nie SDX przegrywa a ew. driver RC_GR8.
2. Czy Twój driver też "siedzi" w extramie i działa tak jak opisuje mono, czyli przełącza banki?
3. Czy działa z SDX, czyli jest alternatywą dla RC_GR8? Nie? Szkoda, może by nie jeden zamienił RC_GR8 na Twój... z tym że raczej spora część korzystających ze sparty ma U1MB, więc musiałby też działać z tym rozszerzeniem, jeśli to nie problem :)
prawidlowo napisany sterownik dziala z kazdym dos
... a prawidłowo napisany loader ładuje przez OS i to z każdego urządzenia obsługiwanego przezeń :)
@xxl: to jeśli można, poproszę do testów.
Ja tu nie dam się za spartę pokroić, daleko mi do tego. Ma niezaprzeczalne zalety, na razie ja osobiście wad nie znalazłem, co nie znaczy, że ich nie ma.
Super ficzer mono wyjaśniał - jest super duper jak masz Rapidusa, nie mam, więc nie jest super duper ;(
nie szkodzi, mam też inne extramy.
Strony Poprzednia 1 2 3
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Sprzęt - 8bit » Tryb 80 kolumn, RC_GR8, ACE-80, SDX itp.
Wygenerowano w 0.028 sekund, wykonano 70 zapytań