SpritesMind.Net

Posted: **Tue Sep 18, 2007 9:39 pm**

Can padding be handled in asmx?

I tried:
ds 524288-*,0

But, this only works up to 1024 bytes, due to the MAX_BYTSTR define. Upping the size of the MAX_BYTSTR would work, but there has to be a cleaner way.

Posted: **Tue Sep 18, 2007 10:09 pm**

How about

Code: Select all

org 524287
ds 1,0

Posted: **Wed Sep 19, 2007 1:07 am**

Chilly Willy wrote:How about
Code: Select all
org 524287
ds 1,0

That's a beauty! Thanks.

It won't work with a defined value though:

Code: Select all

ROMSIZE = 524288

ORG = ROMSIZE-1
DS 1, 0

Posted: **Thu Sep 20, 2007 5:17 am**

cdoty wrote:
Chilly Willy wrote:How about
Code: Select all
org 524287
ds 1,0
That's a beauty! Thanks.

It won't work with a defined value though:
Code: Select all
ROMSIZE = 524288

ORG = ROMSIZE-1
DS 1, 0

You don't use an "=" with org. Org is a directive, not a variable. You might want to do something more general - let's say we want to pad the rom to the next 128K boundary. Something like this:

Code: Select all

romEnd = (* + $1FFFF) / $20000 * $20000
    org romEnd-1
    ds 1,0

Posted: **Thu Sep 20, 2007 5:32 am**

Chilly Willy wrote:
cdoty wrote:
Chilly Willy wrote:How about
You don't use an "=" with org. Org is a directive, not a variable. You might want to do something more general - let's say we want to pad the rom to the next 128K boundary. Something like this:
Code: Select all
romEnd = (* + $1FFFF) / $20000 * $20000
    org romEnd-1
    ds 1,0

D'oh, where did the '=' came from?

It works.

Padding to the next size boundary would come in handy in certain cases. But, for an arcade system the roms are a defined size.

Posted: **Sat Sep 22, 2007 5:03 am**

cdoty wrote:Can padding be handled in asmx?

I tried:
ds 524288-*,0

But, this only works up to 1024 bytes, due to the MAX_BYTSTR define. Upping the size of the MAX_BYTSTR would work, but there has to be a cleaner way.

Like CW said, you probably want ORG $80000. At the very least, you shouldn't specify padding like that in source code. Initialized DS is mostly a way to avoid needing a repeat opcode. If it's for padding, you shouldn't care what value it gets padded with.

And if you want your binary file to start at $80000 anyhow, it's not very useful to initialize stuff that won't even be written.

Chilly Willy wrote:you don't use an "=" with org. Org is a directive, not a variable. You might want to do something more general - let's say we want to pad the rom to the next 128K boundary. Something like this:
Code: Select all
romEnd = (* + $1FFFF) / $20000 * $20000
    org romEnd-1
    ds 1,0

Or you could just do "ALIGN $20000" (or any power of 2), and let the assembler or hex-to-bin converter pad it for you.

If you're outputting a hex file, a hex-to-bin converter should do padding, but if you're outputting to binary, it'll pad with $FF bytes, since $FF is usually the erased state of an EPROM or Flash chip. (and if you care what the value is, then it's not padding)

I suppose a command-line parameter to specify the padding byte might be useful.

Posted: **Sat Sep 22, 2007 5:26 am**

My only use for the padding is MAME and MESS. MAME complains if the file isn't the right size (and about the checksum), and MESS refuses to run the Jaguar emulation if the file size isn't correct.

Actually, another use is that the assembler should generate an error message if the file exceed the specified size. This is a visual reminder to switch to the next size eprom.

Using GCC/AS, objcopy can pad the file (on most toolchains). Under the other compilers, I use a PadFile utility I wrote.

Also, are you planning to finish up the 65C816 assembler?

Posted: **Sat Sep 22, 2007 11:04 pm**

8bitwizard wrote: Or you could just do "ALIGN $20000" (or any power of 2), and let the assembler or hex-to-bin converter pad it for you.

Cool. I didn't realize align could take a value that big. I'll keep it in mind if I need to do something like that.

I suppose a command-line parameter to specify the padding byte might be useful.

For a variety of platforms. Most Atari emulators use the size of the file to determine the file type... exactly 4K, 8K, 16K, 32K = CART, exactly 90K = floppy, etc.

Posted: **Sun Sep 23, 2007 9:34 am**

cdoty wrote:My only use for the padding is MAME and MESS. MAME complains if the file isn't the right size (and about the checksum), and MESS refuses to run the Jaguar emulation if the file size isn't correct.

Actually, another use is that the assembler should generate an error message if the file exceed the specified size. This is a visual reminder to switch to the next size eprom.

Using GCC/AS, objcopy can pad the file (on most toolchains). Under the other compilers, I use a PadFile utility I wrote.

Also, are you planning to finish up the 65C816 assembler?

The genesis hardware need a 128 KB size alignment or your rom won't work correctly. You said objcopy do padding, can it does size alignement which is somewhat different from padding (padding just fill until you reach the pad size where alignement fill until size align).

Posted: **Sun Sep 23, 2007 10:34 am**

I've been using any size ROMs, and all have worked... my ROMs are power of 2 size only when they're 100% finished (so I would not have to wait the writing of 100KB on nmothing if my code is only 412KB)

I use ALIGN $(any value) to get desired size of my ROM image, but I use SNASM68K...

Posted: **Sun Sep 23, 2007 2:01 pm**

TmEE co.(TM) wrote:I've been using any size ROMs, and all have worked... my ROMs are power of 2 size only when they're 100% finished (so I would not have to wait the writing of 100KB on nmothing if my code is only 412KB)

I use ALIGN $(any value) to get desired size of my ROM image, but I use SNASM68K...

Any size of ROMS ? on real hardware ? for me it just doesn't work, gimme some random error. Maybe it's a GCC bug after all.

Posted: **Sun Sep 23, 2007 3:31 pm**

Yes, on real hardware... no problems... what flashcart you use ? maybe the problem lies in there...

Posted: **Sun Sep 23, 2007 4:32 pm**

Stef wrote:The genesis hardware need a 128 KB size alignment or your rom won't work correctly. You said objcopy do padding, can it does size alignement which is somewhat different from padding (padding just fill until you reach the pad size where alignement fill until size align).

The NeoDev linker supports two options:
--gap-fill and --pad-to

gap-fill sets the byte that fills in empty space
and pad-to is the size of the binary.

Posted: **Sun Sep 23, 2007 4:35 pm**

TmEE co.(TM) wrote:Yes, on real hardware... no problems... what flashcart you use ? maybe the problem lies in there...

Yep, Probably the flash card.

If you burn it to eproms, it's automatically padded out (and filled with 0xFF) by the eprom burning software. Or more accurately, eprom burning software is smart enough not to burn 0xFF bytes.

Posted: **Sun Sep 23, 2007 4:39 pm**

My software doesn't pad anything, since erased (flash)EPROM already has FF in unused places...

SpritesMind.Net

asmx and padding?

asmx and padding?

Re: asmx and padding?

Re: asmx and padding?