Pin... ale proszę nie używaj takich bezsensownych argumentów ... pytasz "ogólnie" a czepiasz się "szczególnie" fragmentu odpowiedzi o którym wiesz, że ma inna wymowę w kontekście twojego pytania. Ja nie napisałem nigdzie, że ten program jest przykładem "wyciskania czegokolwiek" tylko, że "wyciskanie" wymagać może omijania czegoś co ktoś uznaje za standard. Mam nadzieję, że nie musze tego jeszcze dobitniej wyjaśniać. Pozwolisz, że zacytuję "Dałem przykład - myśleć".
Ty piszesz o programistach zawodowych. Czy zakładasz, że ktokolwiek na tym forum jest zawodowym programistą Atari? Już w tym kontekście twoje pytanie/zarzut było pozbawione sensu. Bo czemu niby amator Atari ma się trzymać standardów? Nie zadziała na innym sprzęcie, to nikomu nic sie nie stanie i co najwyżej zrobi kolejną wersję skoro ma takie "widzi-mi-się".
BTW XXL pisze przy pomocy tego jakiś minimalny generator labiryntu ... zwracam uwagę na słowo "minimalny". Zresztą nie ważne co pisze. Ważne, że mu się chce.

@Pin - proponuję zatem, by do regulaminu kompotów dopisać punkty:
1. Projekt zgodny ze schematem MVC
2. Założenia muszą być opsane w UML
3. Spełnone metryki HIS
4. Unit testy - bądźmy litościwi - niech będzie przynajmniej 90% pokrycia.
Parę kolejnych punktów pewnie by się dało dodać.
Myślę, że będzie stado chętnych :).

A tak całkiem serio - koledzy chyba przeoczyli fakt, że sprzęt Atari (XE i ST) to jest już trup. Trochę podgrzewamy tego trupa nowym softem i/lub sprzętem, ale jednak wiele to nie zmienia. Nas (podtrzymywaczy) raczej ubywa niż przybywa więc to podgrzewanie coraz słabiej nam wychodzi.

@Pin - i dobrze. Bo to taki korpo-dev-dełkot :).
Ale na scenie używać tego nie trzeba, więc kod pisze się swobodniej. I na tym zabawa polega.

Inna rzecz, że łamanie standardów demoscena ma w swoich genach.

https://www.youtube.com/watch?v=Hfq9LwXcPpA

- w kodzie nie ma zadnego bezposredniego zapisu do pamieci ekranu, wszystko leci przez OS

- stos programowy w tym trybie zabiera 2.5 kb

- systemowy fill to jakas porazka, juz stawianie punktow w petli bylo szybsze ale za to funkcja z posta 57 robi robote :-)

i najwazniejsze - wielkosc kodu, no niestety 3 strony pamieci :/ kiepsko.

Wszystko to znajdziesz u Zientary w "Procedurach Wejścia/Wyjścia": http://tajemnice.atari8.info/ksiazki/index.html
Można spojrzeć do "Procedur interpretera BASIC-a" w jaki sposób realizowane jest LOCATE - wydaje mi się, że x i y należało wstawić do COLCRS i ROWCRS po czym wykonać GET (PLOT analogicznie, ale z PUT-em). Ale głowy nie dam.

http://www.atarimagazines.com/compute/i … _Atari.php

nic odkrywczego, dokladnie ten sam program:

wykorzystujac procedury graficzne OS bezposrednio: 28 sekund
wykorzysujac CIO: 76 sekund

dwa i pol raza szybciej jest bez CIO

czasem przychodzi potrzeba sprawdzenia w jakiej rozdzielczosci pracujem. niestety sterownik nie ma takiej funkcji wiec albo tabelka albo:

os_graphics      equ $ef9c
GETCH            equ $F180
rowcrs           equ $54
colcrs           equ $55
dindex           equ $57
newrow           equ $60
newcol           equ $61

          lda #7
          jsr os_graphics

          lda #0
          sta colcrs
          sta colcrs+1
          sta newcol
          sta newcol+1
          sta rowcrs
@         inc newcol
          bne @+
          inc newcol+1
@         jsr GETCH
          lda rowcrs
          beq @-1
          ldx dindex
          lda $EE8D,x
          sta newrow

w newcol i newrow mamy odpowiedznio rozdzielczosc pozioma i pionowa.

ok, a informacja o szerokości obrazu w bajtach, czyli ile bajtów przypada na poziomą linię obrazu ? też takim sprytnym sposobem czy tabelką ?

To przy okazji informacja o bitach na piksel:
00 = 8 bitów (tryby znakowe)
01 = 4 bity (tryby GTIA)
02 = 2 bity (tryby 4-kolorowe)
03 = 1 bit (mono)

i ten pierwszy sposob:

    ldx dindex
    lda $ee7d,x
    cmp #<320
    beq @+
    clc
@   ldy $ee9d,x
@   dey
    bmi @+
    ror @
    bne @-
@   A = byte per line

dziękuję Panowie, procedura InitGraph w MadPascalu jest teraz krótsza blisko 100 bajtów :)