Best way to allocate work-area from my ROM code

Página 1/2
| 2

Por S0urceror

Expert (112)

Imagen del S0urceror

10-02-2020, 18:36

Hi,

I am busy creating an UNAPI compliant driver as part of my MSXUSB project. The driver will be loaded from ROM and needs to allocate a work-area of around 128 bytes. It ideally should work on any MSX (1/2/2+/tR) with 64KB.

The driver will be initialised during startup of the MSX and can be called via EXTBIO.
What is the best way to do this proper without worrying that (DISK-)BASIC or DOS will overwrite it?

  • Page0 - Is it possible to reserve space that DOS doesn't use for .COM programs?
  • Page1 - Candidate? How to prevent overwrites?
  • Page2 - Is it possible to reserve space that BASIC doesn't use?
  • Page3 - Is there a space I can use? UNAPI uses already SLTWRK and MATHPACK. How to make sure it isn't overwritten?
  • Or accept I have to reserve a whole 16KB via Memory Mapper routines?

Ideas?

PS. gosh, kernel protected memory segments suddenly make a lot of sense oO

Login sesión o register para postear comentarios

Por gdx

Prophet (3558)

Imagen del gdx

11-02-2020, 12:03

To reserve an aera with one of the three methods below.

- Reserve an area in main-Ram using the variable HIMEM (0FC4Ah) and MEMSIZ (0F672h).
- Reserve an area in main-Ram using the variables SLTWRK (0FD09h-0FD88h). (probably the best way for little areas)
- Reserve an segment in the memory mapper using the extended Bios. (You need to create it if MSX-DOS2 or newer is not present)

Por S0urceror

Expert (112)

Imagen del S0urceror

11-02-2020, 13:54

Thanks gdx,

I'll take H.STKE and try to initialise BOTTOM according to the technical handbook.

Hopefully this will protect the area while going to DOS, BASIC and vice-versa. I want my USB keyboard driver to be always present and working.

Por pgimeno

Master (188)

Imagen del pgimeno

11-02-2020, 16:21

As far as I can see, the routine given there may crash in case there's no available memory, due to a stack imbalance. The fix would be to add a POP HL in the NOROOM branch:

NOROOM:
        POP     HL              ;Add this to re-balance the stack
        LD      HL,0
        CALL    WSLW10          ;Clear slot work
        JR      WORKBEND        ;Return 0 in [HL]

Edit: Direct link to the routine I'm talking about:
https://github.com/Konamiman/MSX2-Technical-Handbook/blob/ma...

Por S0urceror

Expert (112)

Imagen del S0urceror

11-02-2020, 18:12

Tried a couple of approaches. Here my results:

H.STKE works but then Nextor/MSX DOS 2 and Disk Basic 2 is skipped and the user is put immediately in Basic. The memory is allocated allright. CALL SYSTEM doesn't work.

When done in the INIT routine of my ROM code, MSX DOS 2 is also skipped but Nextor/Disk Basic 2 is available. Also now the memory is allocated allright. CALL SYSTEM works.

The following code is responsible for this:

;
	ld	hl,(BOTTOM##)		;If RAM is not available down
	ld	de,8000h		; to the bottom of page-2
	COMPAR				; then dive into BASIC as we
	ret	nz			; cannot boot up MSX-DOS.
;

Why does DOS check for BOTTOM on 0x8000 and cannot boot?

Por pgimeno

Master (188)

Imagen del pgimeno

11-02-2020, 20:26

S0urceror wrote:

Why does DOS check for BOTTOM on 0x8000 and cannot boot?

I'm only guessing here, but if something reserves stuff at 8000h, that means that you can't load programs > 32KB in MSXDOS because there's used RAM in the middle of the address space. Also, MSXDOS needs some RAM to live on, and while it could check whether there is enough free for it to install itself, maybe it takes a more radical decision and just refuses to run unless that area is contiguous. Or having something there in the middle conflicts with its memory allocation strategy. Or something.

Perhaps you can allocate top-down instead of bottom-up. I'm not sure what that involves; perhaps it suffices to change HIMEM, perhaps not. Disk controllers do this.

Por Grauw

Ascended (9156)

Imagen del Grauw

11-02-2020, 20:40

(Edit: never mind, I read it wrong.)

Por NYYRIKKI

Enlighted (5556)

Imagen del NYYRIKKI

11-02-2020, 21:03

Indeed, top-down is your only option if you want it to work both on MSX-DOS and BASIC. I would try to keep all of the code in ROM and use RAM only for mandatory variables... The more RAM you reserve the more compatibility problems you get... That is unfortunately the unpleasant fact. The other thing that makes the life a bit hard is that the HIMEM location changes quite a lot depending of your running setup.

The TPA area (memory that each program may use like they see best) in BASIC is from BOTTOM (Usually #8000) to HIMEM, but on DOS from #100 to HIMEM. On top of HIMEM there are normally the stuff like MSX-DOS(2).SYS & disk drivers work areas and then after #F380 system variables and hooks.

Por S0urceror

Expert (112)

Imagen del S0urceror

11-02-2020, 23:38

I can now confirm that changing HIMEM on ROM INIT is the way to go. Even though the technical handbook, see link above, says that changing BOTTOM is recommended.

I can now allocate a space by moving HIMEM 100 bytes lower. Then I put my updated HIMEM pointer in SLTWRK. This way I can easily find the pointer to my allocated area back. Because further initialisation by BASIC or DOS will move it even further down.

Works from DOS and BASIC. And it get's never overwritten. Just like I was looking for. Smile

Por Grauw

Ascended (9156)

Imagen del Grauw

12-02-2020, 00:32

Yeah HIMEM is the correct way to go. I didn’t know the technical handbook described using BOTTOM, I guess it makes a bit of sense in the BASIC environment because the stack doesn’t need to be moved, but almost all resident programs I know of lower HIMEM (this is also what CLEAR in BASIC does).

Por ducasp

Champion (315)

Imagen del ducasp

05-03-2020, 22:46

Hmmmm In such case, wouldn`t you need to move MEMSIZ as well and all memory between HIMEM and MEMSIZ? Or at this point that cartridge doesn't need to care and BASIC will live with less data available for its variables and stack? I`m guessing variables wouldn`t be initialized anyway, right?

Página 1/2
| 2