Mielenkiintoisia retro-makroja

Olisikohan vaikka siksi, että on kiinnostunut kyseisen aikakauden laitteista, tai haluaa luoda jotain uutta retroalustoille?

Hyvä ilmaisu.

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 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.

Lue lisää

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 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.

Lue lisää

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 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.

Lue lisää

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 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.

Lue lisää

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 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.

Lue lisää

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 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.

Lue lisää

"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 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ä.

Lue lisää

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 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 tieto­turvapuute, jopa NSA varoitti poikkeuksellisesti haavoittuvuudesta
Pahimmillaan haavoittuvuus tarkoittaa, että ohjelmistot voidaan huijata asentamaan haitallista sisältöä kuten vakoilu- tai kiristyshaittaohjelmia.

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 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.

Lue lisää

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 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.

Lue lisää

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 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.

Lue lisää

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 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.

Lue lisää

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ä.

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 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 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!

Lue lisää

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 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!

Lue lisää

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 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.

Lue lisää

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.