Nie potrzebujesz G2F. Konwertujesz obrazek jakimkolwiek fotoszopem do odpowiednich rozmiarów i 16 odcieni (zwróć uwagę na kolejność odcieni w palecie!), flipujesz wertykalnie, zapisujesz jako BMP bez kompresji, na Atari wczytujesz obcinając nagłówek, pi razy oko to będzie w tym przypadku jakieś 120 bajtów, ale to sobie już na czuja dograsz.

g2f zlicza sobie kolory ktore wystepuja na obrazku i na podstawie czestotliwosci ich wystepowania przyporzadkowuje je do kolejnych rejestrow koloru, tak wiec kolor ktory najczesciej wystepuje bedzie kolorem tla (712), potem kolejno 708, 709 itd.

dla trybu 9 będę musiał zabronić mu liczyć kolory, wtedy będzie ok

tebe - to chyba cos innego
troche sie pospieszylem z diagnoza. Zrobilem dalsze testy wczytujac "recznie" do pamieci ekranu trybu 9 bitmape z pieca (80x192 grayscale 4bity na pixel).
Okazalo sie, ze zarowno Atari jak i G2F w sposob prawidlowy i "naturalny" interpretuja kodowanie odcienia pixela na polbajcie: $0 - czarny, potem stopniowo coraz jasniejszy az do $F - bialy.
Tymczasem na piecu jest to chyba jakos inaczej. Czarny i bialy sie zgadzaja ale odcien czarego $B jest na biecu jasniejszy niz $D. Zglupialem troche.

A znieksztalcenia kolorow na krawdedziach obiektow tez sie wyjasnily - myslalem ze zrobilem tylko 3 obiekty w 3 odcieniach szarosci. Zapomnialem ze robilem reskalowanie do 80x192 i wtdedy IrfanView zrobil mi to inteligentnie resamplujac i robiac plynne przejscia za pomoca innych odcieni.

Szukam dokladniejszego opisu formatu BMP w sieci.