Beiträge von deramp

    Martin,


    FLOP2PC and PC2FLOP directly access the disk controller to perform disk IO independent of CPM or other operating system. The only way I could write PC2FLOP and FLOP2PC for this particular hardware would be to disassemble the CPM BIOS and/or the 2K PROM you mentioned earlier in order to figure out how to use the disk controller.


    If you want to assume you’ll always have at least one bootable CPM disk, then a version of FLOP2PC and PC2FLOP that uses the CPM BIOS for disk IO could be written. Note that this solution would have to be repeated for QMOS or other non-CPM disks you might have.


    Mike

    deramp

    If I like to make the CP/M 2.2 under CP/M 3 didn't we have a running way ?

    What do you like to make it better?

    I'll put together a procedure and files for doing this under CP/M 3 later this afternoon. Do you think I should add instructions for creating SYSGEN.COM from SYSGEN.ASM for both procedures?


    Mike

    The way image files and SYSGEN were organized in CP/M 2.2 allowed this neat little trick. Give this a try:


    A>DDT GENIECPM.COM

    DDT VERS 2.2

    NEXT PC

    3500 0100

    -ISYSGEN.COM

    -R

    NEXT PC

    3500 0100

    -G0


    A>SAVE 52 GENIECPM.COM


    Now, GENIECPM.COM is a self-installing executable file with SYSGEN built into it. Simply type GENIECPM with no parameters :)


    A>GENIECPM

    GENIE III SYSGEN VER 2.0

    SOURCE DRIVE NAME (OR RETURN TO SKIP) (...press RETURN here)

    DESTINATION DRIVE NAME (OR RETURN TO REBOOT)A

    DESTINATION ON A, THEN TYPE RETURN

    ...

    I have attached a zip file with everything needed to re-create CP/M 2.2 from sources when running under CP/M 2.2. I have also included the original SYSGEN from DRI updated to write the Genie III boot tracks. Give this a whirl and let me know if the procedure works for you.


    As you know, the procedure was a little different when you had to run under CP/M 3. Let me know if you want me to put together a similar package and procedure for creating CP/M 2.2 when running under CP/M 3.


    Mike

    I can remake the notes for putting together the CP/M image based on what we’ve figured out here. I assume you want to run the procedure and SYSGEN under CP/M 2.2 instead of CP/M 3 now that 2.2 is running?


    I can port the real SYSGEN for CP/M 2.2 to your machine, or you can compile the SYSGEN.C program you have if you can find and run the C compiler for it. Let me know which way you prefer since the choice affects the procedure slightly.


    Mike

    It looks like the original COPYSYS program never worked with an image file specified on the command line. It fails to read the file specified into memory because it mixes normal BDOS file I/O with BIOS-direct disk I/O while attempting to read the file and this fails. I have fixed the file load code to use just BDOS file I/O to read the command line file into memory.


    Use the attached SYSGEN.COM program to write GENIE0.COM (it's the same) by running and let me know if the resulting disk boots.


    A>SYSGEN GENIE0.COM

    Let's see what SYSGEN is writing. Run SYSGEN under DDT and stop it right before it writes to disk. We should see the proper disk image starting with 21 50 42 in RAM at 1000h. Let me see what the dump shows (the D1000)


    A>DDT SYSGEN.COM

    DDT VERS 2.2

    NEXT PC

    0880 0100

    -IGENIE0.COM

    -G,4C4

    CP/M 2.2 on CP/M 3 SYSGEN - Version 3.0*04C4

    -D1000

    annotation:


    Mike works with DDT and SAVE. SAVE is an internal command from CP / M 2. I am working with unranked CP / M 3 and SAVE is an external command.


    From the looks of it, DDT and CP / M3 SAVE do not really work with each other. I could load a BIOS22.RSX if that helps.

    Yes, SAVE under CP/M 3 is different than under CP/M 2. Under CP/M 3, you run the SAVE command with no parameters BEFORE starting the DDT session. When you exit DDT with G0 or CTRL-C, the SAVE program automatically "wakes up" and prompts to save a file from a range of memory. SAVE in CP/M 3 allows you to specify the starting and ending address (unlike SAVE under CP/M which always begins the save operation from RAM address 0100h).


    The equivalent steps to SAVE 52 pages of RAM starting from RAM address 0100h to a file GENIECPM.COM under CP/M 3 are:


    CP/M V3.0 Loader V1.00 18-Jan-2002

    Copyright (C) 1982, Digital Research


    A>SAVE

    A>DDT

    DDT VERS 2.2

    - (do your work here)

    -G0


    CP/M 3 SAVE - Version 3.1

    Enter file (type RETURN to exit): GENIECPM.COM

    Beginning hex address 0100

    Ending hex address 34FF


    A>


    Mike

    After digging further into the COPYSYS program, I see it uses a different convention for the command line image file than used by SYSGEN under CP/M 2.2. COPYSYS expects the command line image file to have the first byte of the disk image start at offset zero - not at 800h/900h (or 0F00/1000h) as used in the SYSGEN program.


    I updated COPYSYS again (calling it SYSGEN again). Since it won't be consistent with CP/M 2.2 SYSGEN anyway, I restored the load point used by the program to 1000h (that address no longer has any particular significance). I also updated the GENIECPM.COM file to start the disk image at offset zero instead of offset 800h. This updated GENIE file is called GENIE0.COM.


    Try the following on the CP/M 3 system:


    1) Upload the attached SYSGEN.COM and GENIE0.COM to the CP/M 3 system

    2) Run A>SYSGEN GENIE0.COM and follow the prompts. Answer "No" at the copy CPM.SYS prompt


    Mike

    Note that whenever CP/M or DDT loads a .COM file into memory, it loads offset zero of the .COM file into RAM location 100h (and the SAVE command in CP/M 2.2 does the opposite). Therefore, the boot image that is located at 900h in RAM actually starts at offset 800h in the .COM file.


    If you look at offset 800h in the GENIECPM.COM file you find the 21 50 42 sequence you're looking for.


    Mike