Reserving a few bytes in top of MSX memory at startup
Try using the following piece of code in your ROM boot routine:
;----------------------------------------------------------------------- ; ; ALLOC allocates specified amount of memory downward from current ; HIMEM ; ; Inputs: ; HL = memory size to allocate ; Outputs: ; if successful, carry flag reset, HL points to the beginning ; of allocated area ; otherwise, carry flag set, allocation not done. ; BOOTAD equ 0C000h ;Where boot sector is executed ; BOTTOM equ 0FC48h ;Pointer to bottom of RAM HIMEM equ 0FC4Ah ;Top address of RAM which can be used MEMSIZ equ 0F672h ;Pointer to end of string space STKTOP equ 0F674h ;Pointer to bottom of stack SAVSTK equ 0F6B1h ;Pointer to valid stack bottom MAXFIL equ 0F85Fh ;Maximum file number FILTAB equ 0F860h ;Pointer to file pointer table NULBUF equ 0F862h ;Pointer to buffer #0 ; ALLOC: ld a,l ;is requested size 0? or h ret z ;yes, allocation always succeeds ex de,hl ;calculate -size ld hl,0 sbc hl,de ld c,l ;remember specified size ld b,h add hl,sp ;[HL] = [SP] - size ccf ret c ;size too big ld a,h cp 0C2h ;high(BOOTAD) ret c ;no room left ld de,(BOTTOM) ;get current RAM bottom sbc hl,de ;get memory space left after allocation ret c ;no space left ld a,h ;do we still have breathing room? cp 2 ;high(512) ret c ;no, not enough space left ; ; Now, requested size is legal, begin allocation ; push bc ;save -size ld hl,0 add hl,sp ;get current stack pointer to [HL] ld e,l ;move source address to [DE] ld d,h add hl,bc push hl ;save destination ld hl,(STKTOP) or a sbc hl,de ld c,l ;move byte count to move to [BC] ld b,h inc bc pop hl ;restore destination ld sp,hl ;destination becomes the new SP ex de,hl ldir ;move stack contents pop bc ;restore -size ld hl,(HIMEM) add hl,bc ld (HIMEM),hl ld de,-2*(2+9+256) add hl,de ld (FILTAB),hl ;pointer to first FCB ex de,hl ld hl,(MEMSIZ) ;update MEMSIZ add hl,bc ld (MEMSIZ),hl ld hl,(NULBUF) ;update NULBUF add hl,bc ld (NULBUF),hl ld hl,(STKTOP) ;update STKTOP add hl,bc ; ; Re-build BASIC's file structures ; ld (STKTOP),hl dec hl ;and SAVSTK dec hl ld (SAVSTK),hl ld l,e ;get FILTAB in [HL] ld h,d inc hl ;point to first FCB inc hl inc hl inc hl ld a,2 DSKFLL: ex de,hl ld (hl),e ;set address in FILTAB inc hl ld (hl),d inc hl ex de,hl ld bc,7 ld (hl),b ;make it look closed add hl,bc ld (hl),b ;clear flag byte ld bc,9+256-7 add hl,bc ;point to next FCB dec a jr nz,DSKFLL ret
Ok, thanks! So in fact you shift some pointers down to get empty space...
Anyway try it and let me know if it works, since I didn't write this code, in fact I got it from the DOS 2 kernel ROM.
I discovered that this musn't be called before disk ROM initialized (or maybe another reason), worked well for me when called at cursor first show time, otherwise higher RAM slot routines corrupted.
brawaga wrote:
I discovered that this musn't be called before disk ROM initialized (or maybe another reason), worked well for me when called at cursor first show time, otherwise higher RAM slot routines corrupted.
If you want to interact with the disksystem, you need to use the H.STKE approach. The disksystem has a static workarea (0F1C9h-0F37Fh), so if you reserve memory before the disksystem does (HIMEM is lower than 0F380h) this static workarea can not be allocated and the disksystem will be disabled.
zeilemaker54 wrote:
the H.STKE approach
What's this by the way? The doc says I must store previous state to return after first call from there, and that means I already must have RAM allocated.
zeilemaker54 wrote:
If you want to interact with the disksystem
No, not about disk I/O at all.
I made the initialization lazy now, so it starts when cursor first displayed (H.DSPC), definitely after Disk BASIC and MSX-DOS initialize, but still it works only in BASIC, and in DOS it corrupts after any command executed — text garbage on the screen being produced, and then DI+HALT. I prefer to make my cartridge working in any environment, but still debugging in attempt to make out what's going wrong.
I am allocating place for some code to switch slots to my cartridge from hook call, but even without a call after I enable allocation in lazy initialization, MSX-DOS goes mad at me. I checked — all slots restored after calls, I reused F38Ch function to do the job, so it shouldn't be the reason.
Any advice appreciated, I'd rather go on on features furher more than debugging in such inefficient way.
Maybe there is another way to fit hook into 5 bytes (RST 30 does not work when subROM is active), I invented only a call to allocated area, 01Ch bytes in total, garbaging nearest hooks is not a way, and also I could not find a memory in 0C000h-0FFFEh window that is legally safe and free.
The H.STKE approach is to use the hook H.STKE to let your ROM take control again AFTER all other ROMS have done their initialization. In your H.STKE routine you can allocate the alloc routine of konamiman (looks like a exact copy of the routine used in the disk kernel ROM, by the way). The alloc routine of konamiman does not update the stackpointer itself, nor does it move the stackcontent. So be ware of this if stack and stackcontent is vital (normally it is).
in code:
INIT:
CALL GETSLT ; get current slotid in page 1
LD HL,H.STKE
LD (HL),0F7H
INC HL
LD (HL),A
INC HL
LD DE,MYSTKE
LD (HL),E
INC HL
LD (HL),D
INC HL
LD (HL),0C9H
RET
; make sure to save register HL, if your MYSTKE returns control to BASIC interpreter
MYSTKE:
LD IX,H.STKE
LD (IX+0),0C9H
LD (IX+1),0C9H
LD (IX+2),0C9H
LD (IX+3),0C9H
LD (IX+4),0C9H
;
; your code
;
; make sure to move the stack content as well, if you alloc memory and use the stack
RET
zeilemaker54 wrote:
the alloc routine of konamiman (looks like a exact copy of the routine used in the disk kernel ROM, by the way).
Yes, Konamiman wrote himself:
Quote:
in fact I got it from the DOS 2 kernel ROM.
zeilemaker54 wrote:
to let your ROM take control again AFTER all other ROMS
This won't help, I already postponed memory allocation via H.DSPC hook. For an unknown reason, cartridge initialization called twice, so that's also why I moved memory allocation to later stage.
I put address of allocated memory (<32 bytes) into SLTWRK variable to appropriate part regarding slot and window (slot from A8h port and fixed window 4000h-7FFFh).
If I put RET to postponed initialization before memory allocation, some of my features cannot work, but MSX-DOS works fine.
Despite DOS, BASIC works fine with this initialization (probably without Disk BASIC initialization only).
Also, DOS keyboard handling looks strange for me, it takes from keyboard buffer 0FCh unregarding what my handler puts there after the problem occurs. Why separate code to do same that BIOS does?
brawaga wrote:
zeilemaker54 wrote:
to let your ROM take control again AFTER all other ROMS
This won't help, I already postponed memory allocation via H.DSPC hook. For an unknown reason, cartridge initialization called twice, so that's also why I moved memory allocation to later stage.
I put address of allocated memory (<32 bytes) into SLTWRK variable to appropriate part regarding slot and window (slot from A8h port and fixed window 4000h-7FFFh).
If I put RET to postponed initialization before memory allocation, some of my features cannot work, but MSX-DOS works fine.
Despite DOS, BASIC works fine with this initialization (probably without Disk BASIC initialization only).
Also, DOS keyboard handling looks strange for me, it takes from keyboard buffer 0FCh unregarding what my handler puts there after the problem occurs. Why separate code to do same that BIOS does?
Are you using emulators? If so, you need to indicate the correct size of your rom otherwise it will mirror execute twice. Same for real cartridges, logic must not allow mirroring if you don't want to execute it twice...
Anyway, you can check the value of H in you cartridge execution routine so it doesn't run twice if you have mirroring, hope my code help you with ideas :
https://github.com/ducasp/MSX-Development/blob/master/MSX-SM...