July 9, 2021 at 12:40 pm #993
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.
Glyn.July 13, 2021 at 11:54 am #996
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
SteveJuly 13, 2021 at 4:19 pm #997
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.July 17, 2021 at 9:55 am #1012
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 patienceJuly 17, 2021 at 2:33 pm #1013
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?
SteveJuly 17, 2021 at 4:02 pm #1014
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!
Glyn.July 25, 2021 at 9:48 am #1024
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
SteveJuly 25, 2021 at 12:47 pm #1026
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.
Glyn.July 25, 2021 at 4:43 pm #1027
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.
Glyn.July 26, 2021 at 3:17 am #1028
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.
SteveJuly 26, 2021 at 11:45 am #1029
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.July 26, 2021 at 2:02 pm #1031
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.
July 26, 2021 at 2:05 pm #1033
- This reply was modified 5 months, 3 weeks ago by GlynD.
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 okayJuly 26, 2021 at 2:15 pm #1034
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.
Glyn.July 26, 2021 at 2:36 pm #1035
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.
- You must be logged in to reply to this topic.