http://sources.atari.pl

Takich gotowych kawałków to nie ma wiele: na myśl przychodzą mi tylko plejery msx i procki do dekompresji (BTW. optymalizuję inflate - obecnie ma 512 bajtów, w Numenie >700). Procedury mnożenia to bardziej nadają się do Atariki - np. można przepisać mojego arta z Syzygy.

Mnożenie stałych? W takim razie mój kod wygląda tak:

    mwa #[A*B]&$FFFF    wynik
:[A*B]>>16!=[A*B]>>8    lda #[A*B]>>16
    sta    wynik+2

Można to jeszcze zoptymalizować, ale 15 cykli w najgorszym przypadku jest zadowalającym wynikiem.

Jakieś zabawy ze znakiem na końcu tego kodu to raczej niepotrzebne. Jak się dobrze zaindeksuje x*x/4 to wynik wychodzi od razu z właściwym znakiem.

Zoptymalizowane, tylko że na długość. Na szybkość to trzeba po prostu zinlajnować JSRy.

Ja bym opuścił "GO TO" i zostawił sam nr linii. Jak wiadomo "goto" świadczy o złym stylu. ;)

Moja wykłada się jeszcze bardziej. :)

Bezczelnie zapierniczyc lepiej nie próbuj, ale jeśli grzecznie zapierniczysz, to proszę bardzo. ;)

This is a good choice if you need high compression ratio and quick decompression.
The destination buffer must be continuous, so if you need the uncompressed data to be scattered in the memory, you need to run an additional simple routine that moves blocks in the memory. Numen, of course, contains such a routine. :)

There are several problems with packing executables with embedded INIT routines:
* should the INITs be run while loading from disk (each part before INIT is decompressed separately; should the depacker be re-loaded after each part?) or while depacking (whole file is compressed) ?
* INIT routines are free to mess with the memory in an unknown (to the packer) way, therefore the packer does not know which memory remains available
* some INIT routines do system checking such as MEMLO or whether the loaded program is already installed - these checks should be run as early/quickly as possible
* in many cases INIT routines are small and doesn't compress very well if at all

Since I found no good solution, FP simply rejects executables with embedded INIT routines.
My experience is that INIT routines are especially useful for "loading" messages and these can be easily added to the already packed executable.

Not true, FP can do that.

Muszę tylko zrobić wypełnianie tagów NAME, AUTHOR, DATE na podstawie wyświetlanych napisów. ;)

Wzory będą wychodzić nieco różne w zależności od orientacji układu współrzędnych (czy jak to się tam nazywa - chodzi o to, że 3 prostopadłe osie można narysować z różnymi zwrotami), kierunku oraz kolejności obrotów.

Warto nadmienić, że mnożenie funkcji sin/cos można przekształcić na dodawanie/odejmowanie, co daje jeszcze bardziej wielgachne wzory, ale można policzyć całą macierz w jakieś 300 cykli przy użyciu zwykłej tablicy sinusa. Gotowe procki w Numenie.

ASAP 0.2.1 (z obsługą TM2, bez m.in.) pewnie w okolicach łikendu.

Natomiast kolejna wersja SAP Makera (obsługująca te formaty, które obsługuje ASAP) - w bliżej nieokreślonej przyszłości...

Czy konwertowanie na SAP nie będzie konieczne - no nie wiem. ASAP (jeszcze?) nie wygryzł całkiem innych plejerów. ;) Poza tym w SAPach są AUTHOR, NAME, DATE (z drugiej strony w TM2 też jest trochę miejsca na tekst).

Stary patent. Nawet heyah ma taki wygaszacz pod windę na stronie.

Bardziej hardcorowe byłoby np. wyświetlanie w kodzie Graya.
Albo ósemkowo (zegarek powinien wyglądać normalnie, żeby nie wzbudzać podejrzeń). :)
Albo LFSR (czyli to co jest w POKEYu do generowania zniekształceń) zamiast licznika.

Jeśli sam implementujesz FP, to możesz jak najbardziej wybrać reprezentację little-endian.

W przypadku CC65 korzystniejsze wydaje się big endian - tj. wykładnik w akumulatorze (dla intów i longów jest tam LSB).