Komputery z Z80 > JUPITER ACE
Dema na Jupitera
matofesi:
No to w ramach "wąchania" zrobiłem najprostszego scrollera - font 8x8 (spectrumowy - ten w ROMie jest dziwny i na razie nie chce mi się z nim walczyć ;)), przesuwane o 1 piksel na ramkę. Nie kumam jeszcze tego dialektu FORTHa (a zwłaszcza tego jak obsługuje taśmę w EightyOne) w związku z czym nie ma loadera (nie jestem pewien czy się da w prosty sposób - BLOAD wydaje się być tylko immediate i nie chce wkompliować nazwy pliku w słowo) w związku z czym odpalenie to
--- Kod: ---0 0 bload scroll 16384 call
--- Koniec kodu ---
Nie ustawiam ramtopu, nie testuję ile jest pamięci - zakładam, że pod 16384 będzie RAM ;)
Głównie chciałem sprawdzić czy dobrze myślę, czy da się zrobić to, co wymyśliłem i jak bardzo będzie to skomplikowane. Dobrze, da się i średnio ;)
Teraz doszlifować kanty i mogę kombinować jakiś bardziej zaawansowany efekt :)
KWF:
Brawo :D Uzywaj fontu Jupiterowego prosze. Ten ZXowy wyglada dziwnie na Jupku.
Od 16384 zawsze jest RAM i tylko RAM, jesli zapiety jest plecaczek 2K lub wiecej. Tak jest konca przestrzeni adresowej Z80 ;) Pomijam wynalazki typu DeepThought czy interfejs SD, ktore zjadaja ostanie 8K na wlasny ROM.
Twoj scroller na Jupiterze z fabrycznym 1K RAM to nie pojdzie.
matofesi:
--- Cytat: Klaud w 2020.02.17, 16:05:17 ---Brawo :D Uzywaj fontu Jupiterowego prosze. Ten ZXowy wyglada dziwnie na Jupku.
--- Koniec cytatu ---
Jupiterowy jest dziwny, bo część znaków w ROMie jest zapisanych na 6 a część na 7 bajtach i przeliczanie adresów jak scroller ma być szybki jest kłopotliwe. Na przyszłość wyrwę sobie raz fonta albo napiszę procedurkę wyrywającą z ROMu i przekodowującą do 8x8.
--- Cytuj ---Od 16384 zawsze jest RAM i tylko RAM, jesli zapiety jest plecaczek 16K lub wiecej. Od 16384 RAM jest az do konca przestrzeni adresowej Z80 ;) Pomijam wynalazki typu DeepThought czy interfejs SD, ktore zjadaja ostanie 8K na wasny ROM.
--- Koniec cytatu ---
Czyli jak piszę coś, co i tak nie ruszy na standardowych 3K mogę spokojnie pakować kod od 16384?
--- Cytuj ---Twoj scroller na Jupiterze z fabrycznym 1K RAM to nie pojdzie.
--- Koniec cytatu ---
Wiem. Nawet nie próbowałbym się zmieścić w takiej pamięci ;)
A na razie kombinuję sobie co się da zrobić w tym trybie. Parę efektów powinno się udać. Pytanie tylko takie - czy jest gdzieś jakiś opis timingów video? Dobrze by było wiedzieć ile czasu zajmują bordery, linia itp. No i jeszcze jedno - czy Jupiter zawsze ma czarny BORDER? Nie ma opcji przełączenia na biały?
KWF:
Ad1. Jupiterowy ROM jest upakowany do granic mozliwosci (prawie), dlatego font jest opisany w sposob bardzo uproszczony. Cos Tygrys kombinowal w tym zakresie.
Ad2. RAM: tak, mozesz zalozyc, ze zawsze masz dostepne przynajmniej 16K od 16384.
Ad3. W Jupku masz prawie 900B dla wykorzystania w podstawowej konfiguracji ;) Dalthon wywija cuda wianki w 256B, tutaj oszalalby z nadmiaru miejsca ;)
Z racji swojej budowy Jupiter zawsze ma obraz czarne tlo (wlaczajac ramke) i biale litery. Mozna zrobic inwersje calego ekranu wraz z ramka, ale tylko sprzetowa. A co do timingow przyjmij, ze sa one takie jak w Speccy. Postaram sie sprawdzic te informacje.
Co do TAPa jest on troche inny niz ten znany ze Speccy. Opis TAPa jest tu: http://www.jupiter-ace.co.uk/prog_tap_templates.html
Prezentacja ze speccy.pl party 2019.1 - moze tutaj znajszesz troche o organizacji pamieci w Jupku.
KWF:
Timingi wideo:
Zegar procesora: 3.25MHz
Licznik jednej linii wideo: 416 cykli zegara 6.5MHz, w tym
- lewy margines: 64 (352..415)
- obszar 32 kolumn: 256 (0..255)
- prawy margines: 64 (255..319)
- HSYNC: 32 (320..351)
Jedna ramka to 312 linii, w tym:
- gorny margines: 56 (256..311)
- obszar 24 wierszy: 192 (0..191)
- dolny margines: 56 (192..247)
- VSYNC: 8 (248..255)
No i jeszcze dwie drobne sprawy:
--- Cytuj ---VSYNC Interrupt
The default interrupt handler at 0038h isn't too useful, however, one can put a custom IM2 interrupt handler in RAM. The Z80's /INT pin is wired directly to /VSYNC. This implies two problems:
1) The /VSYNC signal is LOW for 8 scanlines (1664 cycles), so, the IRQ handler should not re-enable IRQs during that period (otherwise the same interrupt would be executed another time). If necessary include a 1664-cycle delay in the IRQ handler, or return without enabling IRQs.
2) For flicker/waitstate-free drawing, it'd be ideal to access VRAM during VBLANK, but since /INT is generated on VSYNC rather than VBLANK, one can use only little more than half of the VBLANK periond.
--- Koniec cytatu ---
Nawigacja
[#] Następna strona
Idź do wersji pełnej