( TCH | 2021. 02. 22., h – 10:07 )

Thx. Ezt a bebbo féle 6-os GCC-vel fordítom, de elméletileg SAS/C-vel is fordulnia kéne, csak most minden szét van itt szedve/borítva, nem próbáltam le az original gépen, a régi környezet még a RocTec-es HDD-ken van.

Nem, ezt EHB-vel nem lehet megcsinálni, legalábbis triviálisan biztos nem, két okból. Egyfelől ugyan az igaz, hogy az EHB 64 színű, tehát abból is lehet 64 egy sorban, de ebből csak 32-őt lehet szabadon állítani, ez pedig minduntalan összeakadásokba fog torkollni, még a csatornák színei is ütközni fognak; nem tudsz olyan palettát összeállítani még egy sorra sem - még akkor sem, ha a színsorrendet figyelmen kívül hagyjuk - ami jó lenne. (Arról konkrétan infóm sincs, hogy a felezés analóg módon történik-e, a "digitális hardware-en túl", azaz a valós feszültségértéket fogja felezni a rendszer a kimeneten és így pl. egy 9-es összetevőből "4.5" lesz, vagy pedig "belül" feleződik és mivel a hardware csak 16 szintet tud per csatorna, így ez 4-re redukálódik és ez is ütközni fog a 8-asból felezett 4-essel.)
A másik ok meg az, hogy Copper mágiát itt lehetetlen lenne alkalmazni, pont az miatt, amit a záróakkordban leírtam: a Coppernek is van késleltetése (konkrétan a 32 színregiszter végigírása 6 bitplane esetében 528 pixelig tartana ((1 + 32) * 16)) és a felbontása 4 pixel "durva", tehát csak nagyobb négyszögeket lehetne vele csinálni, ami meg már nem férne rá a képernyőre.
Pont CPU-val lehetne megcsinálni, mert annak ilyen bajai nincsenek, csak oda meg minek EHB, akkor a monokróm képernyő is jó, teleírva egyessel, majd CPU-ból időzítve az 1-es színregisztert módosítjuk végig. :)

Bezony, ez WineUAE. :)))