Philips P2000T kenner gezocht


Op 15 november 2019 16:57:23 schreef bprosman:
Voor Zemon heb ik een handleiding helaas alleen niet de ROMS

[bijlage]

Hoi,
Ik ben een van de auteurs van de Zemon Assembler/monitor. Ik ben alle spullen daarvan al jaren kwijt, dus ik ben superblij met jouw kopie van de handleiding! Heel erg bedankt!

Groetjes,

Frits

Op 17 november 2019 12:16:11 schreef cancom:
[...]

O.a. hierdoor is me niet duidelijk of iemand hier wel door heeft dat er in de FSM net zo goed als in welk computerboek e.d. dan ook een fout kan staan. En meestal minstens 1.

Ik heb een vraag over de P2000 FSM en of alles daarin nog wel klopt.
In de FSM, staat dat de data bits voor de cassette interface verstuurd zouden moeten worden via bit 0 van port 0x10 en printerdata via bit 7.

Wanneer ik in de monitor ROM kijk lijkt erop dat zowel de cassette als de printer data-bits daar via bit 7 gaan...

cassette code:

printer code:

Wellicht dat een van de experts hier wat over kan zeggen, voordat ik ergens een scoop ga lenen om het na te meten?

Op 24 augustus 2020 09:54:42 schreef Ferenc:
[...]

Ik heb een vraag over de P2000 FSM en of alles daarin nog wel klopt.
In de FSM, staat dat de data bits voor de cassette interface verstuurd zouden moeten worden via bit 0 van port 0x10 en printerdata via bit 7.
[bijlage]

Dat is wel spannend. Ik ben zelf aan het uitzoeken hoe ik de cassette emulatie aan de praat krijg in Mame. Het lijkt alsof er inderdaad niet veel klopt van de handleiding.

Het lijkt dat de inkomende bits van poort 0x20 moeten worden geinverteerd bijv.

Heb je toevallig meer gedocumenteerde rom code? Dat zou ideaal zijn!

De code met commentaar die je ziet is door mijzelf, met wat hulp van de Monitor-disassembly, het adresboekje en wat puzzelwerk gemaakt.
Zoals uit mijn vraag blijkt: ook ik ben bezig met het reverse-engineeren van de cassetteroutines, leuk dat ik niet alleen sta :-)

Ik vind de in M2000 gekozen oplossing, waarbij een illegal opcode wordt afgevangen en vervolgens de hele cassette (en print) afhandeling gebeurt in de emulator code (C), wel slim, maar ik wil graag weten hoe het allemaal precies werkt.

En, vanmorgen in de auto had ik een Eureka moment!

Ik ben namelijk door het commentaar in de originele monitor disassembly (monitor.pdf) op het verkeerde been gezet!

Er staat "schrijf een byte naar tape'
Wat wordt bedoeld is: schrijf een byte naar de printer TIJDENS een cassette IO operatie. (!)

Daarom moet in E de huidige cassette operatie meekomen zodat bij het sturen van de printerbits de cassettestatus niet wordt veranderd.
Dat printen gebeurt alleen als BIT 2 van stacas is gezet, en sluit aan bij het commentaar in 'adresboekje.pdf':

En dan valt alles op zijn plaats...

Ik was ook al aan mijn timingberekeningen gaan twijfelen... ik kwam in de put byte routine op een bit-delay van ca 1040 T-states.
Dat is vrijwel exact 2400 Baud!!
(NB die timing is hardcoded, dus als je een 300baud printer had aangesloten: pech gehad!)

Ook had ik in mijn commentaar bij de disassembly uitgerekend dat het schrijven van 40 blokken naar tape zeker 175 seconden zou kosten met deze snelheid, terwijl dat veel sneller gaat... (ca 90 seconden).

Tot slot: bij het disassembleren van de laad van tape code kwam ik ook al geen logica voor start- en stopbits tegen, en in de Technical Manual werd daar ook al met geen woord over gerept...

Zo zie je maar, rubber-ducken helpt echt.

Ik weet zeker dat ik in de save naar tape code wel IO ga zien over het juiste bitje in poort 10h.

Ferenc

Ik heb ooit in een grijs verleden de hele P2000T monitor gedisassembleerd en stukken van commentaar voorzien.

Toen had ik geen Z80 assembler en heb ik de MASM van MS-DOS misbruikt om Z80 code te genereren d.m.v. een grote MACRO file waar alle Z80 instructies bijna 1 op 1 in stonden met allerlij truken.

De nieuwe disassembly is niet 100% echte Z80 mnemonics maar wel lijkt het er veel op.
Uiteindelijk is het gelukt om de romcode te assembleren met mijn eigen sources en daar een 100% identieke binary uit te krijgen.

Al die code zou nog ergens op een oude AT of Compaq386 moeten staan en die heb ik nog. Maar dat wordt dus graven!

Ook van het mini-dcr cassette loopwerkt moet ik nog zeer gedetailleerde informatie hebben, dat wordt een grotere uitdaging omdat dat op papier is. Voor zover ik weet heb ik nooit iets weggegooid van de P2000T wat uniek is, dus dat moet er ook nog zijn.
Maar ja waar precies?

Henri's Law 1: De wet van behoud van ellende. Law 2: Ellende komt nooit alleen.

Mooi werk!

Mijn verleden ligt meer bij Commodore (C64/Amiga) en ik gooi ook nooit iets van dat soort dingen weg (behalve...). 4 jaar geleden ben ik verhuisd en heb ik veel van die spullen 'teruggevonden'. Zoals een papieren listing van de originele source code (assembler) van Championship Lode Runner voor de C64, van Broderbund :-)

Mijn eigen C64 en veel van mijn zelfgeschreven software had ik helaas wel al een keer de deur uit gedaan :-( Stom!!

Omdat ik de C64 en 6502 best goed ken en daar al ook zo veel over bekend is, zocht ik een ander systeem om te doorgronden. We hadden op mijn middelbare school een P2000T als oefenapparaat bij computerkunde.

Daarom heb ik als hobbyproject de P2000 opgepakt. Hoofddoel: een 21e eeuwse emulator voor de P2000T en P2000M :-) (en wie weet de P2000C??)

Subdoel is een volledige en volledig van commentaar voorziene Monitor listing die assembleert tot de originele ROM...

Best handig bij het correct emuleren van een systeem.

Het zou wel mooi zijn als die disassembly en Cassette-informatie boven water kwamen :-)

Ik ben meer een software man, maar denk wel na over een Arduino/RPI interface om de Cassette via USB te kunnen aansluiten aan de PC, zodat de emulator naast CAS bestanden ook (originele) bandjes kan laden en saven..

Voorlopig nog voldoende te hobbyen!

Op 27 augustus 2020 10:20:12 schreef Ferenc:
Daarom heb ik als hobbyproject de P2000 opgepakt. Hoofddoel: een 21e eeuwse emulator voor de P2000T en P2000M :-) (en wie weet de P2000C??)

Die bestaat al. Vraag effe niet waar, google is your friend.

Henri's Law 1: De wet van behoud van ellende. Law 2: Ellende komt nooit alleen.

Op 24 augustus 2020 09:54:42 schreef Ferenc:
[...]

Wanneer ik in de monitor ROM kijk lijkt erop dat zowel de cassette als de printer data-bits daar via bit 7 gaan...

Ga ik niet op in. Zie gewoon maar bijgaande PDF (sheet 2), misschien kom je daarmee verder. Bedenk daarbij dat beide "devices" bits hebben in zowel de input- als output-poorten: niet verwonderlijk dat er stukken routine door beide gebruikt worden. Laat je niet van de wijs brengen: als er gewerkt wordt met de cassette dan is er geen tijd voor wat anders dan ook.

Deze PDF is een -ietwat verlate- "correctie" op de FSM... Er staat me vaag iets ervan bij dat ik van plan ben geweest die zowat onleesbare pagina's van de sheets (rechtstreeks als PDF 300dpi gescand) te vervangen door JPG 300dpi, maar waarom dat niet ervan kwam, tsja...

Deze scans zijn stukken beter leesbaar, inclusief pennummers. Let wel, alles gaat over het originele ontwerp; of het schema ook wijzigde bij de herziening van de layout, geen idee.

Ik weet ook niet meer of dan tevens de originele sheets van de P2000M-boards erbij zaten (floppy en video). In ieder geval, de enige vellen die ik van die FSM nog heb zijn die (A3) "motherboard"-sheets. De ordner is leeg...

Over ordners gesproken: behalve 1 die ik misgelopen ben -ik meen de Field Service Manual- kwam ik er nog wel 2 tegen waarvoor heel misschien belangstelling bestaat: ergens hier of op retroforum.nl heeft iemand eens 't erover gehad dacht ik.

Die gaan over UCSD-Pascal: de User's Manual en de Internal Architecture Guide. Berkeley uni?

Geen wonder dat ik (nog) nooit begonnen ben die in te scannen want die eerste is me een -letterlijk- zwaar geval; honderden pagina's!

Als iemand die vette PDF's wel zou willen: als je erg lief tegen me doet dan ben ik misschien wel zo gek eraan te beginnen.

Ach ja, de Tour begint morgen en dat gaat ook in etappes.

Enjoy.

...

Verdomd, die PDF is te groot; welja. En op retroforum heb ik ook al niet genoeg ruimte meer over. Later gesplitst, sorry dus.
Of ik stuur e.e.a. maar weer naar github, 't "P2000T Preservation Project" van @dionoid op retroforum.

If the computer really is intelligent nobody will recognise the fact. Because we aren't. - Chad C. Mulligan
bprosman

Golden Member

Geen wonder dat ik (nog) nooit begonnen ben die in te scannen want die eerste is me een -letterlijk- zwaar geval; honderden pagina's!

Als het losbladig is, ik heb een printer/scanner met "automatische velvoeder"

De jongere generatie loopt veel te vaak zijn PIC achterna.

Op 28 augustus 2020 11:19:15 schreef cancom:
[...]

Ga ik niet op in. Zie gewoon maar bijgaande PDF (sheet 2), misschien kom je daarmee verder. Bedenk daarbij dat beide "devices" bits hebben in zowel de input- als output-poorten: niet verwonderlijk dat er stukken routine door beide gebruikt worden. Laat je niet van de wijs brengen: als er gewerkt wordt met de cassette dan is er geen tijd voor wat anders dan ook.

Ik had inmiddels mijn verkeerde conclusie (die ik trok op basis van een foutje in het commentaar in de monitor disassembly) al gecorrigeerd...

Er worden door de casseteroutines wel degelijk bytes naar de printer gestuurd, maar alleen tijdens sommige waits als er gaps geskipt worden.
De wait-routines die dat doen corrigeren netjes hun delay, afhankelijk van of ze wel of niet een of 2 bytes naar de printer sturen.

Hopelijk zet dionoid die pdf binnenkort in die repo...
by the way: Ik heb aan dionoid ook een pull-request gestuurd voor de "P2000 System T & M Reference Manual.pdf" die ik vanmorgen heb ingescand... (22.5 Mb)
Stond ook niet in de repo.

Op 28 augustus 2020 12:48:53 schreef Ferenc:
[...]
Er worden door de casseteroutines wel degelijk bytes naar de printer gestuurd, maar alleen tijdens sommige waits als er gaps geskipt worden.
De wait-routines die dat doen corrigeren netjes hun delay, afhankelijk van of ze wel of niet een of 2 bytes naar de printer sturen.

Bij geen enkele schrijfactie naar poort 16 wordt bit 7 van status veranderd tijdens een cassette-actie. Er wordt geen enkel "byte verstuurd" naar de printerpoort pen 3 (Tx), die wordt netjes koest gehouden.

---

Er viel me een detail op in dat blokje met een stukje instructies voor de cassette: op de voorlaatste regel staat:

rrc a

Let op met zelfs zoiets als een spatie: deze 2-byte 8080-instructie is in de Z80 aangevuld met een 1-byte versie: rrca. Het verschil levert in dit geval een bin op die niet identiek is aan het origineel.

---

Die sheets van 't "mainboard" dan maar in twee keer.

FSM pages 4-11 through 4-14.pdf

Wtf... stond er laatst nou niet een limiet van 5Mb?!
Nu 4... nog meer knippen dus, sheets 1 en 2 morgen ofzo.

Dat is dan voorlopig wel 't laatste; ik ben wel bezig alles samen te harken in 1 map (nu zo'n driekwart gigabyte) maar dat is nog niet af. Dan gaat die map maar weer in een WeTransfer naar github en 't hcm in Helmond. Wordt de mapstructuur dan wel behouden, vraag ik me nu af...

If the computer really is intelligent nobody will recognise the fact. Because we aren't. - Chad C. Mulligan
bprosman

Golden Member

Mocht je de WeTransfer link hier of via mail willen delen houd ik me aanbevolen.

De jongere generatie loopt veel te vaak zijn PIC achterna.

Op 31 augustus 2020 00:43:31 schreef cancom:
....
Er viel me een detail op in dat blokje met een stukje instructies voor de cassette: op de voorlaatste regel staat:

rrc a

Let op met zelfs zoiets als een spatie: deze 2-byte 8080-instructie is in de Z80 aangevuld met een 1-byte versie: rrca. Het verschil levert in dit geval een bin op die niet identiek is aan het origineel.
....

Dat rrca != rrc a had ik inmiddels ook gevonden door code die wordt gegenereerd obv mijn disassembly te vergelijken met de ROM...
iig bedankt voor je scherpe blik en kennis van de P2000 :-)

Op 28 augustus 2020 11:45:20 schreef bprosman:
[...]
Als het losbladig is, ik heb een printer/scanner met "automatische velvoeder"

Jaah... als je die documentatie wel wil: ik heb geen zin om met die ordners naar DB te treinen. Btw: totaal 610 A4-vellen! Ik neem aan dat die scanner van je wel sneller zal zijn dan mijn nogal oude HP2200; maar toch hé?

En die WeTransfer: ok als je niet bij github of hcm wil downloaden wat je interesseert maar ik heb je email-adres niet meer. Dat van @dionoid ook niet trouwens. Want ik heb alles opgeruimd op de PentiumIII (met o.a. XP) omdat ik daarmee niet meer 't net op ga. Wanneer 't met dat ding niet meer mogelijk zal zijn om te internetbankieren met die Firefox-op-leeftijd weet ik veel; ik ben dat voor met een nogal prima laptop van "slechts" zes jaar oud. Ondanks wat dan ook: je wordt tegenwoordig zo ongeveer gedwongen te upgraden... Yeah, I'm slightly pissed off about that.

Maar nogmaals: de map voor die WeTransfer, genaamd "P2000" (hoe verzin ik 't), laat nog wel even op zich wachten. Momenteel kan ik niet bij alles op de diverse dragers van de P2000T vanwege wat mankementen...

En nu maar weer een poging de overige sheets hier te uploaden:

FSM pages 4-7+8.pdf

FSM pages 4-9+10.pdf

Enjoy.

If the computer really is intelligent nobody will recognise the fact. Because we aren't. - Chad C. Mulligan
bprosman

Golden Member

Jaah... als je die documentatie wel wil: ik heb geen zin om met die ordners naar DB te treinen. Btw: totaal 610 A4-vellen! Ik neem aan dat die scanner van je wel sneller zal zijn dan mijn nogal oude HP2200; maar toch hé?

Was ook maar een vrijblijvend aanbod :-)

maar ik heb je email-adres niet meer. Dat van @dionoid ook niet trouwens. Want ik heb alles opgeruimd op de PentiumIII (met o.a. XP) omdat ik daarmee niet meer 't net op ga.

Staat openbaar in mijn profiel.

De jongere generatie loopt veel te vaak zijn PIC achterna.

Op 1 september 2020 07:41:50 schreef bprosman:
[...]
Was ook maar een vrijblijvend aanbod :-)

[...]
Staat openbaar in mijn profiel.

Toch bezig met dat inscannen van die UCSD-docu, zo tussen de bedrijven door. Terwijl voorlopig die P2000-map een zip oplevert van 700+MB. Je kan t.z.t. een emailtje verwachten. Jawel, je adres staat in je profiel; ik log meestal stomweg niet in en denk dan niet aan de info die je ingelogd kan vinden...

Apropos: hoe gaat 't met die M2200? Werkt alles? En heb je die PDF bij de hand?

If the computer really is intelligent nobody will recognise the fact. Because we aren't. - Chad C. Mulligan

Op 31 augustus 2020 00:43:31 schreef cancom:
[...]

Bij geen enkele schrijfactie naar poort 16 wordt bit 7 van status veranderd tijdens een cassette-actie. Er wordt geen enkel "byte verstuurd" naar de printerpoort pen 3 (Tx), die wordt netjes koest gehouden.

Ik heb inmiddels de hele ROM gedisassembleerd en ge reverse-engineered.

Wanneer je bij aanroep van cas_Init het deurtje van de cassette open hebt, en het write protect voeler pinnetje indrukt (geen cassette, write enabled!) wordt bit 2 in cassette status gezet:

code:


; cas_Init
; reset cassette status, motor status.
; checks MDCR bits CIP and WEN
; returns:
; NZ for valid CIP/WEN combinations (01, 00, 11)
; Z  for invalid (10) combination
;    AND sending of cassette status bytes to the comm port is turned on
;
cas_Init:
        xor a
        ld (cassette_status),a      ; reset status bits for cassette
        ld (motor_status),a         ; and cassette motor (motor off and not writing)
        in a,(CPRIN)                ; read cassette status from device  
        and CIP|WEN                 ; interested in tape present and write protect notch
                                    ; valid combinations are:
                                    ; 01 = cas loaded, write protected
                                    ; 00 = cas loaded, write enabled
                                    ; 11 = no cassette, write protected
                                    ; INVALID combination:
                                    ; 10 = no cassette, write enabled
        cp CIP                      ; Compare with Invalid combination No cassette, write enabled
        ret nz                      ; Valid state, so all ok

; invalid cassette sensor combination!!
; An engineer may force this by deperessing the write-protect sensor during a call to cas_Init.
; this code will then turn on the bit that enables output of status bytes to the comm port at 2400 baud.
; In this way the cassette behavior can be followed in more detail.
        ld hl,cassette_status
        set CST_TOCOMM,(hl)         ; set bit 2 in status: enable send error/status bytes to RS232 port 
        ld e,KBIEN                  ; send_cas_status expects CPOUT value in E
        ld h,'1'                    ; status '1' to comm port
        jp send_cas_status          ; returns Z (error)

Wanneer dat bitje aanstaat, sturen cassette operaties status bytes naar de COMM port. Dat gebeurt tijdens GAP-Writes (bij schrijven) of Skips (bij lezen). Hier de code die dat doet met uitleg van wat de codes betekenen:

code:


; send the byte in H to the RS232 comm port (usually the printer) at 2400 baud during a tape-operation
; because reading and writing bits to and from the tape is very time-critcal, this always happens during
; the GAP interactions, which write (or read) a static value, or at the end when the cassette motor is stopped
;
; Format: startbit (1) 8 databits stopbit (0)
;
; My timing calculation (see T-state figures in the comments below) results in ~ 1040 T-states/bit
; that is almost exactly 2400 baud, hardcoded
; returns: Z set (success)
; status byte in H data in H
; current CPOUT value in E, to keep the Cassette command alive while writing bits to the comm port.
;
; status byte meaning:
; '1': cassette status logging to comm port initialized
; '`': block write REPLACE progress, a '`' is sent when:
;       - block replaced successfully
;       - all blocks replaced (end WRITE replace)
;       - failure during append, a second char may specify reason (cassette_error).
; 'a': block write APPEND progress, an 'a' is sent when:
;       - block appended successfully
;       - last block is appended (end WRITE append)
;       - failure during append, a second char may specify reason (cassette_error).
; 'b': block READ progress, a 'b' is sent when:
;       - block read successfully
;       - last block is read successfully
;       - failure during read, a second char may specify reason (cassette_error).
; 'c': Mark error, a second char specifies reason (cassette_error)
; 'd': REV_Skip block: One Block skipped, one for each block 
; 'e': REV_Skip block: invoked
; 'f': FWD_Skip block: invoked
; 'g': cas_Rewind: invoked
; 'h': Write_EOT: invoked

send_cas_status:
                                    ; TTTT 
        ld b,009h                   ;    7 in total 10 bits to write, we do startbit and 8 data bits in a loop, and end with the stop bit 
        ld a,e                      ;    9 save tape status bits in A
        and 01111111b               ;    7 clear bit 7 (RS232 data bit)
        ld e,a                      ;    9 back in E
        rlc e                       ;    8 shift command 1 bit to the left 
                                    ;   40 states for setup
send_bit_loop:
        xor 080h                    ;    7 invert bit (0)(1) (first bit is startbit)
        out (CPOUT),a               ;   12 send command with data bit in bit 7 to the comm port
        call put_bit_delay          ; 1005 delay T-states (988 + 17 (call) = 1005)  0,000404
        srl h                       ;    8 next data bit in carry (0)(1)
        ccf                         ;    4 complement (invert) carry (1)(0) (will be corrected again by the XOR before the out)
        ld a,e                      ;    9 get left-shifted tape commandstatus bits
        adc a,0                     ;    7 add zero with carry, so bit 0 now contains databit
        rrca                        ;    8 rotate right, bit now in pos 7  (1)(0)
        djnz send_bit_loop          ;   13 write bits until done
                                    ; 1073 times 9 bits - 5 for the last djnz not branching 
                                    ; 9652 (1073*9-5)

        and 07fh                    ;    7 prepare stopbit (zero) 
        out (CPOUT),a               ;   12 write stopbit 
        rrc e                       ;    8 restore E 
                                    ;   27 cycles for sending the stop bit
                                    ; fall through in delay for stop bit

; bit delay takes 7+61*16+10 = 988 T-states
put_bit_delay:
        ld d,03dh                   ;    7 loop 61 times 
put_bit_delay_loop:
        dec d                       ;    4 T-states 
        jr nz,put_bit_delay_loop    ;   12 T-states NZ, 7 T-states Z
        ret                         ;   10 T-states
                                    ;  988 for stop bit
                                    ; TOTAL T-states: 40 + 9652 + 27 + 988 = 10.707 
bprosman

Golden Member

Ik heb inmiddels de hele ROM gedisassembleerd en ge reverse-engineered.

Mooi werk. Ga je dat ook delen/publiceren ?

De jongere generatie loopt veel te vaak zijn PIC achterna.

Zeker!
Ik heb al een pull-request open staan op de github-repository: disassembly pull request
Je kan alvast kijken, en als een git-repo te hoogdrempelig is kan ik uiteraard ook hier een zipje delen ;)

bprosman

Golden Member

Op 28 september 2020 15:41:22 schreef Ferenc:
Zeker!
Ik heb al een pull-request open staan op de github-repository: disassembly pull request
Je kan alvast kijken, en als een git-repo te hoogdrempelig is kan ik uiteraard ook hier een zipje delen ;)

Nee hoor github is prima, dank en zeer leerzaam !!

De jongere generatie loopt veel te vaak zijn PIC achterna.

Op 28 september 2020 09:58:24 schreef Ferenc:
[...]

en het write protect voeler pinnetje indrukt (geen cassette, write enabled!)

[...]
Wanneer dat bitje aanstaat, sturen cassette operaties status bytes naar de COMM port. Dat gebeurt tijdens GAP-Writes (bij schrijven) of Skips (bij lezen).

Dat eerste komt nooit voor...

En v.w.b. 't tweede: hang voor de aardigheid eens een logicprobe (deed ik) of een scoop aan de Tx-pen: and the rest is silence.

If the computer really is intelligent nobody will recognise the fact. Because we aren't. - Chad C. Mulligan

Ik geloof je direct, alleen de software zegt wat anders, en probeert wel degelijk bytes naar de COMM poort te sturen.
Dat ze daar uiteindelijk niet aankomen kan allerlei (hardware) redenen hebben, een leuke puzzel om eens uit te zoeken.

Ik heb ooit een chinese (kopie van een) SALAE logic analyzer gekregen, nog nooit wat mee gedaan, eens kijken of ik die aan de praat kan krijgen...

Ik heb het op een andere manier getest, en ik zie, zoals verwacht :-) bytes verschijnen op de comm port!

Wat heb ik gedaan:
Mijn laptop met een serial-usb kabeltje aan de serial port van de P2000 gehangen en een serial port monitor programma gestart. Dat laten luisteren op de juiste poort op 2400 baud, 8 databits, No Parity, geen flow control en 1 stopbit.

Vervolgens de P2000 met een BASIC cartridge erin aangezet, het cassetteklepje opengedaan en de P2000 gereset met alleen het LINKER voeler-pinnetje:

ingedrukt. En toen kwam er 1 byte, hex 0xCE op mijn laptop binnen:

De bits worden geinverteerd verzonden, CE = 11001110, geinverteerd 00110001 = hex 31 = ascii '1', zoals ik al had afgeleid uit de disassembly.
Daarna heb ik een cassette met 4 BAS bestanden in de cassettedrive gestopt en op shift-ZOEK gedrukt. De P2000 spoelde terug en vond 4 bestanden:

Op de laptop kwamen tijdens dat proces de volgende bytes binnen:

Uitleg codes op de COMM port:

code:


BA          -> 0x45                = 'E'         : end of tape na terugspoelen.
98 FF       -> 0x67 0x00           = 'g' 0       : rewind invoked, no error
9d FF 9d ff -> 0x62 0x00 0x62 0x00 = 'b' 0 'b' 0 : 2 maal block read, ok       (file 1)
99 FF       -> 0x66 0x00           = 'f' 0       : forward block skip, ok 
9d FF 9d ff -> 0x62 0x00 0x62 0x00 = 'b' 0 'b' 0 : 2 maal block read, ok       (file 2)
99 FF       -> 0x66 0x00           = 'f' 0       : forward block skip, ok 
9d FF 9d ff -> 0x62 0x00 0x62 0x00 = 'b' 0 'b' 0 : 2 maal block read, ok       (file 3)
9d FF 9d ff -> 0x62 0x00 0x62 0x00 = 'b' 0 'b' 0 : 2 maal block read, ok       (file 4)
99 FF       -> 0x66 0x00           = 'f' 0       : forward block skip, ok
9C B2       -> 0x63 0x4D           = 'c' 'N'     : mark error, mark not found  (no more files)

Er worden dus 4 files gevonden (block read paren). Hoe de 'ZOEK' functie precies werkt is iets om nader uit te zoeken ;-)

Op 2 oktober 2020 17:07:25 schreef Ferenc:
ik zie, zoals verwacht :-) bytes verschijnen op de comm port!

Hm, hoezo gaf de logicprobe geen sjoege; dan toch niet in pulse-mode?

Nou ja, geeft niks. Ik heb geen zin om ook nog eens de scoop eraan te hangen. Want ik vermoed dat de lui van Philips ook gedacht kunnen hebben: wat maakt het uit?

Wat opvalt aan al die bytes is bit 7. Mijn Gemini-10X printer gaat totaal niet reageren want er zit geen enkel commando-byte bij. Ofwel: die blijkbaar ontvangen bytes vanaf de printerpoort worden simpelweg genegeerd. So, who cares?

Mogelijk hebben de programmeurs het maar erbij gelaten om in het "monitor"-programma e.e.a. netjes af te vangen -voor een gedeelde poort- omdat 4kB nou eenmaal niet veel is. En er moest gewerkt worden met de beschikbare hardware.

Maar goed, puzzel maar naar hartelust verder naar elk bitje.

If the computer really is intelligent nobody will recognise the fact. Because we aren't. - Chad C. Mulligan

Ik denk, net als jij, dat die output op de printerpoort niet voor de printer, maar voor een andere tool die ook via RS232 werd aangesloten, was bedoeld...

Ik heb ondertussen de MDCR aan de praat in mijn eigen emulator, en kan .cas bestanden lezen en schrijven, dat was na al dat gedisassembleer niet meer heel ingewikkeld...

Nu ben ik bezig met het scroll register: out &h3x ,offset.
Simpel voor waardes van 0-40, maar ik zie dat als je waardes groter dan 40 stuurt, die niet simpel 'wrappen' maar dat er wat vreemd gedrag optreedt.
En bij een waarde van 128 en hoger wordt het hele scherm wit.

Voordat ik dubbel werk doe: Weet iemand of dat gedrag ergens is gedocumenteerd? Of misschien logisch is als je weet welke chip die waarde gebruikt?

Alweer bedankt!