RetroBrew Computers Forum: General Discussion » Porting CP/M-68K to new HW: the oddity of CPM400.SR and how to solve

Home » RBC Forums » General Discussion » Porting CP/M-68K to new HW: the oddity of CPM400.SR and how to solve

Show: Today's Messages :: Show Polls :: Message Navigator

Porting CP/M-68K to new HW: the oddity of CPM400.SR and how to solve [message #8442]

Wed, 07 April 2021 05:29

just4fun
Messages: 273
Registered: May 2017
Location: Dark side of the Moon

Senior Member

When porting CP/M-68K v1.3 to a new HW a possible way is to follow what the CP/M-68K System Guide says at par. 6.3.

There are two S-record formatted files into the distribution disks named CPM15000.SR and CPM400.SR. They are the CCP+BDOS part of CP/M without any CBIOS, starting at absolute address 0x15000 and 0x400 respectively. You have to choice one of them that better suits your HW and append your CBIOS.

In this way if the HW has a way to load an S-record formatted binary at this point you have a working CP/M.

Of course to make a "compatible" CBIOS you need to know the value of _init and _ccp addresses that are "hard-wired" into the two .SR files so they can be referenced inside the CBIOS.

To know these two addresses the System Guide suggests to give a look at the corresponding .MAP file (CPM15000.MAP or CPM400.MAP) inside the distribution disks.

This is exactly what I did in the first phase of the CP/M porting for my SBC, and it worked perfectly using the CPM15000.SR file.

But I soon realized that the CPM400.SR starting at 0x400 was a better choice so I did the same with it.

Unfortunately things went wrong and I started to investigate...

Looking with better attention at the CPM400.MAP file this is what I realized:

.....
.....
_init   	    6000 equ global abs
_sub_ind	    5D80 global bss
_log_dsk	    5D82 global bss
_load_tr	    5D84 global bss
_gbls   	    5D86 global bss
_crit_ds	    5E74 global bss
_tail   	    5E76 global bss
_cur_dis	    5E7A global bss
_parm   	    5E7C global bss
_dma    	    5EF4 global bss
_chainp 	    5F78 global bss
_sub_use	    5F7C global bss
_save_su	    5F7E global bss
_subfcb 	    6000 global bss
_first_s	    6024 global bss
_subdma 	    6026 global bss
_tpa_hp 	    60A6 global bss
_user   	    60AA global bss
_tpa_lp 	    60AC global bss
_tpa_ht 	    60B0 global bss
_user_pt	    60B4 global bss
_ro_dsk 	    60B8 global bss
_tpa_lt 	    60BA global bss
_autorom	    60BE global bss
_subprom	    60C0 global bss
_end_of_	    60C2 global bss
_subcom 	    60C4 global bss
_glb_ind	    6146 global bss
_chain_s	    614A global bss
_index  	    614C global bss
_dirflag	    614E global bss
_cmdfcb 	    6150 global bss
.....
.....

As you can see the _init address is at 0x6000 * but * there are various variables in the bss section that are inside the CBIOS area (stating at 0x6000), so the resulting file simply can't work...

So there are two possible solutions:

1. put a JMP 0x6200 at the beginning (at $6000) so the CBIOS can continue from 0x6200 outside the bss section of CPM400.SR;

2. use a patched CPM400.SR file where the jump to _init is modified to 0x6200 (instead to 0x6000).

I tested both ways and they worked. The second one is of course the preferred one, and searching around I found this interesting page of the S100 site that pointed me to this page on github.

There I found an S-record formatted file with the patched CPM400.SR file + the specific CBIOS.
So using a simple text editor I have extracted the CPM400.SR part and used it for my own implementation.

The patched CPM400.SR file is in the attachment. The _init is now at 0x6200 and _ccp is at 0x4BC (as in the original file).

So no more problems putting the pieces togheter... Razz

Attachment: CPM400.SR
(Size: 48.54KB, Downloaded 240 times)

[Updated on: Wed, 07 April 2021 07:04]

Report message to a moderator

Re: Porting CP/M-68K to new HW: the oddity of CPM400.SR and how to solve [message #8443 is a reply to message #8442]

Wed, 07 April 2021 10:28

plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA

Senior Member

Excellent work! I was never successful with CPM400.SR, now I know why.
Bill

Report message to a moderator

Re: Porting CP/M-68K to new HW: the oddity of CPM400.SR and how to solve [message #8451 is a reply to message #8442]

Sun, 11 April 2021 01:05

Yves-D.
Messages: 21
Registered: January 2020

Junior Member

Kudos to just4fun for sharing the links to the different websites talking about CP/M-68k migration and analyzing the CPM400.map shortcomings. Great job!
The way to a successful CP/M port to my 68SEC000 board got a little clearer.

Looking at all the current website infos, I'm under the impression that more people are working on CP/M-68k nowadays than in the heyday of CP/M-68k Laughing

Regards,
Yves

Report message to a moderator

Previous Topic:	old designs:PD32
Next Topic:	T80 (Z80) CPU in Multicomp

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Apr 26 13:49:05 PDT 2025

Total time taken to generate the page: 0.00612 seconds