Svenska ElektronikForumet

Har skrivit ett par inlägg redan om min idé att göra en utvecklingskassett för "Channel F", för att spara på signaler och komponenter så kom jag nu fram till att det blir enklast med ett enda sram, 512kbit verkar vara svårt att hitta för 5V men jag hittade ett 1Mbit AS6C1008 som ser lovande ut, har låg "data retention voltage" och låg ström för detta t.ex.
http://www.alliancememory.com/pdf/AS6C1 ... 202007.pdf

Då är frågan, hur många av dessa signaler man är tvungen att jonglera med: /CE, CE2, /WE, /OE?
Funkar det att koppla CE2 till Vcc, /OE till jord och sen köra med bara /CE och /WE eller är man illa tvungen att hantera alla för att slippa problem?
Om man vill kunna läsa och skriva till sram:et, behövs det mer än så?

Från minnesinterfacekretsen (3853SMI) har jag bara /RAM-WRITE och /CPU-READ, om man inte har delat upp minnesområdet i smådelar så borde väl ingen extra logic för detta behövas? Vad jag förstår så hanterar bara SMI:n sin del av adress-området, för de $0000-$07FF som ligger i de två hjälpprocessorerna i konsollen så går signalen inte vidare.

Tankar om detta? Är det inte så man brukar göra (om man är lat)? Har för mig att det för vissa kretsar är bättre att hantera /CE än /OE och vice versa för andra men jag har inte hållt på med det här ordentligt, det brukar mest vara mindre moddande här och där.

I en tidigare cartridge med en 6116 så användes /RAM-WRITE direkt på /WE, /CPU-READ direkt på /OE och /CS var en kombination av /RAM-WRITE, /CPU-READ samt signal från en adress-dekoder, i detta fall en 74LS156.
Om man ska dra slutsatser från det fungerande bygget så kanske man borde/(måste?) göra likadant, /CS eller /CE som en kombination av /RAM-WRITE och /CPU-READ - så att den inte är aktiv hela tiden?

http://swechtrading.se/zencart/index.ph ... ts_id=1477

512k x 8 5V

du behöver inte greja med alla signalerna. De har lagt dit dem för att
de hade pinnar lediga på de större kapslingarna och för att minska
extern logik.

Jag hade styrt CE med din adressavkodare och OE och WE från ramwrite och
cpu read

Swech

Om du tittar på Truth Table på sid 2 så får du svar på flera av dina frågor.

För att du ska få ner standbyströmmen så verkar du t.ex. behöva styra den ena av CE-ingångarna (annars drar den Icc istället för Isb).

Under TIMING WAVEFORMS på sid 5 och framåt så ser du lite mer vilka signaler som måste styras i vilken ordning. Det verkar gå att styra skrivning på flera olika sätt t.ex.

Minnesinterfacekretsen, 3853SMI behövs för att kunna använda standardminne överhuvudtaget. Den styrs av fem kontrollsignaler från CPU:n, det kommer att ligga totalt fyra enheter i kedjan när kassetten är i konsollen: CPU, PSU1, PSU2 och denna SMI. Vad jag förstår av databladet så delas minnesareorna automatiskt upp mellan de tre "hjälpprocessorerna". När data begärs från $0000-$03FF kommer PSU1 att lägga ut detta, från $0400-$07FF är det PSU2 som hanterar det - dessa två är konsollens "bios" med sina inbyggda spel. Från $0800 - $FFFF är det min 3853SMI som kommer att svara på en sådan förfrågan. Som det uttrycks i databladet "The device whose address space includes the contents of PC0 must... osv".

Därför undrar jag om det behövs någon extra avkodning eller om man kan göra som jag tänkt att lägga CE2 hög, /OE låg och sedan låta /CPU-READ och /RAM-WRITE styra /CE och /WE direkt... utan extra kombinationer av minnesområden eller signaler. Eller är det bättre om man styr /OE med /CPU-READ och kombinerar /CPU-READ och /RAM-WRITE för /CE istället?


Ah... swechtrading.se, varför hade jag inte sparat den bland mina elektronik-länkar...?
Letar man tillräckligt länge så hittar man det man söker.
Datablads-länken funkar tyvärr inte från sidan men vad jag kan se så är den ännu större - 4Mbit, utan extra switchande har man 3,5Mbit över.


@Nenne
Jo, har läst, det står aldrig exakt de saker man behöver veta, om /OE är låg hela tiden och CE2 hög hela tiden, jag ser inte att det borde vara att problem men jag kanske inte har tittat tillräckligt noga.
Jag har lagt signal från batteristyrningskretsen så att den drar /CE hög när batteriet slår på.

Länk fixad, tack för noteringen

Swech

Ett annat trix/tanke som kan vara bra då man cadar med minnen
är att man på RAM kan byta på de individuella datapinnarna samt
adresspinnarna för att få till enklare layouter.
Dvs. t.ex. A0 från processorn måste inte gå till A0 på chippet
eller D0 till D0.

Man får naturligtvis se till att dokumentera det hela eftersom det blir
lurigt vid felsökning annara.

Det funkar inte om man kör med PROM / EPROM /EEProm där man
externt bränner in en fil som förutsätter korrekt pinmappning.

Swech

CE2 hög, /OE låg och sedan låta /CPU-READ och /RAM-WRITE styra /CE och /WE

Med risk för att ha hoppat i galen tunna ...

Om OE är aktiv (låg) hela tiden kommer Du väl att sänka bussen kontinuerligt så att andra enheter inte kan "tvinga" en datalina hög.

M.v.h DanG

Självklart ska OE bara vara aktiv inom adressområdet som kretsen använder.

Ja, det kanske är lika bra att göra det på rätt sätt.

Jag vet inte om det kommer igenom någon /CPU-READ eller /RAM-WR om adressen i själva verket ligger på $0000-$07FF av tidigare nämnd anledning. Om det är som jag tror så borde det räcka att lägga /CPU-READ på /OE och /RAM-WR på /WE och sedan göra signalen /CE av (/CPU-READ AND /RAM-WR) så att minnet är aktivt på både läs och skriv.

AND-gate av två dioder och en resistor då om man inte ska krångla till det. Finns dubbeldioder med gemensam anod i SOT23-kapel har jag för mig...

Även om /CPU-READ och /RAM-WR slipper igenom så borde inte 3853SMI:n lägga dessa data på bussen om adressområdet är reserverat.
Jag tror jag kör på det, tackar för brainstormingen.


@Swech - jo man är väl illa tvungen med en PIC att blanda omkring saker och ting, man kan ju glömma att det går att lägga adressbuss och databuss intill vartannat.

Så här ser det preliminära schemat ut just nu:

/OE kan självklart ligga stadigt låg utan att störa bussen för övriga enheter.
Det är först när /CE läggs låg som bussen belastas men det är ju då den behövs...
Fast det blir totalt sett inte rätt ändå, fast av annat skäl.
Du måste koppla en inverterare på din /RAM-WRITE och dra den inverterade signalen till /OE annars så blir det fel, detta då både CPU och RAM skulle driva bussen samtidigt annars...

Swech skrev:Ett annat trix/tanke som kan vara bra då man cadar med minnen
är att man på RAM kan byta på de individuella datapinnarna samt
adresspinnarna för att få till enklare layouter.
Dvs. t.ex. A0 från processorn måste inte gå till A0 på chippet
eller D0 till D0.

Man får naturligtvis se till att dokumentera det hela eftersom det blir
lurigt vid felsökning annara.

Det funkar inte om man kör med PROM / EPROM /EEProm där man
externt bränner in en fil som förutsätter korrekt pinmappning.

Swech

Hmm, såvida inte minnet stöder DMA, då kan det bli det stökigt.

För att återgå till TS fråga, du skall använda de pinnar du behöver för att realisera adressrymden, du kan se de extra CE/CS osv som extra adresspinnar, så flera kretsar kan finnas på samma buss.
Däremot så måste du använda läs och skrivpinnarna.

limpan4all skrev:Du måste koppla en inverterare på din /RAM-WRITE och dra den inverterade signalen till /OE annars så blir det fel, detta då både CPU och RAM skulle driva bussen samtidigt annars...

Har kollat runt lite på andra kopplingar med 3853 SMI.

Klart är att /RAM-WRITE går direkt till /WE, så är det överallt jag har hittat.
CPU-READ heter den när den kommer från 3853 SMI så den måste jag ha en inverterare till - blir mer och mer troligt att det dyker upp en quad NAND istället...

För att skapa /CE vill jag ha signal både från /RAM-WRITE och CPU-READ, det ena eller det andra ska aktivera chippet. Vad jag känner till går det inte att läsa och skriva samtidigt även om man skulle vilja så dessa två utesluter varandra, förstår alltså inte varför /RAM-WRITE eller dess invers skulle behöva vara med i /OE - SRAM:et struntar i vad /OE är vid skrivning.
Så en CPU-READ x 2 till två portars NAND så har man /CPU-READ denna sedan tillsammans med /RAM-WRITE genom nästa port så har jag CE, igenom en port till för att invertera och så är där /CE till slut.

/OE direkt till /CPU-READ precis som i tidigare varianter.

CE2 hängs på Vcc, den behöver inte användas.

Borde inte det fungera (till slut)?

Ett par funderingar:
(Ursäkta om det är lite rörigt, jag har skrivit medan jag läst/funderat...)

Vad har du tänkt för värde på R3 och för transistor för Q2? Dessa (i viss mån ihop med R6) påverkar givetvis både batteriströmförbrukningen och hur mycket toppström minneskretsen får dra från batteri. Läs på i minneskretsens datablad hur lång tid det tar från att man släpper CS till att minnet gått ned i standbyström. Jag hade nog kostat på åtminstone nån avkopplingskondensator på minnets matning, direkt vid minnet, och det skulle säkert också lösa det eventuella problemet med återstående 'hög' strömförbrukning precis då strömmen slås av.

Vad fyller R4 för funktion?

En variant kan vara att använda FET-trissor av något slag för att switcha matningarna, då bör du slippa fundera på detta. Då skulle du kanske (eller kanske inte) kunna slippa omkopplingen mellan matning från USB och matning från Fairchildsystemet genom att också låta FET-trissor växla den matningen.

Värt att kolla upp är hur F3853 SMI mår ifall den bara får +5V långvarigt - det är ju vad som kommer hända med ditt nuvarande schema om du matar från USB. Med reservation för hur det blir med logiknivåerna mellan xx245:orna och F3853 (vid USB-matning av minne+PIC & co) SMI så kan det kanske vara läge att låta +5V-anslutningen på SMI'n alltid vara kopplad till Fairchildsystemet. Då är det läge att se till att _SWITCH och/eller DIR på 245:orna inte kan ge drivning från minnet mot SMI'n om inte Fairchildsystemet ger korrekt +5V.

I enklare kretsar med batteribackup så har jag sett helt vanliga dioder används till minnesmatningen, men då har det dels varit rätt låg hastighet (enstaka Hz) och dels så lär väl någon ha tänkt till vad gäller logiknivåerna. Det jag sett använde inte ens schottkydioder med sitt lägre spänningsfall. En fulvariant på att slå av/på minneskretsen är att helt enkelt ansluta CS2 till den icke batteribackup'ade matningen, då kommer den falla och kretsen avaktiveras när strömmen bryts. Det garanterar dock inte att minnet är avaktiverat i mellantillståndet när resten av kretsen håller på att slås av/på, så du måste ändå tänka på det där med att _CS1 eller _WR inte ska kunna gå låga förrän resten av kretsen är "frisk".

Jag ser i schemat att du använder en ICL7673 och den verkar ju i bland annat i princip agera "resetkrets". Det kan kanske vara läge att låta dess utgång via någon grindfunktion istället styra möjligheten att dra _WE låg istället för att styra _CS1 den vägen. Det borde ge lite bättre skydd mot oönskade "slumpskrivningar".

Jag tittade lite i databladet för F3853 SMI (hittade lite PDF'er här, tänker främst på "F3853 Fairchild Semiconductor Momory Interface", pdf-sida 12 har timingdiagram) och vad jag kan se så drivs databussen både före _RAM WRITE går låg och efter _RAM WRITE gått hög, så du lär koppla _OE till CPU READ och låta CS-ingångarna vara konstant aktiva när systemet är igång.

Så länge du inte driver _OE och/eller _WR men har CS aktivt så gör kretsen inget med bussen, varken läser eller skriver, men den drar 'normal' ström (vilket torde vara försumbart när du inte kör på batteri).

Jag förstår att du använder en lös switch för att välja halva av minnet, men det kunde väl kanske vara en idé att ansluta den switchen på vänstra sidan av någon ledig kanal i IC6 och annars driva A16 från ytterligare någon utgång på PIC'en ifall det är möjligt, då kan du ladda båda bankerna via USB utan att slå om switchen men ändå ha en mekanisk switch för att välja halva då cartridgen är ansluten till Fairchildsystemet utan att du har USB anslutet.

Förresten, hur är det med PIC'ens anslutningar vid uppstart? Kan man vara säker på att alla ben du använt garanterat inte i något ögonblick drivs som utgångar under uppstart?

Kalla mig fegis men jag hade nog kostat på ytterligare fyra xx245:or, då kan du vara helt säker på att det är helt omöjligt att trycka in fel kod i PIC'en som skapar motdrivning på bussen eller liknande elände.

Tack för ett långt och genomtänkt svar, precis sådant som uppskattas.

Vad gäller komponenterna kring batteribackup-kretsen ICL7673 så har jag inte funderat så mycket på det än, de komponenter som har värden är tagna från databladet (t.ex. R4 som väl är en strömbegränsning men kanske helt onödig). Jag har för mig att man bara kan dra 30/38mA beroende på matning. Jag var orolig att det inte skulle räcka, därav den externa styrningen med transistorer (direkt från databladet).

Jag är inte så orolig för batteriförbrukningen, då den ska användas till utveckling så behöver den inte hålla minnet i månader men det är såklart en fördel om man slipper byta batteri så ofta.

SMI:n är inte inkopplad till 5V när man matar kretsen med 5V från USB, jag har J1 för att välja matning antingen från konsolen eller USB.

245:orna är egentligen IDTQS3245, liknande funktion och samma "footprint" som*245.
Jag har mest funderat på om /SWITCH-signalen går i rätt läge (isolerar SMI:n) tillräckligt fort man kanske får ordna med en fristående lösning där. Det bästa hade väl varit om de till 100% låg rätt från början med en fördröjning innan man låter den styras av PIC:en. Om man inte har switchar på PIC:en också så måste man ju vara säker på att den har alla I/O på bussen som ingångar eller med hög impedans iaf.

Har också sett enkla batteribackuper med dioder men inte vågat prova själv, man tappar lite spänning där över dioderna - beroende på vad man har för batteri så kan det ha betydelse för hur länge batteriet kan hålla minnet.
Hur mycket spänning tappar man över en shottkydiod förresten?
Två dioder bara skär ju ner antalet komponenter en hel del men jag var orolig att det skulle ställa till problem så jag petade i samma slags batteriövervakning som Richard H. stoppat i sin FlashBoy.

CS2 till fasta spänningen låter som en idé, ICL7673 drar minnet till standby-läge så snart externa spänningen sjunker till/under batterispänningen, det kanske är tillräckligt, den är väl tänkt att lösa just det problemet.

Jumpern för att välja halva av SRAM är bara för att rent teoretiskt kunna använda andra halvan av minnet, det hade kanske varit bättre med resistor till Vcc och jumper för att dra den låg. Tror inte jag kommer att använda funktionen såvida det inte blir något minnesfel. Hittade inga 5V minnen på 512kbit (64kbit x 8, dvs 64kByte totalt), kändes slösaktigt att bara dra adresspinnen hög eller låg.

Jag får väl kolla på uppstart-läget på PIC:en, hur I/O ligger, det är sådana detaljer man kan förkovra sig i, en lösning är som sagt fler switchar, det finns ju plats över på kortet. Om man väljer rätt I/O på rätt ställe kanske man kan få ett start-läge där alla viktiga signaler redan ligger rätt, switch inaktiv, SRAM inaktivt.

Alla PICar defaultar till ingångar och analoga ingångar vid uppstart.
Dock, så som du kopplat måste du tänka på att du gör om alla Adress/Data/Kontrollsignaler på PICen till ingångar innan du låter det externa minnesinterfacet accessa minnet.