Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Changing CP/M 2.2 start location

  1. #11

    Default

    sorry if this posts more than once.... 4th try.

    rd4secs512:
    LD B,128
    rdByte512:
    CALL CF_DAT_RDY
    IN A,(CF_DATA)
    LD (HL),A
    INC HL
    DEC B
    JR NZ, rdByte512
    DEC C
    JR NZ,rd4secs512
    POP BC
    LD A,(hstsec)
    INC A
    LD (hstsec),A
    >>>>need a DEC B here?
    DJNZ rdSectors

    oops... i misread DJNZ as JNZ
    Last edited by jlang; March 14th, 2020 at 03:33 AM. Reason: I was wrong

  2. #12

    Default

    Quote Originally Posted by WSM View Post
    It's obvious to me that your CPM22 file has been modified from the original distribution but there's no change history or indication of the changes. I'm not going to go through it or your CBIOS but will give a couple of comments based on an initial glance.
    Yeah, amateur programmer here.

    Quote Originally Posted by WSM View Post
    If you look at your assembly listing you'll see that the CPM22 module includes the jumps for the CBIOS at the end since it assumes separate assemblies and that your BIOS will overlay this area. Assuming the #include "CBIOS.ASM" brings in your CBIOS.TXT routine, it then ORGs back over this area and duplicates the jump vector. This relies on your assembler / linker figuring out what you really meant. Much cleaner to change the CPM22 vector to be "BOOT EQU $; WBOOT EQU BOOT+3; CONST EQU BOOT+6" etc. and then there is no need for the ".ORG bios".
    Okay, I think I understand. I've changed the CPM22 jump table to this:

    Code:
    ;**************************************************************
    ;*
    ;*        B I O S   J U M P   T A B L E
    ;*
    ;**************************************************************
    ;
    bios:	.EQU	$	; Set BIOS start
    
    BOOT:	.EQU	$	; These are overlayed by the BIOS jump table
    WBOOT:	.EQU	BOOT+3
    CONST:	.EQU	BOOT+6
    CONIN:	.EQU	BOOT+9
    CONOUT:	.EQU	BOOT+12
    LIST:	.EQU	BOOT+15
    PUNCH:	.EQU	BOOT+18
    READER:	.EQU	BOOT+21
    HOME:	.EQU	BOOT+24
    SELDSK:	.EQU	BOOT+27
    SETTRK:	.EQU	BOOT+30
    SETSEC:	.EQU	BOOT+33
    SETDMA:	.EQU	BOOT+36
    READ:	.EQU	BOOT+39
    WRITE:	.EQU	BOOT+42
    PRSTAT:	.EQU	BOOT+45
    SECTRN:	.EQU	BOOT+48
    I've moved the 'bios' definition out of the CBIOS code to the start of the CPM22 jump table, so instead of having a fixed size calculation working out the address of 'bios' in CBIOS, it is now defined in CPM22 and is now tolerant of any code changes in the CPM or BDOS code. Ditto for 'bdos' - instead of being calculated as 'ccp + 0806h', 'bdos' is now defined as the same address as FBASE, the BDOS entry point. I hope that's right.

    Quote Originally Posted by WSM View Post
    I would suggest changing the CBIOS ".ORG 0050h" to be 0040h which is defined by CP/M as available for the CBIOS whereas 0050h-005Bh is "Not currently used; reserved". Note that you'll then also need to change the .EQU on label CPMLDR_CLK. Perhaps some of your applications are assuming that since this area is reserved for CP/M but not used that they can also use this area.
    I'll leave that for the moment, I don't want to make too many changes until I get this warm-boot bug fixed. I will start looking at DDT and learning how to use it, seems it's going to be the tool to identify the problem. So I could theoretically step through the warm/cold boot procedures using DDT?

  3. #13

    Default

    I would warn against making "gratuitous" changes at this point, your code was working just fine before you made the BIOS larger. Sure, there are plenty of "review comments" that more-experienced programmers would make, but introducing too much change without knowing what the problem is will just complicate the debug process.

    I'm not immediately seeing anything wrong with the parts you posted, but the proof might be in the assembler listing file - by verifying that the addresses being assembled into actually match your expectations. Since this runs correctly after cold boot, I have to assume that the basic addresses are correct, so it may center around the warm boot routine. For example, the assembly symbol 'ccp' might only be used during warm boot (cold boot already has the CCP+BDOS+BIOS loaded by the ROM) and so you wouldn't notice if it were "wrong" until you did a warm boot.

    Brings up a question, though: how does the ROM decide where to load CP/M into memory? Make certain the ROM load address is the same as what is compiled into the BIOS warm boot (as 'ccp') - i.e. make sure all the math is right.
    - Doug

  4. #14

    Default

    If all the warm boot procedure looks correct, another thing to look into is the GPU code - what effect it could be having on the bios. I don't see the code, so have to guess how it is working. Does it operate as the system console in place of the serial port? or does it work in-tandem with the serial port console? Is it active for these runs where you see the problem?

    Might be a bit of a side-track, but does your system have any sort of core dump capability? Something to consider, if not. Maybe reserve a raw chunk of the CF card (large enough to contain all of your RAM), and then write ROM routines to dump RAM into the chunk. Then you can extract that chunk (either in CP/M or on a host PC) and analyze the "dump". I've found this to be very useful on another system I've been working on recently. I'm not sure how your ROM operates, and how much of RAM gets scribbled-on by the ROM, but there are ways to minimize that.
    - Doug

  5. #15

    Default

    I will start looking at DDT and learning how to use it, seems it's going to be the tool to identify the problem. So I could theoretically step through the warm/cold boot procedures using DDT?
    The most basic use of DDT would be to display low memory and verify that the warm boot address and BDOS addresses are correct along with any relevant BIOS information 40h-5Bh.
    DDT<CR>
    D0,5F<CR>

    Another are of interest would be your jump vector and the DDT display parameter is simply the start and end address:
    Dstart,end<CR>

    Exit from DDT is via CTL-C which will act as another test of your warm boot routine after verifying that memory is as you expect.

    In the event you want to change memory with DDT, you can use the "S" command. This isn't as intuitive but is invoked with "Sstart_address<CR>". You can either enter one byte of new hex data or a <CR> will increment to the next address. Terminating the S command is by entering ".<CR>".

    Single stepping and breakpoints in boot routines can get tricky since parts of memory will be overlayed as part of the boot process. My suspicion would be that part of memory is not being initialized as you expect or is being overlayed, possibly by your new GPU code. If neither of those is obvious, I'd double-check the warm boot code reading of the CCP/BDOS and verify rhat it's coming from the correct disk area and going to the correct memory address.

  6. #16
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,666
    Blog Entries
    18

    Default

    I recall having to write my own monitor/single-stepper in the CBIOS boot code. DDT uses too much of the CP/M functionality to be useful for debugging CP/M. If this is a system you've designed, the boot ROM should include a monitor with some debugging capabilities anyway.

  7. #17

    Default

    A quick way to narrow down whether the GPU code is causing a problem would be to replace the "CALL GPU_TX" with 3 NOPs (keeping the rest of the code, and length, identical). Then, we can focus on either the GPU or the warm boot.
    - Doug

  8. #18

    Thumbs up

    Quote Originally Posted by durgadas311 View Post
    Brings up a question, though: how does the ROM decide where to load CP/M into memory? Make certain the ROM load address is the same as what is compiled into the BIOS warm boot (as 'ccp') - i.e. make sure all the math is right.
    Doug, you're a star. You've hit the nail on the head. Thanks to your question, I went and checked the INSTALL command in a little more detail, which copies the CPM image from ROM and writes it onto Sector 0 of the CF card. It was only by doing that, that I checked out the CPMLOAD routine and stumbled across an equate in the code causing the ROM to load CP/M at CE00h. So even though CPM was compiling correctly for the new CB00h starting address, it was getting loaded in by the ROM at CE00h...

    CPM loads fine and I'm able to run MBASIC and quit back to the CCP whilst viewing it all on my monitor now! Thanks everyone for your help and suggestions.

    All I've got to do now is successfully move my video circuit from prototype onto a custom PCB... soldering a 144 pin QFP FPGA is testing my soldering skills at the moment, this video card is the most complex thing I've ever created...

    20200314_144238.jpg

  9. #19

    Default

    Great news! good luck going forward. Must be nice to have a screen now. Curious: how are you handling the keyboard in that situation? I guess, for now, you're just using the serial port as the keyboard?
    - Doug

  10. #20

    Default

    Quote Originally Posted by durgadas311 View Post
    Great news! good luck going forward. Must be nice to have a screen now. Curious: how are you handling the keyboard in that situation? I guess, for now, you're just using the serial port as the keyboard?
    Yes, the serial console is acting as the keyboard for the moment until I get a working video card up and running and can develop the PS2 keyboard interface in the FPGA (I'm finding the prototype video card a little too unstable for me to get a working PS2 interface up and running).

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •