Bertus

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.

On 11/23/2023 at 1:54 PM, cancom said:

@Bertus: op je P2000 met je nieuwe 64k type eens in:

poke &ha000,65:poke &hc000,67:?peek(&ha000),peek(&hc000) <enter>

 

IC's aanelkaar knopen is en blijft een verneukeratieve hobby.

Dank voor jouw scherpe blik! Daar gaat inderdaad nog wat fout op die 74HC157 chip.

14 hours ago, blanka said:

Mooi werk weer. Helaas zitten die van mij al bijna allemaal vol, alleen een dode P2000 niet. Is het een idee de schroefterminalgaten gewoon 2,54mm uit elkaar te doen zodat er een JST connector op kan, dat is netter dan van die schroefklemmen. Wellicht draait ie ook wel met de moderne laag-energie chips van tegenwoordig ook wel direct van het hoofdbord, of is dat te uitdagend voor de voeding?

Dank! 🙂 

• Onder de schroefterminal op de PCB zit een optie om een male 2.54mm header te zetten waar je een JST connector op kunt zetten.
• Het zou me niets verbazen dat dit printplaatje zo'n lage stroom heeft dat je de 5V en GND direct kunt aftappen van een 5V en GND pin op het moederbord. 🤣

De 64kb geheugenuitbreiding voor de P2000T is af en werkt als een zonnetje! Ik ben uiteindelijk op het volgende schema uitgekomen. (png is 2048x1447 pixels; hoop dat dit nu goed gaat qua uitlezen...)

Ik heb nog een paar SMD ledjes toegevoegd aan het ontwerp zodat je de status van het bank register kunt 'uitlezen'. Deze hoef je op de printplaat natuurlijk niet erop te zetten als je dat niet wilt. De PCB sluit je aan op de expansion header die zich achter de cartridge slots bevindt. De 5V en GND haal ik van de voeding PCB af. Voor een impressie, zie onderstaande afbeeldingen.

Ik heb ook een simpele RAM tester utility geschreven. Deze toetst het RAM boven 0x6200 en test ook de bank switching. (als je op onderstaand plaatje klikt wordt je naar een YouTube filmpje verwezen).

Als mensen geïnteresseerd zijn om te testen, laat me even weten! Ik heb nog 1 lege printplaat over als je zelf alle componenten in huis hebt en nog 1 met alle componenten erop. Als er veel interesse is kan ik weer een batch aan printplaten bestellen.

Je kunt ook zelf bestellen; alle ontwerpbestanden zijn op onderstaande Github repository te vinden.

https://github.com/ifilot/p2000t-ram-expansion-board

Duidelijk! Maar dat wordt gelukkig netjes afgehandeld door die splittape tool. 🙂 

Ik denk dat ik dan het proces van inladen dan nog niet helemaal snap.

Welk stukje van de header is dan problematisch? Bij mijn beste weten werkt het als volgt:

• $0032-$0033 en $0034-$0035 zijn inderdaad allebei niet deelbaar door 1280, maar dat hoeft toch ook niet? Het BASIC programma stopt gewoon op een bepaalde geheugenlocatie ($6547 + bestandsgrootte) en dat wordt weggeschreven in $6405, $6407, $6409.
• Hoeveel 'blokken' van 0x400 bytes er ingeladen worden (dus exclusief die 0x100 aan headerdata) wordt bepaald door het getal op $004F.

5 hours ago, blanka said:

Trouwens, de .cas files zijn ook corrupt, dat kan ook boosdoener zijn.

Staat er, afgezien van de "bogus data", dan iets fout in? (weet niet of je de aanwezigheid van de bogus data corrupt noemt) De recnums staan goed en bestandsgrootte is ook in orde. Ik kan beide .cas bestanden gewoon inladen en ze draaien zover ik kan zien prima.

6 hours ago, Hawker17 said:

ondanks dat ik ze niet kan laden in een fysieke P2000T

Ik kan bevestigen dat je een P2000T met meer dan 16kb geheugen nodig hebt, anders draaien ze inderdaad niet.

5 hours ago, HAL9000 said:

Het viel me nu ook op dat het 'dopje' om bij de jumper op het moederbord te komen ook ontbreekt... 

Dat vroeg ik me onlangs nog af: waarvoor is die jumper precies?

14 hours ago, blanka said:

Nu nog 3 kabels maken voor de andere P2000s en die in de klas. Is kijken of ik iemand zo gek kan krijgen dat ie Z80 assembly wil gaan proberen.

Laat ons vooral horen hoe die retrotechnologie ontvangen wordt door de huidige in technologie gemarineerde scholier. Het mooie aan die oude systemen is dat je ze nog redelijk goed kunt begrijpen op signaalniveau. Ik denk dat dat heel leerzaam kan zijn, vooral aan die scholieren die verder willen in electrotechniek of informatica.

Maar zou dat niet raar zijn? Jouw P2000T draait toch net zo goed op 2.5 Mhz? Doet dat MiniWare bord nog iets met de monitor-routines wellicht?

Laten we eens kijken wat het geeft inderdaad bij een 64k uitbreiding. Als het allemaal netjes lineair schaalt (en ik de tijd voor het bank-switching mag verwaarlozen) dan zou ik op ~2.3 seconden uit moeten komen voor de boot. Dat lijkt me nog te doen voor een eindgebruiker.

4 hours ago, blanka said:

Ik heb zitten meten.

Kale bak 1,5 seconde reset tot OK, met 16kB vertikaal insteekbordje 3 seconde tot OK.

Was me nog niet opgevallen dat die boot-tijden langer zijn als je meer RAM had. Als je lang moet wachten op een boot is dat inderdaad minder prettig.

Voor wat de vergelijking waard is: Ik kom zelf uit (via opname op 60 FPS) op ~0.9s voor de kale 16kb (14966 bytes vrij) en op ~1.6s voor de 48kb (39542 bytes vrij). Redelijk overeen met jouw bevindingen dus. Grofweg duurt die extra 32kb dus ~0.7s langer. Ik weet niet precies wat er exact onder de motorkap gebeurt, maar als er simpelweg een toets wordt gedaan waarin eerst data wordt weggeschreven en dan wordt gecontroleerd, dan zou een simpele (en toegegeven erg ruwe) berekening goed in de buurt komen van die 0.7 seconden. Stel dat je de data wegschrijft met een LDIR (16 t-states per byte) op 2.5 MHz , dan zit je op 0.21s. voor die operatie. Als ik dan een factor twee reken voor terug inlezen en controleren, kom ik al aardig in de buurt van die 0.7s.