OldComp.cz

Ha, nekontroloval jsem to po nich a měl jsem za to, že když to je bez prefixu, bude to i v sadě 8080.
Lze asi nahradit C2 *rutina+0A* (2 bajty), ale pak to ztrácí relokovatelnost.
21 *odkud* 11 *kam* 01 *kolik* F5 7E 12 23 13 0B 78 B1 C2 * rutina+0A* F1 C9

To ano, jenže to musím vědět jakou barvu ten pixel má mít. Nejde prostě kopírovat data. Pokud třeba chceš kopírovat obrázek (z videoram do videoram), tak jsi v Basicu pořád v pasti. Sice vyčteš, že tam je pixel nebo není, ale jakou má barvu spolehlivě a snadno nezjistíš - CCh se nedá vyčítat a Basic evidentně používá port pro zápis barev, když v RAM mapuje jen jeden 8 kB bitplan G. Takže žádné snadné kopírování dat jako třeba u PMD 85, kde je informace o barvě součástí videoram.

Tady je teoreticky jak tomu rozumím když máme obrázek v .raw nutné nastránkovat do 0A000 postupně všechny 3 bitplany ve správném pořadí, zapsat do nich 3x data a znovu přistránkovat G bitplan aby se Basic nezhroutil resp. grafika fungovala jak má. Tak to dělá příkaz LOAD VAM. Což je u Basicu poměrně časově divoká věc. Nebo obrázek musí být uložený jinak, napadá mě formát 4+1 bajtů kdy 4 bajty obsahují barevnou informaci pro 8 pixelů/bitů třetího bajtu a 2 bity vždy zůstanou na ocet. To je 40800 bajtů na obrazovku. Nebo využít všechny bity a slučovat je, to by byla dobrá prasárna ale pak by stačil formát 3+1. Ale to si rychlostně už raději vůbec nedovedu v Basicu představit . Pak by na screen, o kterém víme co tam má být stačilo "jen" 32768 bajtů. S externí SRAM a v assembleru by to asi nebyl tak velký problém - použilo by se 8 bloků. Co by dělalo problémy by byla synchronizace obrazu ale používat to jako základ pro vytváření různého bitmapového pozadí dle potřeby bych si dovedl představit.

nebo jak psal dex, použít podobný formát z QL ka, 2 pixely na bajt, celkem 32kB RAM (v každém bajtu 2 hluché bity), ale rychlost bude tragická i ve strojáku

vypadá to na papíře krásně že tam je 24kB VRAM, ale obsloužit to pro tvorbu her na 2MHz nebude úplně triviální

Nojo to se tak dlouho šetřilo s pamětí na 8 barev až z toho vypadl v praxi nepoužitelný paskvil... Ještě tak statický obrázek, ale nějaké animace nebo změny, to je problém. Hlavně mě dostává proč nejde přečíst barva z toho barevného portu, s ním by to už naopak mělo smysl když by se datově četl jeden bitplan... Ale holt historie nezná kdyby.

zkusil jsem trošku jinak zobrazit uloženou VRAM ale asi jsem se zamotal v těch portech mapujících RAM/VRAM...

kdo najde kde je chyba? v jakém pořadí ukládá příkaz SAVE "A"VRAM?



v manažeru nahraju obrázek od 2000h, pak kód rutiny od 8000h ale správně je jen bílá, černá a zelená a na konci mi bliká kurzor fialově místo zeleně...

Nevím zda nenosím dříví do lesa ale G bitplan má hodnotu 2x 4 kB buňky a začíná na buňce (vše decimálně) 234, R bitplan 230 a B bitplan 238. V Basicu je přilepený od 0A000 na adresním buňce 0EAh. Viz https://pp01.borik.net/index.php?pg=memorg

Bitplan R je standardně dostupný na 0E6h, 0E7h, bitplan G 0EAh,0EBh a bitplan B je na 0EEh,0EFh. Já třeba pro úsporu RAM i programu v Basicu všechno přilepoval k adrese 0A000h protože nevím co by mohlo Basic odstřelit a pak jsem to zase vrátil do původních hodnot. Tohle je na tom řadiči paměti sympatické, že lze všechno dynamicky přemapovat podle potřeby kamkoliv. Na krátké prográmky mi dobře funguje mapovat externí SRAM na adresu 04000h, úsek 0E4h, s tím jsem ti už včera hrál ale narazil jsem přitom na relikty předchozích hodnot v dalších bitplanech, tedy barvy se rozhází. Dneska jsem chtěl zkusit něco podobného byť v Basicu, což trvá hrozně dlouho ale na proof-of-concept je také dobrý.

Že bliká kurzor fialově je v "pořádku" protože na tom pozadí máš uložené 2 složky barvy, kterou ale třetí složka toho kurzoru změní na jinou. Je to vlastnost hardwaru, takhle se v něm totiž vytváří barvy. Musel bys nejdřív vymazat R a B bitplan na nuly aby byl kurzor zase zelený. Stačí párkrát odentrovat a až vyjedeš z bílého podkladu obrázku, kurzor opět zezelená . Tohle je pro mě nejotravnější vlastnost, protože pro každý nový pixel musíš vědět jakou má mít barvu a ještě si dávat pozor i na oba další bitplany, které ti barvu zase lehce změní na nechtěnou. Viz příloha - původní čtvereček kurzoru je skoro celý fialový, jak se do něj nakopíroval obrázek po zadání adresy 8000 ale poslední řádek je zelený - tam už obrázek nezasahuje. Spodní zelený kurzor už se vykreslil správně do prázdné části obrazovky.

tak jsem měl v paměti nějaký chaos , rutina je v pořádku, už to frčí, akorát to má do 2ms jak psal BUSY pro přesun 24kB dat dooost daleko...

rozbalit někam do SD, a spustit basic

OPR. - opraven BASIC

Jo to vypadá mnohem líp když se kopíruje do všech bitplánů naráz a zobrazí se rovnou obrázek .

V tom BASICu je na riadku 30 zle uvedená cieľová adresa 8000 namiesto 8000H.

_________________
https://pmd85.borik.net - PMD 85 Emulátor, PMD 85, PMD 32-SD
https://pp01.borik.net - PP 01 Emulátor, PP 01, SD-ROM Modul

ono to tak jen vypadá, jede to po 256 bajtech (1 řádek obrazovky)

Ten spodek je vidět že se vlní barevně ale pořád je to vizuálno příjemnější než mít 3x překryv celé obrazovky, která se od originálu barevně poněkud odlišuje .

Ale měl bych námět - co tu rutinu upravit aby využívala SRAM a nahrála data do ní (řekněme od oblasti 0 ať je to jednoduché) přes banku 0E4h tj. od 4000h. Je potřeba rozsah banky 0 - 5 tj OUT 0E4h,0 - 5. Bylo by to mimochodem první praktické využití SRAM a pak by se mohl testovat i přenos RAM to RAM po I41 ve strojáku.

no je to napsané právě takto a s komentářem aby si to mohl kdokoliv upravit dle potřeby jedná se o pár změn
nechceš už opustit BASIC a věnovat se strojáku?

spíš by to chtělo nějaké urychlení v té smyčce 256 bajtů

Já si to procházel a líbí se mi že to je tak pěkně popsané, ale na takové změny si ještě netroufám. Ale někde se začít musí, to zase jo .

Look udělal druhou verzi načítací rutinky a stáhl rychlost zobrazení skoro na polovinu předchozí rutiny, nyní se obrázek na obrazovku načítá rychlostí zhruba 4,1 FPS, což už je dost blízko Busyho očekávané hodnotě 5 FPS (0,2s).

Mas pravdu, tento spobob vykreslovania nie je vhody na hromadne kopirovanie obsahu videoramky. Bol vymysleny prave na urychlenie samotneho kreslenia pixelov, ciar, a dalsich zakladnych geometrickych obrazcov. Proste, aby jednak si nemusel nastavovat prislusny bit na pozadovane hodnoty v troch roznych oblastiach pameti a dvak, aby si nemusel mat namapovanu celu videoramku naraz.
To by asi ani dost dobre neslo, pretoze #CC neurcuje nejaky konkretny pixel, iba to, akou farbou sa nastavia VSETKY pixely, ktore v danom zapisovanom bajte nastavis na jednicku. Cize mozes takto hromadne nastavovat az osem pixelov na danu konkretnu farbu.
Ale inak suhlasim s tebou, niekedy by sa hodila moznost nejak jednoduchsie zistit farbu pixelu, nez len citanim troch bajtov umiestnenych v uplne inych oblastiach pameti a vyskladanim cisla farby z konkretnych bitov v tychto bajtoch. Na toto som narazil pri pisani mojho Sil1k intra, kde kvoli spravnemu algoritmu potrebujem pri mazani ciary zistit, ci dany pixel patri mazanej ciare o danej farbe. Cele to slo hrozne pomaly, tak som spravil este druhu verziu, kde som sa na zistovanie farieb pixelov vykaslal a ciara sa uplne trivialne zmaze natvrdo ciernou farbou. Nevyzera to sice tak dobre, ale ide to niekolkonasobne rychlejsie
(obe verzie intra su sucastou balicku emulatora - v adresari ...\SDRoot\Demos\PP1Sil1k\)
To je fakt, konverzia dat na iny format dost predlzi cely presun. Ale zase az taky pesimista by som nebol, da sa to zvladnut za 2.2 sekundy, plus nejake to spomalenie kvoli zobrazovaniu, tak povedzme do troch sekund by to urcite bolo. Na animaciu to uz nie je, ale pre zobrazenie nejakeho statickeho obrazu, alebo pozadia pod hru, by to mohlo byt akceptovatelne.
To je pravda, na nejake velkoplosne dynamicke pohybujuce sa pozadia do stran (ako je napr. v Silkworm na ZX Spektre) mozeme zabudnut. Treba robit take hry, kde sa toho naraz pohybuje malo, napriklad zopar "sprajtov" ako v Manic Minerovi. Take by sa dali v pohode stihat. Alebo take, kde staci scrolovat celu obrazovku iba hore-dole