• Please review our updated Terms and Rules here
  • Exhibitor application for VCF West 2022 is now open! If you are interested in exhibiting, please fill out the form here.
  • Here are the results of the VCF East 2022 Post Event Survey: Survey Results

Assembling to an address other than 0100H

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,611
Location
Near Milwaukee Wisconsin
Now that I'm incrementally smarter regarding CP/M, I want to convert my System Monitor program & cold start loader located at the top 2k of my 64k system, to CP/M ASM. I want to add I/O byte code, read/write retry on soft errors, improve some messaging and remove some stuff that I do not need. I also found some poorly written code in my Wait Interrupt FDC code that I want to improve.

So, I'd like some confirmation or correction of the method I want to try.

1. Rewrite my code from my old homemade assembler to CP/M with the corrections I want. I believe that instead of starting out with ORG 0100H I will change this to ORG F800H.

2. Assemble the code as normal to produce X.PRN and X.HEX files.

3. Run DDT with no spec's.

4. Run INPUT - IX.HEX

5. Set the drive number S5C XX 01 Drive A:
XX . CR

6. Read file to a different start address, R8000

I believe that this will result in my new code to be written to 8000H with all the addresses needed to operate at F800H. At this point I can use my EEPROM programmer to transfer this new code to a EEPROM. If my new code works (what are the chances?) all I have to do is plug in this new EEPROM and it should work with the new functions.

Is my thinking & suggested method correct or have I made an error? Thanks Mike
 

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,611
Location
Near Milwaukee Wisconsin
First. I want to apologize for posting this here. It should have been in the CPM one. Yes my programmer would do that. I was under the impression that the .HEX file did not have all the addresses set in it and the LOAD program was responsible for that. Mike
 

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
38,863
Location
Pacific Northwest, USA
Okay, so what you want to do is assemble code to be executed in your PROM mapped at F800, but you need an image of the code to write into the PROM.

So do your assembly ORG-ed at 0F800H

Next, use DDT the way you described, but -

ix.hex
r900
g0
SAVE 8 X.ROM

The idea is this: DDT will add the ORG address to 900H, giving 10100H, but the 64K carryout will be lost. Thus, the code will load at 100H. You quit DDT and issue a SAVE 8 to the file X.ROM. This saves 800H bytes (8 x 256 bytes) to X.ROM. Then program the X.ROM to your EEPROM. (Note that SAVE always starts its writing from 0100H).

Simple, isn't it?
 

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,611
Location
Near Milwaukee Wisconsin
OK, if I assemble the program ORG'ed at F800, that should produce a X.HEX file that has all the addresses set for F800, is that correct? Then the INPUT X.HEX just initializes the default FCB. The READ900 moves the code to 0100H without changing the internal addresses. G0 quits DDT and the SAVE makes the memory image of my new code at 0100H. OK, that sounds fine, although my EEPROM programmer is a CP/M program that also loads at 0100H and will overwrite this file. I think I need to relocate one of these to make it work? Thanks Mike
 

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
38,863
Location
Pacific Northwest, USA
I don't know much about your programmer, but in all of mine, the image of the ROM is what matters, not where the programmer resides in memory. So, the file that you save should be the one that you program--unless you have a very weird programmer.

Consider, for example, using the programmer to progran a PC BIOS image that loads and executes at the 8086 memory address block FE000. You don't have that many address bits (20) on your Z80 address space, but it doesn't matter--all you're doing is programming an 8Kx8 PROM with some bits--where they're located in memory is irrelevant. They might as well be the ASCII for a dirty limerick.
 

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,611
Location
Near Milwaukee Wisconsin
Well..... once again I have to claim that the programmer is of my own design. It is (now) a CP/M program that merely copies one memory block of system memory, defined by the user, to the EEPROM. OR... it reads the EEPROM to a user defined memory block. I made it this way because I didn't know any better and it worked for me. I assume that the programmer that you are familiar with must read a file into some unused memory space (or maybe directly to the EEPROM?) and then program the EEPROM from that? So..... I suppose that what I really need to do is rewrite the programmer to be able to read a file into some unused memory space and then program the EEPROM from there. THanks Mike
 

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
38,863
Location
Pacific Northwest, USA
Well, what you program should be properly treated as a bunch of bits in a file--nothing more. The programmer should not have to care about the actual content. Consider, for example, a ROM used as a character generator. There's absolutely no code in that--it's just bit patterns.
 

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,611
Location
Near Milwaukee Wisconsin
YUP! I agree and my programmer doesn't care what it is moving from memory to the EEPROM. The problem that I will have is when I load the CP/M program that runs my EEPROM programmer it will reside at 0100H. So if I load the X.ROM of the new monitor code at 0100H, one will over write the other, unless there is a way to load X.ROM at some other address. OK! I think it just sank in. I will load my programmer at 0100H and then load the X.ROM with DDT at some other address, just as I did with the X.HEX file. Sorry, you have to remember I'm just an old power plant engineer with fly ash and coal dust in my pockets. Mike
 

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,611
Location
Near Milwaukee Wisconsin
Hey this works! I have successfully converted my monitor and cold start loader to CP/M and using the method above. I moved it to a spot where my EEPROM programmer could grab it and put it on EEPROM. This also gave me another chance to get familiar with my monitor and repair a minor bug I had in it. I also found an error in my CSL in the interrupt handling department. Maybe this is the trouble I'm having with the occasional BAD SECTOR errors. Time will tell. Well, now I have to decide how to proceed with the improvements I want to make. Thanks Mike
 
Top