Home › Forums › Z80 Playground Early-Adopters › An alternative CP/M method
- This topic has 56 replies, 4 voices, and was last updated 11 months ago by
Steve.
-
AuthorPosts
-
July 26, 2021 at 2:48 pm #1036
GlynD
ParticipantHi Steve, thanks for trying. Very odd my end, I too have just created a new drive image and formatted it. Tfer is as solid as a rock so long as I run it twice – go figure???? I’m copying 4 files range from 6k to 30k in size.
Even on the second run, I notice the file size is still reporting 0 Bytes, though checking D: the file size is correct. Looking at the code in filetransfer, the file_size routine looks fairly self contained. I will have a poke around there and see if it leads me anywhere.
I just know its going to be something daft on my part, though I have double checked the edits I made and have gone back to the github version to confirm the area I needed to make the changes.
Regards,
Glyn.
July 26, 2021 at 3:08 pm #1037Steve
ParticipantGlyn
You don’t have the latest filetransfer.asm. I hadn’t posted a fix for the 0 byte transfer. Apologies for that. See Github now.Regards
SteveJuly 26, 2021 at 3:45 pm #1038GlynD
ParticipantYesss! Many thanks Steve, sorted, well sort of.
Files transfer from FAT to CP/M no problem. Oddly on my system, its still reporting zero bytes next to each file transfer, but yet checking in D: drive all the files have arrived and are the correct size.
I can certainly live with that, but will have a dig and see if I can come up with anything.
Many thanks for your hard work,
Glyn.
July 27, 2021 at 8:33 pm #1040GlynD
ParticipantHi Steve, thought you may like to know I found where my final issue is with the transfer file size, its with my compiler. I tried compiling using Pasmo and the resulting com file works as expected and displays the file byte size. Using my compiler Zasm, works but file size bytes are all displayed as “0”
Checking the list file from the respective compilers I see the issue is with the literal #0909 within B2D32 – specifically LD BC, #0909.
Pasmo respects the literal and compile this to: 01 0909 (LD BC,#0909)
Zasm doesn’t respect the literal an compiles to: 01 8D03 (LD BC,#0909)Bit of a gotcha. I’ve looked through the Zasm docs and cant find a directive to force this sort of literal use. If I can’t resolve it I guess I will be switching over to Pasmo.
Bottom line happy to confirm I have successfully got filetransfer.asm to compile and runs perfectly on my system.
Many thanks,
Glyn.
July 28, 2021 at 3:22 am #1041Steve
ParticipantHi Glyn
Glad you found your problem, but man, you don’t like to be beaten LOL!That literal, is just a hex number, try changing it to $0909 or whatever ZASM uses to define a hexadecimal number
Steve
July 28, 2021 at 7:52 am #1043GlynD
ParticipantHi Steve,
Well I’ll be a monkeys a.. You are, as ever, quite correct. Changing the # to a $ allows my compiler to compile the line correctly. I’m going to have to learn to think “outside the box”. I cant tell the amount of searching and combinations I tried – entering as a %bin, decimal etc. As the compiler was converting the #0909 to hex, for some reason, it just didn’t occur to me to just tell the compiler its a hex number – doh!
Anyway all sorted.
Ta,
Glyn.
July 28, 2021 at 8:44 am #1044Steve
ParticipantYAY!
August 22, 2021 at 2:26 pm #1066GlynD
ParticipantHi Steve, long time and all that… Bit of feedback. I noticed the updates to github regarding I/O optimisation. Compiled and working fine on my board.
I’ve also “hacked” your filetransfer.asm, so that I can select a different source FAT directory. As the CP/M drive is limited and FAT only by the size of the memory stick, this mod enables me to have repositories of files grouped in directories. I use D: as a “scratch” drive and just populate it with the FAT directory files as I need.
All the best,
Glyn.August 22, 2021 at 2:31 pm #1067GlynD
ParticipantAlso meant to mention, in cbios.asm, I see there is a new DPB definition labelled dpblk3. This block doesn’t appear to be used? Any benefit using this instead of dpblk2 or can I simply delete /comment out the block?
Ta.
August 23, 2021 at 2:01 pm #1074Steve
ParticipantHi Glyn
The additional DPB is there to show what a 4K block size DPB looks like. Plus I was interested to see if my seek method worked using three formats
ie.
B>a:pip d:=c:*.*So, yes you can delete it
September 21, 2021 at 3:05 pm #1077GlynD
ParticipantHi Steve, I see over on your GitHub portal you have been busy.
In the diff listing of commands.asm I read there is a new monitor option to load CP/M 3 /Plus. I am quite keen to give it a go. Looking through the code it appears I need a CP/M 3 disk image (CPM3.DSK) and the CPMLDR.COM file. I assume the CPMLDR.COM file comes loaded in the CPM3 disk image, but I can’t find CPM3.DSK amongst the github files.
Hope I’m not jumping the gun here, are you happy to release the CPM3.DSK so I can give this a run?
September 22, 2021 at 5:39 am #1078Steve
ParticipantHi Glyn
You eager beaver! Not ready just yet. I can run CP/M 3 but am having a number of problems with disk format. I don’t have so much time to play at the moment, but will get there.
CP/M 3 will have about 43k of TPA. Not as bad as I first thought.
Anyway, watch this space 🙂
-
AuthorPosts
- You must be logged in to reply to this topic.