Hej!
Jag har aldrig labbat med Commodore, men är medveten om att de använde IEEE-488/GPIB för diskenheter. I en annan tråd så indikerade MiaM att det enda som var lika var det elektriska interfacet. Är det någon som känner till hur det förhåller sig, dvs kan en Commodore prata med en HP-diskettstation över GPIB?
Diskprotokoll på gamla Commodore med IEEE-488?
Re: Diskprotokoll på gamla Commodore med IEEE-488?
Commodore serie-488 är nog något HELT annat än GBIP. Dock kan man med ett kort i Cartridge porten använda GBIP.
Re: Diskprotokoll på gamla Commodore med IEEE-488?
blueint:
"hemdatorerna" använde "serie-gpib" (på 6-polig din...), medan de tidigare och de lite mer påkostade kontorsdatorerna i 8-bitarsserien (PET, CBM o.s.v.) använde riktiga GPIB-kontakter.
Burken du visar bild på gör vad jag kan tänka så att man kan ansluta en "PET"-diskdrive (och skrivare) till en C64.
Med andra ord något HALVT annat, inte HELT annat
AndersG:
En ren gissning är att med egenskriven mjukvara så kan troligtvis en Commodore prata med en HP-diskdrive, men med största sannolikhet så fungerar det inte med datorns inbyggda mjukvara. Protokollet är väl troligtvis såpass standardiserat att det inte blir några busskrockar eller andra dumheter om en HP-diskdrive är ansluten till en Commdoredator som pratar Commodoreprotokoll med andra enheter. Med andra ord så borde det kunna fungera att till en gammal Commodore dels ha en Commodorediskdrive för att ladda in sitt eget program och dels en HP-diskdrive som det egna programmet sen kan prata med.
Jag har haft en PET med diskdrive + printer på GPIB, men gjorde mig av med den för ett antal år sen. Jag minns att jag gjorde en GPIB-snifffer genom att helt enkelt ansluta GPIB-signalerna till datapinnarna på två pc-parallellportar (av bidirektionell typ) och sniffade av datat med nåt egenskrivet program. Tanken var att göra just en diskdriveemulator" eller kanske en "datoremulator" (främst för att flytta program mellan Commodoren och PC/"omvärlden"), men det blev aldrig något sådant.
Tyvärr har jag inte kvar några filer från de experimenten så jag kan inte säga något om hur signalerna såg ut. Det enda jag minns är att de verkade stämma med min dåvarande uppfattning om vad GPIB-standarden säger om signalerna, d.v.s. de där NACK, NDAV och vad de nu heter verkade fylla avsedd funktion.
Om du vill läsa på om det specifika protokollet så kan du läsa på om 1541 och de andra prylarna som anslöts via ett seriellt interface. Det var bara på den lägsta nivån som man bytte till seriellt interface, kommandona var i övrigt desamma.
En liten ledtråd får man genom att titta på standardfunktionerna i KERNAL-rom på en C64:
http://sta.c64.org/cbm64krnfunc.html
En del har inget med "gpib"-bussen att göra alls, men de intressanta är väl:
LSTNSA. Send LISTEN secondary address to serial bus. (Must call LISTEN beforehands.)
Input: A = Secondary address.
TALKSA. Send TALK secondary address to serial bus. (Must call TALK beforehands.)
Input: A = Secondary address.
SETTMO. Unknown. (Set serial bus timeout.)
Input: A = Timeout value.
IECIN. Read byte from serial bus. (Must call TALK and TALKSA beforehands.)
Output: A = Byte read.
IECOUT. Write byte to serial bus. (Must call LISTEN and LSTNSA beforehands.)
Input: A = Byte to write.
UNTALK. Send UNTALK command to serial bus.
UNLSTN. Send UNLISTEN command to serial bus.
LISTEN. Send LISTEN command to serial bus.
Input: A = Device number.
TALK. Send TALK command to serial bus.
Input: A = Device number.
SETLFS. Set file parameters.
Input: A = Logical number; X = Device number; Y = Secondary address.
SETNAM. Set file name parameters.
Input: A = File name length; X/Y = Pointer to file name.
OPEN. Open file. (Must call SETLFS and SETNAM beforehands.)
CLOSE. Close file.
Input: A = Logical number.
CHKIN. Define file as default input. (Must call OPEN beforehands.)
Input: X = Logical number.
CHKOUT. Define file as default output. (Must call OPEN beforehands.)
Input: X = Logical number.
CLRCHN. Close default input/output files (for serial bus, send UNTALK and/or UNLISTEN); restore default input/output to keyboard/screen.
CHRIN. Read byte from default input (for keyboard, read a line from the screen). (If not keyboard, must call OPEN and CHKIN beforehands.)
Output: A = Byte read.
CHROUT. Write byte to default output. (If not screen, must call OPEN and CHKOUT beforehands.)
Input: A = Byte to write.
LOAD. Load or verify file. (Must call SETLFS and SETNAM beforehands.)
Input: A: 0 = Load, 1-255 = Verify; X/Y = Load address (if secondary address = 0).
Output: Carry: 0 = No errors, 1 = Error; A = KERNAL error code (if Carry = 1); X/Y = Address of last byte loaded/verified (if Carry = 0).
SAVE. Save file. (Must call SETLFS and SETNAM beforehands.)
Input: A = Address of zero page register holding start address of memory area to save; X/Y = End address of memory area plus 1.
Output: Carry: 0 = No errors, 1 = Error; A = KERNAL error code (if Carry = 1).
GETIN. Read byte from default input. (If not keyboard, must call OPEN and CHKIN beforehands.)
Output: A = Byte read.
CLALL. Clear file table; call CLRCHN.
Helt klart är att LSTNSA, TALKSA, SETTMO, IECIN, IECOUT, UNTALK, UNLSTN, LISTEN och TALK är API'erna på lägst nivå.
Nästa nivå måste vara SETLFS, SETNAM, OPEN, CLOSE, CHKIN, CHKOUT, CLRCHN, CHRIN, CHROUT och GETIN.
"Högnivån" på API'erna måste vara LOAD och SAVE.
Värt att veta är att Logical number avser filnummer i basic eller motsvarande. Device number är GPIB-enhetsnummer och på samma sätt Secondary address just sekundäradress på GPIB'n.
Värt att veta är att det finns en del hårdkodat special i Commodorevärlden. Här ser man t.ex. att 0-3 är hårdkodat till saker som inte finns på GPIB-bussen. Dessa nummer stämmer för VIC-20, C64 och C128. Vissa PET hade två bandspelarportar som jag tror hade nummer 1 och 2, men de hade nog inget som motsvarade RS232 så det var säkert samma nummer i övrigt. Jag är helt säker på att diskdrives använder 8 och uppåt även på PET och 99,99% säker på att printers använder 4 och uppåt även på PET.
http://www.c64-wiki.com/index.php/Device_number
Även sekundäradresserna har speciell betydelse. Jag tror inte det finns flera att välja på när det gäller skrivare. Däremot finns det flera på en diskdrive där man använder olika sekundäradress för att kunna ha flera filer öppna samtidigt. Sekundäradress 15 används som en kommando/statuskanal, åtminstone på diskdrives. Dels kan man t.ex. formattera en diskett genom att skicka ett "N"-kommando på sekundäradress 15, och dels kan man läsa av status från senaste kommando via sekundäradress 15.
För att röra till det så väljer man (vad jag minns) diskett inom en dubbeldrive genom att ha 0: eller 1: först i filnamnet. Disketterna i en dubbeldrive heter alltså 0:x och 1:x på enhetsnummer 8. Om man däremot har två enkeldrives så heter båda disketterna 0: men på enhetsnummer 8 respektive 9.
http://en.wikipedia.org/wiki/Commodore_DOS
En scannad tegelsten:
http://www.pagetable.com/docs/Inside%20 ... %20DOS.pdf
Instruktionsbok till några GPIB-diskdrives:
http://www.classiccmp.org/cini/pdf/Comm ... Manual.pdf
Om du vill sikta på att få ditt bygge användbart mot Commodoredatorer så är minimikravet att ha ett filsystem i ditt bygge, och det bör stödja filnamn om typ 17 tecken, stora/små bokstäver, plus något extra tecken för att hantera filtyp. 99% av allt prat med en diskdrive lär vara att ladda/spara program och då klarar man sig nog på att bara kunna ha en fil öppen samtidigt. Någon enstaka ytterligare procent lär vara att läsa/skriva sekventiella filer, och de hanteras väl i princip ungefär som programfiler. Krångligare blir det med relativa filer, de orkade jag inte ens lära mig hur de funkar då det begav sig.
100% kompabilitet kan du i princip bara få ifall du emulerar hela hårdvaran inklusive 6502-processor. De flesta drive'ar med GPIB-buss hade två 6502-kompatibla processorer (klockade i motfas så att de nyttjade varsin flank på klockan så att säga, ungefär som processor v.s. grafikkrets nyttjar varsin flank/fas på klockan i VIC-20, C64, C128 o.s.v.) medan 15**-serien (som visserligen inte har GPIB utan serievarianten) bara hade en 6502, och nån GPIB-drive som fysiskt ser ut som 1541 (SFD 1001, kanske?) hade nog också bara en enda 6502.
Det jobbiga är att det finns alltså kommandon för att från datorn läsa/skriva direkt i diskdrivens minne och köra kod. Det finns också kommandon för att läsa in ett block från disk och köra det som kod.
Jag skulle nog gissa att de flesta sådana funktioner används bara på C64 och då mestadels av spel och demos och enstaka andra program som behöver processorkraft. (En diskdrive hade ju lika snabb klocka och lika kraftfull processor som datorn, så sånt som att beräka 3D-vektorgrafik i ett demo eller liknande gjordes med fördel med diskdrivens processor, antar jag).
Jag tror att en lagom nivå att sikta på för din del skulle vara att göra en diskdrive som är kompatibel med alla kommandon utom de där för att läsa/skriva minne och köra kod, eller kanske till och med skippa kommandona för att läsa/skriva råa block på disken. Fast för att du ska kunna hantera flera öppna filer samtidigt så behöver du nog byta filsystemet du använder om jag fattat rätt.
En rimlig setup för en Commodreentusiast är nog att ha en orginaldrive på enhetsnummer 8 och något modernt bygge på enhetsnummer 9 eller högre. Jag skulle rekomendera att det åtminstone går att confa in enhetsnummer 8-11. För den som kör PET så kan det kanske hända att man till och med har två orginaldrive'ar, dels en 2040 eller liknande som är i stort sett kompatibel med disketterna från VIC-20/C64/C128 (drive'arna kan läsa varandras disketter men jag tror att rekomendationen är att bara skriva i den drivetyp de är formatterade i, på grund av nån timinggrej), och dels en av de som rymmer mer per diskett (8050,8250 o.s.v.).
Sorry om jag gör dig nedslagen av att det är så mycket krångel...
... det finns dock en del färdiga projekt som emulerar en 1541 som alltså har den seriella varianten av GPIB. Det finns dels varianter med en riktigt enkel hårdvara (någon inverterare, några dioder och/eller bara en kabel) som körs ihop med mjukvara i en dator (som finns med källkod), och dels sådant som körs i modernare mikrokontrollers. De här grejerna kan nog vara läge att titta på. Just bussprotokollet skiljer ju sig åt på lägsta nivå men i övrigt så borde det mesta från något sådant gå att flytta över.
(Sorry om det här blev lite rörigt...)
Sidospår: OBS för övrigt att diskdrive'arna är så gamla att de är anpassade för disketterna som gav 35 respektive 77 spår vid 48 respektive 96 TPI. De kör olika klockfrekvens på olika delar av disketten för att få olika antal sektorer per spår och därmed ungefär samma datadensitet över hela disketten (till skillnad från t.ex. PC som kör samma antal bytes per spår och därmed får mycket högre densitet och därmed även felbenägenhet på de högsta spåren). Detta gör tyvärr att ifall man hackar diskdrivens mjukvara att använda fler spår så blir extraspåren "överklockade" eftersom det inte finns någon ännu lägre datahastighet. Jag förstår att man valde 35 spår på PET-tiden, men åtminstone 1570/1571 som kom ut i samband med C128 och kanske till och med 1541 för C64 eller till och med 1540 för VIC-20 borde haft 40-spår...
Ytterligare sidospår: Åtminstone 1541 använder inte index/synkhålet till något, och eftersom det är en enkelsidig diskdrive så kan man helt enkelt vända de flesta disketter upp-och-ned för att använda baksidan. Det kräver dels att disketten rent mekaniskt inte kärvar när den snurrar baklänges (något som ironiskt nog hände med "PET-disketterna" som såldes i Sverige, men sällan med andra fabrikat) och dels måste man klippa upp ett "ej skrivskyddad"-hål spegelvänt från orginalhålet. Till detta såldes det speciella "diskettklippare" som C64-tillbehör för den som inte var sugen på att krångla med sax
"hemdatorerna" använde "serie-gpib" (på 6-polig din...), medan de tidigare och de lite mer påkostade kontorsdatorerna i 8-bitarsserien (PET, CBM o.s.v.) använde riktiga GPIB-kontakter.
Burken du visar bild på gör vad jag kan tänka så att man kan ansluta en "PET"-diskdrive (och skrivare) till en C64.
Med andra ord något HALVT annat, inte HELT annat
AndersG:
En ren gissning är att med egenskriven mjukvara så kan troligtvis en Commodore prata med en HP-diskdrive, men med största sannolikhet så fungerar det inte med datorns inbyggda mjukvara. Protokollet är väl troligtvis såpass standardiserat att det inte blir några busskrockar eller andra dumheter om en HP-diskdrive är ansluten till en Commdoredator som pratar Commodoreprotokoll med andra enheter. Med andra ord så borde det kunna fungera att till en gammal Commodore dels ha en Commodorediskdrive för att ladda in sitt eget program och dels en HP-diskdrive som det egna programmet sen kan prata med.
Jag har haft en PET med diskdrive + printer på GPIB, men gjorde mig av med den för ett antal år sen. Jag minns att jag gjorde en GPIB-snifffer genom att helt enkelt ansluta GPIB-signalerna till datapinnarna på två pc-parallellportar (av bidirektionell typ) och sniffade av datat med nåt egenskrivet program. Tanken var att göra just en diskdriveemulator" eller kanske en "datoremulator" (främst för att flytta program mellan Commodoren och PC/"omvärlden"), men det blev aldrig något sådant.
Tyvärr har jag inte kvar några filer från de experimenten så jag kan inte säga något om hur signalerna såg ut. Det enda jag minns är att de verkade stämma med min dåvarande uppfattning om vad GPIB-standarden säger om signalerna, d.v.s. de där NACK, NDAV och vad de nu heter verkade fylla avsedd funktion.
Om du vill läsa på om det specifika protokollet så kan du läsa på om 1541 och de andra prylarna som anslöts via ett seriellt interface. Det var bara på den lägsta nivån som man bytte till seriellt interface, kommandona var i övrigt desamma.
En liten ledtråd får man genom att titta på standardfunktionerna i KERNAL-rom på en C64:
http://sta.c64.org/cbm64krnfunc.html
En del har inget med "gpib"-bussen att göra alls, men de intressanta är väl:
LSTNSA. Send LISTEN secondary address to serial bus. (Must call LISTEN beforehands.)
Input: A = Secondary address.
TALKSA. Send TALK secondary address to serial bus. (Must call TALK beforehands.)
Input: A = Secondary address.
SETTMO. Unknown. (Set serial bus timeout.)
Input: A = Timeout value.
IECIN. Read byte from serial bus. (Must call TALK and TALKSA beforehands.)
Output: A = Byte read.
IECOUT. Write byte to serial bus. (Must call LISTEN and LSTNSA beforehands.)
Input: A = Byte to write.
UNTALK. Send UNTALK command to serial bus.
UNLSTN. Send UNLISTEN command to serial bus.
LISTEN. Send LISTEN command to serial bus.
Input: A = Device number.
TALK. Send TALK command to serial bus.
Input: A = Device number.
SETLFS. Set file parameters.
Input: A = Logical number; X = Device number; Y = Secondary address.
SETNAM. Set file name parameters.
Input: A = File name length; X/Y = Pointer to file name.
OPEN. Open file. (Must call SETLFS and SETNAM beforehands.)
CLOSE. Close file.
Input: A = Logical number.
CHKIN. Define file as default input. (Must call OPEN beforehands.)
Input: X = Logical number.
CHKOUT. Define file as default output. (Must call OPEN beforehands.)
Input: X = Logical number.
CLRCHN. Close default input/output files (for serial bus, send UNTALK and/or UNLISTEN); restore default input/output to keyboard/screen.
CHRIN. Read byte from default input (for keyboard, read a line from the screen). (If not keyboard, must call OPEN and CHKIN beforehands.)
Output: A = Byte read.
CHROUT. Write byte to default output. (If not screen, must call OPEN and CHKOUT beforehands.)
Input: A = Byte to write.
LOAD. Load or verify file. (Must call SETLFS and SETNAM beforehands.)
Input: A: 0 = Load, 1-255 = Verify; X/Y = Load address (if secondary address = 0).
Output: Carry: 0 = No errors, 1 = Error; A = KERNAL error code (if Carry = 1); X/Y = Address of last byte loaded/verified (if Carry = 0).
SAVE. Save file. (Must call SETLFS and SETNAM beforehands.)
Input: A = Address of zero page register holding start address of memory area to save; X/Y = End address of memory area plus 1.
Output: Carry: 0 = No errors, 1 = Error; A = KERNAL error code (if Carry = 1).
GETIN. Read byte from default input. (If not keyboard, must call OPEN and CHKIN beforehands.)
Output: A = Byte read.
CLALL. Clear file table; call CLRCHN.
Helt klart är att LSTNSA, TALKSA, SETTMO, IECIN, IECOUT, UNTALK, UNLSTN, LISTEN och TALK är API'erna på lägst nivå.
Nästa nivå måste vara SETLFS, SETNAM, OPEN, CLOSE, CHKIN, CHKOUT, CLRCHN, CHRIN, CHROUT och GETIN.
"Högnivån" på API'erna måste vara LOAD och SAVE.
Värt att veta är att Logical number avser filnummer i basic eller motsvarande. Device number är GPIB-enhetsnummer och på samma sätt Secondary address just sekundäradress på GPIB'n.
Värt att veta är att det finns en del hårdkodat special i Commodorevärlden. Här ser man t.ex. att 0-3 är hårdkodat till saker som inte finns på GPIB-bussen. Dessa nummer stämmer för VIC-20, C64 och C128. Vissa PET hade två bandspelarportar som jag tror hade nummer 1 och 2, men de hade nog inget som motsvarade RS232 så det var säkert samma nummer i övrigt. Jag är helt säker på att diskdrives använder 8 och uppåt även på PET och 99,99% säker på att printers använder 4 och uppåt även på PET.
http://www.c64-wiki.com/index.php/Device_number
Även sekundäradresserna har speciell betydelse. Jag tror inte det finns flera att välja på när det gäller skrivare. Däremot finns det flera på en diskdrive där man använder olika sekundäradress för att kunna ha flera filer öppna samtidigt. Sekundäradress 15 används som en kommando/statuskanal, åtminstone på diskdrives. Dels kan man t.ex. formattera en diskett genom att skicka ett "N"-kommando på sekundäradress 15, och dels kan man läsa av status från senaste kommando via sekundäradress 15.
För att röra till det så väljer man (vad jag minns) diskett inom en dubbeldrive genom att ha 0: eller 1: först i filnamnet. Disketterna i en dubbeldrive heter alltså 0:x och 1:x på enhetsnummer 8. Om man däremot har två enkeldrives så heter båda disketterna 0: men på enhetsnummer 8 respektive 9.
http://en.wikipedia.org/wiki/Commodore_DOS
En scannad tegelsten:
http://www.pagetable.com/docs/Inside%20 ... %20DOS.pdf
Instruktionsbok till några GPIB-diskdrives:
http://www.classiccmp.org/cini/pdf/Comm ... Manual.pdf
Om du vill sikta på att få ditt bygge användbart mot Commodoredatorer så är minimikravet att ha ett filsystem i ditt bygge, och det bör stödja filnamn om typ 17 tecken, stora/små bokstäver, plus något extra tecken för att hantera filtyp. 99% av allt prat med en diskdrive lär vara att ladda/spara program och då klarar man sig nog på att bara kunna ha en fil öppen samtidigt. Någon enstaka ytterligare procent lär vara att läsa/skriva sekventiella filer, och de hanteras väl i princip ungefär som programfiler. Krångligare blir det med relativa filer, de orkade jag inte ens lära mig hur de funkar då det begav sig.
100% kompabilitet kan du i princip bara få ifall du emulerar hela hårdvaran inklusive 6502-processor. De flesta drive'ar med GPIB-buss hade två 6502-kompatibla processorer (klockade i motfas så att de nyttjade varsin flank på klockan så att säga, ungefär som processor v.s. grafikkrets nyttjar varsin flank/fas på klockan i VIC-20, C64, C128 o.s.v.) medan 15**-serien (som visserligen inte har GPIB utan serievarianten) bara hade en 6502, och nån GPIB-drive som fysiskt ser ut som 1541 (SFD 1001, kanske?) hade nog också bara en enda 6502.
Det jobbiga är att det finns alltså kommandon för att från datorn läsa/skriva direkt i diskdrivens minne och köra kod. Det finns också kommandon för att läsa in ett block från disk och köra det som kod.
Jag skulle nog gissa att de flesta sådana funktioner används bara på C64 och då mestadels av spel och demos och enstaka andra program som behöver processorkraft. (En diskdrive hade ju lika snabb klocka och lika kraftfull processor som datorn, så sånt som att beräka 3D-vektorgrafik i ett demo eller liknande gjordes med fördel med diskdrivens processor, antar jag).
Jag tror att en lagom nivå att sikta på för din del skulle vara att göra en diskdrive som är kompatibel med alla kommandon utom de där för att läsa/skriva minne och köra kod, eller kanske till och med skippa kommandona för att läsa/skriva råa block på disken. Fast för att du ska kunna hantera flera öppna filer samtidigt så behöver du nog byta filsystemet du använder om jag fattat rätt.
En rimlig setup för en Commodreentusiast är nog att ha en orginaldrive på enhetsnummer 8 och något modernt bygge på enhetsnummer 9 eller högre. Jag skulle rekomendera att det åtminstone går att confa in enhetsnummer 8-11. För den som kör PET så kan det kanske hända att man till och med har två orginaldrive'ar, dels en 2040 eller liknande som är i stort sett kompatibel med disketterna från VIC-20/C64/C128 (drive'arna kan läsa varandras disketter men jag tror att rekomendationen är att bara skriva i den drivetyp de är formatterade i, på grund av nån timinggrej), och dels en av de som rymmer mer per diskett (8050,8250 o.s.v.).
Sorry om jag gör dig nedslagen av att det är så mycket krångel...
... det finns dock en del färdiga projekt som emulerar en 1541 som alltså har den seriella varianten av GPIB. Det finns dels varianter med en riktigt enkel hårdvara (någon inverterare, några dioder och/eller bara en kabel) som körs ihop med mjukvara i en dator (som finns med källkod), och dels sådant som körs i modernare mikrokontrollers. De här grejerna kan nog vara läge att titta på. Just bussprotokollet skiljer ju sig åt på lägsta nivå men i övrigt så borde det mesta från något sådant gå att flytta över.
(Sorry om det här blev lite rörigt...)
Sidospår: OBS för övrigt att diskdrive'arna är så gamla att de är anpassade för disketterna som gav 35 respektive 77 spår vid 48 respektive 96 TPI. De kör olika klockfrekvens på olika delar av disketten för att få olika antal sektorer per spår och därmed ungefär samma datadensitet över hela disketten (till skillnad från t.ex. PC som kör samma antal bytes per spår och därmed får mycket högre densitet och därmed även felbenägenhet på de högsta spåren). Detta gör tyvärr att ifall man hackar diskdrivens mjukvara att använda fler spår så blir extraspåren "överklockade" eftersom det inte finns någon ännu lägre datahastighet. Jag förstår att man valde 35 spår på PET-tiden, men åtminstone 1570/1571 som kom ut i samband med C128 och kanske till och med 1541 för C64 eller till och med 1540 för VIC-20 borde haft 40-spår...
Ytterligare sidospår: Åtminstone 1541 använder inte index/synkhålet till något, och eftersom det är en enkelsidig diskdrive så kan man helt enkelt vända de flesta disketter upp-och-ned för att använda baksidan. Det kräver dels att disketten rent mekaniskt inte kärvar när den snurrar baklänges (något som ironiskt nog hände med "PET-disketterna" som såldes i Sverige, men sällan med andra fabrikat) och dels måste man klippa upp ett "ej skrivskyddad"-hål spegelvänt från orginalhålet. Till detta såldes det speciella "diskettklippare" som C64-tillbehör för den som inte var sugen på att krångla med sax
Re: Diskprotokoll på gamla Commodore med IEEE-488?
miam: Fidonetklass på det inlägget 
Jag har f.ö en MSD Super Diskdrive SD2, det är en dubbeldiskdrive som kan prata både vanlig seriell IEC, och paralellvarianten som PET kör, men även om man kan adressera varje diskdrive för sej (troligen med 0: 1: osv, minns inte riktigt, har inte använt den sen 1994 eller nåt) så kommer load"$",8 och en list ge en kombinerad listning av diskarna i båda drivarna vill jag minnas, ganska lustigt.
Jag har f.ö en MSD Super Diskdrive SD2, det är en dubbeldiskdrive som kan prata både vanlig seriell IEC, och paralellvarianten som PET kör, men även om man kan adressera varje diskdrive för sej (troligen med 0: 1: osv, minns inte riktigt, har inte använt den sen 1994 eller nåt) så kommer load"$",8 och en list ge en kombinerad listning av diskarna i båda drivarna vill jag minnas, ganska lustigt.
Re: Diskprotokoll på gamla Commodore med IEEE-488?
Tack Mia! Jag har inte tillgång till några Commodoreprylar alls, så tror knappast jag kommer att skriva ngn kod för det, men om någon annan känner sig manad, så borde hårdvaran fungera dock.
Status i dag är att Amigo-emuleringen är klar. HAr även skrivit emulering för SS/80 (det nyare protokollet) och den fungerar, men behöver litet finputsning.
Status i dag är att Amigo-emuleringen är klar. HAr även skrivit emulering för SS/80 (det nyare protokollet) och den fungerar, men behöver litet finputsning.
Re: Diskprotokoll på gamla Commodore med IEEE-488?
Ja, om du inte har några Commodoreprylar så är det väl ingen större idé att skriva kod själv.
Det du ungefär skulle kunna tänka på när du går från prototyp till färdig konstruktion är att välja hårdvara som åtminstone kan tänkas rymma kod nog för att hantera de där funktionerna (exkl att emulera hela processorn & co), och du skulle kanske kunna "slå till" på en lite mer fullständig filsystemimplementation med en gång, som klarar säg åtminstone något halvdussin öppna filer samtidigt. Då borde det bli klart enklare för nästa person att lägga till det Commodore-specifika.
Fast det beror ju på om du över huvud taget vill ha bygget "Commodore-förberett" eller inte.
Det du ungefär skulle kunna tänka på när du går från prototyp till färdig konstruktion är att välja hårdvara som åtminstone kan tänkas rymma kod nog för att hantera de där funktionerna (exkl att emulera hela processorn & co), och du skulle kanske kunna "slå till" på en lite mer fullständig filsystemimplementation med en gång, som klarar säg åtminstone något halvdussin öppna filer samtidigt. Då borde det bli klart enklare för nästa person att lägga till det Commodore-specifika.
Fast det beror ju på om du över huvud taget vill ha bygget "Commodore-förberett" eller inte.
Re: Diskprotokoll på gamla Commodore med IEEE-488?
Hårdvaran är tyvärr ganska klar. Men en PIC8F4620 har ganska gott om minne. Med både Amigo och SS/80 finns 1/3 ledigt. Se http://www.dalton.ax/hpdiskDet du ungefär skulle kunna tänka på när du går från prototyp till färdig konstruktion
