An alternative CP/M method

Home Forums Z80 Playground Early-Adopters An alternative CP/M method

Viewing 15 posts - 31 through 45 (of 57 total)
  • Author
    Posts
  • #993
    GlynD
    Participant

    Life getting in the way of fun!

    Not sure if this will be of interest to you. I have managed to split up your CCP and BDOS into separate ASM files giving me the classical CCP, BDOS and BIOS (CBIOS) configuration. I did this because my CCP of choice is CCPZ and it anticipates there being this classical layout.

    For some reason I couldn’t just rip your supplied BDOS out of the CCP and get it to work. Instead I had to go back to an original BDOS found on a RunCPM (A:) drive. This was in 8080 syntax now converted to Z80. In theory I should be able to just throw any CCP, that follows this model, at the Z80 and it should just work. Anyway for me CCPZ works.

    Hope its OK to throw a zip file of sources on to your github portal under “issues”. Feel free to simply delete it if this is not a direction you want to follow or of interest.

    Enjoy,

    Glyn.

    #996
    Steve
    Participant

    Thanks for your work Glyn,

    The CCP is $800 bytes in size, so long as you have the start address it’s simply the case to overwrite those bytes with any other CCP. I’m unsure why you would have trouble splitting the source.

    Putting files under “Issues” on github might not be obvious to readers – especially when the issue is closed

    Cheers
    Steve

    #997
    GlynD
    Participant

    As my main intended use is as a CP/M machine, I’ve add a little bit of code to auto-boot into CP/M. My mod simply auto-boots into CP/M or if while pressing a key on the keyboard and the board reset, then the code drops into the Monitor. My coding is more hacking so could do with a bit of polish maybe but get the job done.

    I have added an additional function to lib.asm:

    
    ;     
    ; function CHAR_AVAILABLE
    ;
    ; Check to see if there is a character in the Line Status Register (LSR).
    ;
    ; A=0	No Characters waiting
    ; A=FF	Char waiting
    
    CHAR_AVAILABLE:
       IN	A,(UALSR)	; get status from Line Status Register		 
       BIT 	0, A	        ; zero flag set to true if bit 0 is 0 (bit 0 = Receive Data Ready)
    		        ; "logic 0 = no data in receive holding register."
       JP	Z,CHAR_AVAILABLE1 ; zero = no char received
       LD	A, $FF	         ; return true
       RET			; in A
    CHAR_AVAILABLE1:
       LD	A, 0	        ; Return a zero in A
       RET
    	
    ; function end
    

    When called all this does is check if there is a character in the UART buffer.

    Then in main.asm:

    CALL    PRINT_STR           ; display sign on message
    ; --- CP/M autoboot here
    CALL 	CHAR_AVAILABLE	     ;Got a char waiting?
    CP	0		     ;Zero = no
    JP	Z, cmd_cpm           ;NO: fire up CP/M
    CALL    MONITOR              ;YES: fire up the MONITOR 
    

    This calls char_available and if on return A=0 then nothing in the UART jump to the cmd_cpm function in commands.asm to load CP/M. If A isn’t zero, then there is a char waiting (key pressed) so jump to the Monitor.

    #1012
    GlynD
    Participant

    Hi Steve, would you be able to give me some pointers to “decode” the Disk Parameter Block (DPF)? For my own understanding, I’ve been trying to figure out how the physical disk and CP/M’s block structure stich together. In particular I’m trying to bring together the data presented when formatting a new disk image with the actual DPF in cbiso.asm.

    When formatting the onscreen info has:
    SPT BSH BLM EXM DSM DRM AL0 AL1 CHS OFF
    4000 04 0F 00 FF0F FF03 FF FF 0000 0000

    Total tracks: 0400h
    Disk size: 0 K

    cbios.asm DPB for the 8MB HD:
    dpblk2: ;disk parameter block for 8MB – 1024 tracks
    defw 64 ;sectors per track
    defm 4 ;block shift factor = block size of 2048 bytes
    defm 15 ;block mask
    defm 0 ;null mask
    defw 4095 ;disk size-1
    defw 1023 ;directory max
    defm 255 ;alloc 0
    defm 255 ;alloc 1
    defw 0 ;check size
    defw 0 ;track offset

    The problem I’m having is trying to match up:
    SPT 4000 with 64
    DSM FF0F with 4095
    DRM FF03 with 1023

    Many thanks for your time and patience

    #1013
    Steve
    Participant

    Hi Glyn
    The Z80 is little endian, meaning the low byte gets stored before the high byte eg. you have a 16bit value of $1234, it gets stored as $3412. So the SPT value you are looking at is in fact $40 = 64 sectors per track. Likewise, DSM is in fact $0FFF and DRM is in fact $03FF.
    To determine the actual disk size, you take DSM ($0fff) = (4095 + 1) * block size (2048) = 8386560 Bytes.
    The directory size is determined by DRM, which in this case is $03FF = 1023 + 1. The +1’s above are because the values start at 0.

    Does that help?
    Cheers
    Steve

    #1014
    GlynD
    Participant

    Hi there, certainly helps and excellent explanation. Using the numbers in the DPB, I could get the sectors, tracks and blocks size etc. to come out at the correct 8MB, but I just couldn’t see how that worked in the format display. I hadn’t even considered endiness!

    I was just about to work my way through format.asm to see if it lead me anywhere. Glad I checked my emails first!

    Thanks again,

    Glyn.

    #1024
    Steve
    Participant

    Glyn – I have uploaded to git a working version of filetransfer.asm. You will now be able to populate the /TFER directory with a theoretical limit of 85 files (I could increase this number, but I think it unlikely anyone would want to transfer as many as that, let alone more). All files will be created on the D: drive – let me know if you think you want control over the destination

    Regards
    Steve

    #1026
    GlynD
    Participant

    Hi Steve, excellent news I will head over there to get the latest version. Drifting over the source file on git, I notice filetransfer.asm still has an includes memorystick_small.asm, which I didn’t spot in the github site?

    Am I looking in the wrong place?

    Looking forward to giving it a go.

    Thanks,

    Glyn.

    #1027
    GlynD
    Participant

    Ops sorry Steve, I was a bit quick off the mark, it looks like you are still uploading files to github. At this current time of checking filetransfer.asm appears to have the low-level USB bits contained within the same file so no need for the include.

    I will come back later to pull down the new files.

    Regards,

    Glyn.

    #1028
    Steve
    Participant

    Hi Glyn
    Uploads to Git should be complete now.
    I have recently changed my PC. In doing so, it seems my new PC wasn’t actually uploading changes to Github. No errors were being reported. Very odd! It’s resolved now.
    Cheers
    Steve

    #1029
    GlynD
    Participant

    Got a nice new shiny 🙂

    I’ve dragged the latest files down, noting an amend to format.asm. I have compiled and tested format.asm and happy to report my D: drive reformatted with the format ending with Formatting: T: 03FFh – I would expect 03FFh as we are now counting from zero?

    filetransfer.asm: Here I have a problem.
    *Compiled without errors. I put some files in /TFER and ran tfer.com (in my B: drive). This created a very useful and correct list of files found in /TFER. I typed Y to copy all.

    At this point the screen displays the file name its working on line by line, indicating 0 Bytes transferred.

    Changed drive to D: and can see the correct filename and number of file entries in the directory, however doing an SDIR or even a STAT *.* shows 0 bytes next to each file – and of course the files don’t run.

    * My compiler doesn’t like \n\r so I have to go through the source file and correct the strings to end 13,10,”$”. Another “what the!” with my compiler is it isn’t keen on <.label> so these I also clean up removing the “.” and adding a trailing “:” if missing. Not your worry and no issue for me I only mention it so you realise my source isn’t pristine from your github page. I have double checked and cant see my edits would have affected any code logic and my onscreen display is correct.

    To my eye it looks like my set-up is almost there, simply not transferring any actual bits. I’m having a look through the code now, but thought I would feedback what I have in case you have an aha!

    Will report back in the meantime if I solve my issue.

    From what I see so far a nice job.

    All the best,

    Glyn.

    #1031
    GlynD
    Participant

    Hi Steve,

    So here is a thing. With the caveat regarding my filetransfer.asm source edits above.

    With a clean empty D: drive, running tfer.com the first time as above produces the correct file list on D: drive, however all the files are 0 Bytes in size and as you would expect don’t work /run. Now if I go back and re-run tfer, it follows the same process (takes a bit longer to complete) but this time the same list of files on D: drive now show the correct file size and run as they should do.

    This is repeatable. – i.e. era *.* on D: drive to empty the drive. Run tfer once zero file size list of files. Run tfer a second time same file list now with correct file sizes and the files run.

    Still digging…

    Glyn.

    • This reply was modified 1 year ago by GlynD.
    #1033
    Steve
    Participant

    Hi Glyn
    Sorry to hear you are having trouble. I have tested using CP/M 2.2 and NZCOM Z-System. Both run without problems.

    You should see a file size reported against each file as they are transferred. You stated you see 0 bytes. Can you check your USB stick on your PC just to make sure they copied okay

    #1034
    GlynD
    Participant

    Hi Steve, posts probably passed in the post… From my reply #1031 you will see on the second run of tfer the files get copied over correctly suggesting the files are OK in /TFER.

    For completeness I did pull the USB stick and check on the PC and I can confirm the file sizes are correct.

    From your side would you be able to see what happens if you clear your D: drive (era*.*) and try a transfer?

    Very odd. I am sure your source is fine, just cant figure out what I could have change of any relevance.

    Regards,

    Glyn.

    #1035
    Steve
    Participant

    Lol – yes posts crossed. I have just done a reformat of my D: drive and ran tfer.com okay. I then erased all files (era *.*) on my D: drive and reran tfer.com okay. I’m transferring 36 files in my test – file sizes range from 2k to 32k.

Viewing 15 posts - 31 through 45 (of 57 total)
  • You must be logged in to reply to this topic.