asmx and padding?

[cdoty]

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.

[Chilly Willy]

How about

Code: Select all

org 524287
ds 1,0

[cdoty]

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

[Chilly Willy]

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

[cdoty]

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.

[8bitwizard]

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.

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.

[cdoty]

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?

[Chilly Willy]

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.

[Stef]

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).

[TmEE co.(TM)]

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...

[Stef]

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.

[TmEE co.(TM)]

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

[cdoty]

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.

[cdoty]

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.

[TmEE co.(TM)]

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