Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Weekend z Borsuk Retro Gry TV Zapraszamy na weekendowe transmisje z udziałem gości, w tym budowę Custom Atari XL i naprawy sprzętu.
AltirraSDL Lobby Przeglądarkowy front-end dla emulatora Altirra z trybem gry wieloosobowej online od Ilmenita.
Test7800 0.8.0 Nowa wersja Test7800 wprowadza wsparcie dla większych kartridży Bankset oraz obsługę Quadtari.
Flob wkracza na Atari ST Platformówka z 8-bitowego Atari zmierza na komputery z serii ST.
Return to Blacktooth dla Atari ST Nowa, izometryczna przygoda w stylu Head Over Heels już dostępna na komputery Atari ST.
atari.area forum » Posty przez drac030
Jeśli robisz to binarnie to bądź tak miły i zachowaj kolejność lo/hi.
Wyniki FASTCHIP-a były liczone napisanym do tego programem w asemblerze i przy włączonym obrazie (w GR.0).
PS. A właśnie, to też jest wada C - nie daje dos?ępu do obliczeń dziesiętnych.
Dlaczego nie możesz zmieścić zakresu E-38/E+38 na ośmiu bitach wykładnika? Atari zakres E-98/E+98 zmieściło na pięciu.
Nie szkoda ci marnowac całego bajtu na znak? Nie lepiej wsadzić go do najstarszego bitu wykładnika? Pewnie i tak jest nieużywany - a miałbyś jeden bajt więcej na mantysę.
Zresztą, co ja się czepiam, czy ja będę używał CC65? Nie przecież :)
Miałem na myśli float Atari BASIC-a.
Ameryki nie odkryłeś. Tyle że o porcie na Intela nikt nie chce słyszeć.
Adam: http://atariarea.krap.pl/forum/viewtopi ... 465#p30465
Słowo się rzekło.
Adamk: ciekawa koncepcja.
Sikor: od razu widać, żeś pod Papyrusem niczego poważniejszego nie napisał. CalamusSL 2006? A kupisz mi?
Seba: subiektywnie - owszem, desktop KDE mógłby byc lepszy, ale Windows XP jest - dla mnie - zdecydowanie mniej intuicyjne. Uzywałem tego przez jakiś rok-półtora, i nigdy za cholerę nie mogłem się połapać, gdzie co jest, a ogólną funkcjonalność tego desktopu do prozaicznych czynności w rodzaju kopiowania plików oceniam jako przyzerową.
O braku systemowego kompilatora C w tym czymś nawet nie wspomnę.
Vulgar: świetnie wiesz, że XL nie służy do pracy, tylko do zabawy (w moim przypadku - programwania w asmie). Natomiast niestety używając Falcona do zastosowań "pracowych" dotarłem do ściany - sytuacji, kiedy dostępne oprogramowanie (Papyrus właśnie) było niewystarczające, a na nowe nie było widoków. Decyzja: pisać własny procesor tekstu czy wyemigrować pod OpenOffice'a zapada dość prosto.
Vulgar, nie zawracaj głowy. Ok, piszę "wy" prowokacyjnie. Cholera mnie po prostu bierze, jak patrzę na marazm, który panuje u polskiego ST i spółki.
Sam musisz sobie zdawać sprawę z tego, że różnica pomiedzy małym Atari a dużym to jest jak pomiedyz akwarium trzymanym dla przyjemności, a stawem z karpiami. Albo przynajmniej *powinno* tak być. Klasa sprzętu nazywana ST/TT/Falcon (ST to chyba tylko z kurtuazji się tu znajduje) pretenduje do tego, żeby w zastosowaniach użytkowych konkurować z pecetami.
No fajnie - tylko gdzie jest oprogramowanie użytkowe? Spadnie z nieba? Kto ma przeportować GIMP-a czy OpenOffice? Ja? A - przepraszam za intymne pytanie - dlaczego k***a ja mam znowu coś za kogoś robić? Czy ty nie rozumiesz, że używanie komputera, przy którym użytkownik, jeśli chce mieć cokolwiek, to musi sam robić wszystko, z poprawianiem systemu operacyjnego na czele, tak że mu juz czasu brakuje na cokolwiek innego - może z biegiem czasu przynosić zmęczenie?
Zwłaszcza, że oprócz poprawiania systemu operacyjnego i pisania samemu wszelakiego potrzebnego sobie oprogramowania użytkowego, *oraz* używania go - trzeba jeszcze kiedyś normalnie żyć, jeść, spać, uprawiać rozrywki? Po prostu od pewnego momentu zaczyna brakować na to czasu. A jedną z przyczyn jest to, że nie ma się wsparcia ze strony innych uzytkowników tego samego komputera - jest za mało programistów = nie ma nowego softu ani nawet ulepszeń starego. A weź "napisz se" edytor tekstu w rodzaju OpenOffice - pięć lat nad tym spędzisz, zamiast nad tym, co miałeś pod tym edytorem napisać!
Wiesz Vulgar, ja tam jestem jak najbardziej za, że Adam wspomina TOS, MiNT itp. Tylko - co poza tym? Gdzie są polskie programy na Falcona? Jedno demo czy coś tam? No sorry. Już nawet nie wspominając o programach - WAS (tak właśnie: WAS) SIĘ NAWET NIE MOŻNA DOPROSIĆ, ZEBYŚCIE OPRACOWALI PORZĄDNIE HASŁA W ATARIKI POŚWIĘCONE ST. No to czego się spodziewasz?
Tak, popełniłem coś tam. Rzecz w tym, że z tego co widzę, polska scena 8-bit umie o siebie zadbać, a scena ST tylko siedzi i czeka, aż przyjedzie mesjasz.
Jakieś tam ST :P Sami nawet nie potraficie o to zadbać (zob. stan Atariki w tej kwestii), to i nie dziwota, że "Atari OS" jest w świecie bardziej znany niż jakiś tam "TOS" :P
Proszę, oto: http://82.210.159.30/65c816/fastfp.arc
Myślę, że problem leży w czym innym: TBXL najwyraźniej jakoś korzysta z pakietu FP znajdującego się w ROM-ie. Wild guess: przepisuje go do RAM-u, a potem w niektórych procedurach, np. logarytmowania, podmienia skoki JSR FMUL/FDIV/FADD/FSUB itp. na wywołania własnych procedur.
Przypuszczam tak na podstawie tego, że wypraktykowałem, iż nie można "zmieszać" procedur z pakietu oryginalnego oraz FASTCHIP-a - są jakoś niekompatybilne (jak - tego mi się nie chciało sprawdzać, mam wprawdzie pewne podejrzenie, ale...). Procedury FASTCHIPO-a w rodzaju logarytmowania, kiedy podstawi im się oryginalne procedury mnożenia, dzielenia itp. zamiast procedur Marsletta - po prostu przestają działać.
Jeszcze jedno: w docach jest napisane, że pakiet po skompilowaniu powinien mieć taką samą sumę kontrolną jak oryginał, w związku z czym podmiana ma być bezbolesna. Tak nie jest, sumy kontrolne różnią się i to dość drastycznie. Przy wymianie pakietu na FASTCHIP trzeba albo przeliczyć na nowo sumę kontrolną pierwszego bloku ROM-u (tę pod $C000), albo tak dobrać "filler bytes" w FASTCHIP-ie, żeby się zgadzało. Mi się tego ostatniego nie chciało robić.
Szkoda, że liczby FP nie są little endian - można byłoby lepiej wykorzystać 816, a dla 6502 to chyba wszystko jedno.
Co do tematu: jednak chyba nie warto wrzucać tych procedur do ROM-u tak jak są. Właśnie odkryłem, że kiedy ROM ma FASTCHIP zaszyty w sobie, wtedy źle działa ... Turbo BASIC XL. Konkretnie objawem jest wadliwe działanie potęgowania i logarytmowania. Wychodzi na to, że TBXL jednak jakoś z pakietu FP korzysta ... :/
Licencja jest zawarta w pliku źrodłowym. A co do udostępniania, to napisałem, że przy okazji.
PS. Przeczytaj punkt ósmy regulaminu, bo się któregoś dnia zdziwisz.
Po co "ripować"? Przecież pisałem, że procki pana Marsletta są dostępne w _postaci_źrodłowej_.
Indus GT jest z tego co mi wiadomo dość podobny do LDW - bo to jest w gruncie rzeczy to samo - przede wszystkim też ma czarną obudowę a zdjęcia są za słabe, żeby coś zdecydować.
Mimo naprawde szczerych checi ja tam nie slysze motywu z Koziolka Matolka....
Jest, jest. Momentami :)
Tia. Interpreter na szczęście jest - nieco - lepszy, dlatego się nadaje dobrze do pisania wspominanych przez piotrav programików na szybko itp. Zwłaszcza, że załadowanie Turbo BASIC-a z twardego dysku trwa ile - dwie sekundy?
No ale ja teraz uzywam TBXL z rzadka do tych celów, <commercial>MultiBASIC jest jednak wygodniejszy</commercial>. ;)
Dlatego jak dla mnie cc65 mógłby być stosowany na takich polach jak:
- sprytne programiki napisane "na szybko"
- programy złożone algorytmicznie (np. jakieś packery)
- generatory, parsery danych
- gry tekstowe
- programy rozwiązujące problemy matematyczne
Do tego - może oprócz "packerów" - jest BASIC, zwłaszcza Turbo BASIC XL. Ma tę przewagę nad CC65, że działa na Atari no i wystarczy RUN (nie trzeba kompilować, linkować itp.)
Ewentualnie można napisać własną funkcję printf, która co prawda nie będzie miała wszystkich bajerów, ale za to będzie 10x krótsza. Oczywiście jej wielkość i działanie zależy już w tym momencie od konkretnych potrzeb.
W tych 90k jest przede wszystkim printf, a poza tym kod inicjujący libc, parsujący linię komend itp. Osobiście uważam, że rozmiar tego jest chory.
Tzn. że napiszesz "a = b;" i wielkość programu wynikowego idzie w setki lub tysiące bajtów.
A czasem w dziesiątki lub setki kilobajtów. Przyczyną jest linkowany do binarki kod startowy, który na wszelki wypadek robi masę rzeczy a na dodatek często dolinkowuje jeszcze funkcję printf (bo "nie ma takiego programu" - oczywiście - "który nie potrzebowałby funkcji printf" :D ), a ta stdio itd.
Jeśli jednak mamy do czynienia z programem - mimo że takie wg tuzów informatyki nie istnieją - który funkcji printf i tego całego badziewia nie potrzebuje, wystarczy podmienić moduł startowy programu. W takim gcc on się nazywa (IIRC, bo dawno nie zaglądałem) bodaj crt0. Jak by się jednak nie nazywał, linker powinien mieć opcję, za pomocą której automatyczne linkowanie tego się wyłącza. Na gcc pod MiNT-em to jest ... zapomniałem, może -nostartup, ale nic sobie nie dam uciąć. Oczywiście pominięcie kodu startowego powoduje, że w większości przypadków przestanie też działać libc, wobec tego nie ma sensu jej linkować (-nostdlib).
Dzięki stosowaniu tego oraz napisanego własnoręcznie w asemblerze kodu startowego o objętości 300 bajtów (zamiast 90k) udało mi się pod MiNT-em spokojnie pisać w C programy, które po zlinkowaniu - statycznym - miały 3-4k.
To nie ja robiłem, bo ja nie umiem. Skonstruował mi to Jacek Żuk, kiedy stracił cierpliwość do moich częstych wizyt w celu programowania EPROM-ów :-)
Rozumiem wasz problem, i moim zdaniem najlepszym rozwiązaniem jest flash. Ja tak mam zrobione, w jednej połówce zapisanej na stałe mam XL OS, drugą mogę sobie programować czym chcę. Jak coś spieprzę, przełączam pstryczkiem, naprawiam i przełączam z powrotem.
atari.area forum » Posty przez drac030
Wygenerowano w 0.137 sekund, wykonano 19 zapytań