Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit) (+1)

It's not a built-in feature, but you could write a macro:

:macro unpack-long ADDR {
  :calc hi { 0xFF & ADDR >> 8 }
  :calc lo { 0xFF & ADDR }
  v0 := hi
  v1 := lo
}

`:unpack` itself was added before macros existed, much like `:next`.

(+1)

That's interesting! The behaviour is a bit different though: I can :unpack a label that occurs later in my code, but with this macro I can only use labels that are placed before it in my code.

The reason I want to have a 16-bit unpack is to be able to dynamically point to data in the lower 61.5k from the code in the top 3.5k. I guess the advice would then still be to restructure the code with the whole :org to-data to-code trick..? :/

Why is it that :unpack only does 12 bits? Is it also from before the 65k expansion?

(+1)

Yes; :unpack also predates XO-CHIP overall.

(+2)

Alright, I need to be able to do an "unpack-long" type of thing. Seeing as my file was ~3000 lines anyway, I decided to split it up into smaller files and recombine it in a build stage. This also allows me more flexibility in moving data and code around without getting annoyed by it.

So I'm trying do this:

:org 0x1000
  # Data here
:org 0x0200
: main
  # Code here
  loop
  again

But if you try this in Octo it will give you an error: "Data overlap. Address 0x0200 has already been defined". I guess there's an implicit ":org 0x0200" at the top of the file.

This works:

: main
    jump 0x0202
:org 0x1000
  # Data here
    
:org 0x0202
  # Code here
    loop
    again

But I mean, that's just plain annoying ;P Especially since an "unpack-long" is pretty much the first thing I want to do in my ": main". Do you have any suggestions on how to clean this up..?

(+2)

Your first example, or anything like

:org 0x210
    0xAB 0xCD
:org 0x200
: main
    loop again

Should work now.

I corrected a flaw in the assembler; give it another shot. It doesn't actually stem from any sort of implicit :org, but rather the fact that the "main" label is special. For programmer convenience, Octo will reserve space for a jump instruction at 0x200 to branch forward to main if it is not the first label defined in the program. Once you start re-orging things this gets a little fiddly, and it broke some assumptions I made very early in Octo's history. It would have worked fine if anything *except* main was the first definition in code-space, but now you can have those precious two bytes back.

(+1)

Oh no, you didn't just fix this issue in a matter of hours, just because I complained about it, did you? :) I hope I didn't inconvenience you too much... 

It works like a charm now, thanks for saving my two bytes ;P

(+2)

Now that is dedication! :-)