Kirjautuminen

Haku

Tehtävät

Keskustelu: Projektit: Oma levykäyttöjärjestelmä

Sivun loppuun

Turakointi [31.01.2022 08:48:53]

#

Terve. Olen tässä kirjoitellut graafisen käyttöliittymäni alla käytettäväksi omaa DOS-toteutusta, joka pyrkii olemaan enimmäkseen yhteensopiva Digital Researchin ja Microsoftin omien levykäyttöjärjestelmien kanssa. Suunnitelmissa on kuitenkin jättää pois täysin turhia legacy-järjestelmäkutsuja kuten kaikki File Control Blockeihin liittyvä, ja sisällyttää kerneliin muutamia järjestelmäkutsuja joita ei DOSissa yleensä ole, kuten unix-aika.

Video projektista: https://www.youtube.com/watch?v=ecriVQ9QFio

Koodit ja levykuva, jota voi testailla: http://sininenankka.dy.fi/~sami/fdshell/doskernel.php (näitä päivittelen)

Kerneli on kirjoitettu lähes kokonaan C:llä ja assemblyä on vain alkulataaja sekä sellaiset keskeytyskäsittelijät ja järjestelmäkutsut, joita ei ollut C:llä mahdollista kirjoittaa. Pyrin siihen, että kernelin voisi portata myös muille kuin 8086:n käskykannalle mahdollisimman pienin muutoksin.

Dynaamisen välimuistin lisäämisen jälkeen tuosta tuli aika paljon nopeampi kuin FreeDOS ja MS-DOS. Kehitystyö jatkuu.

jsbasic [01.02.2022 19:12:35]

#

Tämäpä on mielenkiintoinen projekti. IBM-PC ja MS-DOS ovat vaikuttaneet tietotekniikkaan niin paljon, että ansaitsevat vähintäänkin jonkinlaista "museoajoa".

Olen ymmärtänyt, että MS-DOS ja muut levykäyttikset eivät olleen teknisesti ihan huikeita. Käskykanta oli aika pieni. Ne oli kuitenkin alku sille, että käyttöjärjestelmä sijaitsi nimensä mukaisesti levyllä, eikä esimerkiksi rommissa. MS-DOS:in edeltäjän nimi oli QDOS, jossa Q tarkoitti "Quick and dirty". Se taisi olla syy, miksi QBASIC:in nimessä on tuo eksoottinen kirjain...

Omat käyttökokemukseni varhaisista DOS-ohjelmista ovat tosi hyviä. Ohjelmat olivat luonteeltaan natiiveja, eli ne riippuivat lähinnä itsestään. Siksi ne toimivat kuin junan vessa. Nyt kun suosituimmaksi ohjelmointikieleksi on Tioben mukaan luikerrellut se tulkki, ja moni C-ohjelmoija kysyy itseltään kannattaako enää tuskailla muistinhallinnan kanssa, niin tuollaiset videot ovat mieluista katsottavaa. DOS-aikaan nähtiin vaivaa sovellusten teknisissä perusteissa, ja ne ohjelmat toimivat edelleen sujuvasti kuten videosta näkyy.

Jere Sumell [01.02.2022 21:20:02]

#

MS-DOS -keskustelu lämpenee.

Itselläni kokemusta DOS 5.0 lähtien, mutta ikää on vasta noin 40, ensimmäisessä omassa PC-tietokoneessani 1995/1996 oli MS-DOS 6.2 muistaakseni, ja siitä lähtien olen käyttänyt kaikkia loppuja DOS-versioita paljon, ja Windowsit pääosin 3.11 Työryhmä windowseista tuttuja, ja jotkin NT winkkarit, joku Windows-versio taisi jäädä välistä. Otan osaa tähän keskusteluun.

MS-DOS lopulta sitä pidettiin yleisesti huonotaisoisena UNIX-kopiona. Voisiko olla näin, että MS-DOS oli alkusysäys sille, että käyttöjärjestelmä sijaitsi levyllä? Voisin olla vaikka eri mieltä tästä asiasta. Nykyaikaisen modernin moniajokäyttöjärjestelmän historia voidaan katsoa alkaneeksi vuodesta 1970, ja DOS ei ollut moniajojärjestelmäkään, eli ei edustanut mitenkään edistyksellistä kehitystä koskaan historiansa aikana.

Alunperin DOSin historia lähtee siitä, että Bill Gates osti Seattle Computer Productilta käyttöjärjestelmän kaikkineen, jonka tuo SCP oli kehittänyt Intelin 8086 -arkkitehtuuriin, ja se kulki nimellä 86-DOS, ja sitten Bill Gates räätälöi siitä MS -DOSin, jota sitten lähti lisenssoimaan IBM:n kloonivalmistajille, tosin IBM:lle myöhemmin sitten myös.

Oli vähän ohjelmasta, ja ohjelmoijan taidoista muistinhallinnan suhteen lopullisen ohjelman toiminta, kuinka siedettävästi ohjelma toimii. Mitä ne ainakin kaupalliset DOS-sovellukset varmaan enimmäkseen kirjoitettiin C++:lla, niin siinähän on muistinkäyttö täysin ohjelmoijan vastuulla, ja sitten riskit kasvaa ohjelman epävakaudelle ohjelmakoodin paisuessa isommaksi.

Vanhoja PC-pelejä, joita itsekin ostin penskana ja teini-iässä, kun ei ollut nopeita nettiyhteyksiä eikä Steamin kaltaista pilvialustaa, niin niitä pelejä on ihan kiva välillä DosBOXilla pelata, ja sitten on vapaasti FreeDOS joissain yhteyksissä boottisektorilla jos tekee esim USB-tikun jostain erityisestä ohjelmasta, firmwareissa yleensä on jokin FreeDOS:in kaltainen käyttöjärjestelmä, minkä hallinnassa ne ohjelmat toimivat siinä laitelmistossa.

Amiga-aikainakin kiintolevylle pystyi tallentamaan Workbenchin, ja eikö sekin ollut Amigan käyttöjärjestelmä ja sekin oli ennen DOS-aikaa taisi olla.

Onko tämä keskustelupuheenvuoro nyt täysin metsään mennyt? Mitä ajatuksia herännyt?

jsbasic [01.02.2022 21:54:35]

#

Ei MS-DOS ollut alkusysäys. Yritin vain avata sanaa "levykäyttöjärjestelmä".

lainaus:

Strictly speaking, this definition does not apply to current generations of operating systems, such as versions of Microsoft Windows in use, and is more appropriately used only for older generations of operating systems.

https://en.wikipedia.org/wiki/Disk_operating_system

Riskit varmasti kasvoivat ohjelmakoodin paisuessa, mutta DOS-ohjelmat olivat suhteellisen pieniä kokonaisuuksia. Lisäksi niissä käytettiin firmojen omia kirjastoja, joiden yhteensopivuus oli varmistettu. Viimeisinä aikoina poikkeuksena oli DOS/4G, joka lisäsikin epävakautta.

jalski [01.02.2022 22:02:35]

#

jsbasic kirjoitti:

Viimeisinä aikoina poikkeuksena oli DOS/4G, joka lisäsikin epävakautta.

Meinaatko DOS/4GW:tä? Minun muistini mukaan tuo toimi ihan hyvin. Itse tosin käytin omiin tuotoksiini Causeway DOS extenderiä.

Turakointi [02.02.2022 01:52:50]

#

Näkisin, että käyttöjärjestelmäkehityksessä on järkevää käyttää jo CP/M:stä tuttua mallia, jossa kerneli koostuu useasta päällekkäisestä ohjelmasta, jotka käyttävät sen alempana olevan ohjelman tarjoamia palveluja. Näin saadaan pienemmällä vaivalla kehitettyä huomattavasti portattavampi käyttöjärjestelmä kuin yhtä monoliittista kerneliä käyttäen.

DOSin alla oleva BIOS tarjoaa abstraktiotason laitteistoon, jotta DOSin ei tarvitse niin sanotusti iskeä rautaa suoraan. DOS ei itsessään ole kovin kummoinen käyttöjärjestelmä, mutta tarjoaa riittävät palvelut tiedostojärjestelmien hyödyntämiseen, ettei sen ohjelmointirajapintaa käyttävillä ohjelmilla tarvitse olla omaa tiedostojärjestelmäajuria. DOS myös antaa ohjelmointrajapintaansa käyttäville ohjelmille täyden pääsyn laitteistoon, mikä helpottaa varsinkin pelien ja demojen kehittämistä. Hyötyohjelmien kanssa näkisin, että parempi on, jos siinä päällä on vielä yksi kerros, joka mahdollistaa esimerkiksi moniajon.

Tein kernelistä uuden version, jossa korjasin pari muistibugia ja muutin asioiden tapahtumajärjestystä EXE-lataajassa. Nyt tuo kykenee lataamaan hyvinkin isoja EXE-ohjelmia muistiin unohtamatta välimuistejaan, mikä nopeuttaa ohjelmien käynnistymistä entisestään huomattavasti. Seuraava vaihe olisi hioa olemassa olevia toimintoja ja tehdä kiintolevyjen ja osiotaulujen tuki.

_Pete_ [02.02.2022 14:03:55]

#

Jere Sumell kirjoitti:

Onko tämä keskustelupuheenvuoro nyt täysin metsään mennyt? Mitä ajatuksia herännyt?

On ainakin noiden vuosilukujen suhteen sillä c++ julkaistiin vasta 1985. Amiga julkaistiin seuraavana vuonna. Dossi oli olemassa jo paljon aikaisemmin.

jsbasic [02.02.2022 20:42:41]

#

Turakointi kirjoitti:

DOS myös antaa ohjelmointrajapintaansa käyttäville ohjelmille täyden pääsyn laitteistoon, mikä helpottaa varsinkin pelien ja demojen kehittämistä.

Juuri näin. Tälle alustalle tehtiin esimerkiksi Doom, joka mullisti videopelien kehityksen. Ehkä Microsoft on halunnutkin jättää "oven auki" ohjelmoijille, koska se on ollut ohjelmointityökaluja valmistava yhtiö.

Turakointi kirjoitti:

Hyötyohjelmien kanssa näkisin, että parempi on, jos siinä päällä on vielä yksi kerros, joka mahdollistaa esimerkiksi moniajon.

Aluksi Microsoft ratkaisi moniajon niin, että siihen suostuminen oli ohjelmille vapaaehtoista ja omaehtoista (co-operative multitasking). Viestisilmukka oli minusta aika mielenkiintoinen ratkaisu. Sitä käytettiin Windowsissa, mutta olisihan se toiminut DOS-ohjelmillakin.

https://retrocomputing.stackexchange.com/questions/791/how-did-windows-3-1-implement-multitasking
http://users.jyu.fi/~vesal/kurssit/winohj/html/winmon/m-3.htm#Heading44
https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows

Grez [03.02.2022 14:29:51]

#

jsbasic kirjoitti:

Ehkä Microsoft on halunnutkin jättää "oven auki" ohjelmoijille, koska se on ollut ohjelmointityökaluja valmistava yhtiö.

Pikemminkin kyse on siitä, että DOS oli järjestelmä, joka oli tarkoitettu yhden käyttäjän yhden ohjelman ajamiseen kerrallaan. Siinä ei siis ollut mitään tarvetta "estää" yhtä ohjelmaa tekemästä "mitä lystää".

Pikemminkin kuin "ovi oli jätetty auki" voisi sanoa, että turhaa ovea, oven karmeja tai edes seinää ei rakennettu.

jsbasic [03.02.2022 19:53:52]

#

Grez kirjoitti:

Pikemminkin kyse on siitä, että DOS oli järjestelmä, joka oli tarkoitettu yhden käyttäjän yhden ohjelman ajamiseen kerrallaan.

Jos MS-DOS:sia vertaa Unixiin, niin on keskeistä, että Dossissa ajettiin yhtä ohjelmaa kerrallaan. Unixissa taas vallitsi työkaluajattelu, jossa kiellettiin monimutkaiset ohjelmat ja turhat sivuvaikutukset.

Olen tässä projektissa pohtinut juuri tuota filosofiaa. DOS-kerneliltä voisi odottaa tukea jollekin korkeamman tason ohjelmointikielelle tai tavukoodille. Mitä jos 286-koneeseen voisi tehdä ohjelmia java-tyyliin C-kielen ja Assyn sijaan, mutta silti säilyttää vapaus rautatasoon! En tiedä onko tuossa järkeä...

Turakointi [03.02.2022 20:36:44]

#

jsbasic kirjoitti:

Olen tässä projektissa pohtinut juuri tuota filosofiaa. DOS-kerneliltä voisi odottaa tukea jollekin korkeamman tason ohjelmointikielelle tai tavukoodille. Mitä jos 286-koneeseen voisi tehdä ohjelmia java-tyyliin C-kielen ja Assyn sijaan, mutta silti säilyttää vapaus rautatasoon! En tiedä onko tuossa järkeä...

Sehän tässä minun systeemissä on nimenomaan ideana. Alla olevalla dossikernelillä voi ajaa täysillä oikeuksilla suoraan raudalla toimivia ohjelmia, ja päällä olevan moniajavan osittain POSIX-yhteensopivan systeemin päällä voi moniajaa muistiturvallisesti tavukoodiohjelmia.

Turakointi [07.02.2022 13:48:57]

#

Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, mikä tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin. Tämä näkyy yksinkertaisten indie-pelien kehitysmäärän laskuna, eivätkä klassikkopelit enää toimi Windowsilla ilman erikseen asennettavia emulaattoreita. Kuitenkin pitkälle 2000-luvun puolelle asti suuri osa, ellei jopa suurin osa, harrastelijoiden tekemistä peleistä oli DOS-pelejä.

Vaikka muuta usein väitetään, niin matalalle tasolle koodatut pelit ovat kuitenkin loppujen lopuksi kaikkein helpoimpia myös portata alustalta toiselle, kunhan ne on kirjoitettu jollain korkeamman tason kielellä, kuten C:llä. Esimerkiksi PC- ja Amiga-versioiden erona voi olla pelkästään eri rutiinit näytölle piirtoon ja näppäimistösyötteen kaappaukseen, vaikka itse koneissa ei ole kovin paljoa samaa. Kaikkein hankalimpia porttauksen kannalta ovat Windowsille tehdyt pelit, koska koko Windowsin ohjelmointirajapinta on suunniteltu niin, että kaikki tehdään taktisesti hieman eri tavalla kuin esimerkiksi kilpailevissa POSIX-yhteensopivissa käyttöjärjestelmissä.

Kasvava määrä rajapintoja ohjelman ja raudan välissä tekee tietokoneen käytöstä hankalaa myös käyttäjälle. Nykypelien kanssa on normaalia tapella mystisten ongelmien kanssa, kun peli ei vain jostain syystä toimi, eikä kukaan oikein tiedä, onko vika jossain pelin käyttämässä rajapinnassa, näytönohjaimen tai äänikortin ajurissa, käyttöjärjestelmän ytimessä vaiko itse pelissä.

Toki pelien ajaminen moniajavan kernelin päällä mahdollistaa monia asioita, kuten videopuhelun tai näytön striimaamisen pelatessa. Omaan DOS-kerneliini voisin jossain vaiheessa yrittää luoda jonkinlaista kellokeskeytykseen kiinnittyvää pinonvaihdinta (stack switcher) esimerkiksi TSR-ohjelmana. Näillä pinonvaihtimilla on aina sellainen ongelma, että ovat yhteensopivia vain yhden dossikernelin kanssa.

Testailin oman graafisen moniajoshellin käynnistystä: https://www.youtube.com/watch?v=Q1DEhtRdm_k

Grez [07.02.2022 15:12:44]

#

Turakointi kirjoitti:

Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, mikä tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin.

Eihän tuon kaiken järjen mukaan pitäisi tehdä ohjelmien tekemisestä tietokoneelle yhtään hankalampaaa. Eihän mikään pakota käyttämään tietokoneella Windowsia. Toisekseen jos haluat tehdä ohjelmia Windowsille, niin ei siinä ole edelleenkään mikään pakko käyttää frameworkia.

En myöskään ole ihan samaa mieltä tuosta väitteestäsi että suoraan raudan tukeminen olisi helpompaa vaikkapa DOS:n kautta kuin käyttämällä Windowsia tai Linuxia tai MacOSx. Tai ainakaan minä en edes tietäisi mistä nykyisin alkaa koodata 3D-moottoria suoraan raudalla eli ilman näytönohjainvalmistajien tekemiä ajureita jne. Amigalla näytönohjaukseen oli aina samat (no pari eri versiota samasta) piirit joiden dokumentaatio oli julkisesti saatavilla. PC:llä taas on kymmeniä erilaisia keskenään (perus 2d käyttöä lukuunottamatta) epäyhteensopivia näytönohjaimia.

jalski [07.02.2022 15:36:52]

#

Turakointi kirjoitti:

Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, mikä tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin. Tämä näkyy yksinkertaisten indie-pelien kehitysmäärän laskuna, eivätkä klassikkopelit enää toimi Windowsilla ilman erikseen asennettavia emulaattoreita. Kuitenkin pitkälle 2000-luvun puolelle asti suuri osa, ellei jopa suurin osa, harrastelijoiden tekemistä peleistä oli DOS-pelejä.

Vaikka muuta usein väitetään, niin matalalle tasolle koodatut pelit ovat kuitenkin loppujen lopuksi kaikkein helpoimpia myös portata alustalta toiselle, kunhan ne on kirjoitettu jollain korkeamman tason kielellä, kuten C:llä. Esimerkiksi PC- ja Amiga-versioiden erona voi olla pelkästään eri rutiinit näytölle piirtoon ja näppäimistösyötteen kaappaukseen, vaikka itse koneissa ei ole kovin paljoa samaa. Kaikkein hankalimpia porttauksen kannalta ovat Windowsille tehdyt pelit, koska koko Windowsin ohjelmointirajapinta on suunniteltu niin, että kaikki tehdään taktisesti hieman eri tavalla kuin esimerkiksi kilpailevissa POSIX-yhteensopivissa käyttöjärjestelmissä.

Itse olen tyytyväinen, että muistia varatessa ei nykyään enää tarvitse kikkailla segmenttien kanssa. Jos totta puhutaan, niin peliohjelmoinnin aloittaminen ei koskaan ole ollut näin helppoa. Saatavilla on älytön määrä kirjastoja joiden avulla voi suoraan keskittyä itse pelin tekemiseen.

Amigan ja PC:n tapauksessa ei suoran peli käännöksen tekeminen ole koskaan ollut järkevää. Amigalla oli kuitenkin omat piirinsä grafiikkaa ja ääntä varten. Otetaan esimerkiksi aikoinaan menetetty mahdollisuus eli Atari Jaguar pelikonsoli. Suurin osa tuolle tehdyistä peleistä oli käytännössä suoria Atari ST käännöksiä eikä Jaguarista otettu irti mitä olisi pystytty.

Turakointi [07.02.2022 15:53:27]

#

Suurin osa PC-näytönohjaimista on VGA-yhteensopivia. Myös OpenGL on avoin standardi, mutta en ole siihen sen tarkemmin perehtynyt. Moni myöhempien aikojen dossipelihän sitä kuitenkin käyttää. Suurin osa näytönohjaimista tukee VESA-standardia ja sillä saa isoja resoluutioita ja värimääriä ilman ajureita.

Ei DOSissakaan tarvitse muistia varatessa kikkailla segmenttien kanssa, jos käyttää frameworkkeja. Pointti olikin, että DOS ylipäätään sallii suoran pääsyn rautaan, mutta Windowsin uudet versiot eivät sitä enää salli, vaan jokainen ohjelma on täysin käyttöjärjestelmäytimen ja sen vuorontimen armoilla.

Nykyframeworkkien kanssa jo pelkän Hello Worldin aikaansaaminen vaatii huomattavasti enemmän tietämystä kuin vanhojen, enemmän raudassa kiinni olevien käyttöliittymien päälle ohjelmointi.

peran [07.02.2022 16:05:25]

#

Turakointi kirjoitti:

Suurin osa PC-näytönohjaimista on VGA-yhteensopivia. Myös OpenGL on avoin standardi, mutta en ole siihen sen tarkemmin perehtynyt. Moni myöhempien aikojen dossipelihän sitä kuitenkin käyttää. Suurin osa näytönohjaimista tukee VESA-standardia ja sillä saa isoja resoluutioita ja värimääriä ilman ajureita.

Kyllä siinäkin tapauksessa tarvitaan VESA-ajuri. Toki se on standartoitu, ja monelle merkille saa tehtyä yhdellä ajurilla VGA-ajuria suuremman resoluution.

Linukka puolella kyseinen VESA-ajuri on ollut pitkään, mutta löytyykö Win98:lle tai Me:lle edes mitään vesa-ajuria varsinkaan ilmaista. (Itselläni olisi henkilökohtainen kiinnostus, jos löytyisi.)

Grez [07.02.2022 16:15:56]

#

Turakointi kirjoitti:

Myös OpenGL on avoin standardi, mutta en ole siihen sen tarkemmin perehtynyt.

Olen siinä käsityksessä että OpenGL:ssä ei hypistellä näytönohjaimia suoraan rautatasolla, vaan näytönohjainvalmistaja toimittaa ajurin joka juttelee OpenGL:ää.

Kommenttini ei liittynyt varsinaisesti siihen voiko joku toimia Windowsilla tai DOSilla vaan tuohon harmitteluusi että pelin ja raudan välissä on monia kerroksia kuten ajurit.

Turakointi kirjoitti:

Windowsin uudet versiot eivät sitä enää salli, vaan jokainen ohjelma on täysin käyttöjärjestelmäytimen ja sen vuorontimen armoilla.

Täähän on toivottu ominaisuus useinkin. Koneesi voi ajella turvallisin mielin muita ohjelmia samalla kun peli pyörii. Jos ajatellaan vaikka jotain TeamSpeakia tms, niin sitä olisi hankala käyttää jos peli olisi ominut koneen kokonaan kuten "vanhoina hyvinä aikoina"

Jos haluaa tehdä pelin joka nappaa koneen hallintaansa, niin eihän siihen tarvita edes DOSia, laittaa vaan pelin latautumaan boot sectorilta kuten esim. Amigalla oli usein tapana tehdä.

peran [07.02.2022 17:05:55]

#

peran kirjoitti:

Linukka puolella kyseinen VESA-ajuri on ollut pitkään, mutta löytyykö Win98:lle tai Me:lle edes mitään vesa-ajuria varsinkaan ilmaista. (Itselläni olisi henkilökohtainen kiinnostus, jos löytyisi.)

Vastaan itselleni...
http://www.win3x.org/win3board/viewtopic.php?t­=2462&language=en

... linkki saattaa olla kokeilemisen arvoinen.

peran [07.02.2022 17:11:46]

#

Jere Sumell kirjoitti:

MS-DOS -keskustelu lämpenee.
...
Amiga-aikainakin kiintolevylle pystyi tallentamaan Workbenchin, ja eikö sekin ollut Amigan käyttöjärjestelmä ja sekin oli ennen DOS-aikaa taisi olla.

Taidat olla väärässä...
https://fi.wikipedia.org/wiki/Amiga

https://fi.wikipedia.org/wiki/MS-DOS

Turakointi [07.02.2022 18:29:24]

#

peran kirjoitti:

Kyllä siinäkin tapauksessa tarvitaan VESA-ajuri. Toki se on standartoitu, ja monelle merkille saa tehtyä yhdellä ajurilla VGA-ajuria suuremman resoluution.

Ajuri on näissä melko suhteellinen käsite. Loppujen lopuksi oman "ajurin", ts. toteutuksen, voi näissä kirjoittaa melko pienellä määrällä koodia. Tuo oma graafinen shellinikin tukee sisäisesti sekä CGA:n, EGA:n että VGA:n hi-res-tiloja sekä mustavalkoisena että värillisenä. VESA-tiloille sille pitäisi vielä kirjoittaa ihan erillinen ladattava ajuri.

Grez kirjoitti:

Täähän on toivottu ominaisuus useinkin.
...
Jos haluaa tehdä pelin joka nappaa koneen hallintaansa, niin eihän siihen tarvita edes DOSia, laittaa vaan pelin latautumaan boot sectorilta

Vuorontimen armoilla oleminen on toivottu ominaisuus usein, mutta ei läheskään aina. Boottisektorissa on se ongelma, että joutuu tiedostojärjestelmästä lähtien toteuttamaan kaiken itse. Dossikernelin (jollainen Amigassa on ROMilla, PC-yhteensopivien firmis on pelkistetympi) päälle tehdessä moni asia helpottuu paljon, mutta täysi hallinta rautaan säilyy.

Grez [07.02.2022 18:48:19]

#

Turakointi kirjoitti:

Boottisektorissa on se ongelma, että joutuu tiedostojärjestelmästä lähtien toteuttamaan kaiken itse. Dossikernelin (jollainen Amigassa on ROMilla, PC-yhteensopivien firmis on pelkistetympi) päälle tehdessä moni asia helpottuu paljon, mutta täysi hallinta rautaan säilyy.

Vaikka Amigan Kickstart ROMissa olikin paljon enemmän tavaraa kuin PC:n BIOSissa, niin useat pelit ja demot varsinkin alkuaikoina* latasivat leykkeeltä ihan vaan lukemalla levyltä sektoreita sellaisenaan ilman virallista levyjärjestelmää. Sama käsittääkseni onnistuu PC:n BIOS-rutiineilla.

* alkuaikoina harvalla oli kiintolevy, niin ei niin paljoa haitannut vaikka demoa ei sieltä voinut käynnistääkään.

Turakointi kirjoitti:

Vuorontimen armoilla oleminen on toivottu ominaisuus usein, mutta ei läheskään aina.

Väittäisin kyllä että peruskäytössä nykyisistä tietokoneiden käyttäjistä tuskin 1%:akaan haluaisi palata tilanteeseen että vain yksi sovellus voi olla kerrallaan käynnissä.

Reaaliaikajärjestelmät, yksinkertaiset sulautetut järjestelmät, sun muut erilaiset käyttötapaukset on sitten asia erikseen.

Turakointi [07.02.2022 19:48:13]

#

Grez kirjoitti:

Väittäisin kyllä että peruskäytössä nykyisistä tietokoneiden käyttäjistä tuskin 1%:akaan haluaisi palata tilanteeseen että vain yksi sovellus voi olla kerrallaan käynnissä.

Tämä on ilmeisesti aihe, josta tietyt ihmiset eivät vain osaa keskustella asiallisesti ilman olkiukkoilua.

Grez [07.02.2022 20:07:50]

#

Olen kyllä pyrkinyt ihan asiallisesti asiasta keskustelemaan. Mitä sitten tarkoitit tuolla että "läheskään aina ei ole toivottua olla vuorontimen armoilla", jos mielestäsi oma tulkintani oli olkiukko?

Ehkä mulla on hukkunut mikä sun pointti on ollut. Lähdit siitä että indiepelien määrä on laskenut kun pelejä ei enää tehdä samaan tyyliin kuin dossiaikoihin.

Itse ajattelen että pelejä käyttävät tavalliset ihmiset ja heitä ei todennäköisesti kiinnosta alkaa pyhittämään tietokonettaa pelkälle pelille, josta johtuen pelejä ei ole myöskään järkevää kehittää esim. DOSille (ellei sitten omaksi tai pienehkön harrastajajoukon huviksi)

Uskon että todennäköisempi syy miksi indiepelien määrä on vähentyntyt (jos niin edes on käynyt) on se, että keskimääräiset pelien kuluttajat ovat tottuneet sellaisiin pelikokemuksiin mihin ei yksittäinen pelin tekijä tai edes pieni tiimi pysty, ainakaan jotain valmista alustaa. Lisäksi myös tarjonta on nykyään niin laajaa että harva lähtee tekemään peliä itse vain "jotta olisi jotain kivaa pelattavaa", kuten joitakin vuosikymmeniä sitten saattoi käydä.

jsbasic [07.02.2022 20:43:21]

#

Jalski kirjoitti:

Jos totta puhutaan, niin peliohjelmoinnin aloittaminen ei koskaan ole ollut näin helppoa. Saatavilla on älytön määrä kirjastoja joiden avulla voi suoraan keskittyä itse pelin tekemiseen.

Mihin ne indiepelit ovat siis kadonneet? Jos pelinteko oli vaikeaa (vaikeus ei ole helposti mitattavissa), niin voihan olla, että ennen juuri haluttiinkin niitä haasteita. Assembly/C/C++ oli kovin arvostettu taito ja osoitus siitä, että tuote on laadukas. Kun pystyi tuottamaan oman "standalone-exen", niin lähes lunasti ohjelmalleen paikan esimerkiksi ilmaisrompulla.

Toisaalta rauta ei ole ohjelmoijan ainoa haaste, vaan ohjelmoinnissa tarvitaan ajattelua. Ohjelman käyttökelpoisuus riippuu sisäisestä arkkitehtuurista. Suorituskyky riippuu ennenkaikkea ohjelmointitaidosta, oli kieli mikä tahansa, minkä olen oppinut täältä Putkasta. Mutta en ihmettele jos raudanhallinta ja muu laatu korreloi eri projekteissa. Dossissa rautatason kehitys kulkee muun ohjelmakehityksen mukana kunkin projekti sisällä. Se on tavallaan ymmärrettävää. Toisaalta Linuxia on kritisoitu siitä, että sovelluskehittäjät joutuvat käyttämään valmiita kirjastoja, mikä tuo ongelmia:

https://en.wikipedia.org/wiki/Criticism_of_desktop_Linux#Third-party_application_development

Etenkin Linuxissa on "älytön määrä kirjastoja". Missä siis viipyvät indiepelit? Kirjastojen määrä ei paljon auta, jos niiden rajapinta on mitä sattuu: Muuttuvat sekä ajallisesti että jakelullisesti.

Grez [07.02.2022 21:15:33]

#

jsbasic kirjoitti:

Mihin ne indiepelit ovat siis kadonneet?

Onko ne sitten kadonneet? Esim. App Storessa on noin 300 000 peliä, 40 000 enemmän kuin puoli vuotta sitten. Kehtaisin väittää asiaa mitenkään tutkimatta, että niistä ainakin kolmasosa on indiepelejä.

Microsoft storesta löytyy ihan osasto "esiin nostetut indiepelit", jossa on 108 peliä
https://www.microsoft.com/en-us/store/collections/indiegamespotlight
Montakohan niitä "ei esiin nostettuja" on.

Windowsille julkaistaan varmasti indiepelejä muutakin kautta.

Omassa Android-puhelimessani on kymmenkunta indiepeliä asennettuna. Ja määrän pienuus ei johdu siitä etteikö tarjontaa olisii vaan siitä, että pelaaminen ei nykyään juurikaan kiinnosta.

En ole paljonkaan tekemisissä nykyisten nuorten kanssa mutta omassa nuoruudessa minulla oli paljon tietokoneita harrastia kavereita, mutta vain yksi joka osasi sen verran ohjelmoida että teki jonkinlaisen matopelin tai muuta vastaavaa joka ei kuitenkaan muutamaa kaveria pidemmälle levinnyt. Tällä hetkellä tuttujen lapsista on ainakin 3 alle 18-vuotiasta, jotka ovat tehneet ja julkaisseet pelin tai pelejä itse.

jsbasic kirjoitti:

Kun pystyi tuottamaan oman "standalone-exen", niin lähes lunasti ohjelmalleen paikan esimerkiksi ilmaisrompulla.

Karrikoiden ehkä näin, mutta täytyi siinä jotain sisältöäkin olla. Eli ääriesimerkkinä pelkkä 60 tavun "Hello world" .exe ei vielä taivaita aukaissut silloinkaan. (Tai 20 tavun .COM nimettynä .EXEksi :p )

mpni [07.02.2022 22:05:43]

#

Grez kirjoitti:

En ole paljonkaan tekemisissä nykyisten nuorten kanssa mutta omassa nuoruudessa minulla oli paljon tietokoneita harrastia kavereita, mutta vain yksi joka osasi sen verran ohjelmoida että teki jonkinlaisen matopelin tai muuta vastaavaa joka ei kuitenkaan muutamaa kaveria pidemmälle levinnyt. Tällä hetkellä tuttujen lapsista on ainakin 3 alle 18-vuotiasta, jotka ovat tehneet ja julkaisseet pelin tai pelejä itse.

Näin se maailma kehittyy. Olin itse ensimmäisten onnekkaiden joukossa, jossa yliopistossa haasteellisen matemaattisen yhtälöiden ratkaisuksi riitti graafisen laskimen ohjelmointi yhtälön ratkaisemiseen. Hauska nähdä myös lukio-opetuksen tulevia suuntia erityisesti matematiikan saralla. En näe mitään järkeä vääntää vaikeaa neljän sivun vastausarkin (integraaliyhtälön?) ratkaisua itse, koska nykyisin hommat hoitaa tietokoneet sadasosasekunneissa. Jättäisin korkeintaan ratkaisun validoinnin opiskelijan hartioille. Näinhän hommat käytännössäkin tapahtuu. Kynällä ja paperilla ei ole juurikaan käyttöä..

jsbasic [07.02.2022 22:13:56]

#

Grez kirjoitti:

Tällä hetkellä tuttujen lapsista on ainakin 3 alle 18-vuotiasta, jotka ovat tehneet ja julkaisseet pelin tai pelejä itse.

Pelikulttuuri on miten se koetaan ja omat kriteerini poikkeavat nuorten omista käsityksistä pelien tekemisestä. Jos peruskoulussa opitaan vähänkin Pythonia, ovat oppilaiden kyvyt ohjelmoida paremmat kuin meillä, jotka kopioimme BASIC-rivejä kirjasta. Mutta lasten (ja meidän vanhempienkin) matematiikan taidot ovat heikkenemässä ja viihteellisyys kasvaa, niin painopiste siirtyy ns. helppoihin kieliin ja metodeihin senkin vuoksi. No, tämä on vahvasti tulkittu, mutta olen itse taantumassa helpomman kielen suuntaan, joten tämä on sen aiheuttamaa pohdintaa.

mpni [07.02.2022 22:48:16]

#

jsbasic kirjoitti:

(07.02.2022 22:13:56): ”– –” Peli­kult­tuuri on miten se koetaan ja omat...

Sanoisin, että hyvä matemaattinen lahjakkuus ja ohjelmointitaito kulkevat jonkin verran käsikädessä. Ongelmien ratkominen ohjelmoimalla vaatii myös matemaattista lahjakkuutta. Ainakin itse olen ajatellut asian näin. Voin toki olla väärässäkin. Onko tämä väite liikaa kärjistetty? Nyt kaikki noobit matemaatikot ja hyvät ohjelmoijat nostakaa rohkeasti käsiä pystyyn! : )

Grez [08.02.2022 08:20:22]

#

mpni kirjoitti:

Nyt kaikki noobit matemaatikot ja hyvät ohjelmoijat nostakaa rohkeasti käsiä pystyyn! : )

No mikä sitten on noobi matemaatikko? Osaa keskustella sujuvasti Riemannin hypoteesin ehdotetusta ratkaisusta mutta ei osaa todistaa sitä vääräksi?

Itse osaan soveltaa matemaattisia kaavoja ja ehkä todistaa jotain ihan yksinkertaisia asioita, mutta kyllä nuo useiden sivujen todistukset mitä matemaatikot pyörittelee menee sen verran vaikeiksi ettei niitä vapaaehtoisesti viitsi tutkia.

Toisaalta ollen myös ohjelmoijana keskinkertainen.

Metabolix [08.02.2022 10:06:42]

#

Ennen kaikki oli paremmin, mutta toisin kuin Turakointi antaa ymmärtää, tuskin se muutoksen juurisyy on kuitenkaan siinä, ettei ohjelmia enää tehdä suoraan rautaan kiinni.

Grez kirjoitti:

(03.02.2022 14:29:51): ”– –” Pikemminkin kyse on siitä, että DOS oli...

Tähän liittyen on syytä tunnustaa tosiasiat: ennen tietokoneet olivat muutenkin yksinkertaisempia, eri laitteita oli vähemmän, ominaisuuksia ja asetuksia vähemmän, tarvittavat ajurit pienempiä.

Kyllä, jos on tarkoitus tehdä äänet ja piirtäminen prosessorilla ja soittaa äänikortilla 2-kanavaista ääntä ja piirtää näytölle pikselidataa, niin tämä kyllä onnistui kivasti reaalitilassa mutta vaatii nykyään ainakin pari kerrosta väliin. Näin yksinkertaisessa asiassa ne välikerrokset ovat varsin hyviä ja luotettavia.

Mutta jos on tarkoitus tehdä laitteistokiihdytettyä 3D-grafiikkaa eri valmistajien eri korteilla, käyttää fysiikkalaskuihin GPU:n laskentatehoa, tukea ääniä kaiuttimien ja kuulokeportin ja ehkä jopa Bluetoothin kautta ja tukea verkkoyhteytenä suojattua WLANia sadalla eri verkkokortilla, niin 16-bittisestä reaalitilasta loppuu muisti välittömästi ja ylipäänsä ”suoraan raudalla toimivia ohjelmia” ei ole mielekästä tehdä, koska ohjelmasta 99% on eri laitteiden ajureita.

Ei ole pelkästään Microsoftin tahtotila, että pakotetaan käyttämään rajapintoja, vaan jokainen asiasta mitään ymmärtävä koodari on kiitollinen, ettei kaikkea edellä mainittua tarvitse tehdä itse rautatasolla, ja jokainen pelaaja voi olla kiitollinen siitä, että näytönohjaimen uusimmat ajurit saa valmistajalta eikä tuurilla jokaiselle pelille erikseen.

Turakointi kirjoitti:

Nykypelien kanssa on normaalia tapella mystisten ongelmien kanssa, kun peli ei vain jostain syystä toimi, eikä kukaan oikein tiedä, onko vika jossain pelin käyttämässä rajapinnassa, näytönohjaimen tai äänikortin ajurissa, käyttöjärjestelmän ytimessä vaiko itse pelissä.

Oletko vakavasti sitä mieltä, että nykypelien ongelmat johtuvat pelkästään useasta kerroksesta? Eli ratkaisiko ongelma, jos pelit tehtäisiin ”matalalla tasolla” eli laitettaisiin käyttöjärjestelmän ja ajureiden ominaisuudet pelin mukaan? Silloin tilanne olisi kyllä yksinkertaisempi, koska vika olisi varmasti pelissä, mutta tuskin se tekisi vian etsimisestä juuri sen helpompaa.

Tai kääntäen: Jos teet DOS-tasoisen pelin, joka siis pyörii vain prosessorilla ja työntää grafiikat ja äänet ulos käyttäen jotain Windowsin perusrajapintaa, niin väitätkö, että siinäkin on odotettavissa käyttöjärjestelmästä tai ajureista johtuvia outoja bugeja? En usko.

Turakointi kirjoitti:

Viimeaikaisten Windows-versioiden myötä Microsoftilla on ollut selkeä tavoite rikkoa taaksepäin yhteensopivuus DOS-ohjelmien kanssa, – – eivätkä klassikkopelit enää toimi Windowsilla ilman erikseen asennettavia emulaattoreita.

Oletko tietoinen, että virtuaalinen 8086-tila toimii vain 32-bittisestä tilasta ja ei enää 64-bittisestä tilasta? Tämä ei ole tietääkseni Microsoftin vika.

Muutenkin DOS-ohjelmien "yhteensopivuus" on menetetty siinä vaiheessa, kun niillä ei ole enää oikeutta sorkkia kaikkia laitteita itse eikä koneessa edes ole esimerkiksi SB-yhteensopivaa äänikorttia. Tästä eteenpäin kaikki on ollut jonkinlaisen emulaattorin varassa.

Pitääkö emulaattorin olla Windowsiin integroituna, on sitten toinen kysymys. Käytännössä Windowsin kautta DOS-ohjelmien ajamisessa on ollut jo kauan ongelmia ja erilliset emulaattorit ovat toimineet paremmin. Ongelmana on ollut virtualisoinnissa liika nopeus (osa peleistä toimii aina prosessorin täydellä nopeudella) ja emulaattoreissa taas hitaus uusimmissa DOS-peleissä.

Turakointi kirjoitti:

tekee ohjelmien tekemisestä tietokoneelle paljon hankalampaa, kun joutuu käyttämään monimutkaisia frameworkkeja perusasioihinkin.

Tämä on ihmeellinen väite. Esimerkiksi SDL 1 on mielestäni paljon helpompi rajapinta kuin käsipelillä näytön tai äänikortin käsittely DOSissa, ja vaikka se on kirjastona nykymittapuulla alkeellinen ja rajoittunut, niin kyllä se ainakin reaalitilaan suunniteltujen pelien porttaamiseen riittää enemmän kuin hyvin.

Turakointi kirjoitti:

Tämä näkyy yksinkertaisten indie-pelien kehitysmäärän laskuna,

Eiköhän se vika ole pikemmin valtavan suuri tarjonta, jossa yksinkertaiselle indie-pelille ei ole enää helppoja markkinoita. Netti ja kännyköiden sovelluskaupat ovat täynnä pieniä pelejä kaikenlaiseen makuun. Tilanne on aivan toinen vaikka 2005.

Turakointi kirjoitti:

Vaikka muuta usein väitetään, niin matalalle tasolle koodatut pelit ovat kuitenkin loppujen lopuksi kaikkein helpoimpia myös portata alustalta toiselle, – – Kaikkein hankalimpia porttauksen kannalta ovat Windowsille tehdyt pelit,

Tämä on koodarin valinta. Kyllä edelleenkin ohjelman voi koodata yhtä ”matalalle tasolle”, ja tarvitsee vaihtaa vain näytön käsittelyyn ja näppäimistön lukemiseen liittyvät rutiinit, jos pelin rakenne on sopiva. Sopivilla kirjastoilla pääsee jopa siihen, että ei tarvitse itse portata peliä, kun kirjaston tekijä on jo portannut kirjaston.

WinAPI:n käyttäminen pitkin ohjelmaa on oma valinta, ei mikään välttämättömyys. Ihan samanlainen valinta on sekin, jos reaalitilan ohjelmaan on siroteltu suoraa näytön käsittelyä sinne tänne. Miten helposti porttaaminen onnistuu, jos jossain yllättävässä kohdassa ohjelmaa onkin päätetty piirtää pari pikseliä käsin: *(char*)0xa0008=0x12;

Turakointi kirjoitti:

Kasvava määrä rajapintoja ohjelman ja raudan välissä tekee tietokoneen käytöstä hankalaa myös käyttäjälle.

Tekeekö?

Nykyään ei tarvitse itse tietää, minkä merkkinen näytönohjain tai äänikortti koneessa on, mikä vaihtoehdoista on tämän kanssa yhteensopiva, mikä osoite, IRQ ja DMA pitää valita asetuksista jne. Nykyään ei tarvitse tietää, minkä numeroiseen COM-porttiin toinen hiiri tai sarjaporttikaapeli on kiinnitetty kaksinpeliä varten. Nykyään ei tarvitse lisätä CONFIG.SYSiin käsin rivejä vaikka CD-aseman ajureille eikä säätää vaihtoehtoisia asetuksia tilanteisiin, joissa kyseinen ajuri on tarpeeton ja ehkä jopa estää jonkin reaalitilan pelin käynnistämisen. Muistatko tällaisia?

Vai onko käsityksesi DOSista sittenkin siltä ajalta, kun näitä ei enää mietitty vaan Windows tarjosi DOS-ohjelmille emuloidun äänikortin mutta piti ehkä osata valita sopivat EMS- tai XMS-muistiasetukset pikakuvakkeisiin ja varoa sekoittamasta DOS-ohjelmia pitkillä tiedostonimillä? Helppoa kuin heinänteko!

Grez [08.02.2022 10:52:20]

#

jalski kirjoitti:

jsbasic kirjoitti:

Viimeisinä aikoina poikkeuksena oli DOS/4G, joka lisäsikin epävakautta.

Meinaatko DOS/4GW:tä?

DOS/4GW oli Watcomin kääntäjän mukana tullut ilmainen rajoitettu versio DOS/4G:stä. En usko että jsbasicin kommentin kannalta oli olennaista, oliko kyse täydestä vai kevytversiosta.

Joskin DOS/4GW oli vissiin versiota 1.97 joten se oli vakaampi kuin aikaisemmat DOS/4G versiot.

jalski [08.02.2022 11:11:03]

#

Grez kirjoitti:

(08.02.2022 10:52:20): ”– –” DOS/4GW oli Watcomin kääntäjän mukana tullut...

En tajunnutkaan, että DOS4GW oli Watcomin kääntäjän mukana tullut versio vaikka tuosta W:stä olisi kyllä pitänyt tajuta...

jalski [08.02.2022 11:50:04]

#

Turakointi, toimiiko tuo DOS toteutuksesi perus reaalitilassa vai käväisetkö suojatussa tilassa asettamassa "unreal mode":n ja saat ohjelmille käyttöön 4 gigan datasegmentin?

Turakointi [08.02.2022 16:28:46]

#

Se on ihan kokonaan real mode -systeemi. Toki unreal moden alustaminen onnistuisi alkulataajallakin, eihän kernelin sitä varsinaisesti välttämättä tarvitse tukea.

jalski [08.02.2022 16:39:01]

#

Joskus Plan 9 käyttöjärjestelmää käyttäneenä pidin tätä mielenkiintoisena lukemisena.

jsbasic [08.02.2022 21:10:24]

#

Metabolix kirjoitti:

Tämä on koodarin valinta. Kyllä edelleenkin ohjelman voi koodata yhtä ”matalalle tasolle”, ja tarvitsee vaihtaa vain näytön käsittelyyn ja näppäimistön lukemiseen liittyvät rutiinit, jos pelin rakenne on sopiva.

Mutta mikään ei kuitenkaan takaa, että rutiinit toimivat samalla tavalla. Esimerkiksi funktioiden suoritusaika voi vaihdella. Jos näytölle piirretään konekielen muistioperaatioilla, siihen kuluva aika on helppo ennustaa. Emulaattorin hitaus tai nopeus on pieni ongelma siihen nähden että yksittäisten rutiinien kesto vaihtelee kellojaksoissa.

Metabolix kirjoitti:

WinAPI:n käyttäminen pitkin ohjelmaa on oma valinta, ei mikään välttämättömyys. Ihan samanlainen valinta on sekin, jos reaalitilan ohjelmaan on siroteltu suoraa näytön käsittelyä sinne tänne. Miten helposti porttaaminen onnistuu, jos jossain yllättävässä kohdassa ohjelmaa onkin päätetty piirtää pari pikseliä käsin: *(char*)0xa0008=0x12;

Tuo on äärimmäinen esimerkki, mutta todellinen. Esimerkiksi Commodore 64:n peleissä näyttömuistia käytettiin tavallisena muistina. Joskus yhtä näytön merkkiä käytettiin laskurina ohjelman sisäisessä toiminnassa.

Metabolix kirjoitti:

jokainen asiasta mitään ymmärtävä koodari on kiitollinen, ettei kaikkea edellä mainittua tarvitse tehdä itse rautatasolla

Ohjelmakoodilla on käytännössä aina jonkin verran sivuvaikutuksia. Sivuvaikutuksista on keskusteltu melkein sata vuotta liittyen vuonna 1936 julkaistuun turing koneen malliin ja lambda-kalkyyliin. Sellainen funktionaalisten kielten ihanne, jossa jokainen toiminto erotetaan omaksi rutiinikseen, ei ole käytönnössä toimiva. Ajatellaan esimerkiksi 3D-peliä unix-putkessa:

peli | unity_tai_muu_3d_moottori | ffplay

Tässä siis pelin stdout ohjataan 3D-moottorin kautta näytölle piirtävään video-ohjelmaan. Tämä olisi ihanteellinen funktionaalinen tapa tehdä 3D-peli, mutta käytännössä tämä olisi tehotonta. Paljon samankaltaisia toimintoja jouduttaisiin laskemaan useassa eri ohjelmassa.

Tämä oli siis teoreettinen esimerkki. Uskon että kerroksia tarvitaan käytännössä helpottamaan koodirien työtä, mutta yhtä lailla sivuvaikutuksista voidaan saada hyötyä tai haittaa. Toisaalta tietokoneen monimutkaisuuden kasvu johtaa siihen, että sivuvaikutuksia pyritään välttämään yhä enemmän. Kehitys on nopeaa ja minusta perinteinen ohjelmointi (jossa on minkää vertaa näitä rautatason juttuja) alkaa olla uhattuna.

Grez [08.02.2022 21:16:37]

#

jsbasic kirjoitti:

Mutta mikään ei kuitenkaan takaa, että rutiinit toimivat samalla tavalla. Esimerkiksi funktioiden suoritusaika voi vaihdella.

Tämä käytännössä ei nykyään ole ongelma, koska ohjelmia ei muutenkaan voi kirjoittaa niin tarkasti suoritusajasta riippuviksi, koska jopa saman arkkitehtuurin tietokoneita on eri nopeuksisia.

jsbasic kirjoitti:

Esimerkiksi Commodore 64:n peleissä näyttömuistia käytettiin tavallisena muistina.

C64:ssä näyttömuisti oli tavallista muistia.

Turakointi [09.02.2022 08:53:03]

#

Implementoin DOS-APIn dokumentoimattoman järjestelmäkutsun int21,58 ja nyt Cutemouse-hiiriajuri näyttää toimivan moitteetta.

Turakointi [06.03.2022 20:25:37]

#

Tein boottilevykkeen, joka käynnistää oman dossikernelin ja sen jälkeen lataa graafisen lEEt/OS-moniajojärjestelmän siihen päälle. Kerneli tukee nyt myös tiedostojärjestelmään kirjoittamista. Pitää tehdä kiintolevyjen tuki seuraavaksi.

https://www.youtube.com/watch?v=YJKsdn2uWbI

Jere Sumell [20.03.2022 09:48:29]

#

Mitä en käynyt vähään aikaan täällä Putkassa, vaan tänään sunnuntaina 20.03.2022 päivitin itseni ajan tasalle, mitä uutta tullut, niin tämä säie poikinut uusia postauksia sitten viime lukemani.

Otan nyt kantaa tuohon, kun tässä aiemmin säikeessä mainittiin, että onko matemaatiikan ymmärrys jotenkin korreloiko se ohjelmointitaitoihin, niin loppupeleissä varmaan onkin niin, kun ohjelmointia voi varmaan kait jossain pisteessä pitää pelkkänä matematiikkana.

Tähän pyydettiin vastauksia hyviltä ohjelmoijilta, mutta vastaan vielä vähän laajemmin oman näkemykseni avaten taustoja, vaikka en ole erityisen hyvä ohjelmoija, enkä erityisen pätevä matematiikassakaan.

Mitä tietojenkäsittelytiede on alunperin matematiikan sivujuonteena päätynyt ainakin Turun Yliopiston ainevalikoimaan, ja matematiikassa se kehittyminen ja sen taju on sillä tavalla astettaista, että mitä pidemmälle sitä opiskelee, ymmärrys laajenee ja sitten sama, mitä joka alalla on, tietyn keskitason voi saavuttaa ihan normaalilla älykkyysosamäärällä kovalla harjoittelulla ja työnteolla, mutta sitten vaaditaan erityistä lahjakkuutta, jos halutaan aivan huipulle. Sama se on tässä musiikkihommassakin, mitä itse harrastan kitaran soittoa.

Käytännön esimerkki tästä todellista lahjakkuutta vaativasta huippuymmärryksestä on esimerkiksi, että varmaan maailmassa on useitakin fyysikkoja, jotka ovat perehtyneet Albert Einsteinin suhteellisuusteoriaan, mitä miestä pidettiin 1900 luvun merkittävimpänä fyysikkona, niin siitä porukasta, joka perehtynyt siihen todella paljon, ymmärtäväkö siitä populaatiosta monikaan sitä niin perusteellisesti, että osaisi jotain mielenkiintoista keskustelun avausta siitä tarjota argumentoiden siten, että voisi kyseenalaistaa jotain siitä?

2000-luvun ensimmäisen toistaiseksi vuosisadan merkittävmpinänä fyysikkona pidetään varmaan Stephen Hawkingiä, joka eli mielestäni erityisen elämän, ja varmaan sama tämän esittämillä lopputulemilla ja papereilla niillä merkittävimmillä, mitä mies on esittänyt.

Eli kovalla työllä voi saavuttaa myös keskiverto-ohjelmoijan taidot ja matematiikan tajun tiettyyn pisteeseen saakka, mutta sitten todellinen huippu-osaaminen vaatii matemaattista luontaista lahjakkuutta.

Mitä itsekin itsetutkikelun empiriaan pohjautuen olen havainnut, että kyllähän ohjelmoidessa tai jotain ohjelmointiongelmaa miettiessä aivoissa aktivoituu samoja osa-alueita, mitä esimerkiksi ajan kuluksi täyttäisin Sudokua kynä/paperi -menetelmällä, joka sekin vaatii jonkinlaista matemaattisen logiikan tajua.

Sitten, jos selkounia harrastaa, mitä joskus itsekin pidin niistä päiväkirjaa, se jäänyt jo monta vuotta sitten, niin matemaattisten ongelmien ratkominen, kun herää aamuyön tunteina, ja aktivoi aivoissa niitä osa-alueita omaehtoisesti, jotka aktivoituvat matemaattisia ongelmia ratkottaessa, niin sitten kun menee noin puolen tunnin päästä uudestaan nukahtaa, pisimmän REM-univaiheen on todennäköisempää päästä Lucid-tilaan.

Turakointi [01.11.2022 00:13:28]

#

Kiintolevyjen tuki on vastatuulessa, koska kerneliä piinaa kiusallinen bugi, joka liittyy jotenkin levylle kirjoittamiseen. Kirjoitusoperaation jälkeen kerneli saattaa täysin satunnaisesti mennä aivan sekaisin. Ennen kiintolevyjen tuen toteuttamista aion tuon bugin korjata, mutta en ole vielä keksinyt, mistä se johtuu.

Viimeisin uusi ominaisuus kernelissä on laiteajurirajapinta. Laiteajureilla saa varattua tiedostonimiä, eli esimerkiksi jos laiteajuri haluaa laitenimekseen COM, niin tiedostonimet alkaen merkkijonosta "COM0" ja päättyen merkkijonoon "COM65535" ovat sitten varattuja tiedostonimiä, ja tuollaisen nimisen "tiedoston" avaaminen sitten avaakin laiteajurin siihen tiedostokahvaan. Laitetiedostoon voi normaalisti kirjoittaa ja lukea mielivaltaisia tavumääriä kerrallaan.

Tässä videossa demonstroin sarjaporttiajurin toimintaa: https://www.youtube.com/watch?v=RCoYLX7ZHLQ

Varattuja tiedostonimiä ovat myös kaikki merkkijonolla "DRV:"-alkavat nimet. Avaamalla esimerkiksi tiedoston DRV:A saadaan luettua osiolta raakadataa ja tehtyä näin esimerkiksi levykuva tai kopio tiedostojärjestelmästä helposti. Levykkeen kopiointi onnistuu yksinkertaisesti komennolla "copy DRV:A DRV:B".

Sarjaporttiajurin avulla on tarkoitus laittaa joku TSR-ohjelma kirjoittamaan sarjaporttiin kernelille tehdyt järjestelmäkutsut ja niiden vastaukset, jotta näen paremmin, mitä kernelissä oikein tapahtuu ennen sekoamista.

Ajurirajapintaa tehdessä löysin mielenkiintoisen dokumentoimattoman ominaisuuden x86-prosessoreista. Segmenttirekisterien arvojen muuttaminen viivästyttää keskeytyksien käsittelyä, mutta speksin mukaan ainoastaan sitä segmenttirekisterin arvoa muuttavaa konekäskyä seuraavan konekäskyn loppuun asti. ( https://www.pcjs.org/documents/manuals/intel/8086/ )

Käytännössä kuitenkin keskeytykset pysyvät segmenttirekisterin muuttamisen jälkeen poissa hieman pitemmän ajan. Käytännössä prosessorin liukuhihnalle jo valmiiksi haettuja käskyjä saatetaan suorittaa useampikin ilman keskeytysten käsittelyä käskyjen välissä. Ajurirajapintani koodissa oli kaksi melko tiukkaa silmukkaa, jotka keskeytyvät vain kolmesta mahdollisesta syystä: Joko ajurin read- tai write-funktio palauttaa arvon joka ei ole 0, ajuri palauttaa virhekoodin tai käyttäjän havaitaan painaneen CTRL+BREAK-näppäinyhdistelmää.

Koska tuo silmukka on varsin tiukkaa koodia ja se sisältää paljon ES-rekisterin muutteluja sekä eri koodisegmenttien välillä hyppiviä funktiokutsuja, niin prosessori ei sitten missään vaiheessa ehtinyt käsitellä keskeytyksiä. Kun ES- tai CS-rekisteriä muuttava käsky aina aiheuttaa keskeytyksien käsittelyn siirtymisen myöhemmäksi ja segmenttirekisterin arvon muuttamisen jälkeen tulee vain muutama yksinkertainen liukuhihnalle jo valmiiksi haettu aritmeettinen käsky, jossa useimmiten on operandeina vain rekistereitä tai prosessorin välimuistissa jo valmiiksi olevaa dataa, niin nuo käskyt sitten tulevat suoritetuksi niin nopeasti, etteivät keskeytykset ehdi mennä takaisin päälle. Sitten tuleekin taas jo joku segmenttirekisteriä muuttava käsky, joka siirtää taas keskeytyksien käsittelyä tuonnemmas. Sain siis yksinkertaisella silmukalla tietokoneen kokonaan jumiin niin, ettei prosessori kyennyt käsittelemään mitään laitekeskeytyksiä, ja ainoa tie silmukasta ulos oli nimenomaan se CTRL+BREAKin painaminen, jonka havaitseminen tietysti olisi edellyttänyt näppäimistökeskeytyksen käsittelyä.

Yritin ensin "korjata" ongelmaa lisäämällä silmukkaan HLT-konekäskyn (lyhenne sanasta "halt"), mutta se ei sitä korjannut. Syy on todennäköisesti se, että koska keskeytyskontrollerissa oli jo valmiiksi kellokeskeytys (joka sattuu olemaan korkeimman prioriteetin keskeytys) odottamassa, niin HLT-konekäskyn jälkeen prosessori vain sai heti käsitelläkseen sen kellokeskeytyksen ja alemman prioriteetin keskeytykset kuten se näppäimistökeskeytys jäivät sitten käsittelemättä, PC:n keskeytyskäsittelijä kun kykenee pitämään "jonossa" vain yhtä keskeytystä ja siinä "jonossa" korkeamman prioriteetin keskeytys aina menee alemman prioriteetin keskeytyksen päälle. Kesken korkeamman prioriteetin keskeytyksen käsittelyn "jonoon" ei voi myöskään tulla odottamaan matalamman prioriteetin keskeytystä, vaan keskeytyskontrolleri ei noteeraa matalamman prioriteetin keskeytyksiä ennen kuin sen ohjausrekisteriin on kirjoitettu End Of Interrupt -tavu (0x20).

Loppujen lopuksi ongelma korjautui lisäämällä silmukkaan peräkkäin konekäskyt STI ja NOP. Ensinmainittu noista laittaa keskeytykset päälle (lyhenne sanoista "set interrupt)", vaikka ne toki olivat päällä jo valmiiksi. STI-käskyllä on kuitenkin sellainen erikoisominaisuus verrattuna noihin segmenttirekisteriin kirjoittaviin käskyihin, että prosessori käsittelee keskeytykset tarkalleen STI-käskyä seuraavan käskyn jälkeen. NOP-konekäsky ei tee mitään (lyhenne sanoista "no operation"), ja se on siinä vain varmistamassa, ettei STI-konekäskyn jälkeen tule mitään sellaista käskyä, joka taas siirtäisi sitä keskeytysten käsittelyä myöhemmäksi. Nyt näppäimistökeskeytys tulee käsitellyksi ja muuten loputtomasta silmukasta pääsee pois painamalla CTRL+BREAK-näppäinyhdistelmää.

Noiden STI- ja NOP-konekäskyjen tilalla myös esimerkiksi kirjainten näytölle tulostaminen BIOS-kutsuilla näytti saavan prosessorin käsittelemään keskeytykset normaalisti. Ratkaisun piti kuitenkin olla sellainen, joka ei vaikuta ohjelman logiikkaan eikä näy käyttäjälle millään tavalla.

Turakointi [01.11.2022 20:06:01]

#

Nyt sarjaporttiajuri tukee myös XON/XOFF- ja RTS/CTS-vuonohjauksia. Kirjoitin sille myös MODE-ohjelman, jolla muutetaan sarjaportin asetuksia.


Sivun alkuun

Vastaus

Muista lukea kirjoitusohjeet.
Tietoa sivustosta