Making ROM images

Well, this may sound like a stupid question, but once one has an object listing or listings, how does one put this into a format that can be burned into a ROM?

For instance, I need several blocks of code that work together in a 4K ROM. The ROM has addresses from $0000 to $0FFF. But in the system the ROM will sit at $F000 - $FFFF. The code segments will be at $FC00-$FCAF, $FE00-$FEFF and at $FFA0-$FFFF in the system. While I know these will need to be at $0C00-$0CAF, etc… in the ROM, how does one normally go about making the file that can be burned directly into the ROM?

Bill

What you store in a ROM is simply a series of numbers. Doesn't matter how they are interpreted in an application, they are just numbers at specific addresses.

You can enable the ROM to appear at any arbitrary set of system addresses by use of an external decoder that only sends CS^ (chip select not) when it has decoded the address at which the ROM exists in the system.

Storing specific values in the ROM at different internal addresses can be done with a set of offset tables. You arrange the data in your computer memory and burn the ROM.

Most often, the programmer takes a block of memory from the host computer and writes it all out to the ROM. Your programmer may allow you to do it an address at a time. You particular ROM and programmer are a mystery at this time.

Thanks for your response beenthere.

I am quite familliar with the hardware aspects and do not have a problem with where the ROM goes or how to address it.

Here's the missing key. How do I arrange the data in a file that can be loaded by an EPROM burner?

To this date, I take the assembler output (object code) and manually, with a text editor, place teh code fragemnts into a matrix of 'FF's to make the file. Like this:

'FF FF FF FF A9 D0 20 00 1C 20 40 1C 29 F0 F0 F9'
'FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF'
'FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF'
'8D 01 10 48 AD 01 10 29 10 F0 F9 68 8D 00 10 60'
'FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF'
'FF FF FF FF FF FF FF FF FF FF FF FF 00 1C FF FF'

I'm using a 6502 cross assembler, so I do not have the luxury of loading the code up in ram, testing it then taking an image of that. There has to be a better way of putting all the object code fragments together with the 'FF' pad characters to produce a ROMable file. Editing lagre files manually like this can't be the only way.

Well, I simply don't know. Back in the day when I was doing assembly with 6502's, that was the way it got done - my burner just transferred a ROM-sized block of memory into the ROM. Sounds really clunky if you can't store the image in RAM and then just write it out as one block.

I've burned a few Z80 EPROMs some years ago. In my projects the code was able to be located starting from address 0, but I can understand your problem.

If it were me, I'd write a Perl script to generate the image. In the Perl, the code would simply do what you've been doing by hand, except do it faster, easier and would help avoid typing errors. Perl could read the original output files, generate filler characters and write a final file, all in one pass.

Yeah, maybe that's the eventual solution. I've been putting it off trying to find something that did this. I am pretty amazed that there is not an assembler with this option or some other utility. Most of my experience has been in hardware and high level compilers. I just assumed the firmware jockey's had all this worked out.

I know this is pretty ancient stuff, but I find designing and building these 'old' computers is great fun.

It wouldn't take all that much to build a solid little utility to do this.

My latest machine, BTW, is an 8 chip design that will run a modified version of Tiny Basic.

Sounds nice. Are you still using original 6502's? Those were nice little critters to use. Too bad Apple stuck them in a niche.

beenthere said:

Sounds nice. Are you still using original 6502's? Those were nice little critters to use. Too bad Apple stuck them in a niche.

Click to expand...

Yes, mostly 6502's and it's siblings. The most recent one uses a 6507. I also have plans for other favourites such as the 1802, 6800 and 6809.

eBay is my usual source for this stuff.

There is actually a company that is still making 65C02 derivatives. They have DIP chips that run to over 15Mhz and cores that run to over 40Mhz. The 6502 must have made a real impression in its time for there to be enough demand for this stuff.

My first computer ever was an OSI SuperBoard II and my first retro-project was an expandable 11 chip controller design that runs the UK101 ROMs. The UK101 was a complete rip-off of the OSI, firmware and all. I just proceeded in kind.

I think it's just a divide - some people tune into register based processors and some prefer memory oriented ones.

I did the Apple IIE thing, but started putting in R65C02's and using them as platforms to run lab projects. The lack of compatible storage stopped that in its tracks. The real hoot was using an assembler written in Applesoft Basic.

Is Western Digital still making them?

beenthere said:

Is Western Digital still making them?

Click to expand...

Sounds familliar.

Most of the ones I want to work with are memory oriented memory mapped I/O types. The 1802 is deffinitely a register oriented architecture. Strange bird that one, but I designed a small unit not terribly unlike an ELF with I/O expandability and an RS232 interface back in the day. I want to re-build it and adress some nagginig issues I had with it - 29 years after the fact.

I may whip up an ELF too, although they are practically useless.

BillO said:

Thanks for your response beenthere.

I am quite familliar with the hardware aspects and do not have a problem with where the ROM goes or how to address it.

Here's the missing key. How do I arrange the data in a file that can be loaded by an EPROM burner?

Click to expand...

Usually the cross assembler comes with conversion tools that the EEPROM
burner can use.

For the 68HC11 I used gcc. gcc comes with a linker/loader program (called ld) that
arranges the code to match your memory map. It also comes with a conversion program
that converts the binary data to S19 records to burn the EEPROM. This conversion program is called objcopy. IIRC S19 records where a Motorola (now Freescale) design.

(* jcl *)

Thanks John, I'll look into that.