Nykyisin ei juuri enää kannata 8-bittisillä koneilla koodata assemblerilla konkreettisella koneella, kun kaikki käy niin paljon kätevämmin emulaattorien kanssa nykykoneilta. Nykyiset assemblerit osaa mm. paketoida koodin rom-moduliksi suoraan - ei tarvitse kuin polttaa oma moduli. Tai voi saada .wav tiedostona ohjelman lataustiedoston, jonka voi ladata vanhaan tapaan c-kasetilta load-komennolla: Riittää lisätä lähdekoodiin makro, joka em. tiedoston tuottaa.
Käännösten tuottamisajat ovat myös mielenkiintoisia: Koska koneet harvoin tukee yli 64k muistia, menee käännökseen maksimissaan aikaa n. 0.5 sekuntia vähän makrojen vaikeusasteesta riippuen: .wav-lataustiedoston tuottaminen voi lopussa viedä jopa 20s.
Mitä hyötyä tästä sitten on? No, vaikka se, että em. koneissa ei vielä ollut erikoisominaisuuksia(MMU, math-co, MMX, jne..) hankaloittamassa koodausta vaan voi keskittyä pelkkään assembleriin. Täytyy tosin sanoa, että nuo vanhat prosessorit on usein hankalampia ohjelmoitavia kuin nykyiset prosessorit - niin paljon huonommin laitteiden hw on dokumentoitu ainakin alunperin: Tai valmistaja ei ole halunnut tietoja julki.
Mielenkiintoisia retro-makroja
24
195
Vastaukset
- Anonyymi
Miksi koodata assemblerilla vanhalle koneelle kun voi käyttää uusia?
- Anonyymi
Olisikohan vaikka siksi, että on kiinnostunut kyseisen aikakauden laitteista, tai haluaa luoda jotain uutta retroalustoille?
- Anonyymi
Hyvä ilmaisu.
- Anonyymi
Anonyymi kirjoitti:
Olisikohan vaikka siksi, että on kiinnostunut kyseisen aikakauden laitteista, tai haluaa luoda jotain uutta retroalustoille?
Kiinnostuksen ymmärrän mutta en sitä miksi näille tekisi yhtään mitään.
Nykyään löytyy mielenkiintoisempiakin alustoja, tai se mahdollisuus että tekee vaikka oman alustan. Siinähän olisi mahdollisuuksi viedä asioita eteenpäin. - Anonyymi
Anonyymi kirjoitti:
Kiinnostuksen ymmärrän mutta en sitä miksi näille tekisi yhtään mitään.
Nykyään löytyy mielenkiintoisempiakin alustoja, tai se mahdollisuus että tekee vaikka oman alustan. Siinähän olisi mahdollisuuksi viedä asioita eteenpäin.Ehkä siksi, että nuo retroalustat pysyvät hengissä. Jatkuvasti esim. Amigalle ja Commodorelle tulee jotain uutta. Pelejä, oheislaitteita jne. Sama koskee montaa muutakin jo historiaan painunutta alustaa. Kaikkea ei välttämättä tarvitse aina järjellä ajatella ja ymmärtää. Antaa niiden ihmisten touhuta noiden parissa, joille se on eräänlainen sydämmen asia. Tämä toiminta ei ole sinulta pois millään tavoin.
- Anonyymi
Anonyymi kirjoitti:
Ehkä siksi, että nuo retroalustat pysyvät hengissä. Jatkuvasti esim. Amigalle ja Commodorelle tulee jotain uutta. Pelejä, oheislaitteita jne. Sama koskee montaa muutakin jo historiaan painunutta alustaa. Kaikkea ei välttämättä tarvitse aina järjellä ajatella ja ymmärtää. Antaa niiden ihmisten touhuta noiden parissa, joille se on eräänlainen sydämmen asia. Tämä toiminta ei ole sinulta pois millään tavoin.
Parhaiten niitä alustoja pitää mielestäni hengissä ylläpito, ei niinkää se että kehittää näille uutta.
Sen lisäksi vanhat alustat eivät oikein liity assembleriin. Että voisi ennemmin tehdä kääntäjää nykyisille ohjelmointikielille vaikka. - Anonyymi
Anonyymi kirjoitti:
Parhaiten niitä alustoja pitää mielestäni hengissä ylläpito, ei niinkää se että kehittää näille uutta.
Sen lisäksi vanhat alustat eivät oikein liity assembleriin. Että voisi ennemmin tehdä kääntäjää nykyisille ohjelmointikielille vaikka.Vanhojen koneiden tehot eivät riittäneet erillisen kääntäjän pyörittämiseen. Vaihtoehdot olivat assembler tai Basic. Vanhojen 8-bittisen aikakauden koneille ylläpito tarkoittaa hieman eri asiaa, kuin nykyisille tietokoneille. Noihin koneisiin joudut vaihtamaan elektrolyyttikonkkia, etsimään ajan saatossa tulleita vikoja, vaihtamaan yksittäisiä muistipiirejä tai logiikkapiirejä.
Alkuperäisen raudan turvin koneet eivät pysy hengissä, koska korvaavia osia ei tahdo saada mistään. On pakko kehittää täysin uutta, millä voi korvata nämä puutteet. - Anonyymi
Anonyymi kirjoitti:
Vanhojen koneiden tehot eivät riittäneet erillisen kääntäjän pyörittämiseen. Vaihtoehdot olivat assembler tai Basic. Vanhojen 8-bittisen aikakauden koneille ylläpito tarkoittaa hieman eri asiaa, kuin nykyisille tietokoneille. Noihin koneisiin joudut vaihtamaan elektrolyyttikonkkia, etsimään ajan saatossa tulleita vikoja, vaihtamaan yksittäisiä muistipiirejä tai logiikkapiirejä.
Alkuperäisen raudan turvin koneet eivät pysy hengissä, koska korvaavia osia ei tahdo saada mistään. On pakko kehittää täysin uutta, millä voi korvata nämä puutteet.Kyllä sen kääntämisen voi tehdä tehokkaammalla tietokoneella, että saa softan siihen laitteeseen.
Mutta väittämäsi siitä, että ei jaksa pyörittää kääntäjää ei pidä paikkaansa. Kääntäminen osataan hyvin, C64:lle oli kääntäjiä ja mikään ei estä sellaisen tekemistä.
Moderneja välineitä sille ei saa mutta helposti saa parempaa kuin Basic koska koodin voi kääntää, että ei tarvitse tulkata. Ja saa myös parempaa kun assembler että olisi yksinkertaisempi ohjelmoida. - Anonyymi
Anonyymi kirjoitti:
Kyllä sen kääntämisen voi tehdä tehokkaammalla tietokoneella, että saa softan siihen laitteeseen.
Mutta väittämäsi siitä, että ei jaksa pyörittää kääntäjää ei pidä paikkaansa. Kääntäminen osataan hyvin, C64:lle oli kääntäjiä ja mikään ei estä sellaisen tekemistä.
Moderneja välineitä sille ei saa mutta helposti saa parempaa kuin Basic koska koodin voi kääntää, että ei tarvitse tulkata. Ja saa myös parempaa kun assembler että olisi yksinkertaisempi ohjelmoida.Kuten kirjoitit, mikään C64:ssa ei estä ajamasta siinä jotakin korkeamman tason kielen kääntäjää tai natiivia konekoodia, joka on käännetty jostakin korkeamman tason kielestä.
Käytännön este tulee prosessorin arkkitehtuurista.
Prosessorin pino on enintään 256 tavun mittainen eli selvästi riittämätön, jos sieltä varattaisiin tila myös funktioiden ja aliohjelmien kutsuparametreille ja paikallisille muuttujille. Siksi parametrejä ja muuttujia varten tulisi olla oma pino. Sen käsittely olisi tässä tapauksessa erittäin kömpelöä. Prosessori on vanha, sitä ei ole suunniteltu korkeamman tason kielellä tehtyjä ohjelmia varten.
Kääntäjän olisi tietenkin mahdollista allokoida staattisesti tila kutsuparametreille ja paikallisille muuttujille, jolloin ohjelman toiminta olisi parhaimmillaan melko optimaalista. Hinta tästä olisi muistintarpeen kasvu ja käytännössä rekursion käytön estyminen.
Kaikeista huolimatta ihmettelisin, jollei C64:lle olisi tehty kääntäjää jostakin korkeamman tason kielestä, esimerkiksi Pascalista. - Anonyymi
Anonyymi kirjoitti:
Kuten kirjoitit, mikään C64:ssa ei estä ajamasta siinä jotakin korkeamman tason kielen kääntäjää tai natiivia konekoodia, joka on käännetty jostakin korkeamman tason kielestä.
Käytännön este tulee prosessorin arkkitehtuurista.
Prosessorin pino on enintään 256 tavun mittainen eli selvästi riittämätön, jos sieltä varattaisiin tila myös funktioiden ja aliohjelmien kutsuparametreille ja paikallisille muuttujille. Siksi parametrejä ja muuttujia varten tulisi olla oma pino. Sen käsittely olisi tässä tapauksessa erittäin kömpelöä. Prosessori on vanha, sitä ei ole suunniteltu korkeamman tason kielellä tehtyjä ohjelmia varten.
Kääntäjän olisi tietenkin mahdollista allokoida staattisesti tila kutsuparametreille ja paikallisille muuttujille, jolloin ohjelman toiminta olisi parhaimmillaan melko optimaalista. Hinta tästä olisi muistintarpeen kasvu ja käytännössä rekursion käytön estyminen.
Kaikeista huolimatta ihmettelisin, jollei C64:lle olisi tehty kääntäjää jostakin korkeamman tason kielestä, esimerkiksi Pascalista."Kääntäjän olisi tietenkin mahdollista allokoida staattisesti tila kutsuparametreille ja paikallisille muuttujille, jolloin ohjelman toiminta olisi parhaimmillaan melko optimaalista. Hinta tästä olisi muistintarpeen kasvu ja käytännössä rekursion käytön estyminen."
Huomauttaisin, että nykypäivänä edelleen käytetään vielä vaikka C++:aa jossa käytetään rajallista pinoa ja rekursiolla on rajansa, että pino ei ylity.
Sen lisäksi ei ole myöskään mahdotonta tehdä kääntäjää joka muuttaa rekursion imperatiiviseksi, että pinoa ei käytetä. - Anonyymi
Anonyymi kirjoitti:
"Kääntäjän olisi tietenkin mahdollista allokoida staattisesti tila kutsuparametreille ja paikallisille muuttujille, jolloin ohjelman toiminta olisi parhaimmillaan melko optimaalista. Hinta tästä olisi muistintarpeen kasvu ja käytännössä rekursion käytön estyminen."
Huomauttaisin, että nykypäivänä edelleen käytetään vielä vaikka C :aa jossa käytetään rajallista pinoa ja rekursiolla on rajansa, että pino ei ylity.
Sen lisäksi ei ole myöskään mahdotonta tehdä kääntäjää joka muuttaa rekursion imperatiiviseksi, että pinoa ei käytetä.Pino on aina rajallinen resurssi. Esimerkiksi PC-koneessa pinoa saatetaan "jatkaa" näppärästi MMU:n avulla, mutta edelleen resurssi on rajallinen. Kevyemmässä raudassa (esim. 6510 tai mikä tahansa pieni mikrokontrolleri) ei tällaista tue, joten pino on kiinteä ja sen ylivuoto varsinkin jonkin keskeytyksen yhteydessä on tyypillinen mysteeriongelma debugattavaksi.
C-kielessä ei ole sisäänrakennettua mekanismia rekursion rajoittamiseksi. Kääntäjä saattaa (jollakin optiolla) tukea pinon testausta näkymättömissä jokaisen funktion alussa, mutta sekään ei ole pomminvarma tapa löytää ylivuotovirhe. Joissakin C-toteutuksissa on stackavail()-tyyppisiä funktioita, joilla on mahdollista kysyä vapaan pinon määrää. Mutta taitaa olla harvoin, kun moisia varotoimia viitsitään kirjoittaa.
Kyllä, rekursio voidaan "purkaa" joissakin tapauksissa, mutta ei sentään aina. Esimerkiksi jos funktio A kutsuu funktiota B, joka taas jossakin tilanteessa kutsuu funktiota A, pitää olla pieniin ihmeisiin pystyvä kääntäjä, joka purkaa rekursion. - Anonyymi
Anonyymi kirjoitti:
Olisikohan vaikka siksi, että on kiinnostunut kyseisen aikakauden laitteista, tai haluaa luoda jotain uutta retroalustoille?
Windows-käyttöjärjestelmästä löytyi laaja ja vakava tietoturvapuute, jopa NSA varoitti poikkeuksellisesti haavoittuvuudesta
Pahimmillaan haavoittuvuus tarkoittaa, että ohjelmistot voidaan huijata asentamaan haitallista sisältöä kuten vakoilu- tai kiristyshaittaohjelmia.
- Anonyymi
Vanhoissa kasibittisissä on hohtonsa. Laitteet ja prosessorit ovat nykymittapuun mukaan yksinkertaisia niin, että koko kone on oleellisesti helpompi ottaa haltuun. Vuosikymmeniä sitten dokumentaatio oli vaatimattomampaa monestakin syystä. Ennen internetiä tieto levisi lähinnä kirjojen välityksellä. Hitaasti ja kalliisti. Mutta eiköhän kaikki tarvittava löydy netistä nykyään.
Minullakin on jokunen vanha kasibittinen naftaliinissa. Vieläköhän 80-luvun lerput pyörähtäisivät? Koneelle voisi löytää käyttöä ohjaamaan jotakin automatiikkaa...
Commodore ja moni muu menneen ajan suuruus on historiaa. Sen sijaan 6500-sarjan prosessoreita ja oheispiirejä valmistetaan ja kehitetään edelleen, ihme kyllä.
https://www.westerndesigncenter.com/- Anonyymi
Yritin löytää internetistä tietoa microprosessorien valmistusmääristä, mutta tietoa löytyy ainoastaan myynnin rahallisesta määrästä.
Mututuntuma on että microprosessoreja valmistetaan vuosittain vähintään muutama miljardi, lähtien muuntajien kontrollipiireistä, eli kyllä myös vaatimattomampia ja "kapeampi"-väyläisiä prosessoreja valmistetaan.
PC-koneet ovat ennen kaikkea tiedon käsittelijöitä, mutta ne ovat pieni osa transistoreja käyttävistä ohjelmoitavista logiikoista, jotka perustuvat microprosessoreihin. - Anonyymi
Anonyymi kirjoitti:
Yritin löytää internetistä tietoa microprosessorien valmistusmääristä, mutta tietoa löytyy ainoastaan myynnin rahallisesta määrästä.
Mututuntuma on että microprosessoreja valmistetaan vuosittain vähintään muutama miljardi, lähtien muuntajien kontrollipiireistä, eli kyllä myös vaatimattomampia ja "kapeampi"-väyläisiä prosessoreja valmistetaan.
PC-koneet ovat ennen kaikkea tiedon käsittelijöitä, mutta ne ovat pieni osa transistoreja käyttävistä ohjelmoitavista logiikoista, jotka perustuvat microprosessoreihin.On hyvä ymmärtää että PC-koneiden kehitys on ainoastaan rahan tekemistä, kun tarvittavan tehoiset laitteet olivat käytössä jo 20 vuotta sitten.
Kun kasvaville tehoille ei ole mitään todellista käyttöä, tuhlataan ne pelailuun ja alati kasvavaan turhaan käyttöjärjestemä-turhuuteen. - Anonyymi
Anonyymi kirjoitti:
Yritin löytää internetistä tietoa microprosessorien valmistusmääristä, mutta tietoa löytyy ainoastaan myynnin rahallisesta määrästä.
Mututuntuma on että microprosessoreja valmistetaan vuosittain vähintään muutama miljardi, lähtien muuntajien kontrollipiireistä, eli kyllä myös vaatimattomampia ja "kapeampi"-väyläisiä prosessoreja valmistetaan.
PC-koneet ovat ennen kaikkea tiedon käsittelijöitä, mutta ne ovat pieni osa transistoreja käyttävistä ohjelmoitavista logiikoista, jotka perustuvat microprosessoreihin.Mikroprosessorien valmistusmäärä johtaa harhaan, koska mikrokontrollereiden (jossa prosessori yhtenä osana) valmistusmäärä on moninkertainen. Esimerkiksi keskivertokännykässä on todennäköisesti useita kontrollereita hoitamassa eri tehtäviä, joten jo niistä luultavasti kertyy muutama miljardi valmistettua prosessoria vuosittain.
Mikrokontrollereita käytetään melkein kaikissa elektroniikkaa sisältävissä laitteissa leluista lentokoneisiin, koska mikrokontrolleri on halpa, mutta monipuolinen komponentti. Mikroprosessoreita löytää lähinnä vain PC- tms. tietokoneista. - Anonyymi
Anonyymi kirjoitti:
On hyvä ymmärtää että PC-koneiden kehitys on ainoastaan rahan tekemistä, kun tarvittavan tehoiset laitteet olivat käytössä jo 20 vuotta sitten.
Kun kasvaville tehoille ei ole mitään todellista käyttöä, tuhlataan ne pelailuun ja alati kasvavaan turhaan käyttöjärjestemä-turhuuteen.Tarve riipu käyttötarkoituksista.
Kehitystä on muunlaistakin kuin suorituskyvyn lisäämistä. Voi sitä ostaa myös tietokoneen mikä vie vähemmän sähköä. - Anonyymi
Anonyymi kirjoitti:
On hyvä ymmärtää että PC-koneiden kehitys on ainoastaan rahan tekemistä, kun tarvittavan tehoiset laitteet olivat käytössä jo 20 vuotta sitten.
Kun kasvaville tehoille ei ole mitään todellista käyttöä, tuhlataan ne pelailuun ja alati kasvavaan turhaan käyttöjärjestemä-turhuuteen.Hyvin sanottu. Käytännössä kaikki työt mitä PC:llä teen päivittäin pystyisin hoitamaan aivan yhtä hyvin 20 vuotta sitten käyttämälläni koneella.
Ongelma on mielenkiintoinen: Laite- ja softakehitysfirmoilla valtava määrä insinöörejä palkkalistoillaan, joten kehitystä ei voi pysäyttää eikä edes jarruttaa. Tulostakin on tehtävä vuodesta toiseen eli ihmisille on myytävä uutta konetta ja uutta softaa joka vuosi, vaikkeivat he sitä oikeasti tarvitsisikaan.
Tässä on samantapainen valuvika kuin kestokulutustarvikkeiden valmistuksessa ylipäätään. Tuotteesta ei kannata tehdä liian hyvää. Hehkulamppujen tuhannen tunnin käyttöikä ehkä tunnetuimpana esimerkkinä.
- Anonyymi
Tämä "retroilu" on tullut osaksi laitteiden harrastus-kulttuuria - erityisesti kehittäjien - piirissä. Varmasti osasyy on se, että laitteet ovat helposti ymmärrettäviä ja historian perspektiivistä mielenkiintoisia, koska nyky-laitteissa on havaittavissa korjaus-liikkeitä, mitä vanhoista prosessoreista on puuttunut tai tehty jotenkin väärin.
Sinclair:lle löytyy mm. n. vuosi sitten youtube:ssa julkaistu oppimateriaali: The Retro Desk:in "Z80 Assembly Language for the ZX Spectrum Tutorial", jossa opetetaan miten kehitystyökaluja käytetään ja toisaalta käydään Z80-assembleria läpi - Sinclair:in näkökulmasta. Tosin, edelleenkin pidän John's Basement:in "Z80 Assembly Language", 1h 44min videota parhaana mitä löytyy.
Nykyään asm ei tosiaan ole ainoa vaihtoehto: C:llä voi tehdä ja varsinkin alustoille kootut tukikirjastot alkaa olla kattavia. Sanoisin kuitenkin, että C:llä koodatun joutuu käymään läpi assembler-tasolla - kääntäjät ei aina tuota kovinkaan optimaalista koodia. Melkoista kikkailua ohjelmistojen kehitys aikanaan ollut, kun muistin määrä rajoittunut max. 64k:hon jos ohjelma ollut iso ja vienyt koko tilan - tästä syystä ohjelmat voi ladata mm. pätkissä. Tätä varten työasemia on aikanaan tarvittu, että homma ei menisi liian hankalaksi.
80-luvulla ei ollut juuri liikkeellä ohjelmointikielien kasetteja, jotka olisi vaatineet myös ohjekirjoja mukaansa, joten mielenkiinnosta tullut katsottua vasta myöhemmin, miten nuo koneet on saatu aikanaan tikittämään. BASIC oli ainoa vaihtoehto tehdä jotain itse.- Anonyymi
Aika tavallista sekin, että ohjelmat tehtiin tehokkaammalla tietokoneella. Kun on enemmän muistia niin helpompi tehdä ja sitten vaan ristiinkääntämällä toisesta koneesta.
- Anonyymi
Anonyymi kirjoitti:
Aika tavallista sekin, että ohjelmat tehtiin tehokkaammalla tietokoneella. Kun on enemmän muistia niin helpompi tehdä ja sitten vaan ristiinkääntämällä toisesta koneesta.
Eikä aina tehokkaammillakaan koneilla: Eräs mielenkiintoinen tapa, mitä olen nähnyt liittyy muistin pankittamiseen Z80-koneilla, jolla 64k koneeseen saadaan esim. 512k muistia käyttämällä pankkeja io:n tai osoitelinjojen kautta. Kääntäjä siis pyörii yhdessä pankissa(16 tai 32k muistialue) ja syöttää käännöksen toiseen muistipankkiin. Lopuksi alueet vaihdetaan ja ohjelma alkaa pyöriä alkuosoitteestaan, kääntäjän tilalla näkyy esim. muistialue, jossa pelin visuaaliset elementit on varastoitu. Jippona tässä on näppäinkomento, jolla ohjelman voi keskeyttää missä tahansa kohtaa koodia ja saada vaikka rekisteri-dumpin ja sen jälkeen suoritettavan assembler-koodin kohdan ruudulle. Valmiista ohjelmasta tuota näppäinkomentoa ei löydy, koska se on itse asiassa esim. bios-piirin näppäimistö-driverin ominaisuus.
Yleensä tällaisella koneella pyöri CP/M käyttöjärjestelmä, jossa tuo muistipankkien vaihto tuli käyttiksen taholta automaattisesti ja kääntäjät pystyi hyödyntämään ylimääräistä muistia vaikkapa kirjastojen lataamiseen. En ole varma, käyttikö kovinkaan moni pelifirma tällaista ympäristöä kuitenkaan: Pelit on aika usein rajattu esim. 16k muistiin, vaikka 64k olisi mahdollista eli siinä on "perus" koneessa mahdollisesti ollut kääntäjä ladattuna, jolloin tilaa ei ole liiemmin jäänyt itse pelille.
Nykyisin tuollaisia muisti-mappereita pystyy rakentelemaan netistä löytyvien ohjeiden perusteella - ja vaikka ajamaan CP/M:ää koneellaan! - Anonyymi
Anonyymi kirjoitti:
Eikä aina tehokkaammillakaan koneilla: Eräs mielenkiintoinen tapa, mitä olen nähnyt liittyy muistin pankittamiseen Z80-koneilla, jolla 64k koneeseen saadaan esim. 512k muistia käyttämällä pankkeja io:n tai osoitelinjojen kautta. Kääntäjä siis pyörii yhdessä pankissa(16 tai 32k muistialue) ja syöttää käännöksen toiseen muistipankkiin. Lopuksi alueet vaihdetaan ja ohjelma alkaa pyöriä alkuosoitteestaan, kääntäjän tilalla näkyy esim. muistialue, jossa pelin visuaaliset elementit on varastoitu. Jippona tässä on näppäinkomento, jolla ohjelman voi keskeyttää missä tahansa kohtaa koodia ja saada vaikka rekisteri-dumpin ja sen jälkeen suoritettavan assembler-koodin kohdan ruudulle. Valmiista ohjelmasta tuota näppäinkomentoa ei löydy, koska se on itse asiassa esim. bios-piirin näppäimistö-driverin ominaisuus.
Yleensä tällaisella koneella pyöri CP/M käyttöjärjestelmä, jossa tuo muistipankkien vaihto tuli käyttiksen taholta automaattisesti ja kääntäjät pystyi hyödyntämään ylimääräistä muistia vaikkapa kirjastojen lataamiseen. En ole varma, käyttikö kovinkaan moni pelifirma tällaista ympäristöä kuitenkaan: Pelit on aika usein rajattu esim. 16k muistiin, vaikka 64k olisi mahdollista eli siinä on "perus" koneessa mahdollisesti ollut kääntäjä ladattuna, jolloin tilaa ei ole liiemmin jäänyt itse pelille.
Nykyisin tuollaisia muisti-mappereita pystyy rakentelemaan netistä löytyvien ohjeiden perusteella - ja vaikka ajamaan CP/M:ää koneellaan!Uutisoitu tapaus rupeaa haiskahtamaan tietomurrolla. Muutaman päivän takainen juttu, jossa käyttäjä ei pääse käyttämään konettaan luottokorttitietoja antamatta tuoksuu petoksen yritykseltä, samoin kuin erehdyttäminen ostamaan Microsoft365. Se sitten taas, että kesken käytön työnnetään ruudun kokoisia mainoksia, on sekin rikoslaissa sanktioitua tietojärjestelmän häirintää.
- Anonyymi
Anonyymi kirjoitti:
Eikä aina tehokkaammillakaan koneilla: Eräs mielenkiintoinen tapa, mitä olen nähnyt liittyy muistin pankittamiseen Z80-koneilla, jolla 64k koneeseen saadaan esim. 512k muistia käyttämällä pankkeja io:n tai osoitelinjojen kautta. Kääntäjä siis pyörii yhdessä pankissa(16 tai 32k muistialue) ja syöttää käännöksen toiseen muistipankkiin. Lopuksi alueet vaihdetaan ja ohjelma alkaa pyöriä alkuosoitteestaan, kääntäjän tilalla näkyy esim. muistialue, jossa pelin visuaaliset elementit on varastoitu. Jippona tässä on näppäinkomento, jolla ohjelman voi keskeyttää missä tahansa kohtaa koodia ja saada vaikka rekisteri-dumpin ja sen jälkeen suoritettavan assembler-koodin kohdan ruudulle. Valmiista ohjelmasta tuota näppäinkomentoa ei löydy, koska se on itse asiassa esim. bios-piirin näppäimistö-driverin ominaisuus.
Yleensä tällaisella koneella pyöri CP/M käyttöjärjestelmä, jossa tuo muistipankkien vaihto tuli käyttiksen taholta automaattisesti ja kääntäjät pystyi hyödyntämään ylimääräistä muistia vaikkapa kirjastojen lataamiseen. En ole varma, käyttikö kovinkaan moni pelifirma tällaista ympäristöä kuitenkaan: Pelit on aika usein rajattu esim. 16k muistiin, vaikka 64k olisi mahdollista eli siinä on "perus" koneessa mahdollisesti ollut kääntäjä ladattuna, jolloin tilaa ei ole liiemmin jäänyt itse pelille.
Nykyisin tuollaisia muisti-mappereita pystyy rakentelemaan netistä löytyvien ohjeiden perusteella - ja vaikka ajamaan CP/M:ää koneellaan!Veikkaisin että tuohon pelien kokoon vaikutti paljolti esim. kasettien kapasiteetti. Myyntihinnan alhaalla pitämiseksihän peli ei voinut ihan hirveän monesta kasetista koostua. Ja olihan se kasetilta latailu hidasta.
Nopeasti löytyi sellainen tieto Commodore 64:sta, että 30 min C-kasettipuoliskolle mahtui 100 kilotavua dataa. Pakkaamalla kapasiteettia sai laajennettua aina 1000 kB asti. Kaikkihan muistavat Turbo Tapen ja muut... En tosin tiedä, millaisia minuuttimääriä noissa myyntipelikaseteissa käytettiin.
Löytyyhän noita ristiinkääntäjiä ainakin C-64:lle muutamakin: Turbo Rascal, C-kääntäjä sekä XC-Basic. Kai noita joku johonkin käyttää. Iso osa alan miehistä, ihan jo muistojenkin takia, taitaa kuitenkin käyttää assembleria. Nykyisinhän sillekin saa ihan hienoja IDEjä ja käännösympäristöjä.
Sorry, jos tuli vähän C64-painotteinen viesti, mutta se on ympäristö jonka tunnen parhaiten. Tosin speccu ja Z80 kyllä kiinnostelisi. - Anonyymi
Anonyymi kirjoitti:
Veikkaisin että tuohon pelien kokoon vaikutti paljolti esim. kasettien kapasiteetti. Myyntihinnan alhaalla pitämiseksihän peli ei voinut ihan hirveän monesta kasetista koostua. Ja olihan se kasetilta latailu hidasta.
Nopeasti löytyi sellainen tieto Commodore 64:sta, että 30 min C-kasettipuoliskolle mahtui 100 kilotavua dataa. Pakkaamalla kapasiteettia sai laajennettua aina 1000 kB asti. Kaikkihan muistavat Turbo Tapen ja muut... En tosin tiedä, millaisia minuuttimääriä noissa myyntipelikaseteissa käytettiin.
Löytyyhän noita ristiinkääntäjiä ainakin C-64:lle muutamakin: Turbo Rascal, C-kääntäjä sekä XC-Basic. Kai noita joku johonkin käyttää. Iso osa alan miehistä, ihan jo muistojenkin takia, taitaa kuitenkin käyttää assembleria. Nykyisinhän sillekin saa ihan hienoja IDEjä ja käännösympäristöjä.
Sorry, jos tuli vähän C64-painotteinen viesti, mutta se on ympäristö jonka tunnen parhaiten. Tosin speccu ja Z80 kyllä kiinnostelisi.Kasettipelit aika tavallisesti tehtiin niin, että sopii kerralla muistiin. Joitakin sellaisia pelejä oli myös kasetilla jotka oli ns. lineaarisia, että peli eteni lataamalla seuraava taso ja takaisin ei päässyt. Niiden pelaaminen alkoi olla jo masokismia.
Levyasema käytännössä tarvittiin laajempiin peleihin.
Sellainen huomio vaikka tuosta Commodore 64 + levyasema yhdistelmästä, että tämä käytännössä kykeni aivan yhtä laajoihin peleihin kuin sen ajan 16-bittinen Amiga.
Ero tuli sitten grafiikassa ja äänissäkin, kun siihen Amigan disketille meni jotain 880kt ja C64:n lerpun puolelle meni 160kt. Peli suunnittelija tietenkin mietti asian niin, että missä vaiheissa peliä tuli levyn vaihtoa (tai levyn kääntö) että sitä ei tapahdu vähän väliä.
Levykkeen vaihto tapahtui yhtä usein mutta 5,5x suurempi määrä dataa tarkoitti enemmän bittejä pikseliä kohden.
Niin Commodore 64:llä kuin Amigallakin pelejä rajoitti eniten juurikin rajallinen tallennustila mutta pelit itsessään olivat yleensä täysin vastaavia. Suurin ero oli grafiikassa kun Commodore 64 oli suunniteltu mustavalkoisille telkkareille joissa värit olivat vain lisäominaisuus jos oli väritelkkari tai monitorissa. Paletti oli vähän harmahtava ja kuva oli ajateltu tuottaa periaatteessa monochromaattisesti jossa jotain korosteväriä. Kuva alue oli myös pienempi.
Amiga sen sijaan oli toisti värit hyvin ja käytännössä sillä meni vastaava sisältö kuin Commodore 64:llä levykkeille mutta esimerkiksi 8 väriä jokaisessa kuvaelementissä.
Molemmat laitteet sai toistamaan värejä paljon mutta peleissä siitä ei ollut paljoa iloa jos sinne levykkeelle ei sopinut niitä kuvia montaa.
Ketjusta on poistettu 2 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Katso: Ohhoh! Miina Äkkijyrkkä sai käskyn lähteä pois Farmi-kuvauksista -Kommentoi asiaa: "En ole.."
Tämä oli shokkiyllätys. Oliko tässä kyse tosiaan siitä, että Äkkijyrkkä sanoi asioita suoraan vai mistä.... Tsemppiä, Mi1365828- 333555
Poliisiauto Omasp:n edessä parkissa
Poliisiauto oli parkissa monta tuntia Seinäjoen konttorin edessä tänään. Haettiinko joku tai jotain pankista tutkittavak251905Haluan jutella kanssasi Nainen
Olisiko jo aika tavata ja avata tunteemme...On niin paljon asioita joihin molemmat ehkä haluaisimme saada vastaukset...O171903Onko mies niin,
että sinulle ei riitä yksi nainen? Minulle suhde tarkoittaa sitoutumista, tosin eihän se vankila saa olla kummallekaan.241730Voitasko leikkiä jotain tunnisteleikkiä?
Tietäisi ketä täällä käy kaipaamassa.. kerro jotain mikä liittyy sinuun ja häneen eikä muut tiedä. Vastaan itsekin kohta741576Tietysti jokainen ansaitsee
Hän varmasti ansaitsee vain parasta ja sopivinta tietenkin, suon sen onnen hänelle enemmän kuin mielelläni. Aika on nyt161502Haluisin suudella ja huokailla
ja purra kaulaasi ja rakastella sinua. Haluisin puristella rintojasi ja pakaroitasi. Ei sinulla taida olla kuitenkaan ni181378Armi Aavikko Malmin hautausmaa
Haudattiinko Armi arkussa Malmin hautausmaalle vai tuhkattiinko hänet? Kuka tietää asiasta oikein?111376Miksi näin?
Miksi vihervassut haluaa maahan porukkaa jonka pyhä kirja kieltää sopeutumisen vääräuskoisten keskuuteen? Näin kotoutumi241317