Szukałem dowodu, że kod nie został napisany w QA i w końcu znalazłem: linie dłuższe, niż 64 znaki, więcej niż 6 znaczących znaków etykiet, no i chyba średnik nie działał dla całoliniowych komentarzy.
Czemu Vector<Double> zamiast po prostu Point2D?

coś takiego

scrad equ $80   ;.w

fontfilesize equ $82    ;.w
charscount equ $84  ;.w
firstchar equ $86   ;.b
origintotop equ $87 ;.b

można zapisać uniwersalniej i przejrzyściej

 org $80

scrad .ds 2

fontfilesize .ds 2
charscount .ds 2
firstchar .ds 1
origintotop .ds 1

albo

.zpvar scrad fontfilesize charscount .word firstchar origintotop .byte = $80

Jak na prototyp, zarówno kod javowy jak i asemblerowy jest bardzo ładnie napisany. Argumentacja przeciw Point2D do mnie nie trafia - to jest przecież właśnie para liczb x,y - to Vector<Double> zupełnie tu nie pasuje. Ostrożnie też podchodziłbym do rady TeBego - ręczne przypisanie adresów pozwala łatwiej debugować, można też przypisać różne zmienne pod te same adresy, gdy zaczyna brakować strony zerowej. Polecam natomiast pseudorozkazy, pomijanie "equ *" i skróconą składnię dta - b(foo,bar,quux).

@Fox: dzięki za pozytywny komentarz, lecz z resztą będę jednak polemizował :)
Strukturkę, jak mówi Laoo zastosowałbym bardzo chętnie (i tak zrobię w kolejnej wersji ;)), ale dalej nie chciałbym używać Point'a (i pochodnych) z pakietów AWT. Cały pakiet onebit.chrdraw.chr jest uniezależniony od grafiki, żeby można było go używać np. w aplikacjach serwerowych nie posiadających środowiska graficznego (TextLine służy tylko do zobrazowania wyglądu fonta i jako jedyna powinna być zależna od pakietów graficznych; plus jeszcze kod tworzący okno). Gdybyśmy mieli zależności od AWT, to chcąc wykorzystać kod dla fontu w aplikacji konsolowej, albo serwerowej trzeba by go przerobić pozbawiając zależności od AWT. A co gdybyśmy chcieli pewnego dnia przerobić bibliotekę do pracy w 3D? Mając java.awt.Point i tak trzeba by wtedy napisać nową klasę pochodną z kolejną składową - może pod tym kątem wektor nie jest najgorszy? Wektorowe fonty w 4 wymiarach... ;) Żartuję! Wolę jednak strukturę niż kolekcję.

Nie upieram się przy swoim, bo to jednak kwestia sporna i zależy od upodobań, ale zdarzyło mi się uruchamiać serwer tcp napisany w java5 na platformie dla routerów w okrojonej javie (gnu classpath - http://www.gnu.org/software/classpath/home.html ). Dzięki temu, że nie wykorzystywałem w modelu klas zależnych od środowiska graficznego, poprawki w kilku zaledwie miejscach ograniczyły się tylko do użycia metod z java2 i skompilowaniu wszystkiego dla starej wersji klas (48.0). Uznałem, że uniezależnienie modelu tam gdzie się da od innych elementów aplikacji to jednak dobra praktyka i dlatego stosuję :) Może kiedyś awt i swing wyleci na stałe z javy a sama java będzie miała niewielki rdzeń plus dodatki...? ;)

jest jakas szansa na uzywanie tylko tych stroke'ow ktore tworza obrys,  a pozniej wypelnianie wnetrza zwyklymi procedurami fill'a? (punkt startu mozna by brac z kolejnego stroka)

Ze strony http://www.bookcase.com/library/softwar … rland.html (zarchiwizowane również u mnie) można ściągnać program do edycji fontów .CHR (na samym dole plik bgifont.zip - http://mono.i-demo.pl/bgifont.zip ). Dodatkowo są też pliki z przykładowymi fontami:
- bgi28fnt.zip ( http://mono.i-demo.pl/bgi28fnt.zip )
- bgifonts.zip ( http://mono.i-demo.pl/bgifonts.zip )
- lcdfonts.zip ( http://mono.i-demo.pl/lcdfonts.zip )
Dodałem fonty z bgi28fnt na dysk .atr ( http://mono.i-demo.pl/chrdraw7.atr ).
Przykładowy font H--C.CHR:

Poza tym na razie nie ma zmian.

Edit: Na stronie http://www.programmersheaven.com/downlo … nload.aspx z kolei znalazłem coś takiego: http://mono.i-demo.pl/sfe.zip co jest podobno nowszą wersją edytora fontów .CHR. Działa ładnie z dosemu, ale trzeba mu dokopiować plik http://mono.i-demo.pl/egavga.bgi .