Jo jag har en förkärlek för "Channel F" som det kallas, ett tv-spel från slutet på 70-talet.
För att använda vanligt sram eller rom har man en interface-krets som heter 3853 Static Memory Interface som ger tillgång till full adressbuss.
Maximalt kan den adressera 64kB men 2kB är reserverat till inbyggt "bios" ($0000-$07FF). Så minnet från $0800-$FFFF är tillgängligt.
Jag har tidigare byggt en del menystyrda multi-carts med latch och ett större minne (2Mbit) men jag använder en cartridge som har ett socklat eprom för att testa nya ideér. Man tar ur rommet och programmerar om för att testa nya versioner.
Detta är en aning segt, tänkte att det istället skulle varit smidigt med en USB-lösning så man kan testa nytt material smidigare. För ändamålet behövs en µP och sedan hade jag tänkt stoppa i 64kB ram och antingen får man koppla adressbussen, databussen och chip enable samt write signal genom processorn eller via någon slags krets man kan slå av/på.
Idén just nu är alltså att via USB ladda max 64kB data i µP minnet, denna data laddas sedan in i RAM, varefter data- och adressbussen till 3853:an sluts så den kan nå informationen, därefter behöver man resetta spel-konsollen för att programmet ska starta. Vet inte vad man hinner med i tid - det tar som kortast 1,3ms innan konsollen läser minnet på $0800 efter värdet $55.
Vet inte vilken µP jag ska välja, PIC ligger väl närmast till hands, behöver lösa USB-delen på något sätt - jag förmodar att det borde finnas hjälp vad gäller kod där, måste ha varit massor med folk som gjort liknande saker. Att skicka data från PC till µP kräver ett program eller om datan skickas via terminalprogram (så man kan göra ett anpassat program seedan kanske). Det är inte hastigheten när man laddar som är viktigast.
Låter det tokigt eller finns det ett enklare sätt? Jag vill bara kunna testa mina programalster smidigt.
Det finns FTDI:s kretsar som jag vet används i diverse grejor - har väl minst två sådana själv men om man kunde hålla antalet kretsar nere så hade det varit trevligt. Det hade också varit bra om man hade chans att löda för hand så BGA är väl uteslutet t.ex.
Tips för eller emot vissa saker? Finns det någon smidig enable krets som hanterar 26 i/o eller mer, någon som sluter 26 anslutningar med en enda enable signal eller bör man låta µP sköta alla dessa och med programmering skicka datan vidare?
Ladda ram via USB?
Re: Ladda ram via USB?
Kolla upp Dataman S3 eller S4.
Men i grunden är det ganska enkelt att åstadkomma vad du vill ha:
Minne nog, använd statiska RAM.
Ha bufferkretsar på adress och databusserna, t.ex. 74HC573 eller liknande. Koppla dom så att styrningen kan växla kontrollen mellan adress/data bus A eller B, kom ihåg handskakningssignalerna.
Sedan är det bara att ha en µC med USB-I/F och göra ett program till PC som kan styra om data ska överföras eller om det ska köra.
Jag hade gjort en utgång för RESET, då kan man "dra" RESET under tiden det laddas in nytt program och "släppa" den när det är klart och programmet ska köra.
Men i grunden är det ganska enkelt att åstadkomma vad du vill ha:
Minne nog, använd statiska RAM.
Ha bufferkretsar på adress och databusserna, t.ex. 74HC573 eller liknande. Koppla dom så att styrningen kan växla kontrollen mellan adress/data bus A eller B, kom ihåg handskakningssignalerna.
Sedan är det bara att ha en µC med USB-I/F och göra ett program till PC som kan styra om data ska överföras eller om det ska köra.
Jag hade gjort en utgång för RESET, då kan man "dra" RESET under tiden det laddas in nytt program och "släppa" den när det är klart och programmet ska köra.
Re: Ladda ram via USB?
Dataman S3 verkar var en eprom programmerare...? Har två redan, förstår inte riktigt hur den skulle hjälpa till här men du får gärna berätta.
Jag hade förstås kunnat slakta ena eprom programmeraren, byggt in den i cartridge-skalet med ett flash-minne fast monterat... så hade jag haft bara en USB-kontakt men det var inte riktigt så jag tänkt.
Ett alternativ hade varit att ta en annan form av parallellt minne på någon slags USB-koppling - vad det nu finns för något och petat i ett sånt.
Det är väl mest USB-delen jag är osäker på, att programmera t.ex. PIC-kretsen så att den flyttar data från interna minnet till ram, ställa om ut/ingångarna till "High Z" och sedan öppna switchen till minneskretsen - det kan jag nog lösa med de problem som kommer att dyka upp.
Så du tänker en switch som byter mellan µP och SMI:n, jo det kan vara ett alternativ. Den IDTQS3245QG som jag kikade på verkar vara enkel att ha att göra med, antingen är den öppen eller sluten.
http://www.farnell.com/datasheets/1563634.pdf
Hur tänker du med reset? Det finns tyvärr inget reset tillgänglig på cartridgeporten, därför tänker jag att bios får köra sitt race, dvs den kommer till testen om det ligger $55 på $0800 efter 1,3ms eller mer och sedan fortsätter den med det inbyggda programmet om man inte hunnit kopiera till ram och slå på switchen. Annars får man testa att resetta konsollen och se om det startar nästa gång eller den fortfarande kopierar. Men även om man använder alla 64kB (vilket väl inte är så stor risk) så borde det väl inte ta så lång tid att kopiera tycker jag... Men det får man väl se.
Så minne kanske AS7C256A.
http://www.farnell.com/datasheets/32792.pdf
Är det någon som vet om det finns PIC-kretsar med färdig USB-hantering så man i princip bara kan haka på en kontakt eller behöver man hitta sådan mjukvara och lägga med i sitt programprojekt?
Någon som gjort någon USB-mojäng?
Finns PIC18F67J50 som skulle kunna passa.
http://www.microchip.com/wwwproducts/De ... e=en027177
http://ww1.microchip.com/downloads/en/D ... 39775c.pdf
Fast den behöver lägre drivspänning, så då blir det en krets till för det - finns väl inga 5V kretsar för detta ändamål gissar jag.
Minnet behöver minst 2,2V för en etta... undra om man kan lita på att den skickar ut det?
Switchen klarar sig.
Alternativet är väl annars att ha nivåkonverterare på data och adressbussen (samt kontrollsignaler) till SMI:n och sedan hålla alla andra kretsar på lägre spänning.
PIC som kör på 5V verkar finnas med max 32kB vilket kullkastar idén (om man inte också lägger till någon slags flashminne).
18F4455 t.ex. som används i Vectrex flash cartridgen VecFlash.
EDIT:
Fast nu tänker jag kanske fel, "program memory" är kanske inget man kan lägga data i - som man hämtar via USB... så då kanske man är tvungen att ha ett flash-rom ändå.
SRAM med batteri kanske... Eller RAM bara så att man måste ha ström från konsollen för att ladda RAM med data... Kanske FeRAM, har använt det i ett par Pac-Man cartidgear till denna maskin. Funkar bra som ram, håller minnet - men de är lite känsliga om man inte ser till att adressbussen är tyst när man stänger av.
Jag hade förstås kunnat slakta ena eprom programmeraren, byggt in den i cartridge-skalet med ett flash-minne fast monterat... så hade jag haft bara en USB-kontakt men det var inte riktigt så jag tänkt.
Ett alternativ hade varit att ta en annan form av parallellt minne på någon slags USB-koppling - vad det nu finns för något och petat i ett sånt.
Det är väl mest USB-delen jag är osäker på, att programmera t.ex. PIC-kretsen så att den flyttar data från interna minnet till ram, ställa om ut/ingångarna till "High Z" och sedan öppna switchen till minneskretsen - det kan jag nog lösa med de problem som kommer att dyka upp.
Så du tänker en switch som byter mellan µP och SMI:n, jo det kan vara ett alternativ. Den IDTQS3245QG som jag kikade på verkar vara enkel att ha att göra med, antingen är den öppen eller sluten.
http://www.farnell.com/datasheets/1563634.pdf
Hur tänker du med reset? Det finns tyvärr inget reset tillgänglig på cartridgeporten, därför tänker jag att bios får köra sitt race, dvs den kommer till testen om det ligger $55 på $0800 efter 1,3ms eller mer och sedan fortsätter den med det inbyggda programmet om man inte hunnit kopiera till ram och slå på switchen. Annars får man testa att resetta konsollen och se om det startar nästa gång eller den fortfarande kopierar. Men även om man använder alla 64kB (vilket väl inte är så stor risk) så borde det väl inte ta så lång tid att kopiera tycker jag... Men det får man väl se.
Så minne kanske AS7C256A.
http://www.farnell.com/datasheets/32792.pdf
Är det någon som vet om det finns PIC-kretsar med färdig USB-hantering så man i princip bara kan haka på en kontakt eller behöver man hitta sådan mjukvara och lägga med i sitt programprojekt?
Någon som gjort någon USB-mojäng?
Finns PIC18F67J50 som skulle kunna passa.
http://www.microchip.com/wwwproducts/De ... e=en027177
http://ww1.microchip.com/downloads/en/D ... 39775c.pdf
Fast den behöver lägre drivspänning, så då blir det en krets till för det - finns väl inga 5V kretsar för detta ändamål gissar jag.
Minnet behöver minst 2,2V för en etta... undra om man kan lita på att den skickar ut det?
Switchen klarar sig.
Alternativet är väl annars att ha nivåkonverterare på data och adressbussen (samt kontrollsignaler) till SMI:n och sedan hålla alla andra kretsar på lägre spänning.
PIC som kör på 5V verkar finnas med max 32kB vilket kullkastar idén (om man inte också lägger till någon slags flashminne).
18F4455 t.ex. som används i Vectrex flash cartridgen VecFlash.
EDIT:
Fast nu tänker jag kanske fel, "program memory" är kanske inget man kan lägga data i - som man hämtar via USB... så då kanske man är tvungen att ha ett flash-rom ändå.
SRAM med batteri kanske... Eller RAM bara så att man måste ha ström från konsollen för att ladda RAM med data... Kanske FeRAM, har använt det i ett par Pac-Man cartidgear till denna maskin. Funkar bra som ram, håller minnet - men de är lite känsliga om man inte ser till att adressbussen är tyst när man stänger av.
Senast redigerad av e5frog 22 december 2013, 00:27:48, redigerad totalt 1 gång.
Re: Ladda ram via USB?
En Dataman S3 (och S4) är en EPROM-brännare, helt korrekt. Men den fungerar även som en EPROM emulator där man laddar in data i minnet via serieporten.
Men ska du göra en cartridge får du väl ta reda på signalnivåer och spänningar osv, utan dessa data kan det hela ju kvitta.
Men vill du ha en enkel USB-anslutning kan FT240X eller FT230X kanske vara en idé? FT240X ger en kommunikation som är parallell, den kan alltså hjälpa till med att skyffla data illa kvickt mellan USB och minnet.
FT230X använder en serieport på µC'n, det sparar pinnar men går inte lika snabbt.
Sedan finns det en lösning som kanske är intressant: dual port memory. Det är i grunden två minnesbussar men samma minne, två enheter kan alltså skriva/läsa samtidig i samma minneskapsel.
Men ska du göra en cartridge får du väl ta reda på signalnivåer och spänningar osv, utan dessa data kan det hela ju kvitta.
Men vill du ha en enkel USB-anslutning kan FT240X eller FT230X kanske vara en idé? FT240X ger en kommunikation som är parallell, den kan alltså hjälpa till med att skyffla data illa kvickt mellan USB och minnet.
FT230X använder en serieport på µC'n, det sparar pinnar men går inte lika snabbt.
Sedan finns det en lösning som kanske är intressant: dual port memory. Det är i grunden två minnesbussar men samma minne, två enheter kan alltså skriva/läsa samtidig i samma minneskapsel.
Re: Ladda ram via USB?
Vet inte hur USB-delen funkar i de PIC-processorer som har USB möjligheter, håller på att undersöka saken, men om USB sköts av µP så slipper man ha en krets till att läsa på om. Om man har använder ett minne som t.ex. ram med batteri-backup eller ett flash rom +ram alternativt annan for av NVRAM så behöver man väl inte ha någon switch till bussarna. µP kan väl lägga sig på High Z på bussarna om man inte har USB inkopplad - så att den inte stör.
Med dual port memory tillkommer väl nya intressanta frågeställningar men det kunde varit smidigt såklart. Runt 300 spänn verkar en 512kbit gå på...
Jag lutar väl just nu mot PIC med USB möjlighet, FlashROM och RAM alternativt ett FeRAM - som jag testat tidigare i den gamla maskinen utan problem.
Har kikat på den VirtualBoy (inte Vectrex som jag trodde tidigare) cartridge som jag har, den använder 5V vänliga 18F4455, ett 5V flashrom i TSOP kapsel, ett 64kbit ram med batteribackup, och en batterikontrollkrets. Den laddas med ett spel via USB, sätts sedan i konsollen. Precis som jag hade föreställt mig att det skulle funka. Det finns inga switchar eller dylikt, inga nivåkonverterare eller andra extra saker.
Med dual port memory tillkommer väl nya intressanta frågeställningar men det kunde varit smidigt såklart. Runt 300 spänn verkar en 512kbit gå på...
Jag lutar väl just nu mot PIC med USB möjlighet, FlashROM och RAM alternativt ett FeRAM - som jag testat tidigare i den gamla maskinen utan problem.
Har kikat på den VirtualBoy (inte Vectrex som jag trodde tidigare) cartridge som jag har, den använder 5V vänliga 18F4455, ett 5V flashrom i TSOP kapsel, ett 64kbit ram med batteribackup, och en batterikontrollkrets. Den laddas med ett spel via USB, sätts sedan i konsollen. Precis som jag hade föreställt mig att det skulle funka. Det finns inga switchar eller dylikt, inga nivåkonverterare eller andra extra saker.
Re: Ladda ram via USB?
Inte riktigt samma sak som du vill bygga, men kanske värt att ta någon ide ifrån.
Det är en diskettemulator som ersätter en mängd olika diskettformat, jag kör den själv på min gamla Amiga 500.
Den läser från ett SD-kort där diskimages ligger lagrade. Jag tror att det går att hitta Scheman och källkod.
http://hxc2001.free.fr/floppy_drive_emulator/
Det är en diskettemulator som ersätter en mängd olika diskettformat, jag kör den själv på min gamla Amiga 500.
Den läser från ett SD-kort där diskimages ligger lagrade. Jag tror att det går att hitta Scheman och källkod.
http://hxc2001.free.fr/floppy_drive_emulator/
Re: Ladda ram via USB?
Tror att du utan problem skulle kunna köra hela altet i ram:et på STM32F4 discovery t.ex.
Re: Ladda ram via USB?
Den har jag funderat på att köpa, riktigt nära ett par gånger, men då den USB-lösa versionen.Jimjou skrev:...det är en diskettemulator som ersätter en mängd olika diskettformat, jag kör den själv på min gamla Amiga 500.
Den kunde man kanske ha hjälp av, ska kika på det. Tackar.
Jo, det kanske går, hade man haft ett färdigt projekt som man kunde ändra lite i så hade det varit intressant.Micke_s skrev:köra hela altet i ram:et på STM32F4 discovery t.ex.
Den känns ännu mer främmande än PIC-processorer, mycket nytt att lära där kanske, mycket att programmera, anpassningselektronik etc.
Re: Ladda ram via USB?
Anpassningslogiken lär vara konvertera 5V <-> 3.3V grindar.
Programmerar finns redan på STM32F4 discovery.
Titta på CooCoox eller EmBlocks.
Programmerar finns redan på STM32F4 discovery.
Titta på CooCoox eller EmBlocks.
Re: Ladda ram via USB?
Jag har fastnat i programmeringen till PIC:en, använder ett färdigt "paket" för USB-delen och ska peta in min egen kod där någonstans, det var lättare att modifiera användarinterfacet för Windows i Visual Studio 2010 Express så den delen är i princip klar.
http://www.waitingforfriday.com/index.p ... USB_device
http://www.waitingforfriday.com/index.p ... USB_device
Re: Ladda ram via USB?
Har väl gett upp den här metoden även om det hade varit trevligt att få det att fungera.
Planen nu är en USB till seriell modul, µP, ram 64kB, batteribackup då man flyttar från datorn till spelet.
Om det ska vara eprom så: 64kByte flash rom, 64kByte ram. Skulle vilja kunna ställa in uppdelningen av minnet så man kan ha det på den vanliga platsen (2kByte på $2800) eller valbart i 2kB block över hela addressområdet. $800, $1000, $1800, ... upp till $F800 ($0-$7FF är reserverat).
Vet inte riktigt hur jag i så fall ska lösa den biten.
Planen nu är en USB till seriell modul, µP, ram 64kB, batteribackup då man flyttar från datorn till spelet.
Om det ska vara eprom så: 64kByte flash rom, 64kByte ram. Skulle vilja kunna ställa in uppdelningen av minnet så man kan ha det på den vanliga platsen (2kByte på $2800) eller valbart i 2kB block över hela addressområdet. $800, $1000, $1800, ... upp till $F800 ($0-$7FF är reserverat).
Vet inte riktigt hur jag i så fall ska lösa den biten.
Re: Ladda ram via USB?
Jag testade att ta en FT230X (USB <-> UART) och koppla med trådar och fågelbo. Fungerade direkt.
Då är USB-interfacet klart och du kan fokusera på att programmera PIC'en och strunta i USB-delen.
Då är USB-interfacet klart och du kan fokusera på att programmera PIC'en och strunta i USB-delen.
Re: Ladda ram via USB?
Ja, det var väl något sådant jag funderade på, har några olika modeller.
Re: Ladda ram via USB?
En helt annan idé:
Du skulle kunna köra EEPROM (eller flash) som innehåller F8-kod för att programmera sig själv, och kombinera med en I/O-krets som kan prata seriedata, antingen med RS232 eller med en RS232<->USB-adapter som Icecap nämner.
Du får förstås fortfarande samma sega förfarande för den första koden, men när den biten väl är avverkad så bör resten gå lätt? Det kan väl inte krävas så många försök att få en fungerande F8-kod som initierar en UART, läser i statusregister och loopar tillbaks om det inte kommer nån data, och om det kommit data skriver till minnet och inkrementerar minnespekaren och hoppar tillbaka till statusregisterläsningen?
I princip skulle detta räcka om du vid reset också gör en avkänning av knapparna för att välja mellan att köra denna kod eller att göra nån bankswitchning så att nedladdad kod körs?
P.S. captain obvious hälsar att bankswitchningen görs väl enklast med en EOR-grind på en av adressledningarna så att de "gömda" första 2k på eeprom/flash/ram byter plats med annan del av minnet. Med lite klurighet så bör det gå att få koden körbar även om man växlar bank "under fötterna" på koden som körs.
Finns det emulatorer med tillgänglig källkod, så att man kan modda en Channel F-emulator så att den också emulerar ett tänkt hårdvarubygge? I så fall lär ju kodandet bli klart enklare, fast då kan du ju lika gärna koda menygrejen för multispel-cartridge direkt i emulatorn.
Du skulle kunna köra EEPROM (eller flash) som innehåller F8-kod för att programmera sig själv, och kombinera med en I/O-krets som kan prata seriedata, antingen med RS232 eller med en RS232<->USB-adapter som Icecap nämner.
Du får förstås fortfarande samma sega förfarande för den första koden, men när den biten väl är avverkad så bör resten gå lätt? Det kan väl inte krävas så många försök att få en fungerande F8-kod som initierar en UART, läser i statusregister och loopar tillbaks om det inte kommer nån data, och om det kommit data skriver till minnet och inkrementerar minnespekaren och hoppar tillbaka till statusregisterläsningen?
I princip skulle detta räcka om du vid reset också gör en avkänning av knapparna för att välja mellan att köra denna kod eller att göra nån bankswitchning så att nedladdad kod körs?
P.S. captain obvious hälsar att bankswitchningen görs väl enklast med en EOR-grind på en av adressledningarna så att de "gömda" första 2k på eeprom/flash/ram byter plats med annan del av minnet. Med lite klurighet så bör det gå att få koden körbar även om man växlar bank "under fötterna" på koden som körs.
Finns det emulatorer med tillgänglig källkod, så att man kan modda en Channel F-emulator så att den också emulerar ett tänkt hårdvarubygge? I så fall lär ju kodandet bli klart enklare, fast då kan du ju lika gärna koda menygrejen för multispel-cartridge direkt i emulatorn.
