How to create a 16k ROM Image

[mkl0815]

Hello out there,

I'm in the planning and evaluation phase for my own 6502 homebrew system. While waiting for the ordered parts I'm doing some research work for the things I need later.
I've got the Symon simulator up and running on my Mac and I'm able to create small assembler programms with ophis or the ca65 assembler and run them step by step in the simulator. Some things are missing like breakpoints or running several steps instead of clicking for every single step, but for now it is ok.

The thing I need help for is to create a complete 16k ROM image that covers the range from 0xC000 to 0xFFFF. The code should start at 0xC000 but it will not fill the whole 16k. I also want the reset and NMI vectors set at the end of the address-range. Is there a simple way to do this with the ophis or the ca65 assembler (or cl65 linker)?
I could create a small script that takes my binary code, fills all remaining bytes with 0xFF and sets the vectors at the end, but if there is a simple way I could avoid this extra work.

Thanks for any hint.

Mario.

[GARTHWILSON]

Hopefully someone familiar with ophis or ca65 will jump in; but until then...
You will most likely start your .asm code with the assembler directive:

Code: Select all

        ORG  $C000

Then at the end of your code when you're ready to skip out to the end to lay down the vectors:

Code: Select all

        ORG  $FFFA

(This is covered in the "Program-Writing: Where Do I Start?" page of the 6502 primer. It doesn't seem to be one of the more stellar pages in the primer, but you will probably still find something helpful there.) The output of the assembler or linker will be some sort of hex file for the (E)EPROM programmer to handle. There are several types. Motorola S19 and Intel Hex seem to be the most common. I have a description of Intel Hex at http://wilsonminesco.com/16bitMathTables/IntelHex.html. A data line in Intel Hex starts with a colon (":"), then the number of actual ROM data bytes in the line, then the base address of the line, then the record type, then has the actual data, and, at the end, a checksum. (I haven't reviewed it in a long time, but that should be correct.) Since the base address of each data line is there, you can have as many ORG directives as you want. (E)EPROM programmer software typically has lots of functions available including the ability to fill a range with some value, usually $FF for locations you don't want to program and are not specified in your hex file.

[Arlet]

Something like this should work:
Source file (demo.a65)

Code: Select all

;
; demo 
;

        .setcpu "6502"

        .segment "OS"

reset:
        ldx     #$ff            ;
        txs                     ;
loop:   jmp     loop            ;


nmi:    jmp     nmi


irq_brk: 
        jmp     irq_brk         ;

        .segment "VECTORS"

        .word   nmi             ; NMI
        .word   reset           ; RESET
        .word   irq_brk         ; IRQ/BRK

Linker config file (demo.cfg)

Code: Select all

MEMORY 
{
     ZP: start=$0, size=$100, type=rw, define=yes;
    RAM: start=$200, size=$3e00, type=rw, define=yes;
    ROM: start=$f000, size=$1000, type=ro, define=yes, fill=yes, file=%O;
}

SEGMENTS 
{
    ZEROPAGE: load=ZP, type=zp;
    DATA:     load=RAM, type=rw, define=yes;
    OS:       load=ROM, type=ro;
    RODATA:   load=ROM, type=ro;
    VECTORS:  load=ROM, type=ro, offset=$ffa;
}

You can find documentation here
Build with:

Code: Select all

ca65 demo.a65 --listing
ld65 demo.o -o demo.bin -C demo.cfg -m demo.map

Note that ld65 produces binary output, not hex records. If you want Intel hex, you need to convert it externally. Use bin2hex.py or some other free tool you can find on the net.

[mkl0815]

Many thanks, that was exactly what I was looking for.
I saw the ca65 documentation, but I missed the "glue" information for the linker config file.

I have now a setup that creates a clean 16k binary image that I can test in the symon simulator. RESET and NMI vectors are used as expected.

Putting the data on an eeprom later will be done by a small self made programmer based on the Atmel/AVR (Arduino) using a serial connection.
I'm quite familiar with this kind of microcontroller so getting this done should not be a big thing.

step by step the picture of my own 6502 system gets clearer

Mario.

[scotws]

mkl0815 wrote:

I've got the Symon simulator up and running on my Mac and I'm able to create small assembler programms with ophis or the ca65 assembler and run them step by step in the simulator.

Ah, a fellow Mac user in this den of Windows fiends . I think the Ophis command you are looking for is .advance . From the manual:

Quote:

.advance address: Forces the program counter to be address. Unlike the .org directive, .advance outputs zeroes until the program counter reaches a specified address. Attempting to .advance to a point behind the current program counter is an assemble-time error.

Can't check my own source file at the moment (this is actually coming from my Chromebook, don't tell Steve Jobs' ghost) but I think I just put it at the end of the code and used the byte right before the vectors as the address.

Note that Symon only works with pure 6502 code, that is, doesn't have the 65c02 new commands such as STZ and BRA. They're really cool. You might want to check out py65 as an alternative (https://github.com/mnaberez/py65).

[mkl0815]

scotws wrote:

Ah, a fellow Mac user in this den of Windows fiends . I think the Ophis command you are looking for is .advance . From the manual:

Cool, thanks for the hint. But it seems that the ca65 has some interesting features like memory-maps. But I will give it a try.

scotws wrote:

Can't check my own source file at the moment (this is actually coming from my Chromebook, don't tell Steve Jobs' ghost) but I think I just put it at the end of the code and used the byte right before the vectors as the address.

I have to work with a Windows Notebook at work but ssh access to my Mac at home is possible, so I can test directly.

scotws wrote:

Note that Symon only works with pure 6502 code, that is, doesn't have the 65c02 new commands such as STZ and BRA. They're really cool. You might want to check out py65 as an alternative (https://github.com/mnaberez/py65).

Is py65 also able to simulate a VIA or ACIA chip? can I configure different memory (RAM,ROM,IO) setups?
Are there any other emulators / simulators for the 6502 and 65c02 running on a Mac?

[BigDumbDinosaur]

scotws wrote:

Ah, a fellow Mac user in this den of Windows fiends .

Mostly on SuSE Linux here.

[scotws]

mkl0815 wrote:

Is py65 also able to simulate a VIA or ACIA chip? can I configure different memory (RAM,ROM,IO) setups?

Not in the way Symon does. There are "getc" and "putc" etc. routines. From the source code:

Code: Select all

m.subscribe_to_write([0xF001], putc)
m.subscribe_to_read([0xF004], getc)
m.subscribe_to_read([0xF005], blocking_getc)

So at the moment, you can have either-or. It would be nice if Symon would get the 65c02 routines, alas, I don't know jack about Java.

[scotws]

Hi Mario,

mkl0815 wrote:

Putting the data on an eeprom later will be done by a small self made programmer based on the Atmel/AVR (Arduino) using a serial connection. I'm quite familiar with this kind of microcontroller so getting this done should not be a big thing.

Getting EEPROMs written seems like it is going to be more and more of a problem as time goes on, especially with the absolutely bizarre prices for programmers. I wonder if it might be worth the effort to try to put together some sort of reference design here for people who are new and are faced with this problem. We could store it on the site somewhere and then say "build that" when the problem comes up the next time.

I'm in the early stages of trying to design an EEPROM programmer on the basis of a Raspberry Pi and a bunch of '595 SIPO chips instead of an Arduino. My reasoning would be that the RPi runs Python and can be used as a "mothership" for all kinds of 6502 stuff, including the assembler and emulator, as well as the programmer. Unfortunately, I've been swamped by Things From the Real Word the last weeks, and it will be Mid-April before I can get my hands on a RPi the earliest.

[mkl0815]

Hi scotws,

maybe we can do this together, cause it seems that you are located near berlin. I'm located in Werder/Havel and I'm working in Kleinmachnow. So working together should not be a problem.

My approach for the programmer are also two '595 shift registers for the address lines and the rest should be done directly by the GPIO ports of the atmega chip. With a small level converter we can still use the raspi as "mothership" that talks via UART to the programmer. The advantage of this is, that you don't need a raspi in fact that any other USB-to TTL-serial adapter can be used to get access to the programmer-board.
I hope that today my order 26C64 eeprom arrived so I can use the long weekend for testing.

Mario.

[GARTHWILSON]

scotws wrote:

Getting EEPROMs written seems like it is going to be more and more of a problem as time goes on, especially with the absolutely bizarre prices for programmers. I wonder if it might be worth the effort to try to put together some sort of reference design here for people who are new and are faced with this problem. We could store it on the site somewhere and then say "build that" when the problem comes up the next time.

Daryl shows us how he does it in-system on his SBC-2 (with a 65c02) at viewtopic.php?f=4&t=2446&p=24465#p24465 and the second post after that. Of course the EEPROM has to have code in it already for the system to work at all, but what's there should help.

[scotws]

mkl0815 wrote:

maybe we can do this together, cause it seems that you are located near berlin. I'm located in Werder/Havel and I'm working in Kleinmachnow. So working together should not be a problem.

Hey, right around the corner! Great idea. We should probably start a separate thread for this ... unfortunately, I don't know jack about the atmega, but your solution sounds simpler and cheaper. Will try to get up to speed ASAP.

[mkl0815]

scotws wrote:

Hey, right around the corner! Great idea. We should probably start a separate thread for this ... unfortunately, I don't know jack about the atmega, but your solution sounds simpler and cheaper. Will try to get up to speed ASAP.

That sounds great. I've just finished a small project that was delayed for several months now and I used the long weekend to get it done. So I'm now "free" to start a new project. I'm still waiting for the EEPROMs but I've got my programming-socket (40 pins) and some ATmega328-20P with 16MHz Crystals waiting for a proper use
I will be off for the rest of the day, but tomorrow I can start playing with an Arduino and a breadboard for first tests.
As soons as I have some results to show I will start a new thread for this.
Mario.