Jag har ett litet projekt att bygga en NSF-spelare (nintendo sound format)
och behöver för att kunna emulera det på ett vettigt sätt rikligt med SRAM (då det enda valet i princip är att ladda upp hela NSF'en i minnet före uppspelning)
Jag har kollat lite på Atmels ARM-serie, där en möjlig lösning vore AT91SAM7S256 med sina 55 MHz och 64 kB SRAM.
Dock så kräver NES-emulationen 8 kB rakt av samt en buffer på kanske 4 kB.
Utöver detta krävs också en hel del andra småvariabler som startadresser m.m. men det blir rätt mycket innan det kommer påverka minnet så mycket.
Då är jag nere på cirka 50 kB för en NSF, en storlek som tråkigt nog några bra spel överpasserar.
Så att få upp en >20 kB minne till vore jvligt trevligt då spelen är omöjliga att dela upp.
Det enda vettiga jag hittar är denna;
http://www.freescale.com/webapp/sps/sit ... 249&srch=1
http://se.farnell.com/jsp/endecaSearch/ ... 8475&N=401
Men jag har aldrig hört talas om Freescale semicondoctors och är lite rädd att jag skall få svårt att hitta bra verktyg och hjälp (även om företaget verkar vara och ha mycket information)
Skall jag köra vidare på MCF5249 eller gå tillbaka till AT91SAM7S256, eller har någon möjligen ett bättre tips?
Är i behov av en kraftig microcontroller, tips tack!
Fujitsu's 16 bitars? Den använder jag och den har förvisso bara 6Kb RAM on-board men kan adressera 16Mb, gratis C-kompiler, 16MHz exekveringscykel, massa av perifergrejor....
Jag använder MB90F583C men det finns ett antal varianter. Programmeringen kräver att man ställer 3 mode pinnar i ett visst läge samt drar 2 pinnar till GND och sedan kör på serieporten via en MAX232 eller liknande. Samma serieport kan sedan användas i programmet för kommunikation osv.
Återställ til körläge: mode pinnerna i ett annat läge, släpp pinnerna från GND och reset. Klart.
Jag använder MB90F583C men det finns ett antal varianter. Programmeringen kräver att man ställer 3 mode pinnar i ett visst läge samt drar 2 pinnar till GND och sedan kör på serieporten via en MAX232 eller liknande. Samma serieport kan sedan användas i programmet för kommunikation osv.
Återställ til körläge: mode pinnerna i ett annat läge, släpp pinnerna från GND och reset. Klart.
> 0.9 MIPS/MHz
Lite udda värde, är väl något slags genomsnitt (?).
I tabellen med instruktionsuppsättningen brukar det framgå
hur många "klockcykler" (eller motsvarande) som varje instruktion kräver.
Sen är det ju även en jäkla skillnad på hur mycket "job" olika
processorer utför *per instruktion*. D.v.s beroende på vad man ska
göra (bithandling, beräkningar, dataskyffling o.s.v) så kan olika
arkitekturer vara bättre eller sämre. Det kanske ska vara en
körna med DSP funktioner ? Eller åtminstående mult/div hårdvara ?
Personligen tror jag att man (d.v.s du
) får matcha olika arkitekturer
mot den typ av behndling som kommer att bli "vanligast" i din
applikation.
Lite udda värde, är väl något slags genomsnitt (?).
I tabellen med instruktionsuppsättningen brukar det framgå
hur många "klockcykler" (eller motsvarande) som varje instruktion kräver.
Sen är det ju även en jäkla skillnad på hur mycket "job" olika
processorer utför *per instruktion*. D.v.s beroende på vad man ska
göra (bithandling, beräkningar, dataskyffling o.s.v) så kan olika
arkitekturer vara bättre eller sämre. Det kanske ska vara en
körna med DSP funktioner ? Eller åtminstående mult/div hårdvara ?
Personligen tror jag att man (d.v.s du
) får matcha olika arkitekturermot den typ av behndling som kommer att bli "vanligast" i din
applikation.
Jag plockade genast fram min bok i grundläggande digital- och datorteknik och läser på lite just nu.
0.9 MIPS/MHz säger alltså att i genomsnitt tar bara varje instruktion lite mer än en klockcykel om jag fattat det rätt?
Lite problem med att kolla vad jag skall göra, då jag nämligen skall emulera en NES-CPU som i princip kan göra vad den vill, även om det rör sig om 10-20 OP-koder som är överlägset vanligast.
NES-APU'n har jag lite bättre koll på dock. Mest räknare och plockande ur listor.
Dess rutiner körs med starkt varierande frekvenser dock med 1.79 MHz som max. CPU'n låg nog på 2.4 MHz om jag inte minns helt fel.
0.9 MIPS/MHz säger alltså att i genomsnitt tar bara varje instruktion lite mer än en klockcykel om jag fattat det rätt?
Lite problem med att kolla vad jag skall göra, då jag nämligen skall emulera en NES-CPU som i princip kan göra vad den vill, även om det rör sig om 10-20 OP-koder som är överlägset vanligast.
NES-APU'n har jag lite bättre koll på dock. Mest räknare och plockande ur listor.
Dess rutiner körs med starkt varierande frekvenser dock med 1.79 MHz som max. CPU'n låg nog på 2.4 MHz om jag inte minns helt fel.
Verkar så.
En instruktion kan ju knappast ta (ca) 1.1 klockcykel, så de måste
ha plockat fram ett "vägt" värde. T.ex att 9 av 10 instruktioner
körs på 1 cykel, den tionde tar två. Eller något sådant...
Ursäkta en lite dum fråga, men varför inte helt enkelt använda de
två "NES-CPU" och "NES-APU" som du beskriver ?
En instruktion kan ju knappast ta (ca) 1.1 klockcykel, så de måste
ha plockat fram ett "vägt" värde. T.ex att 9 av 10 instruktioner
körs på 1 cykel, den tionde tar två. Eller något sådant...
Ursäkta en lite dum fråga, men varför inte helt enkelt använda de
två "NES-CPU" och "NES-APU" som du beskriver ?
Och sen är det faktisk så att Fjutte-processorn har en instruktionscyklus på 62,4ns, alltså 16 "riktiga" MHz (ung. 16MIPS) och efter vad jag vet slår den alla freescale på fingerna pga. den C-förberedde uppbyggnaden.
Men om du har så stort behov av att emulera ett par kretsar börjar det i mina ögon att likna en FPGA.....
Men om du har så stort behov av att emulera ett par kretsar börjar det i mina ögon att likna en FPGA.....
Sodjan;
Att rakt upp och ner exekvera NSF-filerna på en NES-CPU/APU?
Även fast jag är långt ifrån en expert så vågar jag nog säga att det är praktiskt omöjligt även om du mot förmodan fick tag i försäljning av dessa komponenter.
Jag måste ju ha ett överordnande program som tillåter mig att byta NSF-data till nästa spel/låt och avbryta dåvarande emulering. Och om man skulle kunna konstruera det på något sätt ändå så behöver jag förmodligen återskapa halva NES'en för att få allt att funka. (plus att få en hel del bekymmer att lura den att enbart köra NSF'en som annars borde funnits i en kasett)
jag planerar att emulera cpu'n i en "unit" (1/60 sekund), sedan byta till att emulera APU i 1/60 sekund, som då fyller på bufferten.
Samtidigt kör jag en interruptdriven funktion för att sätta 4 pinnar på uC'n till nya värden från denna buffer.
Sist kollar jag ifall något av knapparna är intryckt på spelaren och startar om med CPU'n igen.
1/60 sekund är alltså tiden det skulle tagit i NES'en
CPU'et kommunicerar med APU'et genom en uppsättning register som ändras som oftast var 1/60:e sekund
Icecap:
Jag har fortfarande lite svårt att se vad som skiljer riktiga från vanliga MHz?
uC'n från Freescale som jag tittade på kunde ju köras i 120 MHz med även den ~0.9MIPS/MHz
Borde den inte vara bra mycket snabbare än den från fujistu?
Edit: och FPGA, har läst på lite snabbt nu då jag inte hört ordet förr (mina första hårdvarukurser på högskolenivå kommer först till hösten!)
Men är det verkligen så nödvändigt? Faktum kvarstår att jag behöver en microcontroller, och att börja dela upp i att köra vissa rutiner av emulation och sådant i andra komponenter kommer nog göra det väldans svårt för mig som nybörjare.
Att rakt upp och ner exekvera NSF-filerna på en NES-CPU/APU?
Även fast jag är långt ifrån en expert så vågar jag nog säga att det är praktiskt omöjligt även om du mot förmodan fick tag i försäljning av dessa komponenter.
Jag måste ju ha ett överordnande program som tillåter mig att byta NSF-data till nästa spel/låt och avbryta dåvarande emulering. Och om man skulle kunna konstruera det på något sätt ändå så behöver jag förmodligen återskapa halva NES'en för att få allt att funka. (plus att få en hel del bekymmer att lura den att enbart köra NSF'en som annars borde funnits i en kasett)
jag planerar att emulera cpu'n i en "unit" (1/60 sekund), sedan byta till att emulera APU i 1/60 sekund, som då fyller på bufferten.
Samtidigt kör jag en interruptdriven funktion för att sätta 4 pinnar på uC'n till nya värden från denna buffer.
Sist kollar jag ifall något av knapparna är intryckt på spelaren och startar om med CPU'n igen.
1/60 sekund är alltså tiden det skulle tagit i NES'en
CPU'et kommunicerar med APU'et genom en uppsättning register som ändras som oftast var 1/60:e sekund
Icecap:
Jag har fortfarande lite svårt att se vad som skiljer riktiga från vanliga MHz?
uC'n från Freescale som jag tittade på kunde ju köras i 120 MHz med även den ~0.9MIPS/MHz
Borde den inte vara bra mycket snabbare än den från fujistu?
Edit: och FPGA, har läst på lite snabbt nu då jag inte hört ordet förr (mina första hårdvarukurser på högskolenivå kommer först till hösten!)
Men är det verkligen så nödvändigt? Faktum kvarstår att jag behöver en microcontroller, och att börja dela upp i att köra vissa rutiner av emulation och sådant i andra komponenter kommer nog göra det väldans svårt för mig som nybörjare.
Det som kan göra en processor snabbare än en annan "per MIP" är saker som hur den hanterar minnet. Vissa processorer kan utföra operationer direkt i SRAM medans andra måste kopiera in datan i register först.
Sen har vissa processorer, som Icecap nämner, en instruktionsuppsättning som är anpassad för C, alltså det blir lätt för kompilatorn att göra bra assembler-kod av C-koden.
Sen har vissa processorer, som Icecap nämner, en instruktionsuppsättning som är anpassad för C, alltså det blir lätt för kompilatorn att göra bra assembler-kod av C-koden.
björn;
Vad skulle underlättas med att köras parallellt?
Jag måste läsa på mig lite mer om DSP så jag inte ens vet vad det betyder, men 750 MHz (!) den kan då inte vara gratis!
sedan bearing icecap; Skiljer det verkligen så mycket i C-koden som genereras att 16 MIPS är kan få ut bättre prestanda än de närmare 50 MIPS jag får på atmels ARM-serie?
Vad skulle underlättas med att köras parallellt?
Jag måste läsa på mig lite mer om DSP så jag inte ens vet vad det betyder, men 750 MHz (!) den kan då inte vara gratis!
sedan bearing icecap; Skiljer det verkligen så mycket i C-koden som genereras att 16 MIPS är kan få ut bättre prestanda än de närmare 50 MIPS jag får på atmels ARM-serie?
> Att rakt upp och ner exekvera NSF-filerna på en NES-CPU/APU?
Notera att jag inte vet ett enda smack om vad detta handlar om,
men generellt verkar det enklare att köra original processorerna
än att emulera dom. *OM* de är allmänt tillgängliga, vilket av
din beskrivning inte verkar vara fallet...
Sen är det en annan sak att ett emulerings projekt kan vara
en utmaning i sig, vilket väl har ett egenvärde antar jag...
Men, som sagt, jag har inte en aning om vad "NSF" eller "APU"
är för något, och det spelar inget större roll (för mig).
Jag gjorde bara ett par generella kommentarer om Mhz, MIPS
och "prestanda" i största allmänhet.
Notera att jag inte vet ett enda smack om vad detta handlar om,
men generellt verkar det enklare att köra original processorerna
än att emulera dom. *OM* de är allmänt tillgängliga, vilket av
din beskrivning inte verkar vara fallet...
Sen är det en annan sak att ett emulerings projekt kan vara
en utmaning i sig, vilket väl har ett egenvärde antar jag...
Men, som sagt, jag har inte en aning om vad "NSF" eller "APU"
är för något, och det spelar inget större roll (för mig).
Jag gjorde bara ett par generella kommentarer om Mhz, MIPS
och "prestanda" i största allmänhet.
