64k ram pointers boundary

[sandruzzo]

Is there a way to be sure to have bitplanes and other pointers inside the 64k ram boundary, to speed up pointers' set-up, with allocated or reserved memory on ocs/ecs and Aga too?

[a/b]

I allocate extra 64KB and then ptr = (ptr+$ffff)&(~$ffff). You can also try AllocAbs() in a loop and see if you can get it.

Also, make sure that you don't under/over-flow (e.g. blitter in decrement mode, blits the last line and then mods get "added" and you drop down to the previous 64KB bank, so the next blit will have bad upper words).

[Thomas Richter]

Not from the operating system, but you can allocate the bitmap yourself and fill the plane pointers, and pass the bitmap structure over to OpenScreen with a tag.

To allocate memory aligned, the usual way of doing this is first a Forbid(), then an AllocMem() of the memory block with the size increased by 64K, then round up the start address to the next 64K boundary, then FreeMem(), and then AllocAbs() of the block you need, then finally Permit().

Or, mmulib/AllocAligned(), which does quite the same.

[sandruzzo]

@a/b , @Thomas Richter

Thanks

[a/b]

That's a nice way of doing it, with AllocMem I mean, but what could work better is get exec->MaxLocMem and then loop downwards in 64KB decrements. Leaves no gaps and if you are still multitasking it can reduce segmentation.

[Jobbo]

On the A500 for a game or demo it seems fragile to rely on the OS for multiple allocations.

I just allocate one big chunk that's as big as I need for the whole program and then manage that myself with a stack allocator.

My allocator has calls that will align to some size or make sure to fit inside some alignment. I'm then able to allocate buffers that are within a 64k page without wasting too much space.

My main point is maybe that buffers don't need to be 64k aligned for you to only update the lower 16bits. They just need to be limited to within some 64k page.

Maybe there are other ways of making such an allocation that could be clearer but I found the concept of keeping "inside" an alignment was the best I came up with.

[sandruzzo]

Is it possible to do the same with assemblers' directives like ds.b or rs.b and like that?

[hooverphonique]

Originally Posted by sandruzzo

Is it possible to do the same with assemblers' directives like ds.b or rs.b and like that?

Hmm.. You could reserve a bss_c block like explained with AllocMem above, but the trouble is that it is tricky to free the unneeded part of the block yourself (assuming that you want to do that as soon as you've got your 64k aligned block).

[paraj]

If you mean something like

buffer:
  ds.b buffersize+65336
  ...
  dc.l (buffer+$ffff)&(~$ffff)

Then no, as such a complex relocation isn't possible.

By the way you only need to allocate twice the needed size. Either the allocation already fits or you can move the buffer start to the next 64K boundary. Slightly more complicated but could be useful in low mem situations. I.e. something like:

    move.l  #bufferbytes,a0
    move.l  a0,d0
    add.w   #buffersize-1,d0
    bcc.b   .ok
    clr.w   d0
    add.l   #1<<16,d0
    move.l  d0,a0
.ok
    ; buffer in a0


bufferbytes:
    ds.b    buffersize*2

[Don_Adan]

Originally Posted by paraj

If you mean something like

buffer:
  ds.b buffersize+65336
  ...
  dc.l (buffer+$ffff)&(~$ffff)

Then no, as such a complex relocation isn't possible.

By the way you only need to allocate twice the needed size. Either the allocation already fits or you can move the buffer start to the next 64K boundary. Slightly more complicated but could be useful in low mem situations. I.e. something like:

    move.l  #bufferbytes,a0
    move.l  a0,d0
    add.w   #buffersize-1,d0
    bcc.b   .ok
    clr.w   d0
    add.l   #1<<16,d0
    move.l  d0,a0
.ok
    ; buffer in a0


bufferbytes:
    ds.b    buffersize*2

I dont coded long time, but for me this routine will be dont works correctly if .ok is reached from branch. Still missing is clr.w D0. Perhaps something like this can works.

    move.l  #bufferbytes,a0
    move.l  a0,d0
    add.w   #buffersize-1,d0
    bcc.b   .ok
    add.l   #$10000,d0
.ok
    clr.w D0
    move.l D0,A0
    ; buffer in a0


bufferbytes:
    ds.b    buffersize*2

Anyway if Sandruzzo can waste up to $10000 bytes of memory then the shortest version can looks next:

    move.l  #Buffy+$10000,D0
    clr.w   D0
    move.l  D0,A0   ; buffer in a0


Buffy
    ds.b    $10000+buffersize

[paraj]

I could have made a mistake (and code wasn't tested), but if understood it correctly sandruzzo wants a buffer that doesn't cross a 64K boundary (such that only updates of the l(ow) pointer registers are necessary). I.e. that the whole buffer fits inside a single 64K region (note the caveats that a/b mentioned though), but it is not required that it start at a 64K block (address $XXXX00000). If that is required, disregard my post.
Unconditionally clearing the low part of the buffer address would potentially result in an address before the allocated memory.

The idea is that we have a buffer (of twice the needed size). If ((buffer + buffersize - 1) >> 16) == (buffer>>16), the ".ok" case then all bytes of the buffer are in the same 64K region (easy case). Otherwise we know that the distance to the next 64K boundary must be less than buffersize (otherwise the buffer would have fit), and we can move the start address there (and know that we have enough room, since we moved the pointer at most buffersize-1).

As an example consider buffersize=4, all addresses of bufferbytes up to including $xxxxfffc are ok, when we reach $xxxxfffd through $xxxxffff we get ($xxxx0000 + (1<<16)) (which is less than the buffer end address).

[Don_Adan]

Perhaps you right. I understand wrong.

[sandruzzo]

It could be a nightmare to have every bitplanes' pointers inside 64k limits..

[paraj]

Originally Posted by sandruzzo

It could be a nightmare to have every bitplanes' pointers inside 64k limits..

Absolutely, but what you're usually trying to ensure is hopefully more constrained than everything in one 64K blocks, more like bltXpth/bltptXpth in this copperlist/long blit.

[sandruzzo]

@paraj.

That's the key: to do less copper works by optimizing memory usage

[robinsonb5]

I did once write some custom allocation routines for this kind of thing. To avoid wasting the "offcuts", it kept a record of them and would use them for future allocations where possible.
It's written in C, so probably of limited interest here, but I can dig them out if anyone's interested.