Bertus

6 hours ago, blanka said:

Goed bezig, maar ik zou wel van de DOS bestandsnamen afstappen en minimaal 16 karakters met alle overlap P2000 en UTF tekenset toestaan incl upper/lower case.

Ik snap die suggestie, alleen die informatie staat niet in de directory entries maar in de .CAS bestanden zelf. Dus dan moet je voor elk bestand dat je aantreft in de directory het bestand gaan openen en de cassette header gaan uitlezen. Dat zal het uitlezen van een directory gaan vertragen, maar wellicht dat dat geen probleem is. Ik ga kijken wat er te winnen valt hier. 

Ik heb nog een klein nieuwtje: het is me gelukt om een cartridge in elkaar te zetten waarmee je een SD-kaartje kunt uitlezen om zo .CAS bestanden vanuit de SD-kaart op te starten. Voor een beetje snelle data-overdracht heb ik een parallel <-> serieel circuitje gebouwd dat draait met een 16 MHz klokje zodat je tijdens elke instructie van de Z80 een byte kunt uitlezen vanaf de SD-kaart. Het alternatief was om het SPI signaal te bit-bangen, maar dat zou dan 8x langzamer zijn.

Niet alle SD-kaartjes werken, alleen SD-kaartjes van het type SDHC en geformatteerd met een FAT32 bestandsssysteem. Ik heb tot nu toe 4Gb, 8Gb en 16Gb kaartjes geprobeerd en deze deden het allemaal. Nu is overigens 1Gb al meer dan genoeg om het hele archief aan CAS bestanden op te slaan.

Op de cartridge zit een 128kb ROM en 128kb RAM chip. Op de ROM chip staat een launcher applicatie welke vanuit een aangepaste BASICNL cartridge opgestart wordt. Met deze launcher kun je navigeren op de SD-kaart en .CAS bestanden opstarten. De RAM chip wordt gebruikt om tijdelijk de .CAS bestanden op te slaan alvorens deze op de juiste positie in het RAM geheugen van de P2000T gezet worden.

Het complete schema staat hier: port2-sdcard-interface.pdf 

Door het aantal chips ben ik overgestapt van DIP (THT) naar SMD zodat alles past. Ook had ik een 4-laags PCB nodig om alles te kunnen routen. Hieronder een plaatje van de (achterzijde) van de PCB met alle componenten erop. De SD-kaart lezer is een bekend prototype bordje wat een fijn 'bruggetje' vormt tussen het 5V domein van de P2000T en het 3.3V domein van de SD-kaart.

Voor een indruk hoe de SD-kaart cartridge werkt heb ik hieronder nog een kleine demo (screen capture). De launcher werkt met 3 simpele commando's: cd, ls en run. Met ls ls lees je een folder uit om zo alle bestanden te laten zien. Met cd verander je van folder en met run kun je een .CAS bestand opstarten.

Voor de bronbestanden zie deze Github pagina en voor de documentatie deze website.

20 hours ago, HAL9000 said:

Totaal iets van 300 MB aan pdfs

Zal ik ze aan het archief aanbieden?

Ik ben niet de beheerder van het archief, maar ik zie ze graag in het archief verschijnen! Dank voor het noeste scanwerk!

1 hour ago, blanka said:

Ik heb juist op drie machines, eentje van rond serienummer 2000, een rond 14000 en een rond 26000 allemaal dezelfde ROM, maar die is anders dan die van MdK. Ik heb er daarnaast 2 met een andere versie, beide uniek. En niet een die hetzelfde is als bij de emulator.

Kan er iets van een overzichtje gemaakt worden. Ik ben ook wel nieuwsgierig. Is het een idee dat we een tabelletje bouwen met daarin chassisnummer en bijvoorbeeld een MD5 of CRC16 checksum van de ROMs?

13 minutes ago, dionoid said:

Het adres van de gevraagde I/O poort staat dan op de adres-bus en eventuele data (in of uit) gaat via de data-bus. Klopt dit?

Ja, klopt helemaal, maar dan met de kanttekening dat alleen de laagste byte van de adresbus gebruikt wordt. Je bestuurt dit met de IN en OUT instructies. Op blz 10 van deze Z80 datasheet tref je het tijdschema aan. Je kunt dan met een combinatie van de adresbus en de ~RD en ~WR signalen e.e.a. aansturen. Op deze manier wordt bijvoorbeeld een register aangestuurd voor de bank switching, maar ook de floppydrives werken met die I/O poort. Ik gebruik zelf bijvoorbeeld de I/O poort voor het uitlezen van een SD kaartje.

5 hours ago, cancom said:

Enne... voor dat audio zie "P2000 System T & M Reference Manual" (pdf, ook op PPP), pagina 55 (geen frequentiemodulatie of fsk, dus).

Dank! Phase-encoding dus. Dat is ergens goed nieuws want dat valt makkelijker in software te converteren naar binair.

5 hours ago, cancom said:

deze puzzel wordt U aangeboden door hardwarefabrikanten onder 't motto "waarom makkelijk als 't ook moeilijk kan"

Herkenbaar.  En waarschijnlijk maak ik me er zelf onbewust ook soms schuldig aan.

Dank voor je wijsheden wederom @cancom!

On 2/22/2024 at 4:34 PM, blanka said:

Is er ook een programma om de tapes in audioformaat om te zetten? Bijvoorbeeld vanaf WAV?

Het ziet er redelijk zuiver uit, en hws is een korte beweging 0 en een lange 1 of omgekeerd.

Dit ziet eruit als frequentieverschuivingsmodulatie wat veel gebruikt werd voor het opslaan van data op tapes. Je kunt dit inderdaad in software demoduleren, maar ik ben niet bekend met makkelijke "drop-and-click" programma's hiervoor.

Je zou eens een kijkje kunnen nemen in deze tutorial die het demodulatieproces in stapjes beschrijft:

https://mightydevices.com/index.php/2019/08/decoding-fsk-transmission-recorded-by-rtl-sdr-dongle/

De auteur heeft de Python code op Github staan:

https://github.com/MightyDevices/python-fsk-decoder

Mijn kennis is extreem beperkt hier en dateert vanuit het MS-DOS tijdperk waarin e.e.a. al gestandardiseerd was. Deze kennis is ook erg roestig geworden...

5 hours ago, blanka said:

Superfijn dat de kabel omgekeerd ook past, maar kan ik uit de Maintanance wel concluderen dat ie goed is aangesloten?

Als de floppydrive de Shugart-implementatie volgt - en ik weet niet of die al populair/breed geadopteerd was ten tijde van P2000 - dan zouden de oneven pinnen allemaal GND moeten zijn. Dit zowel op de controller als op de drive. Alle GND pinnen zijn met elkaar en met de GND op de voeding verbonden. Hiermee kun je de aansluiting van de kabel bepalen met minder pogingen dan het maximaal aantal permutaties tussen controller en drive. Dat de drive gaat draaien is een goed teken; kijk eens of PIN16 dan laag gaat wanneer die draait. Op PIN8 (index) hoor je een 50 Hz signaal te krijgen, corresponderend met een toerental van 300 RPM. Het zijn relatief korte negatieve pulsjes.

5 hours ago, blanka said:

Wat betekent het getik

Ik vermoed dat het getik het gevolg is van de stepper motor die tegen het begin/einde aanzit. De stepper motor zoekt track 0 en wanneer deze gevonden wordt dan wordt PIN26 laag (active low). Als de sensor niet goed werkt of het signaal niet goed overgebracht wordt, dan blijft de stepper motor gewoon doorstappen. Soms is die sensor vuil. Je kunt de sensor schoonmaken, maar wees dan voorzichtig dat de sensor niet van locatie veranderd.

5 hours ago, blanka said:

en wat kan ik nu nalopen om tot een goede werking te komen?

Ik denk dat je deze twee zaken apart van elkaar moet debuggen. Je weet vooralsnog niet of de drive of de controller goed werken (of beiden niet). Je zou de signalen op de pinnen kunnen uitlezen (met een osscilloscoop) of zelf signalen (met een Arduino bijvoorbeeld) op de pinnen kunnen zetten en kijken of je goede respons krijgt. De suggestie van @cancom is ook relevant hier. Elke drive heeft een drive nummer toegedeeld gekregen (1-4) welke via jumpers op de drive zelf ingesteld moeten worden. In het MS-DOS tijdperk ging dat overigens door de drive na of voor een cable-twist (A/B twist) en zonder jumpers...

51 minutes ago, blanka said:

Valt ook niet mee, Bertus moet op zijn werk alles in het Engels doen, en dat slaat over naar de hobby.

Eigenlijk wil ik vooral inclusief zijn naar de P2000T gebruikers die geen Nederlands spreken.  

Overigens is dat nog best een grote groep ben ik achter gekomen.

13 hours ago, dionoid said:

Leuk weetje: Ik heb ook een "proof of concept" versie van Cassette Dumper die bytes met een baud rate van 38400 over de seriële poort van de P2000T verstuurt. Dat is dus 32 keer sneller dan de standaard ingestelde 1200 baud "seinsnelheid" van de P2000T

Ik ben nu nieuwsgierig geworden.  Waarom heb je in eerste instantie voor 1200 baud gekozen en wat bepaalt nu eigenlijk of hogere snelheden haalbaar en ook stabiel zijn? Zit die complexiteit bij het uitlijnen van de assembly instructies en het 'bit banging' van de seriële poort?

SLOT1 en 2 zijn beiden niet gebufferd, dus wanneer dat je een cartridge inserteert terwijl de machine draait is het niet onaannemelijk dat de adres-, data- of een van de andere lijnen beinvloed gaat worden wat het lopende proces verstoort.

Iets wat wellicht zou kunnen werken is het volgende: Je zou met een 'halt' instructie de Z80 in de 'suspend' mode kunnen zetten waarbij deze de adres- en databussen vrij geeft. De Z80 moet je dan weer laten ontwaken middels een interrupt op commando van de gebruiker. Je kunt daar niet het toetsenbord voor gebruiken want het uitlezen van het toetsenbord werkt immers op basis van een interrupt die elke 20ms uitgevoerd wordt (deze valt uit te zetten). Je hebt in SLOT2 toegang tot de interrupt lijn, dus je zou met een druktoets en een 74HC123 voor debouncing dit signaal kunnen geven. Tijdens de interrupt routine herstel je dan de staat van het systeem (toetsenbord weer aanzetten bijv) en laat je het programma doorgaan.

9 hours ago, Justforthefun said:

Een directe vraag die ik heb bijvoorbeeld. Naast de chr$ characters om kleur en positie te bepalen, is er ook een video kleur geheugen locatie waarmee je met poke commando's bijvoorbeeld de kleur van een character op het scherm kunt veranderen ? 

Dit kun je wel vinden in de P2000T handleiding, maar inderdaad niet in de vorm van een tutorial of iets dergelijks. Kort samengevat heeft de P2000T een videogeheugen wat door de Mullad SAA5050 teletekst chip uitgelezen wordt om een beeld te vormen. Je hebt een beeld van 25 regels met 40 karakters per regel. De scrollregisters even buiten beschouwing gelaten begint elke regel op geheugenadres $5000 + $50 * regelnummer, waarbij ik het teken $ gebruik om hexidecimale notatie aan te geven en ik de regelnummers tel vanaf 0. Kleuren stel je in door middel van omschakelkarakters. Deze staan benoemd in de handleiding (blz 29). Je kunt via CHR printen, maar je kunt dus ook direct via POKE in het videogeheugen schrijven. Standaard wordt er 'wit op zwart' geprojecteerd, maar als je bijvoorbeeld het getal "1" wegschrijft en daarna de ASCII waarde voor een karakter op het geheugenadres dat volgt, dan krijg je een rood op zwart letter.

Ter illustratie:

In onderstaand voorbeeld wordt eerst het omschakelkarakter "1" weggeschreven (rode tekst) en vervolgens het getal "34", wat correspondeert met een aanhalingsteken in ASCII.

Je ziet dus een zwart (leeg) blokje voor het eerste karakter op regel 23 en het aanhalingsteken als rode tekst op een zwarte achtergrond voor het tweede karakter op regel 23. Je denkt nu vast: 'wat onhandig dat ik telkens een teken moeten printen om van kleur te veranderen", maar dit is nu eenmaal hoe dat dit moet. Je hebt geen apart kleurengeheugen zoals op een NES of een C64.

9 hours ago, Justforthefun said:

Mocht iemand nog documentatie hebben van de basic programmeer taal zelf, dus niet zozeer algemene informatie over programmeren in basic, maar specifiek voor de Basic variant dus van de P2000T basic Interpreter  module, dan ben ik erg geïnteresseerd.  

Ik geloof dat @blanka een serie aan boekjes had weten op te bemachtigen en kan vast wel wat nuttige tips geven. Je kunt ook eens een kijkje nemen op de P2000T repository op Github.

Ik heb destijds (inmiddels weer drie jaar geleden) deze twee gekocht:

• https://www.onlinekabelshop.nl/usb-naar-9-pins-serieel-rs-232-adapter-0-80-meter.html
• https://www.onlinekabelshop.nl/adapter-db25-m-db9-v.html

Die werken voor mij zonder enige problemen.

In de professionele omgeving gebruiken we deze kabels:

https://nl.mouser.com/ProductDetail/FTDI/UT232R-200?qs=oAT38M%2F3lmGoOYMSry895Q%3D%3D

Die hebben een gecertificeerde FTDI chip. Je betaalt dan wel een heel stuk meer.

2 hours ago, blanka said:

Dank @Bertus. Ik ben apparaten gewend die de seriele communicatie enigszins voorbewerken zodat er een byte-stroom binnenkomt en de hele omzetting met pariteitsbits e.d. op de achtergrond gebeurt. Ik ga er eens mee prutsen. Ik neem wel aan dat er ook nog een stukje is dat wacht tot het begin. En waar zit de plek waar het in het geheugen komt in de code?

Je moet vooral @dionoid bedanken.  Die heeft de code geschreven en het noeste werk gedaan om alles (specifiek de timing!) uit te pluizen.

Om je vraag te beantwoorden: De snippet hierboven leest enkel een byte uit en zet deze in register A. Daarna retourneert deze routine. Met de byte in register A kun je zelf bepalen waar je het neer wilt zetten. Een voorbeeld hiervan tref je ook aan in de code. Hieronder nog een snippet:

read_block:
    ld de, $400             ; 11 00 04
read_block_loop:
    call read_byte          ; CD 00 9E
    ld (hl),a               ; 77
    inc hl                  ; 23
    dec de                  ; 1B
    ld a,d                  ; 7A
    or e                    ; B3
    jr nz, read_block_loop  ; 20 F6
    dec c                   ; 0D
    jr nz, ignore_header    ; 20 E9

Het register DE fungeert als een afteller. Er worden 0x400 bytes uitgelezen en die worden weggeschreven naar het adres wat in register HL staat. Na elke iteratie incrementeert HL en decrementeert DE. Wanneer DE op 0 staat zal de lijn 'jr nz, read_block_loop' niet meer naar boven springen en continueert de code naar beneden toe.

Wat je kunt doen is zelf een stukje assembly in elkaar zetten dat 0x400 bytes uitleest en wegschrijft op een vast geheugenadres wat je fijn vindt (bijvoorbeeld 0x9000 - 0x93FF). Je roept de assembly routine aan in BASIC en wanneer die klaar is kun je werken in BASIC met (bijvoorbeeld) de PEEK en POKE commando's om de data op de gewenste plek te zetten.

Ik heb nooit met de RS-232 poort gewerkt, maar ik zal een poging wagen om (hopelijk) wat nuttigs erover te zeggen om je in de zoektocht te helpen. Ik hoop dat wat andere forumgenoten kunnen inspringen.

Het script van @dionoid lijkt mij een goede start: https://github.com/p2000t/software/blob/master/utilities/pc2p2000t/pc2p2000t.z80.asm

In dat script zie je een routine "read_byte" die een byte uitleest vanuit de RS-232 poort middels I/O poort 0x20. Het is een seriële poort, dus je ontvangt inderdaad maar 1 bit tegelijk (anders was het een parallelle poort). Wat dit script doet is telkens een bit uitlezen naar register A, dan een shift right van die bit naar de carry om vervolgens die bit vanuit links te laten inspringen in register C. De code plaatst ook delays; iets om rekening mee te houden bij een port naar BASIC.

; reads a byte from the serial port (9600 baud) and returns in A
read_byte:
    push bc                 ; C5 [11]
check_start_bit:
    in a,($20)              ; DB 20 [11]
    and $01                 ; E6 01 [7] - check if bit D0 is 0
    jr nz, check_start_bit  ; 20 FA [7] 
    ld b, $15               ; 06 15 [7]
delay_on_start_bit:
    djnz delay_on_start_bit ; 10 FE [13/8]
    ld b, $08               ; 06 08 [7] - call read_next_bit 8 times (for 8 bits)

read_next_bit:
    in a,($20)              ; DB 20 [11]

    ; 58 clocks without extra delay
    ; 1.2 * 1041.67 = 1250. Need delay in B: 
    ; 2400 baud: (1250 - 58) / 13 = 91,7 + 1 = 93 (&h5D)

    ; 4800 baud: 1.2 * 520.84 = 625
    ; delay in B: (625 - 58) / 13 = 43,62 + 1 = 45 (&h2D)

    ; 9600 baud: 1.2 * 260.42 = 312.5
    ; delay in B: (312.5 - 58) / 13 = 19.6 + 1 = 21 (&h15)

    rra                     ; 1F [4] - bit 0 into carry
    rr c                    ; CB 19 [8]
    push bc                 ; C5 [11]
    ld b, $10               ; 06 10 [7]
delay_bit:
    djnz delay_bit          ; 10 FE [13/8]
    pop bc                  ; C1 [10]
    djnz read_next_bit      ; 10 F3 [13]

    ; 72 clocks without extra delay. So delay in B: 
    ; 2400 baud: (1041.67 - 72) / 13 = 74.6 + 1 = 76 (&h4C)
    ; 4800 baud: (520.84 - 72) / 13 = 34.53 + 1 = 35 (&h23)
    ; 9600 baud: (260.42 - 72) / 13 = 14.49 + 1 = 16 (&h10)

    ld a,c                  ; 79 [4]
    pop bc                  ; C1 [10]
    ret                     ; C9 [10]

Alternatief is natuurlijk dat je je eigen machinecode schrijft dat een vaste payload wegschrijft naar het RAM geheugen en routine in BASIC insluit.

BASIC geeft dat inderdaad netjes aan, maar het getal is dan gebaseerd op een relatief simpele test. Uiteindelijk wil je controleren of je inderdaad maar 16kb expansie hebt, of dat je wellicht meer hebt, maar dat er een defectje op het expansiebord zit. Een 16kb is echter heel gebruikelijk, dus ik vermoed dat alles wat dat betreft in orde is.

• Zou je misschien een foto kunnen maken van je RAM expansion board? Het kan zijn dat je alleen een 16kb geheugenuitbreiding hebt. Dan werkt het gedeelte A000-DFFF, maar E000-FFFF niet.
• Wat betreft de toetsen; misschien maken deze slecht contact. Je kunt de contactoppervlakken voor deze toetsen proberen schoon te maken met een wattenstaafje en wat isopropyl alcohol.

Ik heb een paar maanden terug deze gekocht: https://www.bol.com/nl/nl/p/philips-mini-cassette-lfh0005-30-minuten-analoog-clip-1-pack/9300000148258602 en ik kan bevestigen dat deze werken. 

Duidelijk verhaal, waarvoor dank wederom! 

Dan ga ik die M1 lijn vervangen voor een A3 lijn.

1 hour ago, cancom said:

Nou ik toch hier bezig ben: @Bertus, leg eens uit waarom je in die data-cartridge voor de poortadresdecodering M1 gebruikt i.p.v. A3 ?

Omdat ik de datacartridge alleen wil gebruiken tijdens een I/O request en niet tijdens een interrupt request. Tijdens een interrupt request gaat nl zowel ~IORQ als ~M1 laag, dus met die inverse M1 wil ik dat voorkomen.

Ik snap overigens je punt om A3 te gebruiken; daarmee zou ik de geheugenadressen nog verder kunnen beperken tot echt alleen 0x60 - 0x67. Nu wordt de waarde van A3 niet meegenomen en kun je bijvoorbeeld 0x60 ook aanschrijven met 0x68.

1 hour ago, blanka said:

Die hou je nog tegoed.

Inmiddels heb ik mijn eigen P2000T opengeschroeft en de voedingskabel van de PCB losgekoppeld. Ik deel je ervaring dat de geheugenuitbreiding ook zonder die 5V werkt. Ik heb een uitgebreide geheugentest gedaan en die laat geen fouten zien. Wanneer ik het spanningsverschil tussen de GND en de 5V rails op de PCB meet, dan staat daar een flucturende (minimale) spanning van +/- 0.05V op. Kortom: de chips worden niet meer gedreven op hun VCC pennen, maar halen de spanning via een andere pen binnen.

Wanneer een van de chips geen 5V signaal op de VCC pen krijgt, probeert deze, via het pad met de minste weerstand, die 5V te krijgen. Dit gebeurt dan via een andere pen zoals een gate-pen of een clear-pen. Blijkbaar heeft elke chip tenminste één pen verbonden met een 5V signaal waardoor deze alsnog kan draaien. (EEVBLOG heeft hier overigens een interessante video over: https://www.youtube.com/watch?v=2yFh7Vv0Paw). Dit houdt wel in dat andere chips op het moederbord de expansiemodule van stroom aan het voorzien zijn, waarvoor ze niet bedoeld zijn.

Kortom: de chips op de expansiemodule zijn niet gemaakt om gedreven te worden op een andere pin dan VCC en de chips op het moederbord zijn niet gemaakt om andere chips van stroom te voorzien. Dat het allemaal werkt komt omdat moderne chips erg energiezuinig zijn en dus weinig vermogen nodig hebben. Ik weet echter niet of een schakeling als deze zonder voedingskabel op lange termijn stabiel blijft. Misschien dat iemand anders hier op het forum verdere wijsheid over kan verschaffen. 

Ik ben positief verrast om te horen dat hij werkt zonder externe voeding! Leuk dat je dat eens geprobeerd hebt. Meten is weten.

Pin 32 (~WAIT) en pin 35 (~LOCK) zijn beiden niet aangesloten op mijn bordje, dus daar kan hij de voeding niet vandaan trekken (lijkt me ook niet verstandig om dat te doen). Ik vermoed dat het bordje draait op de "restspanning" van de gates. Veel CMOS chips blijken vaak goed te draaien zonder dat de VCC pin aangesloten is. De chips draaien nl ook op minder dan 5V en hebben weinig vermogen nodig.

Zou je eens de spanning tussen GND en de 5V pin kunnen meten? Ben benieuwd wat je daar ziet. Er zit nl geen spanningsregulatie op het bordje.

CALL SERVICE krijg je als de geheugentest tijdens de boot niet succesvol retourneert. Dat gebeurt in de monitor en voordat uberhaupt wordt gekeken of er vanaf een cartridge opgestart kan worden. De hardware-test op de multicartridge heeft dus weinig zin. Omdat je wel de tekst CALL SERVICE in beeld krijgt zou ik het zoeken bij de DRAM blokjes.

Ik heb zelf geen ervaring met het controleren van RAM bij de P2000T, wel bij een C64. Hier gebruik ik de volgende strategie. Allereerst met de multimeter de pinnetjes van de DRAM afgaan om te kijken of de spanningen zoals verwacht zijn. Als er iets afwijkt dan kun je kijken of die chip defect is. Het is dan handig als een je een goed functionerende machine hebt die je als testmachine kunt gebruiken. Bij die testmachine desoldeer je enkele RAM blokjes en zet je daar voetjes in. Vervolgens kun je die machine gebruiken om individuele RAM blokjes te testen. Op deze manier kun je de defecte chip opsporen en vervangen in de machine.

42 minutes ago, cancom said:

Meen je dit nou?

A13, niet S0. (heb het bericht gewijzigd)

On 11/25/2023 at 3:48 AM, cancom said:

Check, check en check 1 dag of meer later nog eens. En voor zo'n niet al te grote schakeling is 't handig die in een circuitsimulator te tekenen -zeker als je "scherpe blik" stilaan meer moeite heeft een logicatrein te blijven volgen zonder te ontsporen- waardoor je kan zien of -en zoja hoe- 't de mist in gaat.

Kan ik me alleen maar bij aansluiten.  En ik moet bekennen dat ik dit zelfs heb gedaan, alleen nooit het hele circuit in een simulator gezet. Enkel de stukjes waar ik twijfels over had. In retrospect had ik aan alles moeten twijfelen...

Enfin, het viel gelukkig met een enkele botch wire (A13 -> pin2 van de 74HC157) op te lossen.