Svenska ElektronikForumet

Nu ska vi inte fylla Mattis tråd med OT, men jag kan inte se vad en jordfelsbrytare skulle tillföra när man har en isolationstrafo. En jordfelsbytare skyddar ju om strömmen tar fel väg, det vill säga om strömmen i N skiljer från L. Det får man typisk om man ström går från en av dem till jord. Har man en isolationstrafo så kan det aldrig gå någon ström till jord, om man inte skapar en själv, vilket verkar vara kontraproduktivt.

Sant, halva poängen med isolertrafo försvinner om man ansluter den till jord. Dock med t.ex. mittuttag anslutet till jord så får man lägre spänning mellan jord och strömförande del och kan då använda jordfelsbrytare som löser ut vid lägre felström. Det kan väl ungefär vara bra ifall det finns risk för flera fel samtidigt.

Nu kom extender korten jag ritat i Kicad. Testade några att de passade fysiskt så på den punkten hade jag inte gjort bort mig. Borde väl inte vara några elektriska fel hoppas jag…

Återstår att löda på donen. Några är på väg från Mouser andra har jag redan.

Snyggt!

Tackar!

Jag fick kontaktdonen från Mouser och lyckades efter en hel pill löda löss ett kontaktdon jag fick med maskinen. Föregående ägare skickade med ett extenderkort för någon Ampex-produkt som var alldeles för kort men som i alla fall hade rätt kontaktdon.

Tydligen hade jag gjort en liten miss med layouten. Men det var inget som inte en bågfil kunde lösa lite snabbt.
Det ursprungliga problemet var ju att när man trycker på RESTART-knappen ska den först spola tillbaka bandet och därefter läsa bandet från början. Den spolade aldrig tillbaka bandet utan började spela upp från början direkt. Nu kunde jag mäta lite på kort A3 som är demodulator-kortet.
Signalen REBOOT skapas på kort A9 när man trycker på RESTART-knappen. Den går igenom ett par vippor clockade med signalen CLOCK och kommer till en vipp Z38 och sätter den till aktiv. Det är bara det att signalen END OF TAPE också visade sig vara aktiv samtidigt så den gjorde knappt någon rewind. END OF TAPE skapas på kort A2 genom att välja ut en av två signaler från antingen den främre eller bakre kassette-driven.
Trodde först att det var fel på lampan. Men den glimmade fint. En liten miniatyrlampa placerad inuti kassett-guide-pinnen... Den till vänster i bild.
Lampan lyser på en LDR. Testade att stoppa olika tjocka pappersbitar i vägen för lampan och det gick verkligen att blockera så att man fick END OF TAPE inaktiv. Bara det att man behövde ganska mycket papper. Kunde det vara så att den ljudkassett som jag testade med hade ett band som var för tunt och släppte igenom för mycket ljus?
Precis så var det! Testade med en original data-kassett och visst fungerade det! Den spolade tillbaka fint och började spela en kort stund. Hmm. Kanske att det fungerar alltså? Nu måste jag bara ha en kassett med boot-bart innehåll!

På bitsavers finns ett antal kassett-avbilder i så kallat .TAP-format. Jag har tidigare gått igenom dessa och bootat dem i min Datapoint 2200 emulator. En del av dem var bootbara. Tex hrmtst_3-75.tap eller endure1.6_7-73.tap verkar vara lämpliga att börja med. Två väldigt korta program som gör någon form av tester.

Planen är att koppla in en en STM32 mikro-controller att driva en signal genom läshuvudet på en vanlig ljudkassettebandspelare och på det sättet skriva ett boot-bart band från dessa .TAP-avbilder. Alternativtet skulle vara att använda de två kassette-drivar som sitter i maskinen. Vet inte riktigt vad som är det bästa. Men provar med ljudkassettebandspelare först.

Du kan inte använda en sådan där kassett som man hade i bilen för att koppla in en portabel CD-spelare?

Kul att det går framåt.

Tjockleken på bandet varierar nog en del mellan olika ljudkassetter. Man kan i princip se den genom att dels veta bandets speltid och dels titta hur mycket av "fönstret" som är fyllt av band. T.ex. ett C120-band eller galna C180 har lika mycket utrymme fyllt som ett C90-band, och därmed klart tunnare media. C60-band av bättre kvalitet har ofta tjockare band än C90-band, men det är inte alltid säkert att så är fallet. Än kortare band har mig veterligen sällan än tjockare band - typ det finns ingen "kassettbandens maxisingel" så att säga.

Banden kan nog vara olika genomskinliga även av andra skäl. Gissar att band från sjuttiotalet är mindre genomskinliga än nyare band.

Ifall du hade varit nästgårds så hade jag kunnat erbjuda några sjuttiotalsband att labba med. Annars så kan du chansa på att gå på nån loppis och se om de har några hemska dansbands-kassetter eller liknande, och dra ut en bit av bandet och se hur genomskinligt det verkar, för att se om det är nåt att ha. (Dansband och religiös musik är väl ungefär vad som är väldigt svårsäljbart - de som lyssnade på sånt är väl för gamla för att köpa media längre, ungefär. Därav är det bra att ta just sånt för "annan" användning).

Kanske inte så dum idé det där med magnetisk koppling med via en sådan där grunka man stoppar in i gammal bilstereo. Ska fundera på det.

Faktum är att jag har en hel drös med data-kassetter med det speciella urtaget. Tänkte pröva dem innan jag ger mig på diverse ljudkassetter nu när jag vet om det här problemet.

Men jag har en annan fundering. Till en uppföljare som hette Datapoint 1100 så plockade man bort bandstationerna och kopplade in en diskettedrive monterade i bordet som maskinen stod på. Då behövde man ett sätt att boota maskinen. Det man gjorde vara att stoppa in ett kort på plats A3 som ersatte demodulator kortet. Jag har fått tag på schemat från Jos som beepat sig igenom kortet. Tack för det!
På en hög nivå är det ganska enkelt. Man klockar ut data seriellt med hjälp av Reboot_clk på pinne 11. På ett vanligt band indikeras "end of record (EOR)" genom 11 på varandra följande "1"or vilket göt att "Force_reboot" signalen aktiveras. I den här lösningen verkar man gå på något som baseras på avkodning av dataräknarens högsta bitar och en bygling.

Dessutom verkar en 4.8 kHz signal som går igenom ett par 4 bits räknare vara involverad. Fast jag förstår inte riktigt den delen. Jag kanske måste försöka simulera det hela för säkerhets skull? Någon här kanske har briljanta tankar kring det hela? Inte heller säker på vad TAPE MOTION har för betydelese. Signalen genereras på kort A2 och kommer då från en mono stabil vippa vars ingångar är kopplade till DECK1 STROBE och DECK2 STROBE. Generellt genereras STROBE signaler av CPUn för att klocka in data i I/O enheter. Vet dock inte vad som gäller i detta fallet.

Planen är att använda ett av mina "proto-kort" som jag beställde från JLCPCB till detta projekt och att istället för en EPROM använda en STM32 uController. Tänkte att SPI-utgången skulle kunna vara lämplig för att klocka ut data.

Det här boot-kortet kommer bara vara användbart för att läsa in ganska korta program som går in i ett boot-block. Testprogrammen jag nämnde skulle kunna boota direkt eftersom de består av ett enda block som läses in i minnet. Vill man köra CTOS måste man skriva en riktig kassett och långsiktigt vill jag har kassetter till det här systemet så boot-kortet är bara en temporär lösning för debugging.

Börjar-bli-gammal-kommentar: Det vore bra med lite större font i schemat

för att förstå funktionen så kanske (eller kanske inte) det kan vara värt att flytta runt komponenterna så att det blir mer flödesmässigt. Typ rotera C2,D1,D2 och E1 så att utgångarna är åt höger, och sätt ROM:et till höger om dessa och skiftregistret till höger om ROM:et osv. Inte jätteviktigt, men gör det tydligare. Det vore kanske bra om signalnamnen ändrades så att de t.ex. följer Texas datablad. Lättare att läsa DOWN och UP än CpDn och CpUp osv.

Nåväl, ett försök till analys:
Om TAPE_MOTION är låg så nollställs A1,A2,E1 och D2 eftersom inverteraren B2D ger en etta ut och clear/MR är aktivt hög.
Samtidigt nollställs D1 och C2 men då direkt av icke-inverterad TAPE_MOTION till LOAD-ingångarna på dessa räknare. Signalen går även till en ingång på NAND-grinden B3C som har något att göra med genereringen av signalen flag_reboot. Jag gissar att inverteraren används för att några saker ska drivas direkt av signalen medan andra via inverteraren för att inte lasta signalen för hårt, eller kanske för att göra kretskortslayouten enklare.

Sannolikt är tanken att om CPU inte försöker köra nån av bandstationerna så nollställs hela kortet så att räknarna börjar från noll.

När TAPE_MOTION går hög så brakar allt loss så att säga
Räknaren A1 används för att dela 4800kHz med 16, för att få en klocka på 300Hz.
Räknaren A2 används för att dela 300Hz med 16, dels för att generera 150Hz (Q0) och dels 18,75Hz med väldigt assymetrisk duty cycle (TcUp).

E2 är inte ett skiftregister utan en 1-av-8-multiplexer, som ihop med de lägsta bitarna på räknaren E1 används som 8-bitars skiftregister. D.v.s. med 300bps klockas en synkron datasignal ut från rom:et, bit för bit. Högsta biten på räknaren E1 samt alla bitar på D2 och D1 och de två lägsta bidarna på C2 räknar 11 adressbitar till ROM:et, d.v.s. total 2048 bytes.

Högsta biten på D1 (näst högsta räknaren) samt de tre lägsta bitarna på C2 (högsta räknaren) går också till en 74LS42 (som saknar komponentplaceringsbeteckning??), fyra-till-tio-decimal-dekoder, som i sin tur matar ett jumperblock som verkar välja hur stor datamängd som ska emuleras innan den emulerar att bandläsningen är "klar".

Denna krets matar inverteraren B2C vars utgång går hög när emuleringen är "klar", och den matar i sin tur dataingången på B1A, en halv 74LS74.
Båda halvorna i denna 74LS74 klockas av samma 300Hz-klocka som också klockar "skiftregistret" och ROM-adressräknarna.

Om insignalen reboot är låg så hålls lysdioden släckt samt både räknaren A2 samt första halvan av 74LS74 (B1A) hålls konstant nollställda (via _LOAD respektive _RESET).
Om insignalen reboot är hög och emuleringen av bandet är "klar", alltså inverteraren B2C matad via byglarna från 74LS42 ger hög signal, så kommer första halvan av 74LS74 (B1A) gå aktiv på nästa 300Hz-klocka. På nästa 300Hz-klockpuls kommer andra halvan av 74LS74 (B1B) gå aktiv och det drar utgången force_reboot aktiv, och den signalen nollställer också räknarna D1 och C2 (högsta bitarna till ROM:ets adress osv) för att säkerställa att ingången till första 74LS74-halvan går låg, varpå efter ytterligare två 300Hz-klockpulser så kommer force_reboot att gå låg igen. D.v.s. den kommer vara aktiv under två 300Hz-klockcykler.
Undantaget är dock ifall signalen deck_2 är låg. Då kommer andra halvan av 74LS74 hållas konstant inaktiv, och force_reboot kommer aldrig gå aktiv. Vet inte om deck-2 är aktivit låg eller hög. I vilket fall som helst så lär väl tanken vara att antingen kunna boota och få force_reboot genom att begära läsning från ena bandaren, medan man kan läsa ROM:et som ett band utan att boota om ifall man begär läsning från andra bandaren.

Återstående del är genereringen av flag_reboot.
NAND-grindarna B3C och B3A gör att om tape_motion är låg (emuleringen avstängd så att säga) och/eller force_reboot är aktiv så kommer en halv ytterligare 74LS74 (A3B) nollställas. När den är nollställd så kommer NAND-grinden B3D ihop med inverteraren B2B se till att utgången flag_reboot hålls låg.
Dock när tape_motion är hög (emuleringen igång) och force_reboot är låg=inaktiv så 18,75Hz-klockan få nyss nämda 74LS74-halva (A3B) att gå aktiv. När den är aktiv så ser NAND-grinden B3D till att 150Hz-klocka (Q0 från räknaren A2) skickas ut på flag_reboot.

Vet inte riktigt vad flag_reboot används till. Nån slags pulserande signal som indikerar att inläsning av bootstrap pågår, men till vilken nytta?

Det är väl smaksak hur nära originalet man vill vara. I princip kan du bygga en klassisk ROM-emulator som använder RAM och mux:ar för att det ska vara autentiskt som det kunnat vara vid utveckling på 1970-talet. Eller så kan du emulera hela seriedatagenereringen, och låta 300Hz-klockan gå till en ingång på din mikrokontroller och två utgångar dels ge serdat_out och dels motsvarande utången från 74LS42, och på så sätt skippa ROM, 1-av-8-väljaren samt de fyra räknarna E1, D2, D1 och C2, och 74LS42.

Notera att både kretsen med de två 74LS74-halvorna som genererar force_reboot och alla räknarna till ROM:et reagerar på uppgående flank på 300Hz-klockan. Det är kanske bra att ha kod i mikrokontrollern som reagerar dels på aktivt hög clear eller aktivit låg load och nollställer räknare, och dels reagerar på uppgående flank på 300Hz-klockan och då skiftar ut nästa bit, och när det är gjort förgenererar efterföljande bit, så att det går blixtsnabbt att få fram ny utdatabit (och också signalen som signallerar att emuleringen är klar) på uppgående flank på 300Hz-klockan. Med rätt kodning så lär en klart långsammare mikrokontroller klara av att emulera detta tänker jag. Vet iofs inte vad serdat_out i sin tur matar - ifall det är något synkront med 4800Hz-klockan så behöver emuleringen antagligen vara mycket exakt, annars inte. Det bör väl gå att jämföra med hur bandaren gör.

Eller så kan du emulera hela kortet med en tillräckligt snabb mikrokontroller. Inte lika autentiskt, men...

Nu har jag inte liksom renskrivit ovanstående, ifall det här hade varit en uppgift i en kurs eller om det skulle vara ett officiellt dokument så hade jag nog gått igenom ovanstående nån vända till. Hoppas ändå det tangerar önskade briljanta tankar

Sidospår: det är intressant hur olika hjärnan fungerar på olika personer. Just att följa digitala kretsscheman verkar vara en grej jag har nån slags talang för


Också:
Pluspoäng till TI som har alla databladen från stenåldern som PDF:er, och upplagda så att de hamnar högt om man bara google:ar på t.ex. 74LS193.

Räknaren:
https://www.ti.com/lit/ds/symlink/sn74ls193.pdfdenna visar pinout bäst
https://susta.cz/fel/74/pdf/74LS193.pdfdenna har bra tidsdiagram som sammanfattar logiknivåer/funktion på alla signaler

1-av-8-väljaren som simulerar skiftregister:
https://www.ti.com/lit/ds/symlink/sn54s151.pdf

4-till-10-avkodaren som används för att avgöra när emuleringne är färdig:
https://www.ti.com/lit/ds/symlink/sn74ls42.pdf

74LS74 (för att bli påmind om vilken flank på klockan som den läser dataingången på):
https://www.ti.com/lit/ds/symlink/sn74ls74a.pdf

Just ja, "grunka för bilstereo" känner inte av om motorn snurrar eller inte. Så går förstås att använda men man får starta/stoppa manuellt.

De är byggda med ett vanligt kassett-tonhuvud, utan guidegrejerna, som bara ligger an mot bandspelarens tonhuvud. Enklare mekanik rasslar runt och gör att båda spolarna är något sånär synkade så att ev autostopp tycker att bandet går som det ska.

Tackar!
Alltid bra att ha fler som tittat på en okänd konstruktion.

Det är inte mitt schema utan jag har fått en pdf. Svårt att flytta runt komponenter.

En sak dock. Det är väl inte 300 baud klockan som så att säga klockar ut data. Ja, det är en multiplexor, men det blir sak samma. Reboot_clk driver ju de fyra räknare som dels ger adressen och dels väljer ut en bit av 8. Relationen mellan reboot_clk och 4,8 kHz klockan är oklar och måste undersökas.

TAPE MOTION borde inte vara det som kickar igång allt. Det borde vara REBOOT som gör detta eftersom denna signal i princip skapas direkt från RESTART-knappen. CPU skapar DECK n STROBE som skapar TAPE MOTION. Men CPU går inte nu. Den är helt avstängd till reboot är klar. När EOR inträffar ska CPU starta. Det är också lite märkligt att MR till de fyra 74LS193 kommer från två olika källor dels en inverterad TAPE MOTION och dels av den skapade force_reboot signalen. Det verkar lite märkligt. Kan ju faktiskt vara fel i schemat.

Vill man gräva mer så finns det kompletta schemat för Datapoint 2200 här.

Det är ganska svårläst jämfört med detta fina PDF-ark... Halvtaskig skanning. Krångligt att följa signaler i bakplanet. Men det går.

Originalkortet som detta ersätter heter A3 och finns på sida 20-21. På originalkortet används ett 74165 skiftregister för att klocka ut data. Klockan är REBOOT CLK. REBOOT CLK kommer från A9-S. A9 (sida 16 - 17) är tangentbordsavkodarkortet. Den är gatad med en 7400 och kommer från en signal som heter 01 REBOOT på pinne R. Den kommer i sin tur från kort A4 pinne 6... Kort A4 finns på sida 7-8 är systemets timing generator. Klocksignalen på 9,84 MHz går igenom en vippa och delas ned till 4,92 MHz och gatas genom ett antal grindar för att sedan resultera i signalen på pinne 6. Den har alltså ingen omedelbar relation med 4,8 kHz signalen och man kan anta att det är någon form av pulståg.

Själva processorn finns beskriven på sida 33-37. På sida 36 finns Z81 (74164) som klockar in seriellt boot data med hjälp av ~REBOOT CLK. Dvs inverterad vilket verkar rimligt.

En sak som stör mig är ROM-chippet från Electronic Arrays, EA49xx. Jag har svårt att hitta datablad för det. Det är udda att chipet har en signal ~AR som kommer från en klocksignal. Vanligen har ju ROM och EPROM ingen sådan ingång. Den kan vara med inbyggd latch? Något skumt är det ju med schemat eftersom OE1 och OE2 är ihopkopplade men hänger i luften. Det är ju sannolikt inte TTL så jag är osäker på vad en flytande ingång skulle göra. Pin-layouten är i alla fall inget som liknar ett vanligt EPROM / ROM så det skulle kunna vara hur special som helst...

Rackarns, oj, vet inte hur jag fick det till att 300Hz-signalen klockar allt. Missade Reboot_clk :O

Angående ROM:et så behövde vissa ROM och även SRAM klocka för att fungera. Vet inte varför, typ om det var för att passa vissa bussar eller om det var lättare att konstruera kretsarna. Typisk "stenålder"-grej. De exempel på sådana jag känner till är de ROM och SRAM som användes i första Commodore PET. 6540 och 6550. (Oväntat nog så lär ett vanligt fel på dessa SRAM vara att någon/några av de många enable-ingångarna går sönder, och lösningen för att få igång en PET med sånt fel är att använda trasiga kretsar till bildhårdvaran för där är den alltid enable:ad, och använda kretsar som tidigare satt i bildhårdvaran som vanligt RAM )

Jag har inte tittat på originalschemorna, borde kanske göra det. Kan det vara så att signal för att dra igång en bandare automatiskt genereras av reboot/reset-signal? Antingen att CPU är hårdkodad att dra i den som del av vad den gör vid start, eller helt enkelt att det är en utport som alltid sätts till ett visst tillstånd när man gör reset. Tanken var ju att den skulle kunna läsa från band utan att ha något meningsfullt innehåll i minnet (annars hade det ju suttit ett rom som de helt enkelt bara bytt till annat innehåll när de bytte från bandare till diskdrives. Rom var kanske rimligt prissatt när diskdrives kom, men för dyrt när de använde bandare).

Ska ta en titt på fullständiga schemat senare, om jag inte glömmer bort det

Jo, det är ju problemet med att det är två olika klocksignaler som ställer till det en hel del och gör det krångligt att förstå hur helheten ska fungera. Med en synkron klocka blir det ju väldigt mycket enklare. Till och med nästan banalt.

Jag har sedan tidigare skrivit VHDL modeller för merparten av kretsarna så att slänga ihop det och köra med GHDL är inte så så svårt. Det krångliga blir att ta reda på mer om hur klocksignalerna ser ut och hur EA49xx ROM ska simuleras.

TAPE MOTION ser efter närmare studier ut att aktivera av STROBE signaler eller alla olika sorters rörelse kommandon till driven. Det tiggar en monostabil vippa som har ganska stor R och C. Borde ju vara aktiv för hela ladd-processen annars resetas ju alla räknare. Men laddprocessen borde gå ganska snabbt om man klockar i nära 5 Mbit/s. Med ett 2 kbyte ROM är den klar på några millisekunder.