• Please review our updated Terms and Rules here

Generating new floppy based system

A

archeocomp

Experienced Member
Joined
Apr 29, 2012
Messages
416
Location
EU/SK
Hello. I will probaly have more questions over time as I will progress. To get me started I would like to ask about the way CP/M boots. Suppose I have finished BIOS (which is not done yet) and I want to create bootable diskette. I have a col start loader in EPROM wich reads first sector. First sector contains begin address, end address and start address. Loader then reads consecutive sectors and stores them in RAM in the range begin->end. When it is done loading, it will jump to start address.

So far I know there is OEM CP/M version configured for 20k RAM. I believe I have found it on internet. It is a file CPM.SYS, size 7.5kB. This file must be loaded between 3400H-49FFH. BIOS follows between 4A00H-4FFFH. Start address is 4A00H

When the BIOS is correct CP/M should respond with A>

Now I want to reconfigure the system for 64kB. I could not find MOVCPM.COM in the same archive as I found CPM.SYS. I believe MOVCPM.COM is not always the same and is to be used with the right CPM.SYS right? Can I use other CP/M on the same machine (that I happen to have) to reconfigure OEM CPM.SYS for other RAM sizes? I am stuck right here now, hope someone can explain it better. MOVCPM.COM only moves BDOS+CCP and BIOS is up to me to recompile it for right address right?
 
If you're working from the OEM redistro floppy, you need to construct your own MOVCPM.COM file from the cpmove.* and cpsys?.hex files, as well as your BIOS source. The idea is to generate a page-relocatable image of the binary loadable CP/M files, and your BIOS, as well as the boot sector. This is done by assembling each program twice, the difference being an ORG exactly 100H bytes different.

All of this should be explained in the OEM guide for CP/M.

If you're not trying to set up an OEM distro, it's far easier just to take anyone's running CP/M system, do the MOVCPM and add your own BIOS into the image before writing it to disk.
 
Hi All;
Arch, What I would do is go a little further down that page to the CPM 2.2 Manual in PDF format, and download it.. Then go to page 192 or so , and compare that section to the one that you found for 2.0, they most likely are very close in content, BUT, the Offsets are going to most likely be different.. In the 2.2 manual it says chapter 6 regeneration guide.. That should get You in the Ball Park..

THANK YOU Marty
 
Hi All;
Arch, I compared the two files, now that I am back..
And as near as I can tell, they are the same, But, the one in the CPM 2.2 Manual is easier to read..

THANK YOU Marty
 
I'll look around and see if I can still find my copy of the OEM guide.

FWIW, when I doing an OEM CP/M 2.2 installation back in the day, I had to deal with a system whose bootloader in ROM did not simply load a single sector--it searched for a file called "SYSTEM" in a directory located on the first track and read that in (in more-or-less Intel hex format, complete with checksums). It was a bit more complicated than just making a simple boot sector--I had to duplicate the directory and binary format.
 
When starting from scratch to create a brand-new BIOS and then get CP/M up and running, Ive been using the CP/M 2.2 source code so that I can easily assemble the complete CP/M and my BIOS at the proper location in memory. Once everything works, I then create a MOVCPM module so that the CP/M can be configured for other memory sizes like in the old days. As Chuck mentioned, creating the relocation map for the MOVCPM module requires assembling the complete CP/M source and your BIOS twice in order to determine the bytes that must be modified to relocate the executable code. I've written a Windows program that takes two .hex files and writes out a relocation map for this purpose.

Here's a link to a good CP/M source created by disassembly: http://www.cpm.z80.de/download/cpm2-asm.zip

Mike
 
Thanks, now I have to read it all. BTW it is my own SBC system, so I am free to implement any cold start loader. What I have described is the bootloader that I have at present. Chuck, that OEM guide would be fine too :) Thanks
 
Hi All;
I some years ago, had tried to do the same thing.. ChuckG, I am sure will remember my endless questions..
I had taken the files, that DeRamp links to , and I assembled them.. Using Spasm..
I then would Load them into memory, using a variation of Grants Loader, using TeraTerm on the PC side of things.. Once, I had everything loaded, I put in a Blank floppy, and Using Sysgen, I Created the Bootstrap, for my Floppy.. I didn't use the MOVCPM program, since it was already in memory at the correct place..
My only Problem was after about 4 to 6 Bootings, It would not boot anymore, and I still don't know "why".. Whether it was Bad Memory, or Bad Drive or Bad Media.. But, doing that way IS possible, as well.. I started with either a 58K or 62K, memory map.. I had at first had to Reload it many times working out the I/O technicalities.. For my Altair Screen and Keyboard, thru the 88-2SIO, and the Floppy Disk Controller which was a Tarbell Single Density.. One Help was I had ALL the Listings for the Tarbell CPM, both 1.4 and 2.2... Which are all online, even though I had them from another source..
THANK YOU Marty
 
Last edited:
After holiday got back to CP/M. The document on bootstrapping CP/M on Rich Cini's page http://www.classiccmp.org/cini/my_imsai.htm, who did this very thing a few years back on an IMSAI he restored, under the section "Implementing a new 5.25" disk system" mentions CP/M sources at http://www.cpm.z80.de/source.html. I downloaded the http://www.cpm.z80.de/download/cpm2-asm.zip but I can only find BDOS inside, not CCP. I can compile this BODS to any specific ORG target adress. But I am still missing CCP. Can someone point me to the right sources please?
 
The zip file you downloaded is the correct one. It is the CCP and BDOS combined. CCP starts at the beginning of the file, the BDOS starts later in the file (search for "FBASE").

Mike
 
Correct. After long break I opened wrong file in wrong directory today. I also have BDOS22.ASM from some forgotten source. Thanks.
 
Sooo my CP/M 2.2 can now read and write diskettes (drive c: ). But there is something wrong.

a>c:
c>dir
No file
c>a: pip c:=a:*.*

COPYING -
ASM.COM
CLS.COM
CREF80.COM
DDT.COM
DDUMP.COM
DUMP.COM
ED.COM
FSED.COM
GENHEX.COM
GENMOD.COM
KBAS2.COM
KRUN2.COM
L80.COM
LIB.COM
LOAD.COM
M80.COM
MBASIC.COM
NSWP.COM
Bdos Err On C: R/O

c>a:stat *.*

RECS BYTES EXT ACC
64 8K 1 R/W C:ASM.COM
1 2K 1 R/W C:CLS.COM
30 4K 1 R/W C:CREF80.COM
38 6K 1 R/W C: DDT.COM
32 4K 1 R/W C: DDUMP.COM
4 2K 1 R/W C: DUMP.COM
48 6K 1 R/W C:ED.COM
44 6K 1 R/W C:FSED.COM
7 2K 1 R/W C:GENHEX.COM
9 2K 1 R/W C:GENMOD.COM
164 22K 2 R/W C:KBAS2.COM
136 18K 2 R/W C:KRUN2.COM
84 12K 1 R/W C:L80.COM
38 6K 1 R/W C:LIB.COM
14 2K 1 R/W C:LOAD.COM
62 8K 1 R/W C:MIC.$$$
157 20K 2 R/W C:M80.COM
128 16K 1 R/W C:MBASIC.COM
BYTES REMAINING ON C: 1086K

c>
Click to expand...

It looks like there is a problem with allocation bitmap and BDOS locks the drive. Subsequent stat reveals that MBASIC's second extent was not added correctly. What can it be? Bug in deblocking algorithm or incorrect bitmap size or something else? I checked the first two but can not find error.
 
Last edited:
What is the storage capacity of drive C? Is it really a floppy? If so, it looks like the BDOS has inappropriate parameters for its disk parameter block. For that matter, what size drives are A and B as well?

Mike
 
Sorry for late reply. C drive a 3.5" floppy, it is formatted to 32x256byte sectors per track. Totally approx. 1.2MB. Allocation block size is 2kB. I still did not find the bug. A and B are SD card based drives 2MB each.
 
Thank you. Here it comes. A nad B do not use blocking algorithm, firmware in ATmega makes them appear as they would have 128byte sectors.

; PMD32SD
; size 2MB
; 256 tracks, 64 sectors/track
; 1020 allocation 2kb blocks
; 256 dir size
; 1 system track
DPB: dw 64 ; SPT - logical sectors per track
db 4 ; BSH - block shift
db 15 ; BLM - block mask
db 0 ; EXM - ext.mask
dw 1019 ; DSM - capacity-1
dw 255 ; DRM - dir size-1
db 240 ; AL0 - dir allocation mask
db 0 ; AL1
dw 64 ; CKS - checksum array size
dw 1 ; OFF - system tracks

; Diskette 3,5" HD
; 3.5" / 1.44MB(DOS) / 1.28MB(CP/M)
; 80 tracks(two side), 32 (256 byte) sectors per track/side, 5120 sectors totally
; 632 allocation 2kB blocks (first track reserved for system)
; 256 dir size (4x16x4) - dir is saved in 4 allocation blocks
; 1 system track
DPB4: dw 128 ; SPT - logical sectors per track
db 4 ; BSH - block shift
db 15 ; BLM - block mask
db 0 ; EXM - ext.mask
dw 631 ; DSM - capacity-1
dw 255 ; DRM - dir size-1
db 240 ; AL0 - dir allocation mask
db 0 ; AL1
dw 64 ; CKS - checksum array size
dw 1 ; OFF - system tracks
 
I was originally suspect of disk parameter table settings because I envisioned vintage 8" or 5-1/4" drives on your system. But for the specs of your 3.5" disk, your disk parameter block looks fine.

I assume it's up to code you have written in the BIOS to deblock 256 byte physical sectors into 128 byte logical sectors and to switch heads for physical sectors 0-31 versus 32-63 for a given track number? Did you write your own deblocking routines and write-through (or delayed write) routines, or are you attempting to use the DRI provided code skeleton for deblocking?

Mike
 
You must log in or register to reply here.
Back
Top