Meno suomi24, 0 mutta mitä muuta sä harrastelet kuin kirjoituksesi mukaista paskaa suomi24pätemistä?
0Äänestä
taitoEItule_esille
Ehkä sä voisit vaikka kirjotella miten sä niitä grafiikka-ajureita koodailet..? Jotain miten homma tapahtuu, mitkä ovat ne perusteet, ne keskeiset asiat "ajurikoodauksessa"? Kun kyse ei ole vain tavallisesta 'windows-softasta', niin mitkä on ne tekijät joista pitää lähteä liikkeelle, kyse on kuitenkin aika matalan tason ohjelmoinnista? Miten sä vaikka lähdet suunnittelemaan noita matalan tason, grafiikka-ajureiden toteutuksia? Miten sä integroit sun ohjelmat järjestelmään, tai siis että kerro toki jotain, minua ainakin kiinnostaa, niin kerro toki lisää???
Ei siinä grafiikka-ajurissa mitään ihmeellistä ole, että käytännössä tarvitsee tehdä rajapinnalla joka tarjoaa pääsyn raudan lähelle.
Homma kannattaisi määritellä ensiksi jollain korkean tason kielellä ja simuloida. Haskell olisi tähän hyvä, että kirjoittelee funktioita mitä sen pitäisi tarjota. Ainoastaan pieni poikkeus sinne että on joku monadi siellä että piirtää pikseliä. Tuota specificaatiota voidaan käyttää sitten verifioimaan että lopullinen toteutus toimii oikein.
Sitten vaan alkaisi kirjoitella samaa rajapinnalla mikä tarjoaa pääsyn sinne rautaan. Onhan siellä käyttöjärjestelmissä se komponenttirajapinta jutuille missä toimitaan kernelin muistiavaruudessa. Samalla tavalla tekisi niitä funktioita mutta hoitaisi sen C:llä ja optimoi ja korvaa rautakutsuilla juttuja mitä voi.
Sitä voi sitten tehdä verifiointia esim. Isabellea käyttämällä tai muuten kirjoittamalla testipattereita, että optimoitu ajurikikkare toimii speksin mukaisesti.
Eipä tuollaista oikein tarvitse kun siellä on standardia sekä laitevalmistajien tekemiä ajureita yms. joita käytetään korkeamman tason rajapinnan kautta. Ei siis tarvitse assemblernysvää.
0Äänestä
häkkäystä
No, mä olen aikoinaan motorolan prossulle ohjelmoinut boottisekvenssin uusiksi syystä ettei muisti riittänyt uusien ominaisuuksien tuomiseen muutoin (yliajokoodi).
0Äänestä
Ass Shambler
Itse aikoinaan teininä kirjoittelin assyllä paljonkin, mm. DOS-extenderin (ns protected-mode ajurin) sekä MOD/S3M-moduuleja toistavan soittimen. Nykyään tietokanta-asiantuntijana ei tuo assembler-tuntemus ole niin kovaa valuuttaa, mutta jos tarve tulisi ja palkka pysyisi samana, niin mielellään sitäkin tekisin.
0Äänestä
ei ole ollut tarvett
Eipä ollut sata-2 ajureita tai grafiikkakiihdyttimiä niissä IBM:n keskuskoneissa, joille olen viimeksi (viime vuosituhannen puolella) Assemblerilla koodannut.
Nykyään mennään lähinnä C/C /C#/Java -linjalla.
0Äänestä
assemblyonhyvä
Ei ollut ei, grafiikkakiihdytin prosessoreita ei ollut edes keksittykään vielä silloin, piti vain ilman mitään dokumentaatiota keksiä ja kirjoittaa in/out komennoilla toimintoja 4-bittisillä väreillä olevalle näytönohjainkortille.
Joitain juttuja ei pysty yksinkertaisesti tekemään ilman assemblyä, erittäin matalan tason juttuja, laitteistoajurit sekä sellaiset jotka pystyvät menemään protected mode -käyttöjärjestelmän alle ottamaan resursseja käyttöön muuttamalla protected mode -käyttöjärjestelmän privilage leveleitä.
Visual BASIC:llakin voisi olla huono kirjoittaa oikein hardware low-level -ohjelmia.
Ei ollut ei, grafiikkakiihdytin prosessoreita ei ollut edes keksittykään vielä silloin, piti vain ilman mitään dokumentaatiota keksiä ja kirjoittaa in/out komennoilla toimintoja 4-bittisillä väreillä olevalle näytönohjainkortille.
Joitain juttuja ei pysty yksinkertaisesti tekemään ilman assemblyä, erittäin matalan tason juttuja, laitteistoajurit sekä sellaiset jotka pystyvät menemään protected mode -käyttöjärjestelmän alle ottamaan resursseja käyttöön muuttamalla protected mode -käyttöjärjestelmän privilage leveleitä.
Visual BASIC:llakin voisi olla huono kirjoittaa oikein hardware low-level -ohjelmia.
Ei siinä grafiikka-ajurissa mitään ihmeellistä ole, että käytännössä tarvitsee tehdä rajapinnalla joka tarjoaa pääsyn raudan lähelle.
Homma kannattaisi määritellä ensiksi jollain korkean tason kielellä ja simuloida. Haskell olisi tähän hyvä, että kirjoittelee funktioita mitä sen pitäisi tarjota. Ainoastaan pieni poikkeus sinne että on joku monadi siellä että piirtää pikseliä. Tuota specificaatiota voidaan käyttää sitten verifioimaan että lopullinen toteutus toimii oikein.
Sitten vaan alkaisi kirjoitella samaa rajapinnalla mikä tarjoaa pääsyn sinne rautaan. Onhan siellä käyttöjärjestelmissä se komponenttirajapinta jutuille missä toimitaan kernelin muistiavaruudessa. Samalla tavalla tekisi niitä funktioita mutta hoitaisi sen C:llä ja optimoi ja korvaa rautakutsuilla juttuja mitä voi.
Sitä voi sitten tehdä verifiointia esim. Isabellea käyttämällä tai muuten kirjoittamalla testipattereita, että optimoitu ajurikikkare toimii speksin mukaisesti.
0Äänestä
en_ole_reitmaa
minä olen suunnitellut oman ohjelmoitavan kojeeni ja rakentanut sen ja purkanutkin ja nyt osat keräävät pölyä. TTL-irtologiikalla, ei prosessoria. Sananleveys 16 bittiä, muistia 256 bittiä. Kellotaajuus niin hidas kuin vain käyttäjän sormi nappia painelee. Ei ole grafiikkaa.
0Äänestä
8255_PIO
Ja Z80:lle olen kirjoittanut assemblerilla omia ohjelmia.
0Äänestä
onmiettimisiä
Olen minäkin tehnyt Z80-prossalle aikoinaan :)
Muuttuu huomattavan matalalle tasolle todella kirjoittaa tuollaisia ajureita jotka manipuloivat järjestelmän privilege-leveleitäkin, juurikin tuollaisen keskellä olen nyt. IOPL-tasoja käyttöjärjestelmän ohi.
Mulla on tuossa ajurissa vika, koska ei saa käyttöön aivan kaikkia I/O portteja johtuen service-tyyppisestä kutsusta, joka pitää korjata. Esim. System Control Port 92h on sellainen, johon ei riitä oikeudet, mutta hyvin riittää DMA-linjojen lukemiseen, kuten DMA-0 eli muistin päivitys.
0Äänestä
todellakin_olen
Nasmilla kirjoitin kerran ohjelman; "Terve Mualima"
Vastaukset 13
Vanhimmat
Meno suomi24, 0 mutta mitä muuta sä harrastelet kuin kirjoituksesi mukaista paskaa suomi24pätemistä?
Ehkä sä voisit vaikka kirjotella miten sä niitä grafiikka-ajureita koodailet..? Jotain miten homma tapahtuu, mitkä ovat ne perusteet, ne keskeiset asiat "ajurikoodauksessa"? Kun kyse ei ole vain tavallisesta 'windows-softasta', niin mitkä on ne tekijät joista pitää lähteä liikkeelle, kyse on kuitenkin aika matalan tason ohjelmoinnista? Miten sä vaikka lähdet suunnittelemaan noita matalan tason, grafiikka-ajureiden toteutuksia? Miten sä integroit sun ohjelmat järjestelmään, tai siis että kerro toki jotain, minua ainakin kiinnostaa, niin kerro toki lisää???
Ei siinä grafiikka-ajurissa mitään ihmeellistä ole, että käytännössä tarvitsee tehdä rajapinnalla joka tarjoaa pääsyn raudan lähelle.
Homma kannattaisi määritellä ensiksi jollain korkean tason kielellä ja simuloida. Haskell olisi tähän hyvä, että kirjoittelee funktioita mitä sen pitäisi tarjota. Ainoastaan pieni poikkeus sinne että on joku monadi siellä että piirtää pikseliä. Tuota specificaatiota voidaan käyttää sitten verifioimaan että lopullinen toteutus toimii oikein.
Sitten vaan alkaisi kirjoitella samaa rajapinnalla mikä tarjoaa pääsyn sinne rautaan. Onhan siellä käyttöjärjestelmissä se komponenttirajapinta jutuille missä toimitaan kernelin muistiavaruudessa. Samalla tavalla tekisi niitä funktioita mutta hoitaisi sen C:llä ja optimoi ja korvaa rautakutsuilla juttuja mitä voi.
Sitä voi sitten tehdä verifiointia esim. Isabellea käyttämällä tai muuten kirjoittamalla testipattereita, että optimoitu ajurikikkare toimii speksin mukaisesti.
Eipä tuollaista oikein tarvitse kun siellä on standardia sekä laitevalmistajien tekemiä ajureita yms. joita käytetään korkeamman tason rajapinnan kautta. Ei siis tarvitse assemblernysvää.
No, mä olen aikoinaan motorolan prossulle ohjelmoinut boottisekvenssin uusiksi syystä ettei muisti riittänyt uusien ominaisuuksien tuomiseen muutoin (yliajokoodi).
Itse aikoinaan teininä kirjoittelin assyllä paljonkin, mm. DOS-extenderin (ns protected-mode ajurin) sekä MOD/S3M-moduuleja toistavan soittimen. Nykyään tietokanta-asiantuntijana ei tuo assembler-tuntemus ole niin kovaa valuuttaa, mutta jos tarve tulisi ja palkka pysyisi samana, niin mielellään sitäkin tekisin.
Eipä ollut sata-2 ajureita tai grafiikkakiihdyttimiä niissä IBM:n keskuskoneissa, joille olen viimeksi (viime vuosituhannen puolella) Assemblerilla koodannut.
Nykyään mennään lähinnä C/C /C#/Java -linjalla.
Ei ollut ei, grafiikkakiihdytin prosessoreita ei ollut edes keksittykään vielä silloin, piti vain ilman mitään dokumentaatiota keksiä ja kirjoittaa in/out komennoilla toimintoja 4-bittisillä väreillä olevalle näytönohjainkortille.
Joitain juttuja ei pysty yksinkertaisesti tekemään ilman assemblyä, erittäin matalan tason juttuja, laitteistoajurit sekä sellaiset jotka pystyvät menemään protected mode -käyttöjärjestelmän alle ottamaan resursseja käyttöön muuttamalla protected mode -käyttöjärjestelmän privilage leveleitä.
Visual BASIC:llakin voisi olla huono kirjoittaa oikein hardware low-level -ohjelmia.
Ei siinä grafiikka-ajurissa mitään ihmeellistä ole, että käytännössä tarvitsee tehdä rajapinnalla joka tarjoaa pääsyn raudan lähelle.
Homma kannattaisi määritellä ensiksi jollain korkean tason kielellä ja simuloida. Haskell olisi tähän hyvä, että kirjoittelee funktioita mitä sen pitäisi tarjota. Ainoastaan pieni poikkeus sinne että on joku monadi siellä että piirtää pikseliä. Tuota specificaatiota voidaan käyttää sitten verifioimaan että lopullinen toteutus toimii oikein.
Sitten vaan alkaisi kirjoitella samaa rajapinnalla mikä tarjoaa pääsyn sinne rautaan. Onhan siellä käyttöjärjestelmissä se komponenttirajapinta jutuille missä toimitaan kernelin muistiavaruudessa. Samalla tavalla tekisi niitä funktioita mutta hoitaisi sen C:llä ja optimoi ja korvaa rautakutsuilla juttuja mitä voi.
Sitä voi sitten tehdä verifiointia esim. Isabellea käyttämällä tai muuten kirjoittamalla testipattereita, että optimoitu ajurikikkare toimii speksin mukaisesti.
minä olen suunnitellut oman ohjelmoitavan kojeeni ja rakentanut sen ja purkanutkin ja nyt osat keräävät pölyä. TTL-irtologiikalla, ei prosessoria. Sananleveys 16 bittiä, muistia 256 bittiä. Kellotaajuus niin hidas kuin vain käyttäjän sormi nappia painelee. Ei ole grafiikkaa.
Ja Z80:lle olen kirjoittanut assemblerilla omia ohjelmia.
Olen minäkin tehnyt Z80-prossalle aikoinaan :)
Muuttuu huomattavan matalalle tasolle todella kirjoittaa tuollaisia ajureita jotka manipuloivat järjestelmän privilege-leveleitäkin, juurikin tuollaisen keskellä olen nyt. IOPL-tasoja käyttöjärjestelmän ohi.
Mulla on tuossa ajurissa vika, koska ei saa käyttöön aivan kaikkia I/O portteja johtuen service-tyyppisestä kutsusta, joka pitää korjata. Esim. System Control Port 92h on sellainen, johon ei riitä oikeudet, mutta hyvin riittää DMA-linjojen lukemiseen, kuten DMA-0 eli muistin päivitys.
Nasmilla kirjoitin kerran ohjelman; "Terve Mualima"