First time with DDT

[Mike_Z]

I've been working on improving my CBIOS for CP/M2.2 and am making progress. I decided to try and use my 8" drive system to store my work, rather than linking to the 8080 to my IBM XT. Using my homemade editor, I made the source code copy of my CBIOS. It is an ASCII file. Started this source code at 0100H, then used used the CP/M SAVE command to save the source code to a file on my 8" drive. I know that this worked, in that I can use TYPE to view the code and it looks OK. My problem is trying to retrieve the code later. Being a novice at CP/M, I logically thought that LOAD was what I wanted, but this is incorrect. LOAD makes a COM file out of a HEX file. After reading more, it looks like DDT is the program I need, but I'm having trouble making it work. This is how I start,

DDT CSL32MX.TXT

The program responds

DDT VERS 2.2
-

From what I have read. The dash is the DDT prompt and it is waiting for a command. I'm not going to use DDT for anything more that to load the file at this point, but the code doesn't appear starting at 0100H. Am I doing something wrong? And a second question can I load the code at an address other than 0100H? Thanks Mike

 

[dhoelzer]

Actually, I think that what you want is ASM.COM to assemble it... But first you have to get it into a file.. From what you say, it sounds like you have managed to get the file onto the system. If this is the case then here's what you need to do:

PIP CSL32MX.ASM=CSL32MX.TXT <-- Copy your text file into a file with an ASM extension. ASM.COM requires it.
ASM CSL32MX <-- Assemble the assembly source code... Assuming no errors...
LOAD CSL32MX <-- Turn it into a COM file
CSL32MX <-- Run it!

I've been working on improving my CBIOS for CP/M2.2 and am making progress. I decided to try and use my 8" drive system to store my work, rather than linking to the 8080 to my IBM XT. Using my homemade editor, I made the source code copy of my CBIOS. It is an ASCII file. Started this source code at 0100H, then used used the CP/M SAVE command to save the source code to a file on my 8" drive. I know that this worked, in that I can use TYPE to view the code and it looks OK. My problem is trying to retrieve the code later. Being a novice at CP/M, I logically thought that LOAD was what I wanted, but this is incorrect. LOAD makes a COM file out of a HEX file. After reading more, it looks like DDT is the program I need, but I'm having trouble making it work. This is how I start,

DDT CSL32MX.TXT

The program responds

DDT VERS 2.2
-

From what I have read. The dash is the DDT prompt and it is waiting for a command. I'm not going to use DDT for anything more that to load the file at this point, but the code doesn't appear starting at 0100H. Am I doing something wrong? And a second question can I load the code at an address other than 0100H? Thanks Mike

 

[Mike_Z]

DHoelzer, thanks for the response. I have not graduated to using ASM yet. I have a home made 8080 machine and homemade editor and assembler programs that I have been using for a long time. All my code has previously been saved on my IBM XT via a com link, also homemade. What I want to do is to be able to save some source code, from my editor, that, for now I'll assemble and work with using my old assembler, etal. So, as I said I got to the point of saving the source code with SAVE, but am having difficulty retrieving the code. What I want to do is run a program that will read the file 'CSL32MX.TXT' from my 8" drive back to 0100H. This code is actually my Cold Start Loader which I'm improving the error handling section. Once it works to my satisfaction, this code will be added to my EEPROM Monitor program. Then once this is done, my CBIOS will be adjusted to work with the CSL. So All want to be able to retrieve the disk image from the drive and place it in memory at 0100H. I'm also interested how to load this image into other memory locations. Thanks

 

[dhoelzer]

Ah, I see.

I'm not sure that you can read in a text file to be used to assemble in DDT. You can certainly load a HEX file, though... Maybe check the manual? http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch4.htm

DHoelzer, thanks for the response. I have not graduated to using ASM yet. I have a home made 8080 machine and homemade editor and assembler programs that I have been using for a long time. All my code has previously been saved on my IBM XT via a com link, also homemade. What I want to do is to be able to save some source code, from my editor, that, for now I'll assemble and work with using my old assembler, etal. So, as I said I got to the point of saving the source code with SAVE, but am having difficulty retrieving the code. What I want to do is run a program that will read the file 'CSL32MX.TXT' from my 8" drive back to 0100H. This code is actually my Cold Start Loader which I'm improving the error handling section. Once it works to my satisfaction, this code will be added to my EEPROM Monitor program. Then once this is done, my CBIOS will be adjusted to work with the CSL. So All want to be able to retrieve the disk image from the drive and place it in memory at 0100H. I'm also interested how to load this image into other memory locations. Thanks

 

[Chuck(G)]

Um, unless the text file is in Intel HEX format, it should be there at 0100H. DDT doesn't really attach much importance to file name extensions.

 

[Mike_Z]

Well.... once again it turns out to be my fault. I made a file called FIRST.TXT using ED.COM. Then I saved it and restarted the machine to clear out memory. Using DDT I loaded this file and it worked. The computer response was a little different. Here it is.

DDT FIRST.TXT

DDT VER 2.2
NEXT PC
0280 0100
-

When loading the FIRST.TXT file DDT displayed 'NEXT PC and the numbers" whereas when I loaded CSL32MX.TXT this was not displayed. Don't know why.

Next I looked at the differences between these two files. One was made using ED and the other using my old editor. Here are the differences I noted and are probably the reason I can not load My Editor file. My Editor is an ASCII line file. Each line ends with a Carriage Return, but no line feed. I did this to save memory space, probably a good idea then, but.....Looks like the ED has a CRLF at the end of each line. Also, my editor uses 233 Octal as the end of file marker, not sure what ED uses as EOF marker.

Anyway, it doesn't look like I'll be able to do what I wanted, at least easily. But it does look like DDT works. Thanks Mike

 

[Chuck(G)]

Yup, CRLF is the standard for both CP/M and MSDOS text files, though Windows era programs can be pretty tolerant of just LF.

The boneheadedness of UNIX and other such systems in small matters like this really are a pet peeve. Take a UNIX file and shoot it at a terminal or teletype and the LF doesn't return the carriage at each line, just spaces down one line and keeps going where the last line left off. CRLF files aren't any problem.

If you argue that LF in UNIX is a logical terminator, then you lose the sense of its meaning. There are C0 set codes that can neatly partition a text file--US, RS, FS, GS. Or use the C1 character NEL. But using LF just doesn't make any sense, but we're stuck with it because "That's The Way Things Are".

At least CRLF makes some kind of sense, though CP/M and DOS are silent on what CR or LF alone is supposed to signify.

</rant>

 

[dhoelzer]

Huh. That's interesting. I didn't realize you could read assembly straight into DDT.

Thanks!

Yup, CRLF is the standard for both CP/M and MSDOS text files, though Windows era programs can be pretty tolerant of just LF.

The boneheadedness of UNIX and other such systems in small matters like this really are a pet peeve. Take a UNIX file and shoot it at a terminal or teletype and the LF doesn't return the carriage at each line, just spaces down one line and keeps going where the last line left off. CRLF files aren't any problem.

If you argue that LF in UNIX is a logical terminator, then you lose the sense of its meaning. There are C0 set codes that can neatly partition a text file--US, RS, FS, GS. Or use the C1 character NEL. But using LF just doesn't make any sense, but we're stuck with it because "That's The Way Things Are".

At least CRLF makes some kind of sense, though CP/M and DOS are silent on what CR or LF alone is supposed to signify.

</rant>

 

[Chuck(G)]

Well no, you can't read assembly source into DDT--it just isn't too fussy about what's in a file if it's not an Intel HEX file. It can be handy (as can DOS DEBUG) for use as a binary editor when you don't have one available.

No, Mike will have to use ASM.