Reserving a few bytes in top of MSX memory at startup

Page 1/2
| 2

Par DD

Expert (88)

Portrait de DD

24-06-2009, 09:56

How can we reserve a few bytes in the top of the memory, sat &HF*** at startup?

We need about 20 bytes for information which will be used by a cartridge inserted in slot 1 or 2, at least before the dos rom. I understood some memory should be reserved before the dos rom, just indicate there is less memory free and use that part for own information.

Who has an idea how to use memory for an own application in cartridge rom iwhile keeping t compatible with MSX DOS and memory maganers?

!login ou Inscrivez-vous pour poster

Par konamiman

Paragon (1084)

Portrait de konamiman

24-06-2009, 13:51

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

Par DD

Expert (88)

Portrait de DD

24-06-2009, 14:52

Ok, thanks! So in fact you shift some pointers down to get empty space...

Par konamiman

Paragon (1084)

Portrait de konamiman

24-06-2009, 15:16

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.

Par brawaga

Rookie (18)

Portrait de brawaga

10-10-2020, 03:39

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.

Par zeilemaker54

Champion (281)

Portrait de zeilemaker54

10-10-2020, 12:03

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.

Par brawaga

Rookie (18)

Portrait de brawaga

12-10-2020, 18:24

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.

Par zeilemaker54

Champion (281)

Portrait de zeilemaker54

12-10-2020, 20:24

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

Par Manuel

Ascended (17048)

Portrait de Manuel

12-10-2020, 22:13

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.

Par brawaga

Rookie (18)

Portrait de brawaga

13-10-2020, 02:54

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?

Par ducasp

Champion (383)

Portrait de ducasp

13-10-2020, 13:30

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...

Page 1/2
| 2