Mmm...
En I/O krets... som passar ihop med F8 systemet, låter som om det blir lättast att köra programmeringen separat från tv-spelet. Smidigast hade ju varit att kunna programmera om under körning.
Det finns Channel F emulering i MESS, börjar låta lite skolarbete om man ska hålla på och simulera sitt tänkta bygge. Ännu mer frustrerande sedan om det inte skulle fungera för att man gjort simuleringen fel eller för inexakt.
Enklaste modellen är tänkt så här, PIC processor tar in data via USB->serial adapter, denna data programmeras i RAM, som har batteribackup för att hålla minnet från det att USB-kabeln tas ur till den får ström av konsollen - och om konsollen stängs av.
Liksom tidigare plan får man väl ha möjlighet att isolera RAM från 3853 SMI:n, det är kanske inte så lyckat att den ligger utan spänning och har data på address och data pinnar. Vi har pratat om detta tidigare någonstans, vet inte om det var nödvändigt att isolera alla?
Tror att det skulle vara det snabbaste sättet att få till något.
Jag har seriemodul, jag har PIC (se ovan), jag köpte det där RAM-minnet, 3853 SMI finns, det är väl ett lämpligt kort som behövs och bus switch. Hade ju varit smidigt om man hade kunnat placera PIC kretsen mellan SMI:n och RAM:et och låta den agera bus switch. Men 35 I/O räcker inte till allt om man inte uppgraderar PIC:en.
Med serieanslutning skulle man förstås kunna skicka kommandon via USB att bryta förbindelsen med SMI för att sedan programmera om RAM (nej två-portars eller andra komplicerade lösningar blir det inte) och sedan växla tillbaks - men då det inte går att resetta (annat än om möjligen kortsluta matningspänningen) från kassetten så får man motionera sig bort till konsollen och trycka reset för att starta om.
I Multi-Cartridgen så låter man programmet hoppa till adress $0000 efter latchen är satt, reset känns av genom att trigga latchens reset på ett viss mönster på ROMC-signalerna.
Hade man varit riktigt smidigt kunde man spionerat på ROMC-signalerna, låtit PIC:en ta över och skicka branch -1 eller liknande i en oändlig loop medan RAM programmerades om och sedan låta den lägga in ett JMP$0000 för att boota om och starta det nya programmet. Det hade varit intressant att se om det skulle vara möjligt.
Ladda ram via USB?
Re: Ladda ram via USB?
Jag vet inte alls hur MESS ser ut, men med lite tur är det kanske inte så svårt att modda.
I ett av mina evighetsprojekt, fixa-dona med ett Motorola MEK6802D5 utvärderingskort/enkortdatorbygge, så har jag letat reda på en 6800-emulator som kan emulera två olika dåtida kommersiella datorer. Det verkar rätt lätt att modda den för att emulera ytterligare hårdvara, min plan är att lägga till stöd för att emulera det kort jag har. Fast den emulatorn är inte cykelexakt och den gör en del förenklingar som att t.ex. förutsätta att baudrate på en UART är rätt och den struntar dessutom i handskakningssignalerna. En skrivning till TX-registret ger ett tecken på konsollen i emulatorn, och tangenttryckningar i emulatorn köar upp sig snyggt till RX-regisstret med "oändlig" buffert fast orignal-UART'en bara har någon bytes buffert o.s.v.
28xx-EEPROM är klart enklare att programmera än EPROM. Kretsarna ansluts i princip som ett SRAM och de innehåller själva intelligensen för programmeringsalgoritmer, man skriver en page som om det vore vanligt RAM och så gör man någon viss grej för att få reda på resultatet och få reda på att skrivningen är färdig så att man kan börja med nästa page. Kolla databladet för t.ex. 28256 eller liknande.
Vilka signaler finns i cartridgeporten?
F8-processorn verkar ju ha signaler för att begära/få tillgång till bussen. Kan men cart dra i nån signal som får processorn att sova?
"branch -1" o.s.v. kan ju lika gärna bestå av ett eprom som körs mot SMI'n medan PIC'en pratar med RAM'et. Då kan tv-spelet visa något på skärmen eller liknande medan PIC'en pratar med ram'et.
Men vad hände med tråden med PIC'en & co?
Det känns inte direkt som spjutspetssvårt att få till det här. Ett par databuffertar för att växla mellan SMI och PIC mot SRAM'et, lite komponenter som hejdar minnet från att dränera batteriet och från att skrivas med felaktig data när strömmen slås av/på.
Förutom att använda ROMC för att skicka "branch -1" så skulle de också kunna användas för att välja ögonblick då RAM ska växlas in. Ett litet EPROM skulle kunna innehålla "branch -1" i en liten bank och i en annan bank skulle det kunna ligga en klase "dummyinstruktioner" vars första byte skiljer från "branch -1" men vars andra byte är samma, och därefter JMP$0000. När det är dags att växla in RAM'et så växlar man bank i EPROM'et, beroende på var processorn "är" då så kan det bli så att den bara fortsätter med nästa instruktion som är JMP, eller så håller den just på att läsa "branch -1" och får då läsa "-1" från EPROM'ets andra bank. Hårdvara känner av inläsningen av sista byten i JMP$0000 och växlar då bort EPROM och in med RAM. Som bonus kan EPROM'et också innehålla en radda vanliga spel/program som man redan vet att man vill ha exakt som de är. Det är ju nästan krångligt att få tag på riktigt så EPROM, så det kan ju lika gärna vara en större krets.
EPROM'et kan eventuellt innehålla en tredje bank som innehåller kod som det går att hoppa in i på precis vilken adress som helst, och som i sin tur gör nån slags hopp som gör att man sen kan växla till "branch -1"-banken. Då skulle man i teorin kanske inte behöva reset'a för att kunna växla kod on-the-fly. Fast det är väl å andra sidan inte mycket jobb att faktiskt trycka på reset varje gång man laddat in kod i cart'en? Det kan ju gå att ladda även om PIC'en är ansluten samtidigt som cart'en. (Fast där bör det nog finnas nåt skydd mot farliga jordfel, det är en dålig idé att stoppa i eller ta ur cart'en medan usb-kabeln är ansluten, åtminstone om tv-spelet och/eller usb-kabeln är ansluten till något som är anslutet till något annat (t.ex. elnätet)...
Sorry för lite rörigt inlägg, jag skrev medan jag tänkte
I ett av mina evighetsprojekt, fixa-dona med ett Motorola MEK6802D5 utvärderingskort/enkortdatorbygge, så har jag letat reda på en 6800-emulator som kan emulera två olika dåtida kommersiella datorer. Det verkar rätt lätt att modda den för att emulera ytterligare hårdvara, min plan är att lägga till stöd för att emulera det kort jag har. Fast den emulatorn är inte cykelexakt och den gör en del förenklingar som att t.ex. förutsätta att baudrate på en UART är rätt och den struntar dessutom i handskakningssignalerna. En skrivning till TX-registret ger ett tecken på konsollen i emulatorn, och tangenttryckningar i emulatorn köar upp sig snyggt till RX-regisstret med "oändlig" buffert fast orignal-UART'en bara har någon bytes buffert o.s.v.
28xx-EEPROM är klart enklare att programmera än EPROM. Kretsarna ansluts i princip som ett SRAM och de innehåller själva intelligensen för programmeringsalgoritmer, man skriver en page som om det vore vanligt RAM och så gör man någon viss grej för att få reda på resultatet och få reda på att skrivningen är färdig så att man kan börja med nästa page. Kolla databladet för t.ex. 28256 eller liknande.
Vilka signaler finns i cartridgeporten?
F8-processorn verkar ju ha signaler för att begära/få tillgång till bussen. Kan men cart dra i nån signal som får processorn att sova?
"branch -1" o.s.v. kan ju lika gärna bestå av ett eprom som körs mot SMI'n medan PIC'en pratar med RAM'et. Då kan tv-spelet visa något på skärmen eller liknande medan PIC'en pratar med ram'et.
Men vad hände med tråden med PIC'en & co?
Det känns inte direkt som spjutspetssvårt att få till det här. Ett par databuffertar för att växla mellan SMI och PIC mot SRAM'et, lite komponenter som hejdar minnet från att dränera batteriet och från att skrivas med felaktig data när strömmen slås av/på.
Förutom att använda ROMC för att skicka "branch -1" så skulle de också kunna användas för att välja ögonblick då RAM ska växlas in. Ett litet EPROM skulle kunna innehålla "branch -1" i en liten bank och i en annan bank skulle det kunna ligga en klase "dummyinstruktioner" vars första byte skiljer från "branch -1" men vars andra byte är samma, och därefter JMP$0000. När det är dags att växla in RAM'et så växlar man bank i EPROM'et, beroende på var processorn "är" då så kan det bli så att den bara fortsätter med nästa instruktion som är JMP, eller så håller den just på att läsa "branch -1" och får då läsa "-1" från EPROM'ets andra bank. Hårdvara känner av inläsningen av sista byten i JMP$0000 och växlar då bort EPROM och in med RAM. Som bonus kan EPROM'et också innehålla en radda vanliga spel/program som man redan vet att man vill ha exakt som de är. Det är ju nästan krångligt att få tag på riktigt så EPROM, så det kan ju lika gärna vara en större krets.
EPROM'et kan eventuellt innehålla en tredje bank som innehåller kod som det går att hoppa in i på precis vilken adress som helst, och som i sin tur gör nån slags hopp som gör att man sen kan växla till "branch -1"-banken. Då skulle man i teorin kanske inte behöva reset'a för att kunna växla kod on-the-fly. Fast det är väl å andra sidan inte mycket jobb att faktiskt trycka på reset varje gång man laddat in kod i cart'en? Det kan ju gå att ladda även om PIC'en är ansluten samtidigt som cart'en. (Fast där bör det nog finnas nåt skydd mot farliga jordfel, det är en dålig idé att stoppa i eller ta ur cart'en medan usb-kabeln är ansluten, åtminstone om tv-spelet och/eller usb-kabeln är ansluten till något som är anslutet till något annat (t.ex. elnätet)...
Sorry för lite rörigt inlägg, jag skrev medan jag tänkte
Re: Ladda ram via USB?
e5frog: det ska inte vara något större problem att dels synkronisera in en mindre ROM med dels JMP -1 och dels JMP $0000 och sedan kunde synkronisera tillbaka till "verklig" minne. Det borde klaras med lite logik och ett minimalt PROM i någon form eller rent av bara ett par 74xx245 som är kopplat rätt. Tar man de understa adressbits kan man fint göra en JMP $0000-sekvens hela tiden fram till att enheten "släpps fri"
Under tiden den är satt i JMP $0000 är RAM-kretsen kopplat till en µC som kan skriva osv.
En sak jag undrar: är det för att göra en "jag kan spela vilket av 8 spel jag vill" eller är det för att utveckla och testa saker?
Vill man "bara" ha fler spel/program i en cartridge känns det vettigare med en cartridge med ett flash-minne där man kan sätta de översta adressbits för att välja 1-av-X, evt. med en synkronisering av byte.
Är det för att programmera, debugga och testa är det självklart att det ska vara RAM osv.
Under tiden den är satt i JMP $0000 är RAM-kretsen kopplat till en µC som kan skriva osv.
En sak jag undrar: är det för att göra en "jag kan spela vilket av 8 spel jag vill" eller är det för att utveckla och testa saker?
Vill man "bara" ha fler spel/program i en cartridge känns det vettigare med en cartridge med ett flash-minne där man kan sätta de översta adressbits för att välja 1-av-X, evt. med en synkronisering av byte.
Är det för att programmera, debugga och testa är det självklart att det ska vara RAM osv.
Re: Ladda ram via USB?
Multi-cartridge med meny och alla spel som finns tillgängliga har jag redan gjort runt 90 st redan så det är inte det den ska vara till.
Jag ska ha den för att enkelt kunna testa nya program, höll på med ett mask/Tron-spel och den kassett jag hade socklat eprom på började krångla och lade av helt.
För att inte fastna i hårdvaruprojektet så vill jag försöka göra det så enkelt som möjligt, man blir väl ändå tvungen att göra några tester på vägen. Hade nästan glömt av den andra tråden, hade ju postat en del schema där.
Att använda ett RAM tillåter läsning eller skrivning var som helst utan att behöva stoppa in båda delar och ställa upp en "chip select" tabell för diverse konfigurationer som ska kunna ställas in. Det är väl den här delen med batteri-backup som möjligen krånglar till det. Förr så hade man ett batterpaket med 3,6V och ett par dioder - det var allt. Så man undrar om det inte räcker med detta eller man måste ha batterikontrollkrets. Har iofs för mig att jag tog hem ett par sådana - så varför inte.
Så även om det hade varit enklare att kunna programmera kassetten med denna i konsollen så försöker jag nog sikta på minsta möjliga ansträngning så att jag kan fortsätta med programmeringen av spelet istället.
Jag vill ju kunna göra fler spel och använda samma plattform, kanske blir 62kB för lite någon gång i framtiden men då får man väl bygga något nytt eller utöka.
Hittade en trevlig lång IC, en 32bit switch, verkade smidigare än fyra mindre varianter som jag ritat i det andra schemat. Ska leta reda på den andra tråden och försöka friska upp minnet.
Så planen är denna: SMI, switch, diod på 5V (ingen spänning när den körs från USB), RAM, batterikrets, batteri, µP, USB-seriemodul, usb mini kontakt.
Lagom komplicerat, tror jag kommer att köra fast på µP programmeringen...
Kanske man borde leta reda på en diod med låg Vf - såvida man inte kan dra 5V genom switchen också, har några pinnar kvar där eller så är det kanske bättre att styra 5V med någon transistor via switchen.
Jag ska ha den för att enkelt kunna testa nya program, höll på med ett mask/Tron-spel och den kassett jag hade socklat eprom på började krångla och lade av helt.
För att inte fastna i hårdvaruprojektet så vill jag försöka göra det så enkelt som möjligt, man blir väl ändå tvungen att göra några tester på vägen. Hade nästan glömt av den andra tråden, hade ju postat en del schema där.
Att använda ett RAM tillåter läsning eller skrivning var som helst utan att behöva stoppa in båda delar och ställa upp en "chip select" tabell för diverse konfigurationer som ska kunna ställas in. Det är väl den här delen med batteri-backup som möjligen krånglar till det. Förr så hade man ett batterpaket med 3,6V och ett par dioder - det var allt. Så man undrar om det inte räcker med detta eller man måste ha batterikontrollkrets. Har iofs för mig att jag tog hem ett par sådana - så varför inte.
Så även om det hade varit enklare att kunna programmera kassetten med denna i konsollen så försöker jag nog sikta på minsta möjliga ansträngning så att jag kan fortsätta med programmeringen av spelet istället.
Jag vill ju kunna göra fler spel och använda samma plattform, kanske blir 62kB för lite någon gång i framtiden men då får man väl bygga något nytt eller utöka.
Hittade en trevlig lång IC, en 32bit switch, verkade smidigare än fyra mindre varianter som jag ritat i det andra schemat. Ska leta reda på den andra tråden och försöka friska upp minnet.
Så planen är denna: SMI, switch, diod på 5V (ingen spänning när den körs från USB), RAM, batterikrets, batteri, µP, USB-seriemodul, usb mini kontakt.
Lagom komplicerat, tror jag kommer att köra fast på µP programmeringen...
Kanske man borde leta reda på en diod med låg Vf - såvida man inte kan dra 5V genom switchen också, har några pinnar kvar där eller så är det kanske bättre att styra 5V med någon transistor via switchen.
Re: Ladda ram via USB?
Hoppas du med "switch" menar någon slags buffert. SMI'n måste ju kopplas bort från minnet när mikrokontrollern accessar RAM'et.
Men du, har du kollat på att köpa en färdig epromemulator, eller bygga en universalvariant? Det finns att köpa både proffs- och semiproffsmodeller och det finns även en del byggbeskrivningar. Då kan du använda den även på andra ställen som använder eprom.
Batterikontrollkretsens syfte är väl att få signaler som garanterat ser till att det inte sker skrivningar till RAM under strömpåslag/avslag då tillståndet hos diverse signaler kan vara osäkert.
Men du, har du kollat på att köpa en färdig epromemulator, eller bygga en universalvariant? Det finns att köpa både proffs- och semiproffsmodeller och det finns även en del byggbeskrivningar. Då kan du använda den även på andra ställen som använder eprom.
Batterikontrollkretsens syfte är väl att få signaler som garanterat ser till att det inte sker skrivningar till RAM under strömpåslag/avslag då tillståndet hos diverse signaler kan vara osäkert.
Re: Ladda ram via USB?
En DS1218 styr -CE till en RAM och övervakar spänningsmatningen samtidig så den är gjort just för att se till arr RAM är skyddad under brown-out och power-down förhållande.
Re: Ladda ram via USB?
*34X245*, denna bus switch t.ex.
http://www.ebay.com/itm/171394347156
DS1218 verkar vettig, hade en LTC2917 och även en ICL7673 för batteriet i gamla schemat.
Köpa färdig? Nää... det är väl inget kul.
http://www.ebay.com/itm/171394347156
DS1218 verkar vettig, hade en LTC2917 och även en ICL7673 för batteriet i gamla schemat.
Köpa färdig? Nää... det är väl inget kul.
