Sari la conținut
ELFORUM - Forumul electronistilor

Coral, Independent, PDP11, Felix C/Felix M, Robotron: Emulator unitate de banda magnetica pe 9 piste


skaarj

Postări Recomandate

Te mănâncă în călcâie să sari gardu vreunei uzine abandonate sau a vreunei clădiri industriale rămase în conservare și înăuntru să-ți pice fața: ajungi în sala calculatorului unde doarme ditai dihania mare cât 4...5 șifoniere de-ale bunicului. Te mănâncă curiozitatea să-l vezi pornit dar până acolo e o grămadă de lucru:  întâi să faci formalitățile să-l poți lua acasă... legal. Asta se poate, cu ceva diplomație și cu ceva economii pentru că o să ți-l vândă la kil, apoi trebuie să tocmești un camion și o gașcă de băieți musculoși că e grea a naibii dihania.  După aia îți trebuie un spațiu de stocare - în cazul meu o căsuță mică renovată unde în trecut foștii proprietari stăteau într-o cameră iar în cealaltă băgau calul. Stă bine acum, pornește, merge, își face treaba, ce e important - nu îl poate păcăli nimeni să mineze bitcoin. Corcitura mea Felix-Coral (carcasa de felix, unitatea centrală și perifericele de Coral) butează BSD UNIX și poate fi văzut uite aici:

 

7810291556953926381.jpg

 

Primele de-ți sar în ochi la un asemenea dinozaur sunt unitățile de bandă magnetică. E tare mișto să le urmărești cum transferă datele. Ba înainte, ba înapoi. Interfețele din epoca aia se numesc Unibus/Multibus - specifice sistemelor din familia PDP si mai târziu VAX, preluate parțial și de Coral și Independent;  HPIB - protocolul proprietar Hewlett Packard pentru comunicații cu interfețele periferice simple precum plăci de achiziție, tiparnițe (imprimante), unități secvențiale de stocare a datelor (cartele perforate), și ultimul pe listă - interfața industrială PERTEC care a supraviețuit până în anii 2000. 


PERTEC a fost adoptat ca standard în toate calculatoarele de tip "mainframe", inclusiv în centralele telefonice digitale metropolitane importate și la noi când au desființat celebrele "penta-conta".


Ca să mențină compatibilitatea cu diversele arhitecturi de calcul, au fost construite adaptoare "pertec" pentru diversele magistrale specifice:  pertec-unibus, pertec-multibus, pertec-scsi, pertec-hpib, pertec-ISA pentru calculatoarele PC. Din păcate nu au ajuns să construiască și adaptoare la PCI:  tehnica a evoluat spre unități de bandă mai mici, mai compacte și cu capacități mult mai mari.

 

Ca și mențiune, compania Pertec Computer Corporation a elaborat versiunea lor proprie de interfață cu unitățile floppy-disc care a fost adoptată ca standard în toate PC-urile și a supraviețuit până prin 2005 când a venit cd-rw și sticul USB care le-a tras pe toate floapele pe dreapta.

În proiectul ăsta o să ne concentrăm asupra stabilirii comunicației între o unitate de bandă magnetică pe 9 piste de CORAL - interfață Pertec - cu un microcontroller din seria STM32. Adică să extragem datele de pe o bandă veche de Coral.

 

Pentru că proiectul e de interes și "pe afară", schemele conțin și cuvinte în englezește da' cine mai ține minte ce minuni de-ale mele au fost aici pe forum, o să îmi recunoască stilul - mereu desen pe hârtie de mate - și o să recunoască și scrisul.

 

Uite schema bloc cum arată:

 

5389981555695436270.jpg

 

Sistemul se cuplează între Coral și unitatea de bandă magnetică. Pentru fiecare în parte are dedicată câte o interfață de intrare-ieșire.

Microcontrollerul STM32 e conectat și el printr-o altă interfață - bidirecțională cu schimbare de sens de data asta - care funcționează și ca convertor de nivel. Asta pentru că STM32F429 lucrează pe 3.3V iar unitatea de bandă magnetică pe 5 volți. Catalogul tehnic zice cum că cică pinii sunt toleranți la 5V dar n-am chef să fac pariu cu chinezul pe tema asta. 
Fiecare interfață poate fi activată sau trecută în stare de impedanță înaltă - adică echipamentul corespunzător să fie izolat de sistem.
Pe undeva e și o cartelă microSD dar nu apare în schemă. Acolo se varsă datele.


Comenzile sunt selectate de pe panoul utilizator, informațiile sunt afișate pe ecranul VFD și printr-o intefață serială dedicată depanării. 

Sistemul suportă următoarele funcții:
1. Mod "host" - discuta cu unitatea de banda:  interfața pentru bandă este activată, Coralul e izolat, interfata lui STM32 are activate liniile de scriere+control ca iesiri, iar citire+stare ca intrari;
2. mod "drive" - devine unitate de banda:  interfata pentru banda e izolata, coralul e activat, interfata lui STM32 are activate liniile de scriere+control ca intrari iar iesiri sunt citire+stare;
3. mod "bypass" - Coralul discuta direct cu unitatea de bandă, STM32 e izolat. Ceva analizor de date trage cu urechea să povestească și oamenilor cum se iubește Coralul cu banda;
4. mod "monitorizare"/"service":  toate chestiile de depanare sunt activate și încetinesc sistemul. Oricare din cele 3 moduri anterioare sunt monitorizate pentru identificarea de bălării, probleme, belele la nivel de soft, lipsă de bere la proiectarea hardware și așa mai departe.

Toată nebunia vine băgată într-o cutie de rack uite cam așa:


6035941555696266721.jpg

 

 

Editat de skaarj
Link spre comentariu

Semnalele interfetei PERTEC

Interfata asta are 2 conectoare, de obicei denumite J1 si J2,   P1 si P2,  J(P)71 si J(P)72.   Mai exista interfata DB62, cam odata si jumatate mai lunga decat interfata portului paralel si cu gaurile pe 3 randuri.

Uite schema interfeței cu banda și cu Coralul.  E la fel pentru ambele, am doar doi jumperi pentru selectat cu cine discută:

 

databus_inputs_outputs.jpg

 

Cum se cheamă fiecare linie - scrie acolo. Tot acolo e și corespondența de la bornele P1-P2 la DB62. Prăjire de creieri.

Link spre comentariu

Ăsta e primul prototip cu Arduino clasic - Mega 2560 pentru că are o grămadă de picioare. Arhitectură pe 8 biți ca să avem lucrurile cât mai simplu posibil - pentru că comunicarea pe PERTEC e cu dureri de cap. Care a lucrat în depanarea unităților de bandă magnetică poate să confirme că e nenorocire.
Avem acolo și o memorie-tampon de juma de mega:

 

central_processing_unit.jpg

 


Uite așa arată schema de cablaj - durere:

 

PCB_v1.0.jpg

 

Am dat o căruță de bani la Electra să îmi facă două bucăți. După aia am descoperit că am greșit ca ultimul gherțoi și uite așa am aruncat două'j'dă milioane pe geam ca vita. Stau, mă uit la ele și ele se uită la mine. Nu-s bune nici de priponit cloșca.  Sub mufa DB62 am un scurt tare frumos, iar documentațiile toate ziceau că liniile de selecție trebuiesc toate legate la masă. Țeapă. Alea-s așa puse pe pagina de la "Bitsavers"  ca să pună bețe în roate cui o vrea să se joace cu așa ceva.

Editat de skaarj
Link spre comentariu

Materialul magnetic de stocare are lățimea de 12.7 mm adică juma de țol. Ce benzi se mai găsesc acum prin rematuri sunt toate terci, abia citești de pe ele. Dacă încerci să le rescrii, le-ai terminat. Le-ai demagnetizat de tot și nu o să le mai poți folosi în veci. Dar există o soluție:  banda magnetică din casetele VHS.  Am făcut rost de la ceva firmă olandeză (între timp au desființat-o) de 5 calupuri de bandă, fiecare cu 5 kilometri de material din care mi-am bobinat frumos 5 benzi uite așa:

 

 

 

 

 

 


Uite și datele tehnice determinate experimental:

 

Materialul magnetic VHS suportă densitatea de 6250 octeți pe țol numai când mărimea blocului scris este până în 16 octeți (bytes). Cum cresc mărimea blocului, cum începe să toarne erori cu găleata, linia IHER se activează, unitatea de bandă se blochează și trebuie să o instruiesc să-și revină astfel:  pulsez liniile ILOL sau IREW.
Dacă insist să folosesc densitatea de 6250 octeți pe țol la mărimea asta de bloc, e belea mare:  spațiul fizic între blocuri o să fie de 10 ori mai mare decât spațiul fizic ocupat de date. Adică teoretic banda e cam 90% goală.  
Cu densitățile de 32000 și 1600 octeți pe țol funcționează impecabil.

Link spre comentariu

Soar'le mamii lui de Arduino. M-am enervat ca trebuie sa ma apuc iar de proiectare. Nu incercati acasa nici ce vedeti aici, s-ar putea nici astea sa nu functioneze.
Fiecare din interfețele de mai jos o să fie explicate în postările următoare, până atunci uite cum arată cablajele:

Memoria RAM tampon, interfața cu cartela SD și porturile seriale pentru depanare și afișaj pe VFD:

 

8726911546810722001.JPG

 


Interfața bidirecțională cu microcontrollerul STM32:

6030841546810722449.JPG

 

 


Interfața cu banda, interfața cu Coralul:

5812311546810722789.JPG


Aici jumperii JP1/JP2 din stanga-sus selectează cu cine discută.


Placa de bază cu schema aici:  


3379801546810836867.JPG


 

Link spre comentariu

Placa de bază în lucru pe freza CNC:

 

5746981549990255528.jpg

 


Și perifericele de mai devreme:
4212001549991878093.jpg

 


2645161549991919105.jpg

 

7883671549991925921.jpg

 


Și cum arată la expoziție pusă pe capota de la Dacie:

 

7364231550438788650.jpg

 


9843341550438790986.jpg

 


3948061550438791078.jpg

 


443521550438791234.jpg

 

1683891550438791591.jpg

 

2814901550438794257.jpg

 


4626561550438794676.jpg


Aici se pot observa urmele de deș't ale chinezului - nu s-o spălat pe labe și o mânjit pe placă, iar freza mi-o belit cuprul. Să vezi ștrapuri pe porturile ISA ca la nebuni.

 

Link spre comentariu

Dihania o dat primele semne de viață - a trecut cu succes primul test, transferul serial la viteză de 9600 baud spre afișajul VFD  (de-ăla de casă de marcat)

 

2877581550693728949.jpg


Voltmetrul indică tensiunea de alimentare a procesorului.

 

6910041550693729876.jpg

 

4853841550693730958.jpg

 

1278461550693739534.jpg

 


Un pre'ten mi-o vândut un analizor logic de magistrală tip HP1662 cu unul din cabluri lipsă așa că dacă tot mi-am făcut de cap ca la nebuni cu freza, uite ce o ieșit:

 

1405511550694067284.jpg

 

9939231550694068734.jpg

 


474251550694070380.jpg

 


Pe mufele astea o să monitorizeze ce se întâmplă pe magistrala ISA.

Link spre comentariu

Deja o dăm în vrăjitorie level 90000 așa că neapărat toată puterea magică are nevoie de o cutie de unde să se manifeste în mod util asupra Coralului. Are nevoie și de un ecran și niște butoane de butonat.

 

3538441553629333651.jpg


"NU"  adică să nu dau cu freza prin zona aia. Avertizare pentru când sunt prea turbat de somn ca să mai pot judeca omenește.

 

337301553629537708.jpg


Diverse dispuneri ale butoanelor. Au fost mai multe, cel de jos de pe foaia asta pozată a rămas varianta finală.

2 ore de găurit, frezat, jmirgheluit, tăiat....


4065131553630025855.jpg


O ieșit minunea asta.

 

4694341553630026164.jpg

 

7978611553630172099.jpg


Uite și conectoarele. Mainframe = Coralul,  TAPE = banda
Asta e interfața pertec - coșmarul epocii PDP. Nu există nici un fel de semnale de confirmare între calculator și unitate. Informația e pur și simplu scuipată pe magistrală și tot numărul de dresaj are loc din jongleriile pe liniile de control și stare. La partea de soft o să fie cu scandal. Uite cum arată în interior:

 

7335211553630559233.jpg

 

4096911553630559663.jpg

 

De la stânga la dreapta:  sursa ATX, placa procesorului, placa-ridicatoare de la ISA in sus pe 4 conectori de 40 de pini, interfata bidirectionala procesor-sistem, interceptorul de magistrala (are alti 4 conectori de 40 de pini), placa RAM+comunicatii+sdcard, interfata cu coralul, interfata cu unitatea de banda.

 

8990741553630556889.jpg


Asta-i un VFD de casa de marcat. Habar n-am de prin ce tomberon l-am pescuit.

 

1335451553630556097.jpg

 

6489391553630827513.jpg

 

6505671553630837043.jpg

 

6472771553630837015.jpg

 

/RSS_DIR:  "read+status direction" - se schimba intre host si drive;
WCA_DIR:  "write+control+address direction" - si asta isi schimba nivelul intre cele doua moduri.

 

9707601553630838859.jpg

 

Vedere de aproape a cartelei SD, circuitul MAX232 si conectorul RJ45 pentru interfata seriala cu VFD.

 

6051031553630839747.jpg

 

2204081553630830744.jpg


A 2-a mufa RJ45 este pentru consola seriala de depanare.


9594461553630830770.jpg

 

6877051553630831367.jpg

 

Astia sunt bufferii bidirectionali cu conversie de nivel intre 3.3V si 5V.
Toate circuitele o sa fie detaliate in postarile urmatoare.

 

8416221553630831486.jpg


Ledurile de stare ale sistemului.
De la stanga la dreapta: Izolare CORAL, RSS_DIR, WCA_DIR, izolare banda, izolare procesor, 3.3V, 5V, 12V.


6038041553631465305.jpg

 

4473341553631465784.jpg

 

Asta este interceptorul dintre Coral si sistem. In partea din spate sunt doi conectori direct pe cablaj, se cheama "Card Edge" sau "Margine de placa" in engleza si asa se gasesc si in Eagle. Aia e intrarea. Iesirile J1 si J2 se duc in conectorul din fundul cutiei marcat cu "mainframe" in marker negru si nitel sters.
Pe interceptorul asta se observa 4 conectori de 40 de pini - la fel cum e IDE din fundul hardurilor vechi. Prin mufele alea pot inspecta traficul folosind analizorul logic HP1662. Tot cu analizorul asta pot sa vad cum sta treaba si in sistem si la iesire spre unitatea de banda. Asa pot sa urmaresc orice erori in operare.

 

 

Gata cu vorbaraia, acu' petrecere cu biți și grafice:

 

5447751553631753058.jpg


Randurile alea cu liniute marcate cu A1...A4 corespund celor 4 conectori ai analizorului. Cand vreo liniuta e in sus, indica "1". Cand e jos am zero. Simplu.

Intefata Pertec foloseste logica inversa, adica zero volti masurati inseamna 1 logic sau valoarea "adevarat". Din momentul asta este foarte important ce bere bag pe gât ca să deslușesc sensul datelor în fluxul inversat. Gata de-acuma e totul în ceață.

 

5762951553631754291.jpg


Animalu ăsta are ditai manualul de vreo 800 de pagini care vine cu o tonă de dureri de cap, până nu trec prin el să-l învăț din copertă în copertă nu o să fiu în stare să fac nimic.


2303221553631755115.jpg


Chestia asta n-a mai fost văzută de vreo 40 de ani:  fluxul unui transfer de date pe interfața Pertec.

 

1965231553631755516.jpg

 

5162621553631755832.jpg

 

Liniile de scriere în timpul arhivării directorului /etc în Unix, folosind un convertor pertec-scsi construit pe genunchi.

Link spre comentariu


Postarea asta o să fie cu dureri de cap pentru că aici intrăm deja pe tărâmul softului: definițiile și explicațiile semnalelor pe magistrala PERTEC.
Treaba e în engleză că asta e linba programatorilor moderni:

Următoarele semnale corespund tuturor unităților de bandă pe 9 piste (atenție NU PE 7) cu densități de 1600, 3200 si 6250 octeți pe țol, cu stocarea și în codificare pe fază (PE) și pe Codificare pe grupări de fuxuri (GCR):

/* test write  IW0....IW7
                            [W7] [W6] [W5] [W4] [W3] [W2] [W1] [W0]  
                     15  14  13  12  11  10   9   8   7    6    5    4    3    2    1    0
         PB   0   0   0   0   0   0   0   0   0    0    0    0    0    0    0    0
  [WRITE]                                 X    X    X    X    X    X    X    X
 [WRMASK] 1   1   1   1   1   1   1   1   0    0    0    0    0    0    0    0
    WRMASK = 0b1111111100000000 = 0xFF00;
*/
        
// Liniile sunt ordonate in stil IBM aidca Bit 0 = MSB, 
// Bit 7 = LSB

/*   test IWP   PB8
                                    [WP]
         15  14  13  12  11  10   9   8   7   6   5   4   3   2   1   0
     PB   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
 [IWP]                                X   
 [WRMASK] 1   1   1   1   1   1   1   0   1   1   1   1   1   1   1   1

WPMASK = 0b1111111011111111 = 0xFEFF;
    
*/
// IWP  Write parity - odd parity computed over IW0–IW7 
// and on some drives is ignored and computed by the formatter.



// CONTROL SIGNALS
// Activated by the controller/mainframe side - operations 
// for the drive to execute

/* test CTRL0  PB9...PB15 
       HISP EDIT WFM ERASE REV  WRT LWD
         15  14   13  12    11  10   9   8   7   6   5   4   3   2   1   0
     PB   0   0    0   0     0   0   0   0   0   0   0   0   0   0   0   0
  [CTRL0] X   X    X   X     X   X   X                
 [C0MASK] 0   0    0   0     0   0   0   1   1   1   1   1   1   1   1   1
    C0MASK = 0b0000000111111111 = 0x1FF
*/

#define ILWD    0x200  //  Last word—Used to tell drive that this is 
                       // the last word (byte) to be written 
                       //  in this record, Must be asserted at least 
                       // 300 nsec. before trailing edge of final 
                        //  IWSTR pulse.  
                                     
#define IWRT 0x400   // Write — When asserted with IGO begins a write sequence.

#define IREV    0x800   // Reverse — When asserted, indicates operation is 
                        // to be performed in the reverse direction.
                                        
#define IERASE 0x1000 // Erase—When asserted with IWRT and IGO, 
                      // causes tape to be erased, usually for a
                      // predetermined length. Usually used to 
                      // recover from write errors or provide extra 
                      // space for mode changes (Read after write).
                                            
#define IWFM 0x2000   //  Write filemark; When asserted with 
                      // IWRT, writes a filemark.

#define IEDIT 0x4000  // Edit—Not implmented on all drives.
                      // modifies/updates records inside tape files.

#define IHISP 0x8000  // High speed select—When asserted 1 µsec. before 
                      // and then with IGO (de-asserted any time after 
                       // the trailing edge of IGO selects high-speed 
                        // (streaming) mode.

/*
  test CTRL1  
                                               RTH1 RTH2 REW RWU LOL GO  
        15  14  13  12  11  10   9   8   7   6   5   4   3   2   1   0
    PC   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[CTRL1]                                          X   X   X   X   X   X
[C1MASK] 1   1   1   1   1   1   1   1   1   1   0   0   0   0   0   0
[C1MASK = 0b1111111111000000 = 0xFFC0
*/

//CTRL1:

#define IGO   0x01  // Initiate command—Pulsed low for at least 1µsec. 
                    // to start command execution. The formatter address 
                    // lines must be stable throughout the pulse and 
                    // until IFBY drops.
                                        
#define ILOL  0x02  // Load on-line—Pulsing this line at least 1µsec. 
                    // begins the tape load sequence on many drives.

#define IRWU  0x04 //  Rewind and unload—A pulse of at least 1 µsec. 
                    // initiates a rewind-with-unload and sets
                   // drive offline. Some drives require that IREW is 
                   // also asserted.
                                        
#define IREW  0x08 // Rewind—A pulse of at least 1 µn;sec. starts the 
                   // tape rewind sequence. Completion is 
            // // signalled by IRWD and IRDY being asserted by the drive.
                                        
#define IRTH2 0x10 //  Write density select 2—On some drives, this signal, 
                   // along with IRTH1 is used to 
                   // select the drive write density. If it is implemented, 
                   // it is valid only at BOT and must be asserted with IGO 
                    // during the first write sequence.                                    
#define IRTH1 0x20      //    


/* test ADDR 
                                                         FEN TAD1 TAD0 FAD
          15  14  13  12  11  10   9   8   7   6   5   4   3   2   1   0
     PF    0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ADDR]                                                     X   X   X   X
[ADDRMASK] 1   1   1   1   1   1   1   1   1   1   1   1   0   0   0   0
 ADDRMASK = 0b1111111111110000 = 0xFFF0
*/

#define IFAD  0x01  // PF0    Formatter address
#define ITAD0 0x02 // PF1 Transport address bit 0 (MSB!)—Used to address 
                    // multiple drives on a single controller.
#define ITAD1 0x04 // PF2   Transport address bit 1 (LSB!)
#define IFEN  0x08 // PF3 Formatter enable — This signal should normally 
                   // be asserted all the time. 
                  //  If dropped for a minimum of 2 µsec., aborts any 
                  // comman that asserts IDBY 
                  // (I/O, skip, but not rewind or unload).

// #########################################################

/* test READ  
                                          [R7] [R6] [R5] [R4] [R3] [R2] [R1] [R0]                
          15  14  13  12  11  10   9   8   7    6    5    4    3    2    1    0
     PE    0   0   0   0   0   0   0   0   0    0    0    0    0    0    0    0
   [READ]                                  X    X    X    X    X    X    X    X
[READMASK] 1   1   1   1   1   1   1   1   0    0    0    0    0    0    0    0
 READMASK = 0b1111111100000000 = 0xFF00
*/
// Liniile de citire, ordonare IBM - Bit 0 = MSB, Bit 7 = LSB
#define IR0    0x01
#define IR1    0x02
#define IR2    0x04
#define IR3    0x08
#define IR4    0x10
#define IR5    0x20
#define IR6    0x40
#define IR7    0x80

/* test RP 
                                     [RP]               
          15  14  13  12  11  10   9   8   7    6    5    4    3    2    1    0
     PE    0   0   0   0   0   0   0   0   0    0    0    0    0    0    0    0
    [RP]                               X   
  [RPMASK] 1   1   1   1   1   1   1   0   1    1    1    1    1    1    1    1
 RPMASK = 0b1111111011111111 = 0xFEFF
*/

#define IRP    0x100  // read parity

/* test STAT0  
         RSTR DBY DENT FMK CER HER FBY                                              
           15  14   13  12  11  10   9   8   7    6    5    4    3    2    1    0
      PE    0   0    0   0   0   0   0   0   0    0    0    0    0    0    0    0
  [STAT0]   X   X    X   X   X   X   X   
[STAT0MASK] 0   0    0   0   0   0   0   1   1    1    1    1    1    1    1    1 
 STAT0MASK = 0b0000000111111111 = 0x1FF
*/

// Status lines -  reports sent by the drive

#define IFBY    0x200    //  Forrmatter busy — Set by trailing edge of IGO, 
            // clears when command finished (but you can send a new command 
                    //as soon as IDBY clears)

#define IHER    0x400    //   Hard error — Pulsed during IDBY when a hard 
                        // data error (or illegal character in the IRG) is 
                        // seen.
                      // Note that most modern formatters correct this error 
                        // automatically.

#define ICER    0x800    //  Corrected error — This signal is pulsed during 
                         // IDBY when a single-track dropout is successfully 
                         // corrected using the parity information.

#define IFMK    0x1000    //  File mark—Pulsed during IDBY when a tape mark 
                          // is seen.
#define IDENT   0x2000    //  Identification—Asserted while drive is actually 
                      // reading the PE ID burst, dropped the rest of the 
                      // time so it's up to the controller to catch it and 
                      //remember.

#define IDBY  0x4000  //  Data busy—This signal is asserted during I/O phase 
                      // of read or write commands. It generally lags a few 
                      // milliseconds after the drive asserts IFBY.

#define IRSTR  0x8000  // Read strobe—Pulses low for at least 200 nsec. when 
                        // data on IR0-IR7 and IRP are stable before leading 
                        // edge; typically held for 200 nsec. but this is 
                        // not a requirement. Note that data is made available
                        // there is no check made to ensure that the host has 
                        // picked it up.

/* test STAT1     !!!! LDP - load point / BOT
                                   SGL WSTR RWD FPT SPEED ONL HIDEN  RDY  LDP  EOT
           15  14   13  12  11  10   9   8   7    6    5    4    3    2    1    0
      PI    0   0    0   0   0   0   0   0   0    0    0    0    0    0    0    0
  [STAT1]                            X   X   X    X    X    X    X    X    X    X                                      
[STAT1MASK] 1   1    1   1   1   1   0   0   0    0    0    0    0    0    0    0
 STAT1MASK = 0b1111110000000000 = 0xFC00
*/

#define IEOT    0x01   //End of tape — Asserted whenever the tape is past 
                       // the EOT marker, clears when the tape is 
                       // backspaced past it.
                                         
#define ILDP    0x02   // Load point — Asserted whenever the tape is at the 
                        // load point      
                                            
#define IRDY    0x04    // Ready — Signals that tape is fully loaded, on-line 
                        // and not rewinding. This must be asserted by the 
                        // drive before it will accept any command.

#define IHIDEN    0x08    // High density mode 

#define IONL    0x10    //  Online — Asserted when the drive is online; clears 
                        // within 1 µsec. of being taken offline.

#define ISPEED    0x20    // High-speed — This signal is asserted when commands 
                          // are executing in high-speed mode; that is when 
                          // the drive is not operating in start-stop mode.
                                            
#define IFPT    0x40    //  File protect — This signal is asserted continuously 
                        // when the tape is not write-enabled
                        // No ring - no write.
                                            
#define IRWD    0x80    // Rewinding — This is asserted by the drive while the 
                        // tape is rewinding.

#define IWSTR    0x100  //  Write strobe — Pulses low for at least 200 nsec. 
                        // when the drive is ready to accept data. This is 
                        // roughly similar to an "Acknowledge" signal after 
                        // data has been received. The next data byte can be 
                        // presented immediately.
                                            
#define ISGL    0x200    // Selected drive fault on some drives; not connected 
                         // on others. If used, it is cleared by 
                         // de-asserting, then reasserting IFEN.

Atenție că interfața Pertec folosește logică inversată, adică dacă un semnal e la +5V se consideră "fals" sau valoarea "zero", și când a coborât la zero volți e considerat "adevărat" sau valoarea "unu".

 

Analiza următoare demonstrează ce se întâmplă în timpul operației de citire a benzii:

Presupunând că unitatea de bandă este online (IONL = 0V) și gata de lucru (IRDY = 0V), Coralul pulsează linia "IGO". La pornire, unitatea de bandă magnetică coboară linia IFBY (0V) și după ce rolele ajung la viteza operațională de rotire, IDBY este coborât (0V). Când datele sunt gata de preluare pe liniile IR0...IR7+IRP, linia IRSTR coboară pentru aproximativ 0.8 microsecunde. După 1.2 microsecunde este din nou coborât semnalizând că din nou următorul set de date (8 biți + un bit de paritate) este disponibil pentru preluare în Coral.


9315941555700751455.jpg

 

La sfârșitul fiecărui bloc de date, IDBY se ridică (+5V - valoare fals sau zero) și unitatea de bandă magnetică acceptă o nouă comandă.

 

4042201555700751631.jpg

 

Sfârșitul unui fișier este indicat prin pulsarea liniei IFMK.

Recapitulare pe foaie:


7976581555700749664.jpg

 

După ce IDBY se ridică, urmează un scurt interval de timp după care se ridică și IFBY. Acest interval este folosit de CORAL să reinstruiască unitatea de bandă pentru o nouă operație. Dacă CORAL dorește citire continuă până la sfărșitul datelor de pe bandă (semnalizat de 2 pulsuri succesive IFMK), atunci IGO trebuie pulsat în acest timp. Dacă din anume motive (defectiuni) Coralul nu apucă să își manifeste dorința în acest interval de timp, unitatea va roti banda până la sfârșitul ultimului bloc citit, se va opri și va aștepta o nouă comandă, apoi va începe să rotească iar rolele până la viteza operațională. Acest proces consumă o grămadă de timp și crește artificial uzura benzii - mai ales când CORALUL are vreo dambla pe la liniile de întrerupere și încearcă să comunice cu banda.

 

9591241555701311486.jpg


Sfârșit de date - a nu se confunda cu sfârșitul benzii (IEOT) - e semnalizat de o a 2-a pulsare a IFMK și un buffer de citire gol. Unitatea așteaptă o nouă comandă. Dacă CORAL vrea să adauge date pe bandă, va semnaliza unității de bandă următoarele:   înapoi un bloc (ăla gol din grafic), șterge al 2-lea filemark, scrie chestiile, pulsează IFMK (sfarsit de fisier), apoi mai pulsează unu (sfarsit de date). Echivalent cu inchiderea sesiunii de scriere la CD si DVD.
 

Link spre comentariu

Nu știu ce să zic din punct de vedere tehnic, m-ai lăsat paf cu cate ai făcut și mă bucurcă că ai revenit cu astfel de postări. Nu știu dacă-l mai ai dar cred că și domnul Cucu (păsăroiul) se bucura daca vedea așa ceva.

 

Spor!

Editat de Stefan
Link spre comentariu

Waww! Impresionant ce faci tu aici! 
Vazand titlul topicului, primul lucru venit in minte a fost Domnul Cucu si chiar vroiam sa intreb ce spune de treaba asta, dar Stefan a fost mai iute!

Sa ai spor si succes!

Link spre comentariu

Domnilor, domnu Cucu dă din aripioare și ciugule pe ecranul VFD, cam atâta e în stare să facă. A, și mai toarnă covrigei pe placa de bază cacarisind tot ce prinde. Între timp am avut și bufniță, ciugulea lămpile aprinse pe întuneric. N-am prea avut timp de păsăroi, am fost mult timp plecat pe coclauri cu forajul.  Da' am revenit cu nebunii interesante. Poate de-acu mai aterizează vreun nou Cucu pe la mine prin atelier.

 

Memoria RAM tampon

Ei bine avem o problemă: diferențe între viteza de acces a benzii și viteza de acces a cartelei SD. Plus că cartela SD e o chinezărie mizerabilă: ba merge, ba nu merge, ba refuză să meargă, ba dacă o frec încărcând direct octet cu octet se duce naibii și trebie alta. De obicei bagă întârzieri și nu apuc să prind următoarea citire din bandă. Trebuie ceva să aibă răbdare cu banda, apoi să verse tot fluxul de date pe cartela SD dintr-un foc, fără bâlbâieli și complicații.


Cu metoda tradițională se pierde o grămadă de timp:
- citire continuă a liniilor GPIO sperând că se schimbă ceva în starea lor;
- stochează valoarea în ceva variabilă;
- conversie din format IBM folosind ori niște matematică (puștanii de azi deja au luat-o la fugă), ori tabelă de corespondență (mai rapid), inversează octetul;
- lipește octetul la sfârșitul unui șir de caractere;
- varsă șirul de caractere pe microSD la sfârșitul fiecărui bloc;
- încearcă să prinzi o nouă citire fără să pierzi datele dacă toate cele de mai sus durează mai mult de 1.2 microsecunde.

 

Nașpa, nu?

 

Uite ce se poate face ca să reducem din întârzieri:


1. PERTEC funcționează în logică inversată (0V = adevărat, 5V = fals). Asta permite folosirea de cabluri lungi și nu prea e influențat de zgomote, dar necesită ceva atenție la nivel software (inversarea octetului: fals să fie adevarat și vițăvercea) care papă din ciclurile de procesor - bagă întârzieri la comunicarea cu banda - așa că fiecare buffer conține circuitul integrat sovietic 555AP9 (echivalentul militar al lui 74LS642). Chestia asta inversează automat biții datelor (deci nici pe analizorul logic nu-mi mai sparg creierii descifrând) deci elimin operația asta din software.


Am încercat circuitele normale:
- neinversoare din seria 74 - 245, 74 - 641;
- inversoare din seria 74 - 640, 74 - 642.
Și variantele SMD, și THT.


Din toate variantele mi-a iesit vălătuci de fum. Ori Farnell, Mauser și TME mi-au vandut câte o găleată de gunoaie - EXCLUS, ăștia duc seriozitatea la extrem, nu-s cadre de Partid - ori sovieticii au avut o variantă mai bună. Nu stiu ce s-a întâmplat. Merg pe mâna rușilor.

 

Cu asta am salvat o grămadă de cicluri de procesor, sarcina de inversare fiind preluată la nivel hardware.

 

 

2. Construirea unui banc de memorie RAM folosind 16 x 23LCV1024 (128 kilo octeți) memorie SRAM cu acces rapid:

 

3449001555704708497.jpg


Eu nu folosesc unități comerciale de măsură. Astea sunt blasfemii și minciuni gogonate ce jignesc tehnica. Un MEGABIT numără chestii iluzorii care să păcălească lumea. Este o unitate de măsură publicitară care te fraierește cât de mișto e să vezi rata de transfer mai mare și mai rapidă decât în realitate.

 

4120351555704946486.jpg

 

Un MEGABIT e un fel de Viagra sub formă de picături:  îți torni nițel în ochi și ți-o vezi de 8 ori mai mare.

 

Un MEGA BYTE măsoară o cantitate de 1024 de octeți utilă în calculele logice și reprezintă 1/8 dintr-un așa-zis mega(viagra)bit. Franțujii sunt jmecheri că zic mereu "Mega Octet" ca să nu păcălească lumea. Respect.

 

Deci 23LCV1024 conține 128 de kilo octeți - ăsta e de fapt marele și minunatul Megabit care reprezintă cam 1/8, sau 35% dintr-o amărâtă de disketă veche de 1.44MB.

 

Am făcut un banc de memorie cu capacitatea de 2 mega-octeți folosind 16 circuite de-astea jmechere și o metodă de adresare și mai jmecheră cu port expander. Fanii PIC, Atmega și Arduino știu ce-i ăla.

 

9196501555704947239.jpg

 

Asta e bufferul RAM + stocarea pe microSD + comunicatiile seriale (vfd si consola de depanare).

Adresarea e facuta cu un port-expander MCP23S17, interfata SPI, deci am salvat 13 pini din procesor.  16 pini de selectie + 3 pt interfata SPI fara port-expander (19 total), sau 6 pini SPI cu port-expanderul. 
Daca vreau mai mult RAM, mai bag un port-expander si mai folosesc 3 pini din procesor. Simplu.
Nu m-am aruncat la FPGA ca trebuia sa-mi vand dacia.

 

3.  Am definit si 2 canale DMA ca sa obtin viteza maxima de transfer din aceste 23LCV1024 -  mai degraba ar trebui sa fie denumite 23LCV128k ca sa nu mai fraiereasca lumea de pomana. Problema e ca adresarea cu port-expander nu suporta DMA. Testat la nivel de soft.

 

4. Intreruperi - cosmarul tuturor in facultate. STM32 trateaza liniile 9...15 cu aceeasi prioritate, nu pot fi diferentiate. Aici sa vezi bataie de cap.

_____________________________

6827431555705039595.jpg


Bufferul bidirectional diferențial (3.3V-5V) pentru procesor
De la stanga la dreapta, funcțiile circuitelor:
Scriere, scriere paritate+control, control, citire, citire paritate+stare, stare0, stare1, adresare.

 

5454711555705039778.jpg

 

Gruparea pe fiecare circuit e definită în postarea anterioară.
 

 

 

Modul HOST - cum discută de fapt CORALUL cu unitatea de bandă

 

1. Stabilirea comunicatiei cu unitatea - urmatorii pasi sunt necesari:


- selectarea unității de bandă folosind liniile ITAD (adresă transport 0 și adresă transport 1);
- pulsare IFAD (adresarea interfeței) cu durata de câteva microsecunde pentru a abandona orice posibilă operație întreruptibilă efectuată de unitatea de bandă;
- pulsarea liniei IREW pentru a fi sigur că unitatea de bandă stă la început (BOT - begin of tape, începutul benzii);
- selectarea densității - 1600 octeți pe țol de data asta - astfel:  IFWM, IEDIT, IERASE jos în același timp, pulsat IGO, apoi ăștia trei înapoi sus.

Unitatea de bandă trebuie să răspundă activând următoarele linii de stare - presupunând că avem o bandă deja încărcată în unitate:
IONL (online) (ori automat, ori activat manual din vreun buton), IRDY ("ready"), ILDP ("load point", BOT sau început de bandă), IFPT dacă protecția la scriere a fost activată manual din vreun alt buton.

 

 

2. Pornirea transferului de date


Transferul începe când unitatea primește un puls pe linia IGO, iar restul e descris în postarea de mai devreme: interceptează IRSTR, IDBY, IFBY și IFMK folosind linii prioritizate de întrerupere, umple un buffer de 32kB (mărimea maximă specificată în toate driverele MsDos pentru controllere PERTEC), varsă datele în bancul RAM folosind canale DMA. De fiecare dată când ramul de 2MB se umple, citirea e suspendată iar unitatea de bandă se poziționează automat la sfârșitul ultimului bloc citit. Cât timp unitatea așteaptă pulsarea IGO, ramul este vărsat pe SDCARD folosind alt canal DMA, ramul este apoi resetat și transferul de pe bandă se reia în RAM începând cu circuitul 1, locația zero de memorie. Toată manevra asta se întâmplă până când EOT sau 2 FMK consecutivi sunt semnalizati de unitate.

 

 

3. Stocarea dateleor ori pentru distracție/inspecție/muzeu, ori pentru folosirea efectivă în CORAL:

 

Hai să presupunem ca am găsit o bandă de vreo 40 MB, 9 piste, densitate 1600 octeti pe țol cu ceva planuri sovietice de construcție a celui mai jmecher tractor agricol din lume, care luat la pilă devine avion supersonic cu reacție. Pot ori să mă holbez la date - nimeni nu le mai are în formatul original - ori pot să le încarc în CORAL ca să am acces la planurile secrete.


Pentru prima variantă nu e nevoie să păstrăm și separația în blocuri și fișiere.

 

Dar dacă vreau să-mi fac tractorul meu cu care să iau în stăpânire toate fosturile colhozuri, eventual iau lansetele și să zbor cu el în vacanță până la prima gârlă cu pește (vise la ce accize au băgat hoții ăștia pe combustibili) trebuie să fac cumva rost și de dispunerea în blocuri și fișiere, să creez o hartă a lor și să le replic pulsând liniile PERTEC corespunzătoare de pe interfață în timp ce joc în campionatul "DRIVE".


4. Intră în scenă SIMH Emulator - http://simh.trailing-edge.com/  - un set de programe care simulează virtual o grămadă calculatoare celebre de pe timpurile alea. Au formatul lor propriu de reprezentare a imaginilor de bandă ca fisiere pe hardisc, stic sau cartelă SD. Formatul lor - http://simh.trailing-edge.com/docs/simh_magtape.pdf - specifică cum că fiecare bloc este încadrat între 2 descriptori care zic detalii despre ce a fost vorba în blocul anterior și despre ce e vorba în blocul curent.

Formatul de l-am implementat - ușor modificat față de standard să compensez gărgăunii coralului - arată așa:

 

---------|--------|---------------|--------|---------------|--------|---------------|--------|---------------|--------|
         |        |               |        |               |        |               |        |               |        |
DATA/BOT | BLKINF |     DATA      | BLKINF |     DATA      | BLKINF |     DATA      | BLKINF |     DATA      | BLKINF |
         |64 bits |               |64 bits |               |64 bits |               |64 bits |               |64 bits | 
---------|--------|---------------|--------|---------------|--------|---------------|--------|---------------|--------|

BLKINF - bloc cu informații. Se inserează înainte și după fiecare bloc de date.

Formatul blocului informativ arată așa:

 

|-------------|------------|
|             |            |
| info prev   |  info next |
|     block   |   block    |
|   32 bits   |   32 bits  |
|-------------|------------|

Fiecare bloc de 64 de biți este împărțit in 2, fiecare parte descrie ce a fost și ce va fi să fie:
- există sfârșit de fișier? (FMK=1, bit 31);
- există vreo eroare în bloc determinată de procesul de recuperare de pe bandă? (ERR=1, bit 30);
- e ăsta cumva ultimul bloc de pe bandă? (EOD = 1, bit 29)
- biți trecuți pe zero, rezervați daca cumva în viitor mai am nevoie să adaug vreun alt detaliu, îi las liberi aici altfel modific de-mi sar neuronii pe geam(biti 28-24);
- Câti octeți trebuiesc citiți (înainte sau înapoi)? (BLK LEN, biții 23->0).

 

        FMK    ERR   EOD    ZERO     BLK_LEN
           31     30    29    28->24    23->0
FMKMASK    0       1    1     1 -> 1     1->1 FMKMASK = 0x7FFFFFFF
ERRMASK    1       0    1     1 -> 1     1->1 ERRMASK = 0xBFFFFFFF
EODMASK    1       1    0     1 -> 1     1->1 EODMASK = 0xDFFFFFFF
BLKMASK    1       1    1     1 -> 1     0->0 BLKMASK = 0xFF000000

 

Mai am ceva belele și la tranziția între circuitele propriu-zise din bancul de memorie, să nu-mi mănânce vreo literă pe drum să-mi corupă tractoru. Nu am nici un fel de control hardware al adresării, totul se întâmplă la nivel de soft. 
Chestia de mai jos explică cum primii descriptori sunt încărcați din RAM în memoria microcontrollerului STM32:
(atenție la numărul de linii din fiecare bucată de program - teroare - indică fiecare funcție apelată din soft, de la care bucată de program, de la care rând, să știu unde mă uit când face figuri, dă chix sau strâmbă din bot)
 

drive_rewind()@tape.c line3701: extract INIT PREVREC:
rambuf_rec_extract()@spiram.c line2851: extract RECORD

ram_extract(spiram.c@line2642): startaddr@0 cbank=0 cpos=0 length=4 free=131071, RAMPOS= 0, RAM_FULL = 0

ram_extract(read@spiram.c line2664): length(4) < free(131071) reading from memory bank 0x0, startaddr=0 cpos=0 length=4 free=131071, RAMPOS= 4
 0x0  0x0  0x0  0x0

rambuf_rec_extract()@spiram.c line2886: FMK=0x0; ERR=0x0; EOD=0x0; BLK=0x0; RECORD=0x0

drive_rewind()@tape.c line3704: init PREVREC:  fmk = 0, err = 0, eod = 0, blklen = 0
#####################################

drive_rewind()@tape.c line3710: extract INIT CUR_REC:
rambuf_rec_extract()@spiram.c line2851: extract RECORD

ram_extract(spiram.c@line2642): startaddr@4 cbank=0 cpos=4 length=4 free=131067, RAMPOS= 4, RAM_FULL = 0
▒)$

ram_extract(read@spiram.c line2664): length(4) < free(131067) reading from memory bank 0x0, startaddr=4 cpos=4 length=4 free=131067, RAMPOS= 8
 0xA0  0x16  0x29  0x24

rambuf_rec_extract()@spiram.c line2886: FMK=0x1; ERR=0x0; EOD=0x1; BLK=0x162924; RECORD=0xA0162924

drive_rewind()@tape.c line3713: init CURREC:  fmk = 1, err = 0, eod = 1, blklen = 0x162924, total_tape_length = 1,452,324 BYTES
##############################

drive_rewind()@tape.c line3718: extract 1st PREVREC:
rambuf_rec_extract()@spiram.c line2851: extract RECORD
ram_extract(spiram.c@line2642): startaddr@8 cbank=0 cpos=8 length=4 free=131063, RAMPOS= 8, RAM_FULL = 0

ram_extract(read@spiram.c line2664): length(4) < free(131063) reading from memory bank 0x0, startaddr=8 cpos=8 length=4 free=131063, RAMPOS= 12
 0x80  0x0  0x0  0x0
rambuf_rec_extract()@spiram.c line2886: FMK=0x1; ERR=0x0; EOD=0x0; BLK=0x0; RECORD=0x80000000
drive_rewind()@tape.c line3724: virtual streamer RDY. @start_mainframe() sistemul asteapta /IGO, citeste CURREC, transmite blocul de date si citeste PREVREC.

 

 

Uite un screenshot cu 2 imagini ale aceleiași benzi. În stânga sunt datele de pe suprafața benzii, în dreapta sunt datele și descriptorii după ce banda a fost copiată de sistem pe cartela microSD. Datele sunt completate cu spații ("0x20" în hexazecimal) pentru a fi încadrate în lungimile fixe specifice formatului benzilor.

 

9063911560527274234.png

 

Hai sa vedem logul ăla și primii 128 de octeți din poza asta:

 

Pe coloana din partea dreaptă începând cu adresa 0x00000000 - începutul imaginii în format SIMH modificat - citim pe partea de cifre: 

                             HEX                     BIN                   Activated bits
înregistrare anterioară:  00 00 00 00  00000000000000000000000000000000   nimic. înregistrare anterioară inițială

înregistrare curentă:     A0 16 29 24  10100000000101100010100100100100   FMK=1 EOD=1 BLKLEN = 0x162924(HEX) adică capacitatea totală a datelor clonate de pe banda originală și simulată este de 1,452,324 octeți sau aproximativ o disketă de 3.5", 1.44 MB 

înregistrare anterioară: 80 00 00 00  10000000000000000000000000000000   ăsta a fost un separator de fișier cu bloc de date de lungime zero

înregistrare curentă:     00 00 00 50  00000000000000000000000010100000    urmeaza un bloc cu lungime de 80 de octeți, uite-l: 
VOL1VOL0010 [22 x "spațiu"] VASEA_____BURU [23 x "spațiu"]   total = 80 octeți

Daca ne uităm la headerul de date observăm că în trecut unu de-l cheamă "Vasili Duru" o venit de la departamentul de electronică la centrul de calcul al uzinei  și a scris o bandă conținând ceva fișiere într-un format vechi, datele au fost considerate valide pentru 1402 zile, versiunea 1, generația (varianta) 1 a documentelor. Lungimea blocului selectată de sistemul de operare este de 512 octeți împărțiți în câte 2 sectoare de 256 de octeți. Mai observăm că banda conține o arhivă cu formatul descris de standardul POSIX.1-1988 sub numele de "USTAR". 
Vino încoa cu o ladă de bere și îți povestesc mai multe, eventual ne luăm zborul cu tractorul.

Editat de skaarj
domnu Cucu
Link spre comentariu

Toate detaliile rupătoare de creier de mai sus sunt descrise aici în filmul ăsta  (domnu Cucu din când în când mai ciugulește păianjănu verde de se plimbă pe VFD în timpul transferului):

 

 

 

Domnii veterani în ale electronicii care ați lucrat cu așa ceva: îmi mențin rugămintea:  vă rog frumos, dacă știți pe undeva astfel de dinozauri, dați-mi de știre și o mână de ajutor să-i pot recupera. Am demonstrat aici că pot să-i fac să meargă.

Editat de skaarj
Link spre comentariu

Proiectul este momentan legat de gard. Reproiectez toate placile care urmeaza sa fie date in executie la Iasi la Electra.

 

Intre timp va rog sticky ca e de referință pentru următorii ani și de asemenea dă peste nas altor forumuri "cu mușchi".

Link spre comentariu

De ce nu incercati sa comandati in China PCB-urile? executie in 24 de ore, calitate excelenta, preturi sigur mai mici ca in tara chiar daca transportul este facut cu un curier rapid, etc

Link spre comentariu

Creează un cont sau autentifică-te pentru a adăuga comentariu

Trebuie să fi un membru pentru a putea lăsa un comentariu.

Creează un cont

Înregistrează-te pentru un nou cont în comunitatea nostră. Este simplu!

Înregistrează un nou cont

Autentificare

Ai deja un cont? Autentifică-te aici.

Autentifică-te acum
×
×
  • Creează nouă...

Informații Importante

Am plasat cookie-uri pe dispozitivul tău pentru a îmbunătății navigarea pe acest site. Poți modifica setările cookie, altfel considerăm că ești de acord să continui.Termeni de Utilizare si Ghidări