Skip to content

toy far memory support for MSXDOS2#2517

Merged
suborb merged 3 commits intoz88dk:masterfrom
bradstallion:msx_far_memory
Apr 16, 2024
Merged

toy far memory support for MSXDOS2#2517
suborb merged 3 commits intoz88dk:masterfrom
bradstallion:msx_far_memory

Conversation

@bradstallion
Copy link
Copy Markdown
Contributor

No description provided.

@suborb suborb merged commit 075b598 into z88dk:master Apr 16, 2024
@suborb
Copy link
Copy Markdown
Member

suborb commented Apr 16, 2024

Thanks a lot. I shall tinker (maybe a lot!)

@bradstallion
Copy link
Copy Markdown
Contributor Author

I hope so! :-D

@suborb
Copy link
Copy Markdown
Member

suborb commented Apr 16, 2024

I think something like this (untested) sorts out the low-level primitives - assuming that the banks have been setup (eg by the loader) in crt0.

Should be a speed improvement on your implementation.

Malloc() and friends themselves could be written in C, start off with a 16k heap and extend as necessary, just making sure the banks used for the pool are adjacent (so that pointer addresses in the pool are a continuous range even if the actual hardware segments aren't). Doing it that way would allow an allocation > 64k. E

Each free block has a header:

; +----------------------+
; |                      |
; +--  size (3 or 4 bytes)
; |                      |
; +----------------------+
; |                      |
; +--  next (3 bytes)  --+
; |                      |
; +----------------------+
; |                      |
; |   available bytes    |
; |                      |

And allocated block has:

; +----------------------+
; |                      |
; +--  size (3 or 4 bytes)
; |                      |
; +----------------------+
' |
' |  Allocated data

Getting ahead of myself though, I'll test out my variants and see how they work.

; Entry: hl = physical address
;       ebc = logical address
__msx_incptr:
    inc     hl
    inc     c
    ret     nz
    inc     b
    jr      nz,skiphigh
    inc     e
skiphigh:
    ; We end up repaging every 256 bytes which isn't optimal§
    push    af
    call    __msx_virt2log_page
    pop    af
    ret



; Entry: ebc = logical address
;         a' = local memory page
; Exit:   hl = physical address to access (bank paged in)
;        ebc = logical address
;
; Corrupts: d,a
__msx_virt2log_page:
    ld      a,e        ;With e=0 it refers to local memory
    and     a
    jr      z,localfar
    ld      d,e
    dec     d    ;Fudge (e=0=local memory, e=1=first banked memory)
    ld      a,b
    rla
    rl      d
    rla
    rl      d
    ; d is now which bank we should look at
    ld      a,b
    and     @00111111      ;Take mod 16384
    or      @01000000   ;Map to 0x8000 page
    ld      h,a
    ld      l,c
    ; hl = offset within bank
    push    hl
    push    de
    ld      hl,__msx_bank_mappings
    ld      e,d
    ld      d,0
    add     hl,de
    ld      a,(hl)
    call    PUT_P2
    pop     de
    pop     hl
    ret

localfar:
    ex     af,af
    ld     d,a
    call   PUT_P2
    ld     a,d
    ex     af,af
    ld     hl,bc
    ret

With primitives looking like:

; Entry ehl = logical address
;        hl =  int to return
lp_gint:
    call    GET_P2
    ex      af,af
    ld      bc,hl
    call    __msx_virt2log_page
    ; hl = physical address
    ld      a,(hl)
    call    __msx_incptr
    ld      h,(hl)
    ld      l,a
    ex      af,af
    call    PUT_P2
    re

@bradstallion
Copy link
Copy Markdown
Contributor Author

That's interesting. I look forward to know how it will proceed :-)

@suborb
Copy link
Copy Markdown
Member

suborb commented Apr 17, 2024

I've tested it within the named address space example and the mechanism works

    int *__far p;

    p = 0x00010000;
    printf("Far pointer value is %d\n",*p);

    *p = 52;

    printf("Value in address space 1 is %d\n", value_in_b1);
image

I think that's enough for one evening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants