NickAddr0: INTEGER is declaring a signed variable. When you divide by 16 it will do a signed divide.

You need an unsigned variable instead. I don't know how to do that in your Pascal, but in some you can declare NickAddr0: WORD.

----Google Translate ----

NickAddr0: Az INTEGER aláírt változót deklarál. Ha osztja 16-ig, akkor aláírja a megosztást.

Szüksége van egy aláírás nélküli változóra. Nem tudom, hogyan kell ezt tenni a Pascalban, de egyesekben kijelentheted NickAddr0: WORD.

Sikerült az eredeti LPT címének a visszaállítása!!!! Valószínűleg tényleg a 32767 fölötti érték zavart be, hiába volt átállítva POKE-okkal az INTEGER a 0..65535 tartományra. Azért be kell vallani, hogy nem csak ez volt az egyetlen hiba, csináltam én is párat. Egyet kiemelnék: az LPT-nek kevés helyet hagytam (ez a bitmap előtt van), így nagy képnél a bittérkép első sorát felülírta az LPT vége, ez is javítva lett. Ezt a képet a Pascal program töltötte be, és utána visszaállította rendesen a képernyőt. Újfent köszönöm mindenkinek a segítséget, nagyon jó fórum ez nagyon jó társasággal!

Maga a konvertáló program most nem változott, csak a példaprogram és a leírás, de a verziószámot átírtam a mai napra, ezért újrafordítottam.

Módosítás: mégis változott a program, a konvertált kép nagyításánál volt egy hiba, ami javítva lett. Ahogy látom, még nem lett letöltve a hibás verzió.

Nem. Azt az üzemmódot nem ismerem, meg így is jóval több lett a program, mint aminek indult (16 színű módban háttérkép készítése játékhoz).

Az az üzemmód nem a 256 színű módhoz áll legközelebb? Felbontásban és színekben mintha ugyanaz lenne, csak valahogy karakteresen éred el és a karakter kódja határozza meg a színt, ha jól értem. Vagy miben más ez, mint egy HIRES 256 képernyő?

Karakteres módban is van 2, 4, 16, és 256 szín, és chr64, chr128, chr256 mód
Annyiban különbözik a bitmap módtól, hogy van egy külön memória rész a karakter definícióknak, (8 pixel magas karakterek esetén chr64 módban 200h , chr128-ban 400h, chr256-ban 800h a mérete)
ennek a címe található meg az LPB 6-7 pozíciójában (kis számolgatás szükséges ), és az LPB 4-5 pozíciójában található character map, ami a képernyőn megjelent karaktereket tartalmazza, egy bájt azonosít egy karaktert a characterset memóriában, és az jelenik meg a képernyőn.
A színek is érdekesek ebben a módban, 2 szín módban 1 színpártól egészen 4 színpárig be lehet állítani a használt színeket, és a színeket a character map karakterkódjainak felső két bitje szabályozza (1 színpár használatánál természetesen nem )
4 szín módban 2 x szín négyes használható, természetesen a felbntás feleződik a 2 szín módhoz képest (4 pixel széles egy karakter)
16 szín módot még sose használtam, de gondolom a paletta 16 színéről veszi a színeket, és 2 pixel széles egy karakter
256 szín módban minden karakterset byte 1 színt azonosít, és 1 pixel széles egy karakter

Akkor ez inkább az attribútum üzemmódhoz hasonlít, de mégis más. Ha megértem pontosan, akkor majd megnézem, hogyan lehetne ezzel kibővíteni a programot. Geco magyarázata érthető, csak kell némi idő megemészteni.

Akkor egy kép -> ascii konverterhez hasonló, csak itt a karakterek is definiálhatók, plusz vannak színek. Ez teljesen más logika, mint sok színből kiválasztani 16-ot, aztán ditheringgel még javítani rajta.

Fel kéne osztani a képet X*Y méretű karakterekre, majd azokat, amik nagyon kicsit különböznek alakra, egy közös bitmap-pal helyettesíteni. Ezt addig folytatni, amíg 64, 128 vagy 256 különböző marad. Aztán lehetne színezni. Az mondjuk megzavarhatja a konvertálást, ha az ismétlődő részek nem X és Y többszörösének megfelelő pozíción vannak. Ki kéne próbálni, milyen hatású képet csinálna.

Minden 8 sorhoz saját karakterkészlet az már szinte bitmap. Azzal az összes 8*8-as terület lefedhetô, ha mondjuk 46 karakter széles a kép. Akkor inkább mindegyik ilyen területet egy-egy konvertálandó mini képnek kellene tekinteni, és kiválogatni hozzá azt a 2 vagy 4 színt, ami leginkább jellemzi. Mint attribútum módban.

Kotasoft EP128pal 2.180126-os verzió változások:
- blokkonként különböző videomódok támogatása (ehhez új vezérlő van a kép bal oldalán)
- a videomódok miatt megváltozott az .EPI kép formátuma (a videomódot a blokkokba menti, a vízszintes méretet nem tárolja, stb.)
- a Pascal és Basic példaprogramok módosítása az új formátumhoz
- a pixelsoronkénti üzemmódot jobb kattintással egyszerűbben lehet be/kikapcsolni
- a kép arányos átméretezésénél be/kikapcsolható a teljes kitöltés

A változó videomódokkal kíváncsi voltam, hogy milyen hatást lehet elérni. Igazából inkább csak érdekes lett, mint látványos, de ha a Nick chip támogatja ezt, akkor érdemes kísérletezgetni vele. Talán olyankor lehet jó, mikor egy grafikus játék fölé/alá valamilyen nagyobb felbontású logót szeretnénk elhelyezni. Érdekes lehet esetleg a pixelsoronként változó videomód, mert a Nick ilyet is tud, de ahhoz nagyon át kéne alakítani a program felületét, hogy ezt kezelni lehessen. Esetleg fixen két üzemmódot váltakoztatva, pl. attribútum és 256 szín, vagy valami algoritmus megnézné, hogy melyik üzemmód lenne a legjobb... A mostani verzió csak a 9 egész számú többszörösének megfelelő méretű blokkokat támogatja, ami annyiból jó, hogy szabványos EXOS videolapokkal is használható pl. Basicből.