Well, sometimes a little help is all I need. From what I can tell, right now, is that CP/M is kinda similar to the assembler I'm using now. ORG is the same as *, DB and DW are the same, the fields are similar (there is a new one called DS), except my assembler requires the operands to be on the next line instead of inline. There are items called EQU and SET which are new. Labels can be longer, the error messages are different. I don't mind spending a little for some help. Arch, I'll look into the ones you have suggested. Chuck, I have the Command Summary you mentioned. It will be handy, but sometimes it is good to see examples etal. One other question, and I think I have the answer, Can I write the assembly language in Word and then save it as a text file then copy to my disks and assemble that instead of using ED.COM? Thanks Mike
Yes, you can do that--you can even assemble the stuff under an emulator and transfer the object files.
EQU and SET serve similar purposes--the first permanently assigns a value to a symbol; the second permits re-assignment of a value to a symbol. That's pretty much it--so for instance, you can assemble:
Code:
SYM1 SET 5
...
SYM1 SET SYM1+1
With the result that SYM1 will have the value 6. Doing the same thing with EQU will result in an assembly error.
DS is like BSS in other assemblers--it reserves storage, but does not specify an initialization value. This is an important distinction when you have a system loader that allows for address specification, but CP/M loads memory images for execution, so the distinction is somewhat artificial. In practice, all DS does is advance the location counter by the specified number of positions.
The output of ASM is Intel HEX-format files which are not suitable for direct execution. You have to "absolutize" them with LOAD, which essentially constructs a memory image from the HEX file and writes it as a COM file.
So, you may well ask, why doesn't ASM output a memory image and skip the HEX thing? Compatibility for one. The Intel MDS understands this format, as do many other operating systems.
Ever wonder how MOVCPM works? Since the BDOS and CCP is in high memory, above the user application, addresses have to be changed every time the system memory size is changed. Now that requires relocating addresses in 8080 code, since relative addressing is not part of the hardware. Without implementing a full-blown relocating assembler and loader, how does one go about this?
It's actually pretty clever and MP/M even uses this scheme to construct its page-relocatable files. You simply assemble the source program
twice with the second assembly origin 100H (256 bytes) higher than the first. The two binary images are then compared, byte for byte, and a map constructed of where pairs of bytes differ in value by exactly 100H. The result is a list of locations where the relocation value needs to be adjusted if the location of a program in memory is to be moved.
MP/M calls this sort of file PRL (page relocatable), but I don't know that CP/M 2.2 ever coined a name for it.
