HAL9000

Als ik kijk naar hoeveel speling bijvoorbeeld de BASIC module heeft in het slot, zou je de behuizing ook makkelijk een mm of 2 'dikker' kunnen maken... Just my 2 cents.

Ik heb een DM gestuurd, wil ook graag testen

13 hours ago, cancom said:

Ik weet niet (meer) wat voor ding die C ook weer is, maar ok. Je zal wel e.e.a. moeten aanpassen en/of wijzigen. B.v., je zal opmerken dat ik NIET de standaard printerpoort gebruik. Waarom zou ik, ik heb die SIO op de M2200. Dat gaat makkelijker, betrouwbaarder en sneller.

 

Succes ermee. Je weet waar me te vinden mocht je nog vragen hebben over die routines.

Heel veel dank, ik ga ermee aan de slag!!

5 hours ago, cancom said:

En sorry HAL9000: mijn vergeetachtigheid hield in dat die M2200.pdf nog niet op github staat want die heb ik nog niet opgestuurd. En hier als bijlage zetten gaat niet meer vanwege te weinig ruimte. Je kan die pdf wel vinden in een P2000-topic op COL, ergens.

 

Wat er wel staat in documentation/hardware op github is de datasheet van die floppycontroller-chip type 765. Dat is voor het geval dat je die nodig hebt: ik heb geen idee wat er wel nodig is voor je emulator. Is een opsomming van de commando's en mogelijke instellingen van b.v. JWS-DOS al genoeg?

Want die controller-gegevens komen op de proppen bij een fysieke aansluiting en dat is iets geheel anders.

Ten eerste wederom bedankt voor alle info, dat helpt heel veel

Ik heb, door de monitor te disassembleren, begrepen dat de floppy-controllers 'intelligent' zijn, en dat die na een commando te hebben uitgevoerd, een interupt triggeren.

Voor mij is dus de interne werking van de controller en chips minder belangrijk (nu): ik kan bij bijvoorbeeld een 'read track' commando de 16 (of wat er is ingesteld in dat commando) data-sectoren naar het huiste geheugenadres verplaatsen en dan de juiste interrupt (van de CTC) triggeren.

Dus aan deze tracks, en eventueel de handleiding/commando's van JWS-DOS zou ik al heel veel hebben om allerlei tests te kunnen doen.

Beschrijving van de chips (en controllers zelf) is uiteraard ook interessant: ik heb de CTC documentatie ook gebruikt om die goed te kunnen emuleren.

Maar ik wil eerst zorgen dat alles zoveel mogelijk werkt, en daarna gaan werken aan de (preciezere)emulatie van de hardware zelf.

Ik ga even kijken op COL voor die M2200 documentatie, altijd leuk voor op het nachtkastje! 

16 hours ago, cancom said:

En die "images" heb ik overgebracht met een routine die ik gemaakt heb met de Zemon-assembler en daarin uitgevoerd met "go adres". Aan de ontvangende kant gebruikte ik Hyperterminal.

 

En oh ja, als je 't hebt over compressie en andere features die je op een PC tegenkomt: vergeet dat alles! De P2000 is geen PC!

Ik noemde compressie omdat het kon zijn dat de tool om images te maken/terug te schrijven (op de pc) die images wel comprimeerde. Dat er standaard geen compressie was kan ik me nog goed herinneren!

Heb je die asm code nog? Wellicht kan ik die ook gebruiken om wat floppen over te zetten naar de PC, met hulp van de P2000C, waarvan ik ergens las dat die heel veel soorten floppen kan lezen.

Ik heb een serial-receive programmaatje gemaakt op de PC en daarmee heb ik al een aantal bandjes overgezet om mijn cassette-emulatie te testen.

1 minute ago, Keetie said:

Voor CP/M zeer zeker.

Dan ga ik die zeker meenemen, bedankt!

Vandaag deze ouwe reus aangesloten, en hij doet het! Volgens mij wat gemodificeerd, de 'Hallo Jan,' en HCC-P2000 gg lijken mij niet standaard.

Die laatste staat ook zonder een CPM bootdisk, na reset, gewoon in beeld!

Maar wel mooi: er zitten 2 stuks 5.25" drives en 1 maal een 3.5" drive en een ramdisk in. Hij boot netjes van een CPM disk.

Eerste taak: safety copy van de bootdisk maken denk ik...

Tweede taak: CP/M kennis bijschaven

NOTE: booten van de 3.5 flop doet hij niet en ook een DIR geeft een leesfout, denk dat die flop een ander doel had (zat wel in de 2000C toen ik m op de kop tikte)

3 hours ago, cancom said:

"zo'n bootdisk" is niet eenduidig, je hebt voor een Basic-module op de T (er zijn nog andere "bootdisk"s) sowieso al Miniware en JWS. Die laatste staat hier in een bericht van 30 juni.

 

Ik heb dat bestand uit dat bericht net bekeken, het zijn 4096+352 bytes, dat is meer dan 1 track van 16 sectoren*256 bytes, dus ik vermoed dat er nog wat (meta) data in zit. Is er een beschrijving van het formaat? Misschien kan dat worden afgeleid uit het tooltje, dat je noemt, waarmee deze bin naar disk kan worden geschreven?

De data lijkt uncompressed omdat ik her en der leesbare/herkenbare stukjes Hex zie,

Ik bedacht me ook dit: de 'monitor' leest van een 'stand-alone' boot disk 2 tracks, (2*4k), dan is dit weer te weinig data.

Het zou kunnen zijn dat deze track/data wordt ingeladen door de software in de JWS insteekmodule en niet door de monitor.

Die JWS module ken ik niet, dus dat ik het mis heb is heel goed mogelijk.

Ik ben wel blij met alle nieuwe dingen die ik leer van deze input, merci!

3 hours ago, cancom said:

"zo'n bootdisk" is niet eenduidig, je hebt voor een Basic-module op de T (er zijn nog andere "bootdisk"s) sowieso al Miniware en JWS. Die laatste staat hier in een bericht van 30 juni.

 

Ik heb ooit een backup van al m'n flops (Basic, Zemon, CP/M, UCSD Pascal e.a.) naar de PC gestuurd; dat gaat dan om track-voor-track "images" van b.v. 640 of 800 kB. Of ik die ook in de ooit te uploaden ZIP ga zetten weet ik zo net nog niet (ik zou eerst moeten nagaan waarin privacy-gevoelige records o.i.d. staan). Een en ander barst wel van de eventueel voor lieden hier interessante programma's e.d.

 

Interssant. En dat er meerdere bootdisks zijn lijkt me ook logisch . 

Maar als ik 1 bootab1le disk-image aan de praat kan krijgen zou dat in princpe voor allemaal moeten werken.

Wat ik wel heb begrepen is dat zo'n disk een 'signature' heeft: 0xf3 (ofwel 0f3h) als eerste byte van de eerste track, die door de monitor van de P2000T/M wordt ingeladen op e000h . Bij de images die ik heb gevonden is die eerste byte 0xc3, dus ik vermoed dat deze P2000C images NIET compatible zijn met de P2000T/M.

Kan jij je nog herinneren hoe je die images hebt gemaakt? En waren de disks voor de P2000 enkel- of dubbelzijdig? Of kon allebei?

Vermoedelijk is daar in een (service) manual iets over te vinden, alleen ben ik het nog niet tegengekomen.

Trouwens: Die UCSD Pascal intrigeert mij zeer. Ik heb daar originele manuals van op de kop getikt, alleen geen software.

Klopt, en via die site ook info gevonden om het te kunnen lezen.

Maar mijn vraag was niet hoe dit formaat werkt, maar of het een goede kandidaat is om te ondersteunen...

Ergens in dit topic heb ik een referentie gevonden naar een paar P2000C disk-images, die zijn in 'IMD' formaat. (Deze dus) 

Ik heb even een quick-and-dirty loader geschreven voor het IMD formaat, om wat boot tracks te kunnen analyseren, ervan uitgaande dat deze tracks ook werken voor een P2000T/M

Is er iemand die weet of dit IMD-formaat (nog steeds) een veelgebruikt formaat is?

Of is er wellicht een andere standaard waarin ook (meer?) disk images voor de P2000 te vinden zijn?

Dit vraag ik om een goede keuze te maken voor de te ondersteunen formaten voor het floppy-image-support dat ik wil gaan implementeren in mijn P2000(T) emulator.

thx!!

Simpele manier: Je kan de hele repo als een zip downloaden en de spullen uit dat archive halen. Als je later bijdragen wil doen aan de repo dan zijn er allerlei methodes en tools...

Heb jij verstand van hardware? Ik heb een P2000C die wat display-issues heeft  

13 hours ago, dionoid said:

 

Dat klinkt heel erg veelbelovend! Ben je van plan om de sources te delen via Github o.i.d.?

Jazeker, zodra het interfacedeel klaar is zet ik mijn github repo op public...

Ik heb zelf, voor mijn plezier, in het afgelopen jaar een P2000T emulator geschreven in C# en .NET Core. Doel: 'modernere' emulator die op Windows, Linux en Mac kan draaien.

Hij doet het prima 'on my machine', maar is nog niet van een gebruiksvriendelijke UI / commandline voorzien, daar ben ik nu mee bezig.

Ik heb ook interesse om een keer een floppydrive, systeem met interface en een bootflop te lenen zodat ik ook de floppy emulatie kan implementeren. 

Zolang ik geen toegang heb tot een systeem/drive zou ik ook al geholpen zijn met een image van zo'n bootdisk, en eventueel ook andere images.

Weet iemand of die ergens te vinden zijn? 

Zijn de floppen voor een P2000M/C gelijk aan die voor een P2000T?

Ik ben op zoek naar (een P2000 met) een miniware uitbreidingskaart. Heeft of weet iemand er een (te koop)??

On 5/4/2021 at 11:48 AM, Wolf said:

Hij spoelt alleen vooruit. Niet achteruit.. 

 

Lijkt mij interessant om nader uit te pluizen. Ik heb evt. een P2000 te leen.

Doet de drive helemaal niks, dus ook niet spoelen?

Helaas kan ik je ook zelf niks meer vertellen. Ik heb ook wat gezocht op internet, hierbij mijn 2 cent:

Hier: https://forumindex.nl/techniek/memory-lane-mijn-eerste-eigen-computer-t98478.html

staat in een reactie: Ik mocht zowaar op school een computer cursus volgen, programmeren in ecol. 1972 (vereenvoudigde algol eigenlijk)

En in deze PDF: https://pure.tue.nl/ws/files/3119549/200810691.pdf

staat op pag. 314: ECOL Educational Computer Language

Het lijkt dus op een educatief in te zetten programmeertaal.

Dus dat het Ministerie van onderwijs er iets mee van doen had klinkt dan logisch...

Ik heb ondertussen de MDCR aan de praat in mijn eigen emulator, was na dat gedisassembleer niet meer heel ingewikkeld...

Nu ben ik bezig met het scroll register. out &h3x , offset. Ik zie dat als je waardes groter dan 40 stuurt, die niet 'wrappen' maar dat er wat vreemd gedrag optreedt.

En bij een waarde van 128 en hoger wordt het hele scherm wit.

Weet iemand of dat gedrag ergens is gedocumenteerd?

Door jullie foto's herinnerde ik me opeens dat ik ook een paar printplaatjes had aangetroffen in een doos met P2000 spul.

3 stuks 8-in-1 printje:

en 5 Centronics boards:

In de doos zaten ook 4 niet-zo-standaard P2000 insteekmodules:

Misschien dat de Centronics print een kopie is van die op de foto... 

Ik ga dat vanavond eens bekijken!

On 9/22/2020 at 2:12 PM, HAL9000 said:

 

Ik heb inmiddels de hele monitor gedisassembleerd en ge reverse engineered, en zal de .asm files toevoegen aan de github repo,

Pull request is gemaakt, @dionoid is nu aan zet. hier een preview: https://github.com/p2000t/documentation/pull/4/commits/3571d9ca7a28ff7461443b5cbc5d2b026e1b9142

On 9/13/2020 at 11:21 PM, pokowaka said:

Dat is volgens mij de terugspoel routine. Ik ontdekte dat er in terug blok (0c61) routine iets vreemds aan de hand was. Hier zijn de stukjes:

 

;; Read the RDA state and set bit 5 in A
;; RDA_state | BET
;; Note when the tape is moving in reverse this actually gets the RDC bit.
get_rda:
      in       a,(cas_inp)    ;0cee    db  20
      and      080h           ;0cf0    e6  80
      set      5,a            ;0cf2    cb  ef
      ret                     ;0cf4    c9

      ;; This seems to read a byte when the tape is moving backwards.
      ;; Note that RDA <-> RDC when moving backwards.
      ;;
      ;; Args:
      ;;   A must contain the current state of RDC & BET
      ;;   D related to time we are willing to wait to see a byte.
      ;;
      ;; Returns:
      ;;   Sets the C flag in case of failure (beginning of tape, or tape removed.)
      ;;   Sets (caserror) with the actual error in case C is set
read_rev_byte:
      ld       c,008h         ;0cbf    0e  08        ; wait for at most 8 bits
rev_next_bit:
      xor      080h           ;0cc1    ee  80        ; Flip the expected RDA, we wait for next clock
      ld       h,a            ;0cc3    67           
l0cc4h:
      ld       b,000h         ;0cc4    06  00        ; Max time we are willing to wait for RDA clock signal, we loop 256 times
wait_for_rev_bit:
      ; Keep spinning until we have a bit flip
      in       a,(cas_inp)    ;0cc6    db  20        ;
      and      0b0h           ;0cc8    e6  b0        ; RDA, BET, CIP
      cp       h              ;0cca    bc            ; Is the clock state as expected?
      jr       z,rev_bit_available  ;0ccb    28  10  
      djnz     wait_for_rev_bit     ;0ccd    10  f7  ; Spin until RDA changes.
      and      030h           ;0ccf    e6  30        ; mask bet & cip
      cp       020h           ;0cd1    fe  20        ; this checks for errors.
      jr       nz,read_rev_err     ;0cd3    20  0d   ; Check if we are at the end, or cassette removed.
      dec      d              ;0cd5    15
      jr       nz,l0cc4h      ;0cd6    20  ec
      ld       a,h            ;0cd8    7c
      xor      080h           ;0cd9    ee  80
      inc      d              ;0cdb    14
      ret                     ;0cdc    c9
rev_bit_available:
      ;; This is called when we have a bit available..
      ld       a,h            ;0cdd    7c
      dec      c              ;0cde    0d
      jr       nz,rev_next_bit      ;0cdf    20  e0
      ret                     ;0ce1    c9  ; We have read 8 bits..

read_rev_err:
      ;; This happens when we hit the beginning of the tape, or if we
      ;; removed the tape while moving backwards.
      or       a              ;0ce2    b7
      ld       a,"E"          ;0ce3    3e  45   ; End of tape error
      jr       z,l0ce9h       ;0ce5    28  02
      ld       a,"A"          ;0ce7    3e  41   ; No tape
l0ce9h:
      ld       (caserror),a   ;0ce9    32  17  60
      scf                     ;0cec    37       ; Set the carry flag to indicate failure.
      ret                     ;0ced    c9

 

read_rev_byte lijkt alleen maar zinnig als het RDA bit wordt gebruikt als klok signaal. Wat blijkbaar ook het geval is.  Mame kan nu in ieder geval wav files schrijven en lezen, en een pull request is al open

https://github.com/mamedev/mame/pull/7215. Ik ben bezig met een converter van .cas -> wav zodat mame ook de cas files kan lezen.

 

Helaas bevatten de .cas files niet de checksum

Ik zie dat de 'read_rev_byte' routine ook wordt aangeroepen om bytes te skippen als de tape vooruit loopt (in de block_forward code), dus jouw hypothese dat RDC op RDA staat als REV actief is, lijkt niet te kloppen.
Volgens mijn analyse worden 8 data-bit transities geskipt in beide richtingen...

Dat zou een oorzaak kunnen zijn van het zo nu en dan niet goed kunnen 'doorladen', omdat de skip forward zich in jouw implementatie net iets anders gedraagt.

NB:

Ik heb inmiddels de hele monitor gedisassembleerd en ge reverse engineered, en zal de .asm files toevoegen aan de github repo,

8 minutes ago, pokowaka said:

W00T! Cassette support is nu in Mame! Het is nog niet helemaal perfect:

 

- Soms onverwachte cassette fout L

- Soms lukt het niet om van een laad scherm (piraten avontuur, ghosthunt) de juiste file te laden.

 

Dit zijn waarschijnlijk timing gerelateerde problemen. 

 

- Ongerelateerd aan de mini cassette, soms hangt mame voor een paar seconden.

SUPER!

On 9/14/2020 at 9:36 AM, pokowaka said:

 

void calc_chksum(uint16_t* de, bool bit)
{
	//  TODO Cleanup to something readable.
    uint8_t e = *de & 0xff;
    uint8_t d = (*de >> 8) & 0xff;
    e         = e ^ (bit ? 1 : 0);
    if (e & 0x01)
    {
        e = e ^ 2;
        d = d ^ 0x40;
    }
    else
    {
        d = d ^ 0x00;
    }
    bool c = d & 0x01;
    d >>= 1;
    bool cp = e & 0x01;
    e >>= 1;
    if (c)
    {
        e |= 0x80;
    }
    if (cp)
    {
        d |= 0x80;
    }
    *de = (d << 8) | e;
}

Mame kan nu native de .cas files inlezen. Met echte P2000t snelheid :-). 

 

Leesbaarder:

            
de ^= bit;
if (de & 0x01) de ^= 0x4002;
// we rotate the bits, and lo bit of de wraps to hi bit
uint16_t hibit = (de & 0x01) ? 0x8000 : 0;
de = hibit|(de>>1);

4 hours ago, pokowaka said:

Ik heb de checksum code achterhaald:

 

      and      001h           ;07ac    e6  01   ; DE with checksum is active
      xor      e              ;07ae    ab       ; a = written bit.
      ld       e,a            ;07af    5f       ; e = e ^ (bit written)
      and      001h           ;07b0    e6  01
      jr       z,l07d3h       ;07b2    28  1f   ; through a complex web it will jump to chksum (timing)
      ld       a,002h         ;07b4    3e  02
      xor      e              ;07b6    ab
      ld       e,a            ;07b7    5f       ; e = e ^ 0x02
      ld       a,040h         ;07b8    3e  40
chksum:
      xor      d              ;07ba    aa       ; a = d ^ (0x40 | 0x0)
      rra                     ;07bb    1f       ; >> 1
      rr       e              ;07bc    cb  1b   ; >> rotate through DE (i.e. e0 -> d7 etc..)
      jr       c,l07c2h       ;07be    38  02
      jr       l07c4h         ;07c0    18  02
l07c2h:
      or       080h           ;07c2    f6  80  ;
l07c4h:
      ld       d,a            ;07c4    57

 

 

Deze code was ik ook al op gestuit, in de inlees routine, had ik even geparkeerd.  Mooi dat jij die uit elkaar hebt geplozen... 

Iets verderop wordt DE (checksum dus op dat moment!) weer gebruikt:

; data handling routine 'read payload'
; it stores the data byte at destination.
; HL, BC, DE contain dest, count and data
; not sure yet what DE means here ?? when all bytes were read (DE == 0) ???? 
; ?????
read_payload:
        exx				; save databyte, destination and count, get DE 
; next byte a filler or payload?
        ld a,d			; DE contains ????? 
        or e			;
        jr nz,set_carry		; DE not zero

        ex af,af'       ; get load control flags (P, C)
        xor a			; Set Z flag, set P, clear carry
        jp store_byte 
set_carry:
        ex af,af'		; get load control flags (P, C)
        scf				; Set Carry
        rla				; shift in A
        or a			; NZ, Set P 
store_byte:
        exx				; get data byte, dest and count
        ld (hl),d		; store data byte
        cpi	        	; inc HL, dec BC  P <- 0 when BC == 0
                        ; this triggers next len, dest and handler retrieval 
                        ; after finishing the data block
        exx				; save dest, count
        jr get_next_byte

8 hours ago, pokowaka said:

 

De reden waarom de Cassette fout B optreed is omdat de P2000 bits telt tijdens het terug spoelen en uiteindelijk het begin van de tape bereikt. Het goede nieuws is dat het nu lijkt of alles werkt!

Mooi werk!!!

Kleine aanvulling: volgens mij (en mijn disassembly) telt de P2000 geen bits, maar seconden:

; cas_Rewind  (address 0x0bb4)
; rewinds tape for a maximum duration of 103 seconds.
; a verified data tape rewinds within 90-something seconds
; if EOT is not reached within 103 seconds, the tape is either broken
; or too long (not a supported tape) 
; inputs: none
; outputs: Cassette error contains no error, 'A' or 'I' 
cas_Rewind:
        call write_disabled             ; writing?
        ret nz                          ; yes! so don't rewind

        ld a,KBIEN|REV                  ; start rewinding
        out (CPOUT),a                   ; 
        ld b,103                        ; wait max 103 seconds  (1m 43s)
_rew_wait_loop:
        call wait_1second               ; this routine returns NZ when tape ejected or EOT is reached
        jr nz,_EOT_or_Ejected           ; EOT is what we want check this
        djnz _rew_wait_loop             ; keep rewinding for one more second 
        ld a,'I'                        ; still no eot after 103 seconds: Error 'I' means time out during rewind 
        ld (cassette_error),a           ; 
        ld c,00fh                       ; not sure why this is... ????

; status from wait_1_second can be:
; 0x41 = 'A' no tape
; 0x45 = 'E' end of tape (during write)
_EOT_or_Ejected:
        ld a,(cassette_error)           ; get error 
        cp 'E'                          ; equal to end of tape?
        jr nz,_was_ejected              ; no, other problem 
        ld a,0                          ; no error, because EOT is what we wanted here
        ld (cassette_error),a           ;
        ld hl,cassette_status           ;
        set 4,(hl)                      ; set begin of tape flag
        res 0,(hl)                      ; and start mark found (bit 0 == 0)
_was_ejected:
        ld h,'g'                        ; error code to write to comm port
        jp cas_motor_off                ; turn motor off and send h to comm (if this is enabled)