Jag håller nu på med att jobba vidare på mina Minimig-ideer och har lite av beslutsångest. Jag vet inte riktigt vad jag skall prioritera och vad som kan tänkas efterfrågas mest. I grunden har jag tre ideer:
1. Gå vidare med ursprungsmodellen (XC3S400, Mini-ITX, fixa till ISP till PIC samt förenkla spänningsdelen).
2. Ta originaldesignen och krympa ner den till max så den kan göras bärbar (XC3S400, 1M x 16 SDRAM, headers i stället för kontaktdon, 4-lagerskort).
3. Trimmad modell med större FPGA (XC3S500E, Mini-ITX, fungerande ICP, riktiga portar).
Personligen är alternativ 2 mest lockande, måste bara hitta en passande skärm inom intervallet 3.5 - 6.5". Det blir dessutom lite utmaning att fixa till kontrollerna.
Prioritera Minimig-design - vad är mest önskvärt egentlig
Om den ska bli portabel så tänk på att kontakterna kanske bör vara IDC 2.54mm åt sidorna. XC3S500E är nog ett bättre val än XC3S400 pga att ingen i/o på minimig använder något annat än 3.3v single ended lvttl vad jag vet, och E modellen har mer logikutrymme.
Portabel skärm är enkelt.. bygg om en dvd-spelare
Byt gärna sdram'et mot ett rejält sdram
Switchat nätagg för att fixa dom olika spänningarna bör nog tas i beaktning vid batteridrift.
+1.2 spänning för kärnan
+2.5 extern i/o
+3.3 övrig standard i/o
+5.0 ev för tft skärm (kanske +12 för inverter?)
Kolla på hur spartan-3e sample pack har designat sin nätdel.
Portabel skärm är enkelt.. bygg om en dvd-spelare
Byt gärna sdram'et mot ett rejält sdram
Switchat nätagg för att fixa dom olika spänningarna bör nog tas i beaktning vid batteridrift.
+1.2 spänning för kärnan
+2.5 extern i/o
+3.3 övrig standard i/o
+5.0 ev för tft skärm (kanske +12 för inverter?)
Kolla på hur spartan-3e sample pack har designat sin nätdel.
Angående skärmen så kan du ju ta en titt på den skärm som PSP använder.
Länk!
Finns även touch screen att köpa till på Sparkfun. De säljer även det kontaktdon som behövs. Självklart säljer de även hela displayen där, men den är $39 dyrare där
Upplösningen är 480x272, tyvärr inte så imponerande högt. Men borde vara fullt dugligt.
Länk!
Finns även touch screen att köpa till på Sparkfun. De säljer även det kontaktdon som behövs. Självklart säljer de även hela displayen där, men den är $39 dyrare där
Upplösningen är 480x272, tyvärr inte så imponerande högt. Men borde vara fullt dugligt.
-
Illuwatar
- Inlägg: 2256
- Blev medlem: 10 november 2003, 14:44:27
- Skype: illuwatar70
- Ort: Haninge
- Kontakt:
Verkar inte vara någon vidare kvalitet på dessa PSP-skärmar med tanke på kommentarerna...
Dessutom är PSP widescreen, vilket Amigan inte är. Det enklaste är en 4:3-display som kan ta analog RGB alternativt S-video (C-video ger så dassig bild) i PAL (50 Hz). Då behöver man inte göra något med FPGA-koden. Jag har en 6.4" videodisplay som bara tar 60 Hz, så där sitter jag fast för tillfället - 50 Hz ger bara skräp på skärmen och de moddar som har föreslagits på http://www.opencircuits.com/Minimig_NTSC verkar inte fungera (kräver troligtvis mer kodändringar).
Gällandes FPGA'n så borde det inte vara några problem att ta 500E - jag har redan lyckats kompilera om koden för denna. Tyvärr så ger denna inte mer IO (många portar är input only) jämfört med originalet, vilket gör det lite svårt att dra ut extra adressledningar för mer än 4MB RAM (med A1 - A19 + RAM_SEL0 får man ut 1M x 16, använder man RAM_SEL1 skulle man kunna få ut 2M x 16 vilket ger 4MB, fast då behövs två minneskretsar igen och utrymmesbesparingen försvann). Det är faktiskt så att XC3S400 har tre överblivna IO (USER1 - USER3) som skulle kunna göras om till adressledningar, fast då förlorar man det större logikutrymmet i XC3S500E. Surt att man måste gå till BGA för att bli av med dessa IO-begränsningar...
Edit: Kunde frigöra en IO till - så det är möjligt att få ut 8 MB RAM adressutrymme (A1 - A22). Jag kommer lägga upp ett preliminärt schema så den som är FPGA-guru kan börja modda koden för 8 MB RAM. Rent fysiskt får det bli 1M x 16 x 4 med extern adressavkodning (pinnarna på FPGAn är slut) för att få detta att fungera. Så FPGAn kan se minnet som ett på 4M x 16. Detta kort lär då inte bli den portabla versionen direkt...
Edit 2: Här är ett schema som visar FPGA/CPU/RAM till den tänkta 8 MB versionen med 500E FPGA:
http://www.illuwatar.se/project_pages/m ... ig500E.pdf
Notera att schemat är inte komplett - det är bara tänkt att visa core-delen så ni kan se eventuella tankefel med den nya FPGAn.
Dessutom är PSP widescreen, vilket Amigan inte är. Det enklaste är en 4:3-display som kan ta analog RGB alternativt S-video (C-video ger så dassig bild) i PAL (50 Hz). Då behöver man inte göra något med FPGA-koden. Jag har en 6.4" videodisplay som bara tar 60 Hz, så där sitter jag fast för tillfället - 50 Hz ger bara skräp på skärmen och de moddar som har föreslagits på http://www.opencircuits.com/Minimig_NTSC verkar inte fungera (kräver troligtvis mer kodändringar).
Gällandes FPGA'n så borde det inte vara några problem att ta 500E - jag har redan lyckats kompilera om koden för denna. Tyvärr så ger denna inte mer IO (många portar är input only) jämfört med originalet, vilket gör det lite svårt att dra ut extra adressledningar för mer än 4MB RAM (med A1 - A19 + RAM_SEL0 får man ut 1M x 16, använder man RAM_SEL1 skulle man kunna få ut 2M x 16 vilket ger 4MB, fast då behövs två minneskretsar igen och utrymmesbesparingen försvann). Det är faktiskt så att XC3S400 har tre överblivna IO (USER1 - USER3) som skulle kunna göras om till adressledningar, fast då förlorar man det större logikutrymmet i XC3S500E. Surt att man måste gå till BGA för att bli av med dessa IO-begränsningar...
Edit: Kunde frigöra en IO till - så det är möjligt att få ut 8 MB RAM adressutrymme (A1 - A22). Jag kommer lägga upp ett preliminärt schema så den som är FPGA-guru kan börja modda koden för 8 MB RAM. Rent fysiskt får det bli 1M x 16 x 4 med extern adressavkodning (pinnarna på FPGAn är slut) för att få detta att fungera. Så FPGAn kan se minnet som ett på 4M x 16. Detta kort lär då inte bli den portabla versionen direkt...
Edit 2: Här är ett schema som visar FPGA/CPU/RAM till den tänkta 8 MB versionen med 500E FPGA:
http://www.illuwatar.se/project_pages/m ... ig500E.pdf
Notera att schemat är inte komplett - det är bara tänkt att visa core-delen så ni kan se eventuella tankefel med den nya FPGAn.
Byt ut sram chippet mot ett sdram så får du mer I/O och mer ram minne. Detta då man laddar RAS/CAS seperat och således får dubblerat antal adresspinnar.
Och flytta sådant som t.ex. joysticks som mest är "input only" till IP pinnarna.
Som sista åtgärd kan man multiplexa saker med latchar och n-av-m multiplexers.
Och flytta sådant som t.ex. joysticks som mest är "input only" till IP pinnarna.
Som sista åtgärd kan man multiplexa saker med latchar och n-av-m multiplexers.
-
Illuwatar
- Inlägg: 2256
- Blev medlem: 10 november 2003, 14:44:27
- Skype: illuwatar70
- Ort: Haninge
- Kontakt:
Om någon (blueint kanske?) kan få ihop FPGA-koden för en DRAM-kontroller så kan jag fixa hårdvaran så denna typ av minne går att använda. När det gäller IP-pinnarna så är de spridda lite över hela FPGAn, så det blir en ganska ful layout. Joystickportarna är dock inte så känsliga och kör man 4-lagers så borde man kunna få detta någorlunda snyggt.
Sedan är ju frågan HUR mycket RAM behövs det i en Amiga 500? Själva CPUn har trots allt inte så stort adressområde (16 MB, och dessa delas med I/O och customchip).
Oberoende av mängden minne så måste vi få till 60 Hz VGA någon gång...
Sedan är ju frågan HUR mycket RAM behövs det i en Amiga 500? Själva CPUn har trots allt inte så stort adressområde (16 MB, och dessa delas med I/O och customchip).
Oberoende av mängden minne så måste vi få till 60 Hz VGA någon gång...
Tobiflex SDRAM kontroller:
http://www.amiga.org/modules/newbb/view ... &start=540
Opencores SDRAM kontroller:
http://www.opencores.org/browse.cgi/fil ... ory_memory
http://www.opencores.org/projects.cgi/web/ddr_sdr
Fördelar:
* Ett chip löser alltihop
* Mer I/O över
* Minne för "framerate converter" etc..
* Kan köra stora applikationsprogram, el använda som ramdisk.
60 Hz måste antagligen baseras på 30 Hz NTSC, iaf för spel. I workbench kan man säkert rakt av bara definiera skärmen.
SDRAM pinnarna:
nCS
nRAS 1
nCAS 1
nWE 1
nBA0
nBA1
A10 1
A[9:0] 8 (depend on memsize)
CLK 0
CKE
DQM 0
DQ[7:0] 8
Storage_bits = Data_width * 2^(2*Address_width)
(siffrorna är från ett experiment om hur hårt man kan banta interfacet)
http://www.amiga.org/modules/newbb/view ... &start=540
Opencores SDRAM kontroller:
http://www.opencores.org/browse.cgi/fil ... ory_memory
http://www.opencores.org/projects.cgi/web/ddr_sdr
Fördelar:
* Ett chip löser alltihop
* Mer I/O över
* Minne för "framerate converter" etc..
* Kan köra stora applikationsprogram, el använda som ramdisk.
60 Hz måste antagligen baseras på 30 Hz NTSC, iaf för spel. I workbench kan man säkert rakt av bara definiera skärmen.
SDRAM pinnarna:
nCS
nRAS 1
nCAS 1
nWE 1
nBA0
nBA1
A10 1
A[9:0] 8 (depend on memsize)
CLK 0
CKE
DQM 0
DQ[7:0] 8
Storage_bits = Data_width * 2^(2*Address_width)
(siffrorna är från ett experiment om hur hårt man kan banta interfacet)
Jag har funderat på att göra en egen design på ett moderkort till minimig.
Men jag inser att jag inte kommer ha tid till det.
Min tanke är minimig-PCI allt på ett pci kort, vga kontakt, 2 st joystic kontakter, audio. Då kan man ha allt i PCn.
kanske ett PCI kort brevid som är anslutet via bandkabel till minimigen, där det sitter kortläsarplats och RS-232
Man borde kunna ta spänningarna från PCI kontakten.
Samt att man slipper fixet med låda.
Så jag röstar på min ide!
vad tycker ni??
Men jag inser att jag inte kommer ha tid till det.
Min tanke är minimig-PCI allt på ett pci kort, vga kontakt, 2 st joystic kontakter, audio. Då kan man ha allt i PCn.
kanske ett PCI kort brevid som är anslutet via bandkabel till minimigen, där det sitter kortläsarplats och RS-232
Man borde kunna ta spänningarna från PCI kontakten.
Samt att man slipper fixet med låda.
Så jag röstar på min ide!
vad tycker ni??-
Illuwatar
- Inlägg: 2256
- Blev medlem: 10 november 2003, 14:44:27
- Skype: illuwatar70
- Ort: Haninge
- Kontakt:
För mig skulle 60 Hz video räcka - det är det som är för tillfället mitt primära hinder för en bärbar Minimig "on a budget". Fast hittar man en liten TFT som accepterar 50 Hz analog 15 kHz RGB alternativt S-video och som inte kostar skjortan så är det problemet ur världen.
PCI-grejen är inte riktigt vad jag är intresserad av. Minimig'arna jag gör skall kunna användas stand-alone, utan att behöva blanda in en åbäkig PC i det hela. Det enda som skulle motivera en sådan lösning vore om man kunde köra video-ut som overlay i Windows (ungefär som ett TV-kort) samt kunna mappa in PC'ns kontroller till att styra Minimig-kortet. Fast då låter WinUAE som ett enklare alternativ...
När det gäller minnet så är det fullt möjlig att få 8 MByte på ett chip (har kollat lite på Digikey och de har SDRAM på 4M x 16, PC133). Mer än 8 MB är nog overkill för en OCS gaming-Amiga. Frågan bara hur man slår ihop Dennis SRAM-logik med en SDRAM-kontroller. Mina Verlog-kunskaper är i stort sett obefintliga för att kunna avgöra detta. Jag har i alla fall uppdaterat schemat så att alla joystick-signaler går till input-only-pinnar. Det gav mig 7 lediga riktiga IO.
Om jag ändå är inne på FPGA: det finns tre pinnar (M0, M1, M2) som skall dras höga vid uppstart för att konfigureringen skall fungera. På XC3S400 var dessa dedikerade anslutningar. På XC3S500E delas dessa av IO-portar. M2 delas med GCLK1, vilket inte var så stor sak - MCLK får gå in på GCLK0 i stället. Däremot M0 och M1 används till minnet. Frågan är om det räcker att lägga pull-up's på dessa två pinnar för att de skall vara höga under uppstarten? Samma gäller HSWAP, som skall vara låg vid start - pull-down?
Till sist (för denna gång): I samband med 60 Hz-grejen så läste jag om ett förslag att använda en standardfrekvens på MCLK och därefter generera den interna 28.37516 MHz PAL-klockan med hjälp av FPGA'ns klockgenerator. Både 20 MHz och 50 MHz angavs som förslag. Skulle man kunna få ut denna 28.37516 MHz från en 20 MHz kristalloscillator är ett problem ur världen när det gäller utrymmesbesparing. Det gäller bara att hitta lämpliga värden på CLKFX_DIVIDE och CLKFX_MULTIPLY. Dessutom borde denna oscillator även kunna driva PICen på samma gång...
PCI-grejen är inte riktigt vad jag är intresserad av. Minimig'arna jag gör skall kunna användas stand-alone, utan att behöva blanda in en åbäkig PC i det hela. Det enda som skulle motivera en sådan lösning vore om man kunde köra video-ut som overlay i Windows (ungefär som ett TV-kort) samt kunna mappa in PC'ns kontroller till att styra Minimig-kortet. Fast då låter WinUAE som ett enklare alternativ...
När det gäller minnet så är det fullt möjlig att få 8 MByte på ett chip (har kollat lite på Digikey och de har SDRAM på 4M x 16, PC133). Mer än 8 MB är nog overkill för en OCS gaming-Amiga. Frågan bara hur man slår ihop Dennis SRAM-logik med en SDRAM-kontroller. Mina Verlog-kunskaper är i stort sett obefintliga för att kunna avgöra detta. Jag har i alla fall uppdaterat schemat så att alla joystick-signaler går till input-only-pinnar. Det gav mig 7 lediga riktiga IO.
Om jag ändå är inne på FPGA: det finns tre pinnar (M0, M1, M2) som skall dras höga vid uppstart för att konfigureringen skall fungera. På XC3S400 var dessa dedikerade anslutningar. På XC3S500E delas dessa av IO-portar. M2 delas med GCLK1, vilket inte var så stor sak - MCLK får gå in på GCLK0 i stället. Däremot M0 och M1 används till minnet. Frågan är om det räcker att lägga pull-up's på dessa två pinnar för att de skall vara höga under uppstarten? Samma gäller HSWAP, som skall vara låg vid start - pull-down?
Till sist (för denna gång): I samband med 60 Hz-grejen så läste jag om ett förslag att använda en standardfrekvens på MCLK och därefter generera den interna 28.37516 MHz PAL-klockan med hjälp av FPGA'ns klockgenerator. Både 20 MHz och 50 MHz angavs som förslag. Skulle man kunna få ut denna 28.37516 MHz från en 20 MHz kristalloscillator är ett problem ur världen när det gäller utrymmesbesparing. Det gäller bara att hitta lämpliga värden på CLKFX_DIVIDE och CLKFX_MULTIPLY. Dessutom borde denna oscillator även kunna driva PICen på samma gång...
Vad slags interface till TFT matrisen har du ..? Har inte sett någon TFT matris som begränsar vertikal synken till minst 60 Hz. Däremot TFT kontroller..
En annan möjlighet. Jag har för mig DVI/HDMI ingångarna stödjer 50 Hz, och genom att sätta 4 utgångar i LVDS25 läge kan du skicka dessa signaler direkt från fpgan. Och dessutom spara I/O på samma gång.
PCI = Massa extra utvecklingsjobb dessvärre.
Om man ändå använder SDRAM kan man lika gärna bre på
Glöm inte klockfeedback från SDRAMet. Dvs CLK_FB ska dras till CLK pinnen på SDRAM chippet.
Har för mig att M0,M1,M2 måste ha pull motstånd till det mode som du skall använda. Efter konfiguration kan du förmodligen driva dom rakt av. HSWAP får FPGAn att driva utgångarna höga vid spänningspåslag. Så dess läge beror i princip på om någon i/o får fnatt ifall den inte blir driven. Möjligtvis skulle flashminnet kunna spökskriva, I övrigt är det bara fråga om något perferi-chip misstycker att få sin utgång driven hög.
Skulle föreslå att driva MCU chippet med en PAL klocka eller multipel därav. Därför att PIC chippet är relativt okänsligt för klockvariation. Medans PAL signalering som går fel förmodligen är rätt störande. Så kan man driva både fpga & mcu utan färgsynk problem.
Klocksyntesen är inte perfekt, ha det i minne.
Ta en titt dessa punkter innan du gör kortet också:
http://www.opencircuits.com/Minimig_Board_v1.0_issues
En annan möjlighet. Jag har för mig DVI/HDMI ingångarna stödjer 50 Hz, och genom att sätta 4 utgångar i LVDS25 läge kan du skicka dessa signaler direkt från fpgan. Och dessutom spara I/O på samma gång.
PCI = Massa extra utvecklingsjobb dessvärre.
Om man ändå använder SDRAM kan man lika gärna bre på
Glöm inte klockfeedback från SDRAMet. Dvs CLK_FB ska dras till CLK pinnen på SDRAM chippet.
Har för mig att M0,M1,M2 måste ha pull motstånd till det mode som du skall använda. Efter konfiguration kan du förmodligen driva dom rakt av. HSWAP får FPGAn att driva utgångarna höga vid spänningspåslag. Så dess läge beror i princip på om någon i/o får fnatt ifall den inte blir driven. Möjligtvis skulle flashminnet kunna spökskriva
, I övrigt är det bara fråga om något perferi-chip misstycker att få sin utgång driven hög.Skulle föreslå att driva MCU chippet med en PAL klocka eller multipel därav. Därför att PIC chippet är relativt okänsligt för klockvariation. Medans PAL signalering som går fel förmodligen är rätt störande. Så kan man driva både fpga & mcu utan färgsynk problem.
Klocksyntesen är inte perfekt, ha det i minne.
Ta en titt dessa punkter innan du gör kortet också:
http://www.opencircuits.com/Minimig_Board_v1.0_issues
-
Illuwatar
- Inlägg: 2256
- Blev medlem: 10 november 2003, 14:44:27
- Skype: illuwatar70
- Ort: Haninge
- Kontakt:
Displayen är denna:
Skapligt lång länk
Den har en integrerad videocontroller som körs direkt på analog 15 kHz RGB alternativt kompositvideo. Nackdelen är just 60 Hz (gjord för USA antagligen). Fördelen är priset...
Jag skall kolla igenom listan du hänvisar till. Vissa saker ser bekanta ut och som jag själv haft i åtanke...
Edit - Lite åsikter om listan:
* Power: Denna skall jag titta på. För Mini-itx gäller det att få ner kostnaderna, i den bärbara gäller effektivitet samt att en laddare måste till.
* SPI_DOUT: Denna bugg var fixad redan i min första prototyp (samt även i Dennis Minimig V1.1).
* MMC/SD: Har inte haft problem med den ursprungliga designen så detta har inte någon prioritet.
* Ljudet: Där skall en kombinerad line-driver/headphone amp läggas till. Med DC-styrd volymkontroll.
* SRAM: 1M x 16 hade jag i åtanke innan jag läste listan. Det lär nog bli ett sådant i den bärbara (den skall bara kunna köra spel så 2 MB räcker, samt SRAM drar mindre ström). SDRAM kan bli aktuellt för Mini-ITX (om jag får lite hjälp på traven).
* Kristall: Även detta är i åtanke, speciellt för en bärbar. 4060'n med tillbehör tar för mycket plats.
* Barnsäkra designen: ESD-skydd är i åtanke, framförallt för joystickportarna. Jag litar inte fullt ut på FPGAns inbyggda skydd.
* Resten verkar vara mest olika åsikter om detaljer som inte har någon betydelse för en nydesign. Jag har trots allt friheten att välja kondensatorer själv...
Skapligt lång länk
Den har en integrerad videocontroller som körs direkt på analog 15 kHz RGB alternativt kompositvideo. Nackdelen är just 60 Hz (gjord för USA antagligen). Fördelen är priset...
Jag skall kolla igenom listan du hänvisar till. Vissa saker ser bekanta ut och som jag själv haft i åtanke...
Edit - Lite åsikter om listan:
* Power: Denna skall jag titta på. För Mini-itx gäller det att få ner kostnaderna, i den bärbara gäller effektivitet samt att en laddare måste till.
* SPI_DOUT: Denna bugg var fixad redan i min första prototyp (samt även i Dennis Minimig V1.1).
* MMC/SD: Har inte haft problem med den ursprungliga designen så detta har inte någon prioritet.
* Ljudet: Där skall en kombinerad line-driver/headphone amp läggas till. Med DC-styrd volymkontroll.
* SRAM: 1M x 16 hade jag i åtanke innan jag läste listan. Det lär nog bli ett sådant i den bärbara (den skall bara kunna köra spel så 2 MB räcker, samt SRAM drar mindre ström). SDRAM kan bli aktuellt för Mini-ITX (om jag får lite hjälp på traven).
* Kristall: Även detta är i åtanke, speciellt för en bärbar. 4060'n med tillbehör tar för mycket plats.
* Barnsäkra designen: ESD-skydd är i åtanke, framförallt för joystickportarna. Jag litar inte fullt ut på FPGAns inbyggda skydd.
* Resten verkar vara mest olika åsikter om detaljer som inte har någon betydelse för en nydesign. Jag har trots allt friheten att välja kondensatorer själv...
