Miłośnik magnetofonu - magnetofil?

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 .

Ja na moim slackware 10.1 musiałem przy odczytach sprawdzać ile się faktycznie odczytało danych i powtarzać aż do skompletowania żądanej ilości. Ale może wystarczy jakąś stałą zastosować.

Fill jest w planie zaraz po rysowaniu tekstu na ścieżce, które może będzie nawet dzisiaj.

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

Kiedyś używałem tego programu do pracy nad grą na komórę (j2me). Bardzo przydatna okazała się możliwość pisania własnych skryptów w języku LUA - dzięki temu mając wyedytowany poziom mogłem go sobie zapisać do własnego formatu.
A najbardziej chyba podobała mi się możliwość ustalania własnych atrybutów int i bool dla klocków. Polecam również - całkiem dobre narzędzie o sporych możliwościach.

Nie bardzo podobało mi się użycie klasy z AWT podczas parsowania parametrów commandline'a, które jest przecież niezależne od warstwy graficznej. I nigdzie w programie nie byłby ten Point używany do niczego innego, jak tylko do składowania informacji (jest użyty tylko przy transformacjach afinicznych). Aczkolwiek nie jestem tu konsekwentny - wiem, bo aplikacja jest zbudowana na pochodnej JFrame'a ze Swing'a a w takim razie powinna być np. zwykłym Object'em a okno powinno być wydzielone do osobnej klasy. Trudno jednak sobie rozwarstwić aplikację bo sama AffineTransform jest w pakiecie w AWT :(, a może powinna być w jakimś java.math.geom(?). Konkludując - jestem zdania, że nie powinno się mieszać warstw i stąd użycie Vector'ów (choć powinna być zdefiniowana własna klasa Point ze współrzędnymi dla translacji, oraz analogiczna klasa Factor dla skalowania i pochylania). Jak już wcześniej pisałem projekt mógłby być ładniej napisany, ale to prototyp i chciałem szybko zobaczyć wyniki :)

A co do kodu asm - napisany w jEdit'cie na piecu i assemblowany mads'em 1.8.4, odpalany emulgatorem atari800. Też nieładny i nieszybki z tych samych powodów co wyżej.

Ewentualnie tac - ale to dla ekscentryków.

Hmmm. Ale wydaje mi się, że 20 lat temu w czasach działalności Avalonu (poprzez artykuły w Tajemnicach Atari) właśnie starano się gruntować poprawne nawyki wśród programistów: umiejętności przedłużania wektorów systemowych i korzystania z nich, wychodzenie do dosa, współdzielenie pamięci i zasobów przez programy, pisanie nakładek, handlerów cio itp.

Z inicjalizacją urządzenia E: to jednak mam mieszane uczucia. Bo jeśli ustawiamy wektor dlisty to można go przywrócić. Otwarcie E: jest niezbędne gdy robimy coś w pamięci ekranu i dlisty (choć i tak lepiej chyba zachować ten obszar chwilowo i przywrócić przed wyjściem do DOSa), ale jakoś dziwnie by to wyglądało gdyby po inicjalizacji zwykłej nakładki ekran został zresetowany - po skoku do DOSVEC chyba raczej DOS tego nie robi, a robi raczej przy inicjalizacji po RESET.

Co do wyjścia przez rts - chyba jednak preferowałbym jmp ($a), bo nigdy nie ma pewności z czego odpalany jest program i czy adres powrotu leży na stosie. Nawet zdaje się taki JBW COMmander instaluje się w pamięci przechwytując m.in. wektor DOS i nie każe aplikacjom bazować na powrotach przez rts.

Ja też byłbym zainteresowany.

Jeśli chodzi o rozmiar pliku na dyskietce to nie ma tu żadnych ograniczeń prócz fizycznych możliwości nośnika.
Program ładujący do kolejnych banków może wyglądać np tak (wyjęty z jakiegoś mojego kodu i zmodyfikowany, ale nie przetestowany):

load equ *
  ldx #$10
  lda #4    ;read
  sta icaux1,x
  lda #3    ;open
  sta iccmd,x
  lda <filename
  sta icbufa,x
  lda >filename
  sta icbufa+1,x
  lda #filenamelength
  sta icbufl,x
  lda #0
  sta icbufl+1,x
  jsr ciov
  bmi err
  
  ldy #0
  sty bankindex
loadloop equ *
  lda banks,y
  sta portb
  ;zaladowanie bloku do banku
  lda #4   ;read
  sta icaux1,x
  lda #7    ;getbyte
  sta iccmd,x
  lda <$4000
  sta icbufa,x
  lda >$4000
  sta icbufa+1,x
  lda <$4000
  sta icbufl,x
  lda >$4000
  sta icbufl+1,x
  jsr ciov
  bmi doclose

  inc bankindex
  ldy bankindex
  cpy #bankscount
  bcc loadloop
  
doclose equ *
  php

  ;na końcu włączamy podstawowy bank
  lda #$ff
  sta portb

  lda #12    ;close
  sta iccmd,x
  jsr ciov
  plp
err equ *
  rts

filename dta c'D1:DOWOL.DTA'
filenamelength equ *-filename

;tu są wartości dla portb włączające odpowiednie banki - system powinien być włączony!
banks dta b($c3),b($c7)
bankscount equ *-banks

To Ci pozwoli ładować strumieniowo plik (nie musisz go dzielić fizycznie na ileś tam plików, bo nie ma takiej potrzeby) do kilku banków zdefiniowanych w tablicy banks.
Na wyjściu w Y masz kod błędu, rejestr F nienaruszony w tym sensie, że po jsr load możesz zrobić bmi obsługabłędu.

Niby tak, ale na razie to jest font nieskalowany. A ponieważ jest to stroked font to po skalowaniu zobaczymy pewnie z jakich linii tak naprawdę się to wszystko składa :(. Stroked nie jest wypełniany, jak normalny font wektorowy. Można przy skalowaniu spróbować malować pędzlem kilkupikselowym (a nie jedno-, jak teraz). Inna rzecz, to niestety rozmiar fontu :(. Te z borlanda mają nawet 20 kb; z tablicami dla ekranu i kodem (1kb) to nam zajmuje całą pamięć :(. Ale to chyba cecha stroków - im ma być dokładniejszy tym będzie większy, bo mamy do dyspozycji tylko przesunięcia i proste drawto.