Philips P2000T kenner gezocht

Ik heb vroeger ook een P2000T gehad. Daar had ik zelf de geheugenuitbreiding bij gefabriekt (van de standaard 16kb naar 39kb plus nog wat schakelbare banken) en de in dit topic beschreven 4-in-1 uitbreidingsmodule.
Een andere handige toevoeging, die in het P2000 magazine is verschenen, was een 'soft' reset. Die genereerde een NMI als ik me niet vergis, en die werd in de Basic interpreter afgevangen waardoor het lopende programma stopte. Als je de reset toets lang ingedrukt hield werd een echte harde reset uitgevoerd en was je dus alles kwijt.

Als ik me goed herinner was Zemon een assembler waardoor je direct machinetaal programma's kon schrijven.

Groeten, Ron.

Mij is het in eerste instantie te doen om de oorspronkelijke machines (zowel mijn T als mijn M) die op zolder stonden te verstoffen weer aan de praat te krijgen. Wanneer daar tzt leuke zaken uit die tijd aan toegevoegd kunnen worden (cpm, ucsd, spelletjes) is dat aardig. En wanneer daar op kleine schaal ook voor anderen interesse is, zou een gg handig zijn. Zeker met mensen (@cancom) die in die tijd actief zijn geweest. Een centrale database met spul, ervaringen en hints lijkt me zeer handig.

Voor Zemon heb ik een handleiding helaas alleen niet de ROMS

Zemon.zip

Op 15 november 2019 12:53:37 schreef Rontronix:
Die genereerde een NMI als ik me niet vergis, en die werd in de Basic interpreter afgevangen waardoor het lopende programma stopte.

Een NMI-puls van gedefinieerde lengte veroorzaakt een sprong naar #66, en dat is dus in de monitor/bios. Welke module in slot1 zit doet er niet toe. Vooral handig in een assembler.

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

Ik vermoed dat er geen kip (in leven) meer is die bezwaar kan hebben tegen het verspreiden van wat dan ook wat met de P2000 te maken heeft; dus U vraagt, wij draaien. Zie maar hoe je 't in eprom(s) krijgt...

Op 15 november 2019 13:07:56 schreef WijnandJan:
...die in die tijd actief zijn geweest. Een centrale database met spul, ervaringen en hints lijkt me zeer handig.

Hoezo "geweest"?

En mogelijk zou het homecomputermuseum in Helmond willen meewerken.
Hun bedoeling is juist om de geschiedenis te laten zien, inclusief die van "onze" P2000's. En sowieso hebben ze daar belangstelling voor die spullen, ervaringen, hints; want daar zijn wel enkele P2000's maar nauwelijks meer erbij dan de Basic.

OK, wie is geinteresseerd in een apparte discussie/gebruikersgroep/database voor de P2000? Bij meer dan 10 man zal ik het proberen op te zetten. Suggesties wat daarvoor te gebruiken? Ik host mijn eigen spul op een Ubuntu-server maar dat kan of mag ook in de cloud (ook ik heb niet het eeuwige leven).

Laat maar horen...!

Op 13 november 2019 00:05:50 schreef henri62:
1: Ik zie net dat in het originele schema (field support manual) de CARSEL1/2 ook "omgedraaid" zijn en niet logisch.

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.

Adresdecoder pen 6 = CARS1 = slot 1 pen 12B,
pen 7 = CARS2 = slot 1 pen 13A.

Dat staat op pagina's 47 en 65.

Jammer dan, de signalen zitten op pennen 13A=CARS1 en 12B=CARS2.

Een logische aansluiting van signalen op connectors bestaat niet voor wat betreft de uiteindelijke layout... Het kan best dat de FSM al gedrukt was; maar dan heeft iemand vergeten b.v. een addendum toe te voegen want ik heb nergens een vermelding over die te verwisselen pennen gezien. Tsja.

...

Had deze nog niet gezien: https://www.circuitsonline.net/forum/view/140023/last#highlight=p2000

Daar gebeurt al een tijd niks meer maar toch dit dan voor de gelukkige bezitter: de Miniware multifunctiekaart M2200 bevat 64kb geheugenuitbreiding, een floppycontroller, RS232 en RS422, Centronics en een RTC.
En verder RAMdisk in 2 uitvoeringen: 64kb of 256kb.

De 64kb "gewoon" geheugen behelst 16kb als aanvulling tot &HE000 en de rest=48kb in banken van 8kb van &HE000 t/m &HFFFF, te schakelen met poort &H94.

De 80-kolomskaart is te activeren met out 0,1; terug naar 40 met dus out 0,0. Niet de poke&H60B0,79 vergeten of terug met poke&H60B0,39. De status van de poort lezen met inp(112).

Op Retroforum.nl heb ik onder dezelfde naam een aantal cartridges/modules gezet die interessant kunnen zijn voor deze of gene zoals 2 Maintenance-packs. D.w.z. 't gaat om dumps van eprom-inhoud; de extensie is niet van belang, maar er maar BIN van als je wil.

Die files staan ook op: https://github.com/p2000t

Voor bprosman: bijlage voor 't geval dat je die nog niet hebt gevonden. Misschien heb je ook al de accu vervangen; dat lijkt me in ieder geval wel nodig.

...

Voor de zekerheid dan maar een email met die M2200.pdf

Have fun.

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?

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.

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.

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"

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...

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

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.

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.

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?

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:

; 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:

; 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 

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

Mooi werk. Ga je dat ook delen/publiceren ?

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