• Please review our updated Terms and Rules here

Z80 assembler question

E

enrico

Experienced Member
Joined
Nov 4, 2007
Messages
121
Location
Pisa - Italy
I'm using an assembler z80 by practicing to see if it can properly assemble the source code of my card Ferguson BigBoard I. At reset, the CPU executes a sequence inserted in his first 16 bytes :
DI
ROMRAM: LD HL,0010H
LD DE,ROM
LD BC,0800H
LDIR
JP ROM
NOP
This sequence allows to copy the contents of the 2716 EPROM (2Kbyte) in RAM at F000H address and then jump to run the copied code into RAM at that address.

The assembler requires me to enter 3 addresses in hexadecimal.

1) Enter the base address of flash or ROM memory in the system. This wizard assumes this area is contiguous but the linker is not restricted to this setup

2) Enter the base START address of RAM in the system. This wizard assumes RAM is contìguous above this address the linker is not restricted to this setup

3) Enter the base logical START address of RAM in the system noting that logical addresses are from 0000 to FFFF. For a banked program, this should be blank for automatic assignement.


The values ​​that I thought would be:

1) 0000H, because the itself ROM start address is 0000H
2) 0000H, because in CPM system, the zero page RAM starts at 0000H
3) 0000H, why not using bank switching (not sure exactly what it is) the zero page and the start of RAM should still 0000H

In this way, however, get a .bin file of 62kbytes as if it were an image of all the RAM 0000 to F7FF instead of a 2Kbytes file like the code I copied from my 2716 eprom.

Could you suggest me what to put exactly?

Thanks in advance for any suggestion
Enrico
 
You'll have to locate your move routine above address 4000 hex, because bit 7 of port 1C controls whether or not the ROM is mapped into the lower 16K of the Z80 address space. The simplest way to snapshot the ROM would be to locate your code above 16K, set bit 7 of port 1CH and copy from 0-8K (where the ROM will be) to some location above 16K, then clear bit 7 in 1CH after the copy is done.
 
In your code, you have not specified a value for the label ROM. It should be the high memory start address - in my 64k RAM system this is C600H but it seems your system specifies F000H.

It would be better to use a different name such as HIRAM, because the destination for the LDIR move is in RAM but you are naming it as ROM, which can be confusing.

In your post, it is not clear whether the "wizard" is generating this code. Do you have a LIST file of what happens when you run your assembler? Check what values are being generated for HL, BC and DE.

Rick
 
Rick, both the ROM and video memory are bankswitched in at 0000 on the Ferguson Big Board I. The system starts at reset at 0000, with ROM and video mapped in. After that, it's up to the software what ends up in high RAM.
 
I don't know how the Fergusson board configures its bank-switching. Enrico seems to be assuming a single address space 0000-FFFFH. Is Chuck saying that the Fergusson board translates 0000 to F000h by hardware jumper selection?

If the value of the label "ROM" is declared to be 0000H in the source code, then the command JP ROM, after the LDIR, will jump to whatever instruction has been copied from 0010h in the hardware ROM to address 0000h in RAM. If the boot code does some basic hardware configuration and then loads CP/M in high RAM and jumps to it, as Enrico seems to be expecting, then that code at base of memory will be overwritten by CP/M's cold boot sequence that puts a number of jump vectors in page 0 of RAM.

Enrico says that his modified source is compiling to a size of 62Kb. That suggests that the address F000H is being set as a location within the ROM code, with the result that the compiler takes F000h as defining the end of the code space.

It's only guesswork unless Enrico can provide a listing of his compiled code.

Rick
 
What I understand about the BB 1 is that the BIOS ROM and video are bank-switched at 0000 for 16K. Part of the startup is to copy what's needed to high RAM and then bankswitch the ROM and video RAM out until needed for console I/O. While this gives you 64K of RAM, it's a little bit awkward, since the video routines have to switch the video memory in to update it.

Note that, upon reset, execution starts at 0000.
 
Good pointer to Bitsavers (when all else fails, RTFM)

The linked pdf shows a monitor assembled for ORG F000H, which doesn't solve the initial load issue.

At this link http://bitsavers.org/bits/Furguson/bbrom/INIT.MAC (note misspelled Ferguson) is the code needed at a reset to 0000H. It is part of a family of MAC sources for the monitor modules.

This shows that the ROM code performs CRC memory and video checks and hardware configs before copying the resident monitor up to F000H and jumping to it there. CP/M is loaded on a command from the monitor prompt.

I think Enrico has been trying to do a normal CP/M-type load and boot from ROM code. This won't work because the Ferguson ROM code wants to configure hardware before loading CP/M. I suppose there might be home-brew CP/M BIOS versions that skip the monitor load - but not on Bitsavers.

No sign of any "wizards" there either - perhaps a reseller or user-group made one?

I didn't see code to switch out the ROM at 0000h after loading high, or to ensure port ICh has enabled full 64k RAM, but it may be buried in those MAC sources. My system uses S100 "phantom" line to disable ROM. CP/M will use RAM page 0 anyway after cold boot completes.

Hope Enrico is making some sense of this?

Rick

Rick
 
MikeS said:
What does the display system do in the meantime, or does it fit into the vertical blanking interval?

What is this "wizard" of which the OP speaks?
Click to expand...

Dunno about wizards. Thought that was Microsoft-speak for nearly useless diagnostic utilities, such as "Is your computer turned on? Click "Yes" if it is, "No" if not or "Don't know" if you're uncertain.".

I haven't looked at the video update code in a long time, but it's entirely possible that it's possible to update the video without waiting for the blanking interval.
 
RickNel said:
I didn't see code to switch out the ROM at 0000h after loading high, or to ensure port ICh has enabled full 64k RAM, but it may be buried in those MAC sources. My system uses S100 "phantom" line to disable ROM. CP/M will use RAM page 0 anyway after cold boot completes.

Hope Enrico is making some sense of this?
Click to expand...

Pretty much what I said back at no. 3.
 
Chuck(G) said:
Dunno about wizards. Thought that was Microsoft-speak for nearly useless diagnostic utilities, such as "Is your computer turned on? Click "Yes" if it is, "No" if not or "Don't know" if you're uncertain.".
Click to expand...
:rofl:

I haven't looked at the video update code in a long time, but it's entirely possible that it's possible to update the video without waiting for the blanking interval.
Click to expand...
No doubt, but it'd be interesting to see how they did it with the video RAM moved. Not interesting enough to dig through the docs though ;-)
 
You must log in or register to reply here.
Back
Top