An alternative CP/M method

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

Viewing 12 posts - 46 through 57 (of 57 total)
  • Author
    Posts
  • #1036
    GlynD
    Participant

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

    #1037
    Steve
    Participant

    Glyn
    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
    Steve

    #1038
    GlynD
    Participant

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

    #1040
    GlynD
    Participant

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

    #1041
    Steve
    Participant

    Hi 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

    #1043
    GlynD
    Participant

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

    #1044
    Steve
    Participant

    YAY!

    #1066
    GlynD
    Participant

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

    #1067
    GlynD
    Participant

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

    #1074
    Steve
    Participant

    Hi 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

    #1077
    GlynD
    Participant

    Hi 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?

    #1078
    Steve
    Participant

    Hi 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 🙂

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