Terve! Tuli koodailtua tällainen graafinen käyttöliittymä IBM PC-yhteensopivien tietokoneiden reaalitilassa toimiville levykäyttöjärjestelmille. Moniajoa tässä ei ole (vielä), mutta paljon muita dossin käyttöä helpottavia ja nopeuttavia ominaisuuksia löytyy.
http://sininenankka.dy.fi/~sami/fdshell/index.
Bugeja löytyy vielä jonkin verran ja lähdekoodi on aika epäselvää, koska en sitä jaksanut kovin paljoa siistiä ennen julkaisua. Kuitenkin itse kyseistä ohjelmaa käytän dossikoneessa käyttöliittymänä ja omasta mielestäni ohjelman toimivuus ja vakaus on jo ihan käytettävällä tasolla.
Tein uuden version. Korjasin pari pikku bugia ikkunamanagerissa ja optimoin funktiokutsuja ja näytölle piirtoa. Ohjelman toiminta nopeutui ja binäärin koko pieneni muutamalla kilotavulla.
Tämä projekti on alkanut saamaan käyttöjärjestelmän piirteitä. Skrolliin tulossa artikkelia jossain vaiheessa.
Nyt sillä pääsee internettiin. https://www.youtube.com/watch?v=I0MRRZlMUkQ
No nyt on kunnon kontenttia!
Paljon olet jaksanut. Videosta jäin miettimään, miksi on niin hidas. Luulisi tekstipohjaisen systeemin toimivan nykyisellä raudalla liukkaammin.
Mitä tarkoitat "nykyisellä raudalla"? Tuossa videollahan koneena on 25-megahertsisellä 80386SX-prossulla oleva MikroMikko, kuten videolla mainitsenkin.
Yksittäisten pikselien ja tekstin piirto on hitaahkoa, koska piirtorutiineissa on optimoitu ensisijaisesti muistinkulutusta. Siksi näin hitailla prossuilla esimerkiksi Windows 3 on hieman nopeampi. Sen sijaan 486:lla ja nopeammilla tuo minun systeemi on jo nopeampi, koska se hyötyy leveämmästä näytönohjainväylästä ja prosessorin välimuistista paljon.
Ja tekstipohjainenhan tuo ei ole, vaan graafista tilaa käyttää.
Turakointi kirjoitti:
Tuossa videollahan koneena on 25-megahertsisellä 80386SX-prossulla oleva MikroMikko, kuten videolla mainitsenkin.
Ahaa, katsoin videota ilman ääniä, joten en saanut tätä tietoa. Lähinnä mietin tuota, kun näyttää, että kun ohjelma tulostaa tekstirivin, siitäkin merkit näyttävät tulevan yksitellen. Kuvittelisin, että jos itse teksti on puskuroitu ja ruutua ei väkisin piirretä joka merkin välissä vaan vasta tulostuskomennon lopussa tai rivin vaihtuessa, jopa 25 MHz prosessorilla saisi yhden tekstirivin piirrettyä niin nopeasti, ettei yksittäisten kirjainten piirtämistä ehdi nähdä.
Ei sitä ole puskuroitu, koska se kuluttaisi muistia.
Eikö ole siis edes yhtä riviä ruudulla puskuroitu? 80 tavua? Tai edes 8 tavua, kai sekin jo nopeuttaisi? Onko todella muisti niin tiukalla? Jos pitää oikein pihistellä, voisiko puskuriksi käyttää näyttömuistista seuraavien merkkien sijaintia? Vilkkuva pikseli tuntuisi pienemmältä häiriöltä kuin hidas teksti.
Eri näyttötilat ovat muistimalliltaan varsin erilaisia, ja tuollaista puskurointia ei oikein voi toteuttaa niin, että se toimisi kaikilla näyttötiloilla. Planaarisiin näyttötiloihin ei noin vain voi kopioida jotain valmista bittikarttaa.
Eikä tuo piirto nyt minusta mitenkään hidasta ole nykyiselläänkään.
Päivitystä.
Dossikerneliä olen tehnyt tälle, ettei tarvitse olla riippuvainen FreeDOSsin kernelistä.
Nyt tein alikansioiden tuen ja järjestelmäkutsun 0x36.
Testikoneena 286, joka ilman turbo-valoa vastaa benchmark-ohjelmien mielestä 9-megahertsistä XT-mikrotietokonetta.
Aivan halvatun mielenkiintoista, mutta valitettavasi jo kauan sitten mennyttä aikaa.
neosofta kirjoitti:
Aivan halvatun mielenkiintoista, mutta valitettavasi jo kauan sitten mennyttä aikaa.
Kyllä tuota voi nyky-PC-koneissakin ajaa ainakin vielä. Jos kehitys jatkuu nykyisen suuntaisena, niin muutaman vuoden päästä ei enää voi, kun niihin tulee boottilukitukset ja suostuvat sitten enää käynnistämään ainoastaan Microsoft Windowsin.
Viime aikoina olen optimoinut vuoronninta ja TCP/IP-pinoa. Nyt tuo vastailee pingiin suurin piirtein yhtä nopeasti kuin Linux samalla koneella. Jostain syystä oman TCP/IP-pinon lähettämät paketit eivät useinkaan mene Huawein reitittimistä läpi, vaikka paketeissa ei sinänsä näyttäisi olevan mitään väärin. Epäilen syyksi Huawein reititinten SPI-palomuurissa olevaa bugia, jolle en mahda oikein mitään eikä noissa paskalaatikoissa saa sitä palomuuria myöskään kokonaan pois päältä.
Esimerkiksi TCP-kättely porttiin 80 näyttää tältä: https://ibb.co/X5MyBKt
Tuo ensimmäinen ACK siis vain ei mene perille ikinä edes uudelleenlähetettynä.
Toteutin TCP/IP-pinoon ruuhkaikkunan. Kaistanleveys ulkoverkon yli kasvoi noin 30-kertaiseksi. Linkki käyttöjärjestelmää käyttävään palvelimeen: http://486servu.dy.fi
TCP/IP-pino käyttää nyt asynkronista tiedonsiirtoa pakettien lähettämisessä, jos pakettiajuri tukee sitä.