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ć.

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 ... :/

Po co "ripować"? Przecież pisałem, że procki pana Marsletta są dostępne w _postaci_źrodłowej_.

Jest, jest. Momentami :)

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.)

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.

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 :-)

nosty, to nie jest takie proste. W takim emulatorze atari800 większość mocy maszyny zżera prawdopodobnie nie tyle sama emulacja CPU, co fakt, że emulator musi też utrzymać proporcje czasowe rozkazów i w ogóle działania całości. Czyli, LDA #$02 / CLC / ADC #$02 nie ma tylko dodawać dwa do dwóch, ale jeszcze zrobić to w sześć cykli wirtualnego czasu. To tak tytułem prostego przykładu.

Poza tym faktem jest owszem, że dzisiejsze procesory są nowsze i lepsze, ale zwróć uwagę, że 6502 jest procesorem ośmiobitowym, a rozkazy operują na pojedynczych bajtach. W związku z tym spora część mocy obliczeniowej takiego 32-bitowego procesora jak Motorola 68030 się przy emulowaniu takiego LDA/STA po prostu marnuje, bo co z tego, że procesor jest w stanie machnąć 32-bitowe move, skoro to w normalnym silniku 6502 w zasadzie nie zachodzi (aczkolwiek można posztuczkować, pewnie, wszystko można). Itd.

Do użycia MMU w celu bankowania pamięci nigdy nie doszedłem, porzuciłem dalszą pracę nad tym programem sporo wcześniej, kiedy się przekonałem, że host jest za wolny na to, co chcę zrobić. Teraz (68060/66 MHz) jest prawdopodobnie wystarczająco szybki, no ale mi się już nie chce.

Cieszę się, że nieporozumienie zostało wyjaśnione.

Zgadza się, o tyle o ile. Kompilator faktycznie "rozumie" program pod względem formalnym, "wie" co robią poszczególne instrukcje oraz złożone z nich wyrażenia. Nie rozumie jednak programu jako całości, nie wie, do czego on ma służyć i co W ISTOCIE robić. Nie może tego wiedzieć, bo jest tępym automatem o zerowej inteligencji i coś takiego jak "koncepcja" czy "idea" jest mu kompletnie obce.

W 9999 przypadków na 10000 ta wiedza nie jest mu do niczego potrzebna, a efekty i tak są zadowalające. Zachodzi jednak wyjątek, o którym tu mowa, przy którym kompilator nie jest w stanie wykorzystać zasobów maszyny, bo nie wie, że mogą być ewentualnie do tego przydatne. A nie wie tego, bo nie wie do czego mają być przydatne, a tego z kolei nie wie, bo nie rozumie, co program ma robić. Itd.

Nie będzie. Język C nie pozwala na zastosowanie takiej konstrukcji. I wolałbym, żebyście jako ludzie inteligentni obaj czytali ze zrozumieniem to, co piszę.

Fox, zgodzę się z Twoimi twierdzeniami zawartymi powyżej bardzo chętnie, jeśli siądziesz do gcc i napiszesz silnik 6502, który po skompilowaniu z dowolnymi opcjami optymalizacji będzie na tej samej maszynie (68030/16 MHz) działał chociaz o połowę wolniej niż mój silnik asemblerowy.

I póki to nie nastąpi, może zawieśmy tę dyskusję, bo niestety ja wiem, co mówię, a Ty nie (oczywiście, bo nie znasz mojego kodu, a ja owszem).