Érdekes dolgot vettem észre.
 Graphics 2-ben a pixelek soványak. 1:2 arányú szélesség:magasság méretnél.
 Graphics 4-ben a pixel pont arányosan négyzet.
 Graphics 16-ban pedig lapos 2:1 arányú.

 A Microsoft Paint csak arányos 1:1 pixelt támogat.
 Emiatt hogy a kép hasonló legyen, Graphics 2 ben minden pixel mellé kell tenni egy másikat. Graphics 16-ban pedig fölé.
 A Graphics 2-ben mellérakott pixel máris Graphics 4-et eredményez, akkor viszont már 4 színt is lehet használni.

 Vannak olyan rajzolóptogramok amik támogatják az aránytalan pixelméretet, de ennek a témának a mélyére nem akartam menni.

 Graphics 2 esetén interlace móddal lehetne arányos pixelt csinálni, de annyira körülményes az interlace, hogy ezzel nem foglakozom.

 Nagyon érdekes a dolog az is ha az EP nem monitorra hanem tv-re van kötve és PAL Composite jelátalakítás miatt bizonyos színeket összemos/összekever, a "dithering" (pöttyösítés) miatt akár új színnek jöhetnek létre. Ennek oka, hogy a színátvitel sávszélessége elég keskeny, a gyors színváltoztatást csak átmenettel tudja kijelezni.
 Az jutott eszembe, hogy az emulátorból pont ez a funkció hiányzik, amikor a képpontokat elkeni mint egy TV képernyő. Az elkenésnek köszönhetően lesz szebb a kép.


 

Majd megnézem, köszönöm a tippet.

 Akkor értettem meg az általad említett "homályos vacak" dolgot amikor valamelyik retro youtube tartalomkészítő kitért erre a témára, és összehasonlított játékokat kompozit ill. RGB bemeneteken. Mondta, hogy sok játéknak azért olyan furcsa a színválasztása, mert compozit jelre volt optimalizálva. Megmutatta a két képet összehasonlítva.
 Szerintem a Playstation 1-nél is azért volt, hogy TV-n szebb mint emulátoron, mert sok szűrést-simítást elvégzett a kompozit konverzió.

 Én az RF jelet tartom homályos vacaknak. A compozit jel hozzá képest nagyon szép.

15-20 évvel ezelőtt lehet hogy gondolkodtam volna tömörítésen. De manapság már amikor terrabájtokat tárolunk otthon, és az EP is bővíthető 3 Megabyte-ig gond nélkül, nem hiszem hogy a 10kb / 1kb probléma akkora gond lenne.
 Létezik EP-re SD-kártyás floppy emulátor is. Merevlemez is. Az emulátorban meg úgyis mindegy.

 Onnan indultam, hogy a legegyszerübb programmal (Microsoft Paint) összedobok valami grafikát, elmentem és amott betöltöm. A paint BMP-t nem tud úgy tömöríteni. Ha pedig egy harmadik programot kell használni, akkor az egész már túl bonyolult.

 Már Photoshoppal is beleestem a problémába, hogy nem nagyon támogatja a kevés színnel való munkát.

IDK how IS-BASIC really works, so maybe I'm asking something stupid. Could you replace the GOTO in lines 545 and 565 with NEXT? That may add a bit to the speedup if syntax allows it.
Nem tudom hogyan működik igazából az IS-BASIC, szóval lehet hogy ostobaságot fogok kérdezni. Ki lehetne cserélni a GOTO-t NEXT-re a 545-ös és 565-ös sorokban? Ha a szintaxis engedi az még adhat egy keveset a gyorsításhoz.

Very interesting in other programming languages you cannot place the nesting-function-end (NEXT/LOOP etc) multiple places in a program code.
If you want to end the cycle in the middle, you have a special command for example "EXIT DO", "EXIT FOR", or in other language "break;".
Probably because the interpreter parsing algorithm must find easily the start and end of the nest, cannot be placed after an IF statement.

Hun:
 Nagyon érdekes, hogy más programnyelveknél nem teheti az ember akárhová a ciklus záró kulcsszavakat (NEXT/LOOP stb).
Ha arra van szükség, hogy a ciklus közepén kilépjen az ember, akkor erre van egy külön parancs "EXIT DO", "EXIT FOR" vagy más programnyelvben a "break;".
Ez valószínűleg azért van, mert a fordító kiértékelő algoritmusának biztosan tudnia kell, hogy hol kezdődik és végződik egy ciklus, nem lehet feltételhez kötni.