MSX Malloc on memory > 64KB

Timmy
Well known member
Posts: 399
Joined: Sat Mar 10, 2012 4:18 pm

Re: MSX Malloc on memory > 64KB

Post by Timmy »

dom wrote: Mon Apr 29, 2024 12:34 pm Where's the MSX implementation? A Timex2068 + ZX128 implementation would be quite nice to have since they're hardware backed.
I assume this is a tile based thing? Because MSX would be easy to that. For example in screen 0 and 1. In other screen modes it would be a bit harder.

But I don't know if ZX128 would be easy at all.

On the other hand, ZX81 would probably be easy.
stefano
Well known member
Posts: 2167
Joined: Mon Jul 16, 2007 7:39 pm

Re: MSX Malloc on memory > 64KB

Post by stefano »

There should be something in the MSX examples folder.
My own incomplete attempt to merge the oz700 and MSX is here

https://github.com/z88dk/z88dk/blob/mas ... howlib3d.c

Probably in many cases it is easier to hack base_graphics, the problem is to make the new functions portable
stefano
Well known member
Posts: 2167
Joined: Mon Jul 16, 2007 7:39 pm

Re: MSX Malloc on memory > 64KB

Post by stefano »

I now remember something more about the frame buffer thoughts. We may have hardware and software enabled buffers, while the hardware one is usually able to switch the visibility on a memory region, the software uses some sort of fast copy routine to limit the glitches.
The user program in the first case could rely on a "flip page" function wiping and rebuilding the hidden page. It could be emulated in software but if we're not sure that the page will be wiped, we should provide 2 buffers to permit small faster changes in the hidden frame.

Long story short I couldn't decide which approach was preferable, being an universal fast copy routine too minimalistic, even for my taste!
bradstallion
Member
Posts: 30
Joined: Wed Mar 13, 2024 12:52 pm

Re: MSX Malloc on memory > 64KB

Post by bradstallion »

dom wrote: Mon Apr 29, 2024 8:27 am
bradstallion wrote: Mon Apr 29, 2024 8:16 amThat would be GREAT! Does sprintf would be affected too?
Of course, all the *printf functions share the same core code.
But a sprintf(char *__far dest, ...) is not in the plan, I suppose, right?

BTW, I tested the nightly build. I think you know it, but %S doesn't seem to be ready yet:

Code: Select all

  char *__far ss = (char *__far)malloc_far(10);

  *ss = 'a';
  *(ss+1) = 'b';
  *(ss+2) = 'c';
  *(ss+3) = 0;

  printf("test %S\n", ss);exit(0);
It prints 'a' followed by a couple of garbage chars.
Thanks
Timmy
Well known member
Posts: 399
Joined: Sat Mar 10, 2012 4:18 pm

Re: MSX Malloc on memory > 64KB

Post by Timmy »

bradstallion wrote: Tue Apr 30, 2024 9:50 am BTW, I tested the nightly build. I think you know it, but %S doesn't seem to be ready yet:
Stupid question, I have never heard of %S, is this something new? (I have heard of %s but that's not this one, right?)
bradstallion
Member
Posts: 30
Joined: Wed Mar 13, 2024 12:52 pm

Re: MSX Malloc on memory > 64KB

Post by bradstallion »

Timmy wrote: Tue Apr 30, 2024 12:09 pm
bradstallion wrote: Tue Apr 30, 2024 9:50 am BTW, I tested the nightly build. I think you know it, but %S doesn't seem to be ready yet:
Stupid question, I have never heard of %S, is this something new? (I have heard of %s but that's not this one, right?)
it is for strings in far memory, you can find info some posts ago
User avatar
dom
Well known member
Posts: 2141
Joined: Sun Jul 15, 2007 10:01 pm

Re: MSX Malloc on memory > 64KB

Post by dom »

bradstallion wrote: Tue Apr 30, 2024 9:50 am But a sprintf(char *__far dest, ...) is not in the plan, I suppose, right?
I forgot about that way round! I can make it happen fairly easily.
BTW, I tested the nightly build. I think you know it, but %S doesn't seem to be ready yet:
Oh, I had it working for +test, but then got distracted by (I think) LLP64 issues on Windows so never got to try it on +msx. I shall dig, bound to be something daft like an assumption over register preservation.
User avatar
dom
Well known member
Posts: 2141
Joined: Sun Jul 15, 2007 10:01 pm

Re: MSX Malloc on memory > 64KB

Post by dom »

dom wrote: Tue Apr 30, 2024 12:34 pm bound to be something daft like an assumption over register preservation.
Quite, I forgot that MSXDOS will corrupt the alternate register set.

sprintff, snprintff, vsnprintff have been added (this is where the f suffix is fairly unpleasant)
bradstallion
Member
Posts: 30
Joined: Wed Mar 13, 2024 12:52 pm

Re: MSX Malloc on memory > 64KB

Post by bradstallion »

dom wrote: Tue Apr 30, 2024 6:55 pm
dom wrote: Tue Apr 30, 2024 12:34 pm bound to be something daft like an assumption over register preservation.
Quite, I forgot that MSXDOS will corrupt the alternate register set.

sprintff, snprintff, vsnprintff have been added (this is where the f suffix is fairly unpleasant)
@dom, that's REALLY AWESOME!!!
Tomorrow I'll try it!
Thanks!!!
User avatar
dom
Well known member
Posts: 2141
Joined: Sun Jul 15, 2007 10:01 pm

Re: MSX Malloc on memory > 64KB

Post by dom »

bradstallion wrote: Tue Apr 30, 2024 8:15 pm [@dom, that's REALLY AWESOME!!!
Tomorrow I'll try it!
Thanks!!!
No worries, the auto-tests passed and the manual +msx test worked for me, so they should work for you as well.

Thanks for the kick about doing this, definitely overdue and __far is a rather fun feature to work on even if it is z80 only. I'm genuinely interested about what sort of things can be written using it.

I'm thinking about adding support for Aquarius+, SAM and ZXN (assuming I can get an emulator working) since they have a decent amount of memory.
bradstallion
Member
Posts: 30
Joined: Wed Mar 13, 2024 12:52 pm

Re: MSX Malloc on memory > 64KB

Post by bradstallion »

dom wrote: Tue Apr 30, 2024 10:51 pm No worries, the auto-tests passed and the manual +msx test worked for me, so they should work for you as well.
Yes, I confirm: I've just tried sprintff and printf(%S) on MSX and they work as expected!
Thanks for the kick about doing this, definitely overdue and __far is a rather fun feature to work on even if it is z80 only. I'm genuinely interested about what sort of things can be written using it.
As I wrote in the first post of this thread, I'm testing the limits of application size and heap size. So I'm mixing __banked functions and __far pointers.
I think that it's very important to have an easy way to malloc all the memory available on these microsystems, and your __far support just makes it possible.

About "what sort of things can be written using it", I hope that this will ease the development of a larger range of applications. I'm not thinking of games, though.

I'll show you the project I'm working on, once I'll finish to move the near mallocs to far ;)
pjshumphreys
Member
Posts: 83
Joined: Sat Feb 06, 2021 2:32 pm

Re: MSX Malloc on memory > 64KB

Post by pjshumphreys »

Timmy wrote: Mon Apr 29, 2024 2:09 pm
dom wrote: Mon Apr 29, 2024 12:34 pm Where's the MSX implementation? A Timex2068 + ZX128 implementation would be quite nice to have since they're hardware backed.
I assume this is a tile based thing? Because MSX would be easy to that. For example in screen 0 and 1. In other screen modes it would be a bit harder.

But I don't know if ZX128 would be easy at all.

On the other hand, ZX81 would probably be easy.
Double buffering on a spectrum +3 is easy as the display buffer can be moved between page 5 and page 7. I believe there's even example code of how to do double buffering in the manual that came with the computer. That paging ability isn't available on a zx128 if I remember rightly.

I have some code that does printing using page 7 on a +3 because then page 5 can be used for heap storage. This gives 30 ish kb available for the near heap and stack (I left the speccy's system variables intact to be able to return to using page 5 for the screen and back to the basic prompt).
pjshumphreys
Member
Posts: 83
Joined: Sat Feb 06, 2021 2:32 pm

Re: MSX Malloc on memory > 64KB

Post by pjshumphreys »

dom wrote: Tue Apr 23, 2024 10:27 pm I've not tested it, but I've added in some code for the PCW 8512. I've made (slightly informed) guesses regarding the default page used in CP/M and the first free page - I'm hoping that the RAM disc doesn't use the extra 256k.
The RAM disc apparently does use the extra space, but after talking with John Elliott of seasip.info he informs me that the RAM disc can be reformatted to a smaller size. To do this, the DSM entry in the DPB gives the number of blocks and BSH gives the block size, so you can work out from that how many blocks in a bank, reduce DSM by that number, and reset the directory to all 0E5h. The freed memory banks will then be the highest-numbered ones; if you instead want the lowest-numbered ones, you also need to fiddle with the OFF entry which, for the RAMdisc, counts in units of 16k.

Here's some code he provided me with from back when I asked about the topic. But unfortunately I haven't yet got around to making use of it:

Code: Select all

You can find the DPB address using the BDOS:

LD C,0Eh  ; DRV_SET
LD E,0Ch  ; Drive M:
CALL 5
LD C,1Fh  ; DRV_DPB
CALL 5 ; Returns address in HL.

By 'reset the directory to all 0E5h', I mean fill the first block of the RAMdisc with 0E5h bytes. Here's one way to do it:

MOVE    equ    0FC4Bh    ;That's where these BIOS entry points are on the PCW -- not
XMOVE   equ    0FC57h    ;very portable!

    ld    hl,buffer    ;Create a 16k buffer of all 0E5h
    ld    de,buffer+1
    ld    bc,3FFFh
    ld    (hl),0E5h
    ldir
    ld    bc,0301h    ;Move from TPA to CP/M bank 3
    call    XMOVE
    ld    hl, 4000h    ;Target address in bank 3
    ld    de, buffer
    ld    bc, 4000h    ;Length of transfer
    call    MOVE

(The memory banking API used in PCW CP/M maps the RAMdisc into CP/M banks 3, 4, 5... in the 4000h-7FFFh range. You can also access them directly by writing to hardware registers, in which case they're banks 89h, 8Ah, 8Bh...)
User avatar
dom
Well known member
Posts: 2141
Joined: Sun Jul 15, 2007 10:01 pm

Re: MSX Malloc on memory > 64KB

Post by dom »

pjshumphreys wrote: Fri May 03, 2024 8:00 pm The RAM disc apparently does use the extra space, but after talking with John Elliott of seasip.info he informs me that the RAM disc can be reformatted to a smaller size.
That makes sense. Thanks for the info on how to resize it. I'll bookmark for when it's needed (i.e. a returning program that uses the ram disc!). It looks like moving OFF would be the easiest way to do it, though either way is destructive.
bradstallion
Member
Posts: 30
Joined: Wed Mar 13, 2024 12:52 pm

Re: MSX Malloc on memory > 64KB

Post by bradstallion »

Ciao @dom,
I was trying the following code:

Code: Select all

typedef union {
  int a;
  long b;
} un_t;

typedef struct {
  char c;
  un_t pt;
} st_t;

void main() {
  st_t *__far far_p = (st_t *__far)malloc_far(sizeof(st_t));
  printf("sizeof st_t: %d\n", sizeof(st_t));
  printf("far_p: %lp\n", far_p);
  printf("far_p->c: %lp\n", &(far_p->c));
  printf("far_p->pt: %lp\n", &(far_p->pt));
}
Compiled with -pragma-define:CLIB_FARHEAP_BANKS=1

On MSX it prints:

Code: Select all

sizeof st_t: 5
far_p: 1d0003
far_p->c: 1d0003
far_p->pt: 40f6b
Considering that I allocated just one bank for far memory, I was expecting to have far_p->pt in bank "1d".
Am I missing something?

Thanks!
User avatar
dom
Well known member
Posts: 2141
Joined: Sun Jul 15, 2007 10:01 pm

Re: MSX Malloc on memory > 64KB

Post by dom »

bradstallion wrote: Mon May 06, 2024 9:29 amConsidering that I allocated just one bank for far memory, I was expecting to have far_p->pt in bank "1d".
Am I missing something?
Thanks for the report: I'm testing a fix for it, should be merged for the next nightly.
Post Reply