Atmel AVR op geheugen adres Motorola 68000

Ik ben al dagen aan het denken hoe ik het voor elkaar moet krijgen om een AVR op een geheugen adres te krijgen van een Motorola 68000, zonder gebruik van CPLD of FPGA. Ik weet dat dit de beste en meest flexibele oplossing zal zijn maar ik probeer een alternatief te vinden. Niemand uit de groep waar ik mee samen werk heeft echt ervaring hiermee.

Snelheid is het belangrijkste uitgangspunt en hierdoor is een RS-232 verbinding te langzaam. SPI zou kunnen al gebruik ik die op de AVR al voor een enc28j60. Dat is meteen het doel van de AVR, Hierop draait de ethernet verbinding met mijn eigen TCP/IP stack. En de AVR ontvangt en verzend kleine data pakketjes maar wel heel snel achter elkaar.

Het doel is dat de 68k naar een byte of word schrijft naar een geheugen adres en dat deze binnen alle timing van beide CPU's kan worden uitgelezen zonder dat met name de 68k moet wachten. Ik heb gedacht aan dual-port geheugen maar dit is een erg kostbare oplossing.

Ik hoop dat iemand mij in de juiste richting kan wijzen want ik kom er niet echt uit :D

bprosman

Golden Member

"Vroeger" in de tijd van de Acorn, BBC, z80, 6800 etc. tijd gebruikten we daar een 6821, 6522 oid voor.

De jongere generatie loopt veel te vaak zijn PIC achterna.
Arco

Special Member

Een controller met een parallel port is daar goed voor (veel pic's en 805x hebben dat, zelfs de oeroude 8042 heeft 't). Ik weet niet of de AVR dat ook heeft?
Je kunt een andere controller overwegen, of anders inderdaad iets als dual ported ram.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Via de 6821 kwam ik met wat zoekwerk op de 68230 uit. Dit is precies wat ik zoek op het gebied van specs, maar de chip is erg groot en de enige webshop die hem heeft kost ie 25-30 dollar. Dat kost dual-port RAM ook en dan zou dat denk ik een betere optie zijn.

We hebben nu gekozen om de Atmega2560 te gebruiken vanwege de vele I/O poorten die deze standaard heeft, en ik hoop te kunnen vermijden dat we een andere controller moeten gaan gebruiken. Met PIC's heb ik vroeger wel wat gedaan en heb er nog wel een hele bak vol mee liggen, maar ben er geen fan van. En ik weet dat de de grotere PIC's het vaak hebben en daarom hoopte ik dat de AVR het ook zou hebben.

mel

Golden Member

u=ir betekent niet :U bent ingenieur..
Arco

Special Member

Met PIC's heb ik vroeger wel wat gedaan en heb er nog wel een hele bak vol mee liggen, maar ben er geen fan van.

Komt hopelijk nog wel... (moet er toch eens van komen... :) )
De 24FJ256GA110 (of de 24FJ256GB110 als je USB nodig hebt) is qua mogelijkheden vergelijkbaar, is alleen 16 bits en heeft geen EEPROM meer.
(parameters kun je ook run-time in flash opslaan of een klein serial ee-prommetje...)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

De ATmega128 heeft een External Memory Interface om (o.a) XRAM aan te sturen.

With all the features the External Memory Interface provides, it is well suited to operate as an
interface to memory devices such as External SRAM and Flash, and peripherals such as LCD-
display, A/D, and D/A. The main features are:
• Four different wait-state settings (including no wait-state).
• Independent wait-state setting for different extErnal Memory sectors (configurable sector size).
• The number of bits dedicated to address high byte is selectable.
• Bus-keepers on data lines to minimize current consumption (optional).
Overview When the eXternal MEMory (XMEM) is enabled, address space outside the internal SRAM
becomes available using the dedicated External Memory pins (see Figure 1 on page 2, Table 27
on page 72, Table 33 on page 76, and Table 45 on page 84). The memory configuration is
shown in Figure 11.

RES

Als ik het goed begrijp, wil je dus schrijfacties van een bestaande 68000 CPU onderscheppen, en de geschreven waarde via de AVR controller verder verwerken.

Om hoeveel adressen gaat het? Is het 1 enkele variabele, of zijn het er meerdere?

Weet je wat de timing parameters zijn die 68000 zijn? Dat is immers de specificatie waar je nieuwe stuk circuit aan zal moeten voldoen.

Als het maar om een enkel adres gaat, zou je een digitale comparator gebruiken op de adres bus om een trigger signaal te maken, en een transparante latch om de data op te slaan, zodat je AVR deze kan uitlezen zonder bijzonder kritische timing.

Ik ken geen periferals in een microcontroller die de status van een groot aantal digitale ingangen kan latchen op een externe trigger, aangenomen dat zo'n XRAM interface geen slave mode heeft. Als je dat in software wilt doen, zul je moeten garanderen dat je interrupt latency zo kort is dat je binnen de timing specificaties blijft, en dat lijkt me praktisch onmogelijk met een AVR op 16MHz.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

De kloksnelheid is 7.61 Mhz (en 7.67Mhz) en het is inderdaad een bestaande 68000 CPU die moet kunnen lezen en schrijven naar een adres waar de AVR er iets mee kan doen.

Er moeten ongeveer 16 bytes per keer worden uitgewisseld. Maar er zijn ook plannen voor een bulk van 256 bytes per keer. De software voor beide kanten moet nog worden geschreven dus het zou niet veel uitmaken of het via meerdere adressen of 1 enkele zou werken. Het maakt ook niet uit of lezen en schrijven via verschillende adressen zou moeten.

Ik dacht ik begin mijn vraag algemeen, maar om precies te zijn is de 68000 Computer een Sega Mega Drive in mijn geval. De anderen uit de groep zijn uit de US en hebben dus een Sega Genesis. Vandaar het verschil in klok snelheid.

We zijn bezig om multi-player mogelijk te maken over internet.

Arco

Special Member

Daar waren lang geleden (1989!) heel goede oplossingen voor. Bijv. de 80C452 van Intel. Met 128 byte FIFO buffer...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Juist, ik dacht dat je een bestaand apparaat had, waarvan je de software niet kon aanpassen, waar je data uit wilde trekken.

Als ik het goed begrijp, wil je 2 kanten op kunnen communiceren; dat is nog een stuk moeilijker dan alleen data opvangen en lezen. Je zult dan dus ofwel in het RAM moeten kunnen schrijven, wat lastig is, omdat je moet voorkomen dat die 68000 op dat moment de bus gaat gebruiken, ofwel je zult moeten detecteren dat die 68000 een bepaald adres leest, de output enable van het RAM laag houden, en zelf de data op de bus zetten. Dat vereist een onderbreking van die output enable lijn, een heleboel data- en adreslijnen, en een reactiesnelheid die met zo'n AVR zeer waarschijnlijk onmogelijk is om te halen.

Is het niet VEEL gemakkelijker om een microcontroller te kiezen die 2 SPI bussen beschikbaar heeft, of nog beter, een controller die Ethernet aan boord heeft, en dat dus niet via SPI doen?

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Wat jij wil kan denk ik wel met een fifo. Cypress maakt die dingen nog, zullen wel een tientje per stuk kosten in kleine aantallen.

http://www.cypress.com/documentation/datasheets/cy7c421-512-9-asynchro…

bprosman

Golden Member

De jongere generatie loopt veel te vaak zijn PIC achterna.

Ik gebruikte hiervoor jaren lang de asyncFIFO's van IDT zoals de IDT7202 1Kx9. zie:
http://www.idt.com/products/memory-logic/fifo-products/asynchronous-fi…
Deze fifo's waren heel snel en beide zijden hebben hun eigen clock systeem. Vele malen gebruikt met 68000, 68020 en 68030 CPU's en uitwisseling van data met de slave CPU's. Waren zeer betrouwbare en vooral snelle chips tot 12 nsec lees/schrijf snelheid.

Arco

Special Member

Die IDT720x zijn inderdaad heel goed (vaak gebruikt) maar wel relatief duur, en ze zijn er volgens mij alleen in vrij lompe behuizingen. (DIL, PLCC)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Op 16 juni 2016 16:44:24 schreef Arco:
Die IDT720x zijn inderdaad heel goed (vaak gebruikt) maar wel relatief duur, en ze zijn er volgens mij alleen in vrij lompe behuizingen. (DIL, PLCC)

We gebruikten altijd de PLCC versie. Ik zie hier nog een IDT72105-80 liggen PLCC maar die is 1Kx16
Een AM7201A-50 PLCC is een 512x9 versie.
Een AM7202A-50 PLCC is de 1Kx9 versie.
De MC68000 waren meestal ook PLCC versie's, hier liggen er ook nog 6 stuks.

Dat waren de jaren 1980 en later...

Toen de CPLD's uitkwamen maakten we meer gebruik van snelle sram die we dan zelf dual ported via de CPLD maakten. Die waren groter en toch snel genoeg SRAM's waren ook tot 15 nsec. Met de FPGA komst zat alles in de FPGA en was het nog eenvoudiger.

Voor nog groter fifo's gebruikte ik heel veel de averlogic AL422B-15 die was 3 Mbit 384Kx8bit 15 nsec. Dat was ook met de FPGA's voor morphology toepassingen.
http://www.averlogic.com/pdf/AL422B_Flyer.pdf

Ik heb die FIFO's eens bekeken en dat lijkt inderdaad wel op iets wat kan gaan werken. Die IC's zijn ook niet enorm groot maar ik heb er volgensmij dan wel 2 van nodig om twee kanten op te communiceren toch?

Ik denk zelf dat het makkelijker wordt met dual-port SRAM. We zijn van plan om een soort nieuwe Game Genie te ontwerpen die niet gelimiteerd is aan 5 codes. Dit hebben we nodig om de spellen aan te passen zodat ze met onze hardware werken en we op die manier data naar de andere ontvanger kunnen sturen via internet. Deze nieuwe game genie heeft ook een ethernet aansluiting voor de verbinding met internet. En in plaats van ingewikkeld doen met kleine stukjes geheugen vervangen zoals de game genie doet willen we 4MB SRAM gebruiken om de game in te kopieren. Het orgineel gaat nog steeds bovenop zodat we geen piraterij gaan promoten.

Ik heb een idee met een soort van "multi-stage bootloader" die ik in het dual-port SRAM laad en dan de sega hardware initialiseert en vervolgens ons menu in het 4MB SRAM zet. Hiervoor moet ik nog wel een methode bedenken om het kleine DP-SRAM te switchen met het grotere SRAM. Op deze manier hebben we voor het menu geen Flash chip's meer nodig denk ik. En via het menu wordt de verbinding gemaakt met een andere speler en wordt het spel dat bovenop zit in het 4MB SRAM geladen en gepatched.

Ik heb het nu zo kort mogelijk geprobeerd uit te leggen maar ik denk dat dit we lkan gaan werken. Alleen de persoon die het PCB moet gaan ontwerpen ziet het niet zo zitten. Waarschijnlijk vanwege de velen traces die het dual-port sram nodig heeft. Ik zag er ook wel een nadeel aan en dat is dat enorm veel stroom vraagt. max 320mA! Dat vind ik best veel eigenlijk en ik betwijfel of de Sega zoveel stroom kan leveren.

Is het niet een idee om met een wat dikkere processor de "interfacing" te doen?

Je kan bijvoorbeeld een raspberry pi zero nemen. Die is denk ik snel genoeg om een interrupt te zien, en in de interrupt routine de door de 68000 geschreven data gewoon van de bus te plukken. Alleen vervelend dat maar een zeer beperkte hoeveelheid pins beschikbaar is, en zeker geen "opeenvolgende" zodat je dus moet gaan bitshiften om de data te reconstrueren.

Andere optie is een STM32. Ik heb een bordje waarbij een GND, GND, PC0-PC15, VCC, VCC connector beschikbaar is. Mogelijk moet je net 1 of twee cycles aan waitstates toevoegen, maar ook die kan op interrupt bassis redelijk direct aan de bus hangen.

Oh, wacht. Daaar zou ik het anders doen. Om data de STM in te krijgen denk ik dat dit gaat lukken. De andere kant op ben ik bang van niet.

Je stelt in de STM een DMA in die getriggerd wordt door de adres select lijn en de write. source is het GPIO data register, destination gewoon interne main ram. Om dat de andere kant op te laten werken, heb je denk ik een output buffer nodig. Door een write naar een apart adres -> pulsje op een pinnetje, laat je de STM dingen klaar zetten voor een serie reads en iedere read zorgt voor het verschijnen van nieuwe data op de GPIO. Een externe bus buffer moet de "tristate indien module niet geadresserd" verzorgen, want ik zie nog niet hoe het kan werken zonder die externe hardware.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Ik ben via google op deze thread gestumbled, en heb het uiteindelijk opgelost gekregen, zal men oplossing hier maar achterlaten.

Ik had practisch dezelfde setup en probleem, en het was echt echt nodig voor mij om dat zo snel mogelijk af te handelen, zelfs de jump kon er niet meer af.

Ik weet dat ik hier redelijk extreem te werk ben gegaan, maar ik heb het uiteindelijk wel kunnen oplossen door een lijn toe te voegen aan mijn platform.txt die me toelaat een powershell scriptje in mijn .ino bestand te steken. Dit scriptje wordt dan uitgevoerd nadat het .elf bestand gegenereerd is.

In dit scriptje heb ik dan iets geschreven dat de bytes in dat .elf bestand aanpast.

Ik heb er wat meer over geschreven op m'n github: https://github.com/L0laapk3/powershell-in-arduino-IDE

Ik weet dat dit echt geen goeie conventie is om zo dingen te doen, als iemand een oplossing weet die iets eenvoudiger is dan het bypassen van de compiler door middel van powershell, laat het me zeker weten, ik heb echt ongeveer alles geprobeerd waar ik op kon komen. Achja, het werkt zo ten minste :)