;; NASM2HDR.TXT  7-30-10  8:31:23 pm s_dubrovich@yahoo.com
;; Include: nasm2hdr.c, nasm2hdr.exe, biosmem3.hdr, nasm.exe, biosmem3.asm,
;;  biosmem3.bin, biosmem3.lst, biosmem3.map, biosmem3.txt, biosmem3.cmd,
;;  pgbound.clp, prep.clp, nasm2hdr.txt
---------------------------------------
Re: NASM cross development for CP/M-86.
---------------------------------------

NASM2HDR.EXE is a utility to create a header record in order to make a .CMD
 file out of a NASM .BIN file.  The utility reads a .map file output as a
 result of a NASM assembly and creates the cp/m-86 executable header record
 from the .section information listed in the .map file.  This utility helps
 cross development to cp/m-86 from NASM assembly.  You might want to use 
 NASM because it supports 32bit & Xn86 assembly instructions so that if you
 are running cp/m-86 natively on a modern processor, you can use any of the
 real mode instructions in your application development.  Protected mode
 instructions are not out of the question either.  Source is provided, 
 nasm2hdr.c, for the utility which was compiled under Mix Software PowerC.
 Also compiles with Borland TC 2.01 as well.  When you run nasm2hdr.exe,
 it asks for the name of the .map file to parse.  It outputs a .hdr binary
 file, 128 bytes long, with the fields set according to the .MAP section
 descriptors.  It also outputs a .TXT file giving the descriptor lines
 which were parsed.  This is for your reference only, a way to spot a mis-
 typed section name.  It also outputs some information to the console, then
 terminates.

-------------------------------------------------------------
Re: NASM -f bin biosmem3.asm -o biosmem3.bin -l biosmem3.lst
-------------------------------------------------------------

NASM in this form, outputs its assembly as straight binary, generally meaning,
 directly executable.  This is quite similar to cp/m-86, only that the
 cp/m-86 loader expects an 128 byte header record prepended to give the 
 loader some information on what goes where in memory before execution.
 There is some structure which needs to kept in mind for cp/m-86, see the
 Nasm Hints section.  The above command line was used to make the example,
 biosmem3.cmd from biosmem3.asm, with the straight binary to the .bin file
 and an optional .lst listing file.  The required .MAP file is produced
 when the directive: [MAP BIOSMEM3.MAP] is placed near the beginning of the
 assembler source code, there is not a command line option to create a .MAP
 file.  BIOSMEM.ASM was written by Chris Giese, see the source for more
 information, as well as what little was changed for cp/m-86.

----------------------------
Re: NASM for CP/M-86 Hints.
----------------------------
The modified example source shows what needs to be done to reflect what
 structure is required for a cp/m-86 8080 model application.  Namely,
 the requirement that space be left for 'page zero', the 100h bytes at the
 begining of the code segment of a 8080 model, single section, application.
 Also, the nasm  naming of sections must be as for cp/m-86's asm86: .cseg, 
 as well as, .dseg, .eseg, .sseg, .x1, .x2, .x3, .x4, if used, in that order,
 for other models of code namely small and compact.  If small and compact
 models are used, then the space for 'page zero', 0100h bytes, is required
 to be at the beginning of the .dseg section.  For more insight on CP/M-86
 code models, segments, structure, see the 'CP/M-86 Operating System System
 Guide'.

The steps required to produce a .cmd file under Dos are:

 1) Assemble suitable asm source with NASM.  For the example, the command is:
     nasm -f bin biosmem3.asm -o biosmem3.bin -l biosmem3.lst
 2) Use the utility NASM2HDR to convert a .MAP file to a .HDR record.  At 
     nasm2hdr's prompt:  biosmem3.map
 3) Combine the .HDR binary to the front of the binary .BIN to make
     a .CMD executable for cp/m-86.
    This step is done using Copy.  With DRDOS v6, the command line is:
    COPY /B BIOSMEM3.HDR+BIOSMEM3.BIN /B BIOSMEM3.CMD

-------------
 Errata
-------------
 2 clippings of code are provided: pgbound.clp pads a section out to a 16
  byte page boundry, which is when the lowest order nibble, of the address of
  the last byte in a section, is 0000b-1, i.e. nnnFh.
  This helps keep relative addresses sane thru alignment roundings.  The page
  boundry macros are meant to be used at the end of each section used.  It
  forces the section to be a multiple of 16 bytes in physical size.

  Also, prep.clp is provided as an example of how to reserve the 'page zero'
  area.  This is one structure requirement for cp/m-86 applications.  Another
  requirement is section naming and order, it is the same as for DRI's 
  ASM86.CMD usage, and as given above.

  NASM outputs a default .text section in the map file.  It is a null section
  description if nothing is described in the source using that section name,
  and for cp/m-86 applications, nothing should be described for it.  The
  utility, nasm2hdr.exe, expects the null .text section decriptor to be present
  in the .map and begins its line processing of the .map section descriptors
  following it.  If future versions of nasm change the .map listing format,
  then the utility will need to be changed.  NASM is the Netwide Assembler,
  see SourceForge on the net.  My copy is included for consistancy checking.

 The example program, which uses RomBios Calls to get the full memory of
 a system, needs a clear screen function.  If the cursor is at the bottom line
 when the program is run, then the output picks-up the status line video char
 attribute, and overwrites the cp/m-86 status line. 

 Model code for Small and Compact was not sufficiently explored as yet, just
 the utility was verified to output proper header record info if multi-
 sectioned code is used.  Sections .x1, .x2, .x3, .x4, are virtual .BSS type
 sections to reserve addressable space at program runtime.  This is
 accomplished by use of resb, resw, etc., assembler directives.  No generated
 code or data can occupy these sections.  This is a restriction of the cp/m-86
 Loader for these segment descriptors.

---------------------------
Re: Disclaimers & Feedback
---------------------------
 Usual disclaimers, use at your own risk.  Don't develop on production systems.
 Don't develop on mission critical systems.  Don't develop on your main home
 system.  This code is poorly tested, not suitable for any situation where
 risk of loss of any type is possible.

 Feedback: s_dubrovich@yahoo.com re:NASM2HDR

;; -- eof --
