Už minule som písal, že opustenie klávesnicovej rutiny, ak bolo zistené prijatie bytu USARTu, je zámerné a dôležité. A skutočne to urobili kvôli módu Terminál, aby sa nestrácali prijaté byty.
A riešenie to nie je zlé, resp. je zodpovedajúce hardvérovým možnostiam, keďže USART nie je na prerušenie hardvérovo "naviazaný".
Celý MIKROS, teda v skutočnosti celý BIOS nie je v RAM preto, že by bol veľmi dlhý a tak by uberal z cennej RAM pre bežiace programy. Preto sa využívajú rutiny z Monitora a podľa potreby sa stránkuje.
Monitor má svoje chyby a určite mohol byť napísaný sofistikovanejšie, ale skutočnosť je taká, aká je. Dvojkový Monitor je ale oproti jednotkovému skvost...
Nevěděl jsem že se rom stránkuje přes uživatelský cp/m program, to je pak samozřejmě jiná. Myslel jsem že je tam kde je normálně část biosu.
To víš, co se týče PMD jsem začátečník a dokumentace je chaotická.
Bohužel ale
XRA A
OUT 1FH
OUT 1FH
OUT 1FH
nepomohlo, je to úplně stejné a podle mě logické
Je potřeba ty data někde vyčíst a tím uvolnit.
Snad najdu kam to okolo volání INKEY dát a bude šance, že by se to tam vešlo.
Z Monitora sa okrem testu klávesnice využíva aj tlač na obrazovku, rolovanie obrazu, zmazanie obrazu a font. Toto všetko by muselo byť v RAM, aby bol BIOS nezávislý od Monitora.
Na úroveň rutiny INKEY, resp. BIOSu by som "vyprázdňovanie" prijímacieho buffra nedával.
Vzhľadom na to, že nie je možné používať riadenie hardvérového toku dát pomocou CTS/RTS, tak by som danú "synchronizáciu" robil na úrovni samotnej aplikácie.
Aplikácia na základe požiadavky užívateľa vie, kedy má prenos začať a tak si prípadný čakajúci byte pred zavolaním rutiny pre test klávesnice prečíta.
To ale znamená aj to, že vysielacia strana (PC) nesmie nič na linku posielať a môže začať až v okamihu, keď užívateľ zaháji príjem dát a PMD 85 zažne sledovať linku.
S tím nesouhlasím.
a) to není cp/m kompatibilní
b) znak může přijít i náhodou (rušení, manululace s konektorem) a náhodně příchozí znak podle mě nemůže způsobit zásek počítače, to se mi zdá neakceptovatelné
Avšak, ak do svojho programu dávaš inicializáciu USARTu a aj samotnú komunikáciu, tak je to opäť proti akejsi "konvencii" CP/M.
Kedisy som skušobne "porotoval" KERMIT na PMD 85 a plus/mínus mi to fungovalo. Samozrejme, inicializácia USARTu a aj komunikácia sú súčasťou kódu KERMITu.
To že mám inicializaci ve vlastním programu, je proto, že to ladím a hledám cestu jak to později naimplementovat systémově
Bohužel teď když koukám na kód booteru, který obsahuje ty interfacy mezi rom rutinami a biosem, začínám mít pocit že to je pro mě asi veliký sousto.
Jak je to tam rozkouskováno pro oblasta vedle videoram, moc se v tom neorientuju.
Rád bych ověřil, jestli je tam trochu místa a pokud ano udělal tam cca 8B kruhový přijímací buffer pro sériovku. Nebo víc, pokud se vejde.
Do něj v CONIN: odkládal data co překáží rutině INKEY.
Potom při volání služby READER: také pro jistotu očuchat HW (kdyby INKEY nebyl nějakou dobu volán) data přidat do FIFO a potom vrátit BDOSu první bajt ve frontě, nebo EOF a Zero flag když by byla prázdná.
Pozor.
Booter presúva do oblasti vedľa VideoRAM kód, ktorý je normálne súčasťou Monitora PMD 85-3.
Takže rozšírenie Bootera o nejaký "pomocný" kód bude znamenať, že daná vec nebude na PMD 85-3 fungovať.
Rozširovať sa teda môže iba samotný BIOS.
V PMD 85-3 má Monitor 8kB (umiestnený ale od adresy 0E000h) a v tej rozšírenej časti (4kB) je okrem ďalších vecí aj ovládač pre PMD 32 a základ BIOSu, teda to, čo Booter ukladá v prípade PMD 85-2(A) vedľa VRAM. Keďže je to v ROM, tak je úprava pre PMD 85-3 nemožná. Ak teda nezauvažujeme o úprave priamo v Monitore. Miesto tam je.
Pre PMD 85-2(A) by sa zodpovedajúca úprava musela urobiť v Booteri.
No tak se pojďme dohodnout co bude z hlediska kompatibility nejlepší.
Ty jsi na rozdíl ode mě odborník.
Já jen chci cp/m čistý způsob jak zprovoznit sériový port. Abych svoje výtvory, které programuju a překládám na pc, mohl nasunout do hw bez manipulace se sdkartou.
A i z jiných důvodů bych funkční sériák chtěl.
V BIOS4UNI.MAC je málo místa.
V booteru se zdá, z pohledu 2A, že by se tam pár desítek bajtů nějak našlo. Ovšem co to všechno znamená pro 3 nevím.
Udělám to jak doporučíš.
Message
Author ::JL Posted :: 2013-12-25 08:54:03 PM Subject ::Re: Závislost Mikrosu na nastavení 8251???? - umístění ovladače
Ahoj
Zdá se mi, že když ROM 2A leží od 0x8000 po 0x8fff a ROM 3 od 0xe000 po 0xffff, je tady díra 0x9000 až 0xdfff.
Oblast sdílená videoram a "vedle videoram" je 0xc000 až 0xffff
To znamená, že "vedle videoram" 0xc030 až 0xdfff vypadá "volná" na obou typech počítačů.
Ovšem asi tam jsou ještě data monitoru.
Pokud začnu z dola tam co to dělá booter, tak mám 0xc470 až 0xdfff což je 111 stránek, čili 1776 B.
Pro rozšíření nad rámec stávajícího booteru, který obsadí 80 stránek, zbývá 31 x 16 = 496 B
To furt nevypadá špatně. Do toho se to musí vejít několikrát. Otázka je jestli jsem se někde nepřepočítal. Nebo jestli tam nesedí ještě něco o čem nevím.
