Autor ::Roman Bórik Poslaná :: 25.12.2013 15:03:15 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
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...
Správa
Autor ::JL Poslaná :: 25.12.2013 15:12:28 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
No tak to je pěkně v háji.
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.
Správa
Autor ::Roman Bórik Poslaná :: 25.12.2013 15:55:19 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
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.
Správa
Autor ::JL Poslaná :: 25.12.2013 16:07:26 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
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é
Správa
Autor ::Roman Bórik Poslaná :: 25.12.2013 16:20:51 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
OK, s tým súhlasím. Je to tak.
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.
Správa
Autor ::JL Poslaná :: 25.12.2013 16:39:55 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
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á.
Ovšem nevím jak je to s tím místem...
Správa
Autor ::Roman Bórik Poslaná :: 25.12.2013 17:13:49 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
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.
Správa
Autor ::JL Poslaná :: 25.12.2013 17:30:31 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
A na tom -3 je to RO, nebo je to kopie v RAM?
Jak tak počítám, tak je obsazeno 80 stránek z 255
Takže by se to tam nějak nasoukat dalo, případně v biosu modifikovat adresu rutiny CONOUT na novou náhradní mimo kolizi s ROM.
Jestli teda i tam není nějakej průser.
Jakub
Správa
Autor ::Roman Bórik Poslaná :: 25.12.2013 19:11:33 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
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.
Správa
Autor ::JL Poslaná :: 25.12.2013 19:37:19 Predmet ::Re: Závislost Mikrosu na nastavení 8251???? - tušení
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číš.
Správa
Autor ::JL Poslaná :: 25.12.2013 20:54:03 Predmet ::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.
