Hi

Im putting together a 6502 based computer on an FPGA. I want to put a 4k ROM starting at 0xF000h.

What I don't understand is how to create this ROM in assembler. I have been using the xa65 assembler. The problems I am unable to solve are.

1) Getting the assembler to output a file exactly 4K long so I can convert it too VHDL easily.

2) Placing bytes at specific positions in this ROM (e.g. at byte FFFC to determine on reset behaviour).

3) Having all code labels from 0xF000h -> 0xFFFFh.

Hopefully my problems makes sense. I have poured over the man pages but am none the wiser. If anyone know how to solve these problems, or where I might go too look for a solution I would be very grateful.

Thanks

Jack

1. The unused space is "don't care." IOW, you can fill it with FF's or leave it random, or whatever. The file doesn't have to be for exactly 4K; but if you want it to be, use whatever kind of FILL directive your assembler has to fill the space you don't use.

2. The assembler directive on the assemblers I've used (and it's probably almost universal) to tell it where to start laying down code is ".org" for "origin" of the following code. So the line before the vectors will say something like:



3. the .ORG $F000 line at the beginning of your ROM code will start it at the appropriate place. You might need another .ORG before the actual ROM code starts however for RAM-resident variables. That's ok, since you can use .ORG as often as needed. In fact in one of my projects, I used it many hundreds of times.

Since I am the original author of xa65, I can probably help...



Those two can actually be solved the same way. In absolute mode (i.e. the file starts with "*=$f000" for example to define the ROM start address), you can fill in bytes up to a specified address with



The pseudo opcode has two parameters, one the number of bytes to fill, second the byte used to fill (which is optional). Using "$fff0-*" computes the number of bytes to fill from current PC ("*") to address $FFF0. I.e. the following opcodes or data will be located at $fff0.

For example to put the vectors at the end of the ROM:




Not exactly sure what you mean with this. To output all labels into a specific file, add the command line option "-l labelfile" to the xa65 command line. Then xa writes the labels to the given file, but this is written in the man page.



Hope I could help,
André

Just a pet peeve of mine -- writing 0xF000h is supported only in the Department of Redundancy Department.

0x is the C-language prefix for hexadecimal base. 'h' is the Intel suffix for the same. '$' is the Motorola prefix for the same.

So, 0xF000 or 0F000h or $F000 are all the same thing. 0xF000h is, strictly speaking, nonsensical, for 'h' isn't a hexadecimal digit, and neither is 'x'.

We now return to our regularly scheduled discussion.

And '&' was Acorns prefix on the BBC Micro!

_________________
"Either we are alone in this universe, or we are not"

Using $ to denote hex has been a 6502 tradition since the beginning of time. As for the Department of Redundancy Department, I have a book here called UNIX Internals (authors Myril Shaw and his wife) in which that august department is in full swing. The book's page count would have been at least 20 percent smaller if the DoRD had been disbanded prior to going to press.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I know the 0x____ is standard C stuff, but it really, really rubs me the wrong way, because in other contexts the "x" usually means you either don't know or don't care what that digit is. For example, we had a "44x" model where the x could be a 4, a 6, or an 8, so "44x" was less cumbersome in the documentation than "the 444, 446, and/or 448" over and over and over. I would also say the address of port B of VIA1 on my workbench computer is $60x0, where the "x" is 4 "don't care" bits. They can be anything and it won't make a bit of difference to the VIA or anything else in the computer. It could be $6000, $6010, $6020, $6030, etc..

But Garth, in every single case you listed, it's 100% unambiguous what you mean. 0xF00 is likewise unambiguous when you're talking about software written in C. You will never see 'x' without that leading zero.

For the same reason, is BEEFH a label? Or, is it a hexadecimal constant? It could well be both. What determines which is that leading zero, again. 0BEEFH is the constant, BEEFH is the label.

You just have to know what context you're talking in.

I'm in agreement with Garth. The 0xABCD format is not intuitive (presuming that hex is somewhat intuitive to the reader) and the "H" suffix makes for Harder reading. I like the $ABCD format because the dollar sign has no resemblance to an alpha character or a numeral. As the very earliest MOS Technology documentation used the dollar sign to refer to hex values, it has power of precedence. Why deviate? Is it because the person doing the deviation thinks their way is better? If so, let's see some supporting evidence that it is.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Wow -- and you call ME confrontational...


I have a better explanation.

C has, in effect, dominated 99% of the software development conducted on any arbitrary microprocessor you care to name, either directly (it's displaced Forth as the language du jour for embedded development) or indirectly. It's literally everywhere -- it features itself quite prominently in languages like C++, C#, Java, and perhaps to a lesser degree, Perl. So, given the statistical probability of prior C exposure by the author, it is natural that he used 0x-notation without even thinking about it. It's not an issue of it being "better". Further, you won't find evidence of it being superior or inferior because you cannot objectively measure subjective opinions, impacts on parser design in any meaningful way, or even ease of IDE implementation. So, it's not even worth it to try. 0x-notation can be parsed with LL or LR grammars, and both parser- and lexer-generator tools make quick work of supporting 0x-notation without batting an eyebrow. Even if the resulting parser becomes somewhat more complex (perhaps a reduction rule or two at most), the notation's popularity ensures that's just one less thing you need to train new users of your product on, so there's just no question that that complexity will pay itself off on its own.

Additionally, an increasing number of assemblers now support this notation. It's the only system supported by the AVR 8-bit assemblers (I presume the same is true for their 32-bit line-up too) I've ever used. It's recognized, if not actively used, in every 80x86 assembler I've used, Unix or Windows alike. It's also dominated the hex notation used in virtually every RISC processor assembly syntax on the market today.

P.S.: I'm not sure if I mentioned this before, but the $-notation actually started with Motorola, as I indicated before, with the release of the 6800 microprocessor and its documentation. This is not a MOS Technologies original.

I'd like to point out that I prefer $-notation because it's more comfortable for me to type, not because I have an easier time reading it. I have no problems what-so-ever discerning 0x-notation hex constants from non-hex constants.

So, I'm not arguing in favor of 0x-notation. I am, however, trying to keep the discussion as objective as possible. And, I note that we've veered horrifically from the original topic of this thread.

so going back to the original topic - did you manage to create the boot rom?
Any more questions concerning xa65?

André

I'm using the ASxxxx collection of assemblers, because it covers most of the processors I want using similar syntax, and is relocatable. It requires 0x even on the 6502.