Hi all,
I am working on a project class where I have to design and build a 68k single board computer. I've gotten my hardware assembled and am trying to work out the kinks and verify function.

I've been provided with the test loop program below, intended to test RAM function. It's not working, though, and while I doubt it's a problem with the program, I am having a hard time troubleshooting the issue because I don't fully understand what the program is trying to do.

As I understand it, each time the program jumps into the do-nothing sub-routine, it has to push registers onto the stack first, and since the stack is a location in memory, this means the memory is getting used and working (if the program runs).

What is the address of the stack? Is it being assigned by the $8080 given on the first line? Is "SUPER_STACK" a sort of keyword used for that?

My system has 512 kb each of ROM and RAM. My decoding scheme uses address bits 16 and 17 to decide if a given address is RAM, ROM, or UART. So, I think valid memory address range should be:
$8000 - $FFFF



Thanks for any insight or pointers!
Scott

The software should work assuming ROM is at $0 and RAM is at $8000. SUPER_STACK is a label. The stack is defined with "DC.L SUPER_STACK" which is at location $0. 68000 loads the stack value at location $0 and program start address at $4 after a reset.

I assume this code is programmed in ROM. Is your processor 68000 or 68008? If it is 68000, you need to split the code into even and odd ROM.

A16, A17 are correct for decoding 512kb (or 64K-byte) ROM and RAM, but then the memory map should be:
$0-$FFFF ROM
$10000-$1FFFF RAM
Your program assign stack at $8080 which is still in the ROM space.

Hrmm. But if ROM extends to $FFFF, that address requires 16 bits to represent, and my chips only have 15 address lines. I thought with 15 address lines, the highest possible address would be 15 binary 1's, or $7FFF ? It sounds like there is something I am misunderstanding.

The processor is a 68000. I split the s record into separate high and low byte files using the software for the ROM burner. There may be an easier way to do that directly from EASy68k. Then I placed these on the high and low ROMs.

Thank you!

I posted another question earlier but I think it is still being moderated. However, in order to avoid wasting anyone's time, I wanted to add that I think I understand now why the addresses are as Plasmo said and it makes sense now. I didn't realize that in software there is an a0 that hasn't got a physical pin associated with it.

With this new understanding in hand, I'll see if I can get things working correctly. Thanks for your help, Plasmo!

68000 has no A0 as you've found out. It uses nUDS and nLDS to represent the even and odd byte access of a word.

EASy68K has a helper program called EASyBIN. You can use it to read in the S record generated by EASy68K. It has the Binary I/O Split feature to split the file into odd and even halves.