Som jag nämnt i en annan tråd så har jag tänkt konstruera en "floppy drivesimulator" till AMIGA. Jag har till att börja med tänkt dela upp datan från en .adf-fil i sectors och tracks och mfm-koda på en PC (detta är nästan löst, jag har crc-generering kvar) och sedan låta en pic18f458 kommunicera med AMIGAN och fungera ungefär som ett paralellt till seriellt buffrat skiftregister mellan paralellporten på PC å diskettinterfacet på AMIGAN. Jag har funderat på lite olika lösningar för att få skiftningen att ta så lite tid som möjligt (AMIGAN förväntar sig data i 300 kilobit/s).
Jag har funderat på att använda PIC:ens SPI-stöd som skiftregister (för det är väl det det är) så att jag kan ägna så mkt tid som möjligt åt att buffra data. Är det någon som försökt använda SPI-stödet på det här sättet eller har några andra synpunkter.
PIC SPI för jämn dataström
Har inte provat SPI, fast kan tipsa om indirect adressing i RAM (om du inte redan vet). I stället för att definera registernamn och lägga data i dom 'manuelt', kan du adressera med FSR registret. Sedan skriver/läser du i INDF registret.
Det funkar som ett vanlig RAM; FSR är adress, INDF är data. Fast kolla noga vart du lägger din 'bank'.
Programmet går att skriva som en lång loop:
1)kolla LPT, lagra i INDF och incrementera FSR om data finns
2)kolla LPT, lagra i INDF och incrementera FSR om data finns en 2 gång
3)Clocka ut en Amiga-bit på en pinne. Decrementera FSR om alla 8/10 skickats
4) goto start
Något ställe måste man kolla buffer pointer (FSR) så den inte gått ur området... I så fall får programmet kanske hänvisas till en annan programsnutt som 'meddelar' Amigan och PC'en.
Med 20MHz kan man ha 16-17 ASM instruktioner i loopen.
Det funkar som ett vanlig RAM; FSR är adress, INDF är data. Fast kolla noga vart du lägger din 'bank'.
Programmet går att skriva som en lång loop:
1)kolla LPT, lagra i INDF och incrementera FSR om data finns
2)kolla LPT, lagra i INDF och incrementera FSR om data finns en 2 gång
3)Clocka ut en Amiga-bit på en pinne. Decrementera FSR om alla 8/10 skickats
4) goto start
Något ställe måste man kolla buffer pointer (FSR) så den inte gått ur området... I så fall får programmet kanske hänvisas till en annan programsnutt som 'meddelar' Amigan och PC'en.
Med 20MHz kan man ha 16-17 ASM instruktioner i loopen.
Jo, jag tänkte göra något sånt, man kan ha FSR0 som utpekare och FSR1 som inpekare och låta dessa röra sig över några banker i all oändlighet (nästan 
). Så länge inpekaren ligger "framför" utpekaren begär man en ny byte från PC:n, och om utpekaren pekar på samma adress som inpekaren så ger man nåt snyggt meddelande som t.ex. "buffer underrun". Det var kanske så du menade.
Det där med klockningen har jag klurat på. Om jag använder interrupt för att generera bitströmmen så och om jag vill köpa kristall på ELFA får jag nöja mig med med en kristall på 6MHz och dela den med 20 för att få 300kHz men då har jag också mindre än 20 instruktioncykler på mig att buffra. Ingen som vet var man kan få tag på en 9900000Hz-kristall, finns det ens? Jag undrar vad man tjänar mest på. Använder man inte interrupt så slipper man tiden det tar att komma till interruptkoden, om man använder interrupt är inte buffringen begränsad av bithastigheten. Jag får tänka över det.
Jag hade från början tänkt nåt sånt här:
huvudkoden:
1 begär byte
2 vänta på byte
3 kommer inpekare hamna på samma adress som utpekare?
4 ja, goto 3
5 nej, lagra byte
6 öka inpekare
7 goto 1
interruptkoden:
vart åttonde klockinterrupt:
1 pekar utpekare på samma adress som inpekare?
2 ja, "buffer underrun"
3 nej, hämta byte
4 öka utpekare
5 skicka ut bit
6 avsluta interrupt
). Så länge inpekaren ligger "framför" utpekaren begär man en ny byte från PC:n, och om utpekaren pekar på samma adress som inpekaren så ger man nåt snyggt meddelande som t.ex. "buffer underrun". Det var kanske så du menade.Det där med klockningen har jag klurat på. Om jag använder interrupt för att generera bitströmmen så och om jag vill köpa kristall på ELFA får jag nöja mig med med en kristall på 6MHz och dela den med 20 för att få 300kHz men då har jag också mindre än 20 instruktioncykler på mig att buffra. Ingen som vet var man kan få tag på en 9900000Hz-kristall, finns det ens? Jag undrar vad man tjänar mest på. Använder man inte interrupt så slipper man tiden det tar att komma till interruptkoden, om man använder interrupt är inte buffringen begränsad av bithastigheten. Jag får tänka över det.
Jag hade från början tänkt nåt sånt här:
huvudkoden:
1 begär byte
2 vänta på byte
3 kommer inpekare hamna på samma adress som utpekare?
4 ja, goto 3
5 nej, lagra byte
6 öka inpekare
7 goto 1
interruptkoden:
vart åttonde klockinterrupt:
1 pekar utpekare på samma adress som inpekare?
2 ja, "buffer underrun"
3 nej, hämta byte
4 öka utpekare
5 skicka ut bit
6 avsluta interrupt
Jag tänkte fel med buffern, den är ju LIFO... Och så behöver man ju bara kolla LPT 1 gång, det kommar ju att hända 8 ggr så ofta som en byte skickas ut... Du är inne på en bra programsnutt.
Interrupter 300K ggr/S är ganska ofta.. Bara dom 8-10 instruktioner för att spara undan W och STATUS tar halva tiden...
Enda nackdelen med att inte ha interrupt är programmet måste ha fast antal instruktioner när det kör. Vad gäller kristall kan man ju ha olika antal (dummy) instruktioner t.ex:
300.000 * 16 *4 = 19,2MHz
300.000 * 17*4 = 20,4MHz osv. Excel är bra för att skapa sådana tabeller.
Konverter'n behöver ju inte skicka felmeddelande om buffern är tom/full, den kan ju ha egna READY/BUSY-flaggor om datorerna stöder det..
Interrupter 300K ggr/S är ganska ofta.. Bara dom 8-10 instruktioner för att spara undan W och STATUS tar halva tiden...
Enda nackdelen med att inte ha interrupt är programmet måste ha fast antal instruktioner när det kör. Vad gäller kristall kan man ju ha olika antal (dummy) instruktioner t.ex:
300.000 * 16 *4 = 19,2MHz
300.000 * 17*4 = 20,4MHz osv. Excel är bra för att skapa sådana tabeller.
Konverter'n behöver ju inte skicka felmeddelande om buffern är tom/full, den kan ju ha egna READY/BUSY-flaggor om datorerna stöder det..
READY/BUSY är inget problem mellan PIC å PC. Amigans floppyinterface däremot har en ready-pinne men den är nog mest till för att vänta in spårbyte och andra fördröjningar. Amigan säger till floppydriven att starta motorn och förväntar sig säkert att, efter att motorn kommit upp i varv, få en jämn ström av data tills dess att den stänger av motorn eller byter spår. Jag måste därför hela tiden, för att datan amigan får inte ska bli felaktig, se till att inte få slut på data.
Du har rätt om interrupten, tusan också att PIC:arna är så långsamma/har så få arbetsregister, men nu när jag har en 18f458 så vill jag använda den.
Hu, trevligt och bra att ha nån att bolla med.
Du har rätt om interrupten, tusan också att PIC:arna är så långsamma/har så få arbetsregister, men nu när jag har en 18f458 så vill jag använda den.
Hu, trevligt och bra att ha nån att bolla med.
Tror nog det skulle funka, PC'en ska ju bara skicka 37,5Kb/S...
Ett par andra ideer:
I stället för 2 pekare kan man ha en pekare och en offset. Offseten blir då samma värde som bufferns storlek (som ska kollas).
Maska bort delar av pekar-bytet (andlw) som adresser i stället för att resetta registren. Då kommer dom att 'rolla över' av sig själv, och offseten blir alltid ett positivt värde.
Ett par andra ideer:
I stället för 2 pekare kan man ha en pekare och en offset. Offseten blir då samma värde som bufferns storlek (som ska kollas).
Maska bort delar av pekar-bytet (andlw) som adresser i stället för att resetta registren. Då kommer dom att 'rolla över' av sig själv, och offseten blir alltid ett positivt värde.
