The following program is an attempt to show to all programmers, what easy is programming under MNBIOS on a multitasking enviroment system.
All comments or questions will be reply....

		org	$4000
;
header:
;
.exec:		dw	code.exec,0	; EXEC part
.task:		dw	code.task,0	; TASK part
.fkey:		dw	code.fkey,0	; FKEY part
.stop:		dw	code.stop,0	; STOP part
.ftask:		dw	code.ftask,0	; FTASK part
.close:		dw	code.close,0	; CLOSE part
;
.nac:		
.nac.length:	equ	$ - .nac
		ds	28 - .nac.length," "
;
.ver:		db	0
.sver:		db	0
.mver:		db	0
.msver:		db	0
;
.mark:		
.mark.length:	equ	$ - .mark
		ds	16 - .mark.length," "
;
.prog:		
.prog.length:	equ	$ - .prog
		ds	16 - .prog.length," "
;
.nidea:		
.nidea.length:	equ	$ - .nidea
		ds	16 - .nidea.length," "
;
.ngrp:		
.ngrp.length:	equ	$ - .ngrp
		ds	16 - .ngrp.length," "
;
.nsnd: 
.nsnd.length:	equ	$ - .nsnd
		ds	16 - .nsnd.length," "
;
.date:		db	"DD/MM/YYYY"
.fdate:		db	"DD/MM/YYYY"
;
.btask:		dw	code.btask,0	; BTASK part
;



; Variables needed
FlagTask:       db      0
Text:           db      "Hello world!!!",0
TextAgain:      db      "Hello world AGAIN!!!",0
TextWait:       db      "<Press any key to continue or Q for Quit>",0

code:
;
.exec:		LD	A,18h
		LD	HL,text
		CALL	0C260h		; WR_CHRS function

.JUMP2:		LD	A,18h
		LD	HL,TextWait
		CALL	0C260h		; WR_CHRS function

.Loop:		CALL	0C27Ch	; INPUT$(1) function
		JR	C,.Errored
		CP	"Q"
		ret	z		; "Q" is pressed, exit program
		JP	.exec

.Errored:	CP	61h		; Check the error code returned
		JR	z,.bige
		xor	a		; If is not a big event error, then
					; can be a key buffer error
		CALL	0C2E0h		; SET_BUFFER_KEY  (it activate the buffer key when A=0)
		Jp	.Loop

.bige:		LD	a,(FlagTask)	; a bigger event appear...
		CP	0FFh		; check if is a MULTITASKING event..
		jr	nz,.Loop
					; Is a multitasking event...
					; and the program not got nothing to do
					; simply quickly return the control to
					; the multitasking system...
		xor	a
		LD	(FlagTask),a	; It erase the flag task variable

		LD	 IY,00FDh
		LD	 C,01h
		RST	 30h		; DRIVER function.

		JP	.exec		; Normally the multitasking system doesn't
					; return the control to this code
					; anymore... but if the call fails,
					; an error code will return,
					; like when system resources
					; are not enough
					; What to do here? nothing....
					; maybe try freeing resources or simply
					; re-running this aplication for a later
					; attempt.


.task:		
		LD	A,18h
		LD	HL,TextAgain
		CALL	0C260h		; WR_CHRS function
		JP	.JUMP2

.fkey:		ret			; ON KEY GOSUB unused
.stop:		ret			; ON STOP GOSUB unused

.ftask:		LD	A,0FFh
		LD	(FlagTask),A	; it sets the flag task variable
		ret

.close:					; it is called when the user use a
					; EXTERNAL CLOSE APLICATION FUNCTION
					; With nothing to do, the aplication
					; will erase after this.
		ret


.btask:		ret			; For background proccess, disabled on DEMO version.

Long code for just saying "Hey babe, how you're doing" . ..

Which copiler?

This should be compilable on tniASM and SjASM and probably dozens of other cross-assemblers. AFAIK no native MSX assemblers support local labels (yet?), so you'll have to do some editing then...

Quote:

Long code for just saying "Hey babe, how you're doing" . ..

not only that, also got:

1. back-from-multitasking-system instance
2. go-to-multitasking-system instance

and to make time to allow to the user to press GRPH-CTRL-CODE keys to call to the multitasking system was inserted a INPUT$(1) with a message like <press any key to continue>.

Anyway, allways on HELLO WORLD!!! you need the EXEC header full structured...

The "HELLO WORLD" code inself is the following:

exec: LD A,18h
LD HL,text
CALL 0C260h ; WR_CHRS function

nothing more

Quote:

.fkey: ret ; ON KEY GOSUB unused .stop: ret ; ON STOP GOSUB unused

hmm... Is these really so much needed, that they need to be included to every program by default. I think, that these functions could be asked when they are needed like:

ld hl,fkey
call init_fkey

... or something like that.

Quote:

Quote: .fkey: ret ; ON KEY GOSUB unused .stop: ret ; ON STOP GOSUB unused hmm... Is these really so much needed, that they need to be included to every program by default. I think, that these functions could be asked when they are needed like: ld hl,fkey call init_fkey ... or something like that.

.fkey is not for define the TEXT of a F key.....


.STOP, .FKEY and .FTASK are three instance programming that are runned inside of the interrupt routine.... (by that reason only is allow set a aplication variable with a value.... and nothing more) .... and THEN on normal aplication procedure you can test that variable looking for a "bigger event".

A bigger event is trigged when:

1. The user press any F-key
2. The user press the STOP key
3. The user press CTRL+GRPH+CODE (to order to change the aplication).

While your program are running a LINE INPUT or INPUT$(1) function if a bigger event appear the function return the error code &H61.... if your program get that error code you need check if the bigger event is a <FTASK> event in this case...

how check that? ... checking that aplication variable that you set on .FTASK instance....

WHY? .... because when the .FTASK instance is runned that mean the user want to change to another aplication and for that the user press CTRL+GRPH+CODE then the MNBIOS run the .FTASK instence to order to the aplication to return the control to the multitasking system.

Why to do in this way?... Is the only one way for avoid the aplication was interrupted in a precious procedure unrecoverable. In this way the normal procedure code decides when want (in the most short time possible) return the control to the multitasking system.

conclusions: That 3 instances exists to allow inform when appear a bigger event to the normal procedure aplication code (that outside of the interrupt routine).

You can use the same aplication variable for all this instances...

Normally i use...

value = 0FFh --------- FTASK event
value = 1 up to 0Ah ----FKEY event (the value = Fx pressed)
value = 80h --------- STOP key event
value = 0 ------------ nothing happen....

Example:

.fkey:		LD (FlagTask),A		; In this instance A = F key pressed
		ret			; ON KEY GOSUB

.stop:		LD A,80h
		LD (FlagTask),A
		ret			; ON STOP GOSUB

.ftask:		LD A,0FFh
		LD (FlagTask),A		; ON MULTITASKING GOSUB
		ret

I HOPE ThiS INFORMATION IS CLEAR

It's still a lot of code tho

well!!!! is assembler ... remember that?????

Sure a good enviroment programming for MNBIOS will create the header and instances routine automatically... and you only need to insert the instruction inside...

Hehe.

I think we're getting 2 things confused here.
- an O.S.
- a G.U.I.

Fly is building BOTH. a kernel with a matching GUi. The long headers Fly has in his code are for the GUI to interact with the kernel etc. (hence the on stop gosub keys etc)
(atleast I hope fly has seperated those features)

A kernel (read: OS) should not concern about user input etc. That's for a GUi to check. We've talked about this earlier in another threat but due poor communication this topic hasn't been settled and understood yet, I suppose.

a "Hey babe, how you're doing" routine should be as short as this:

start:
Ld HL,string
jp printroutine
string: db "Damn we're smooth!",0

Thaz it.
no header, no extra features. nada. zip. ziltch. No, for this piece of code to work in a multitasked enviroment it should indeed be as the code Flyguy posted earlier.

So, the big question here. Do "we" (the coders) really want to code progs for a GUI enviroment, or just make use of the neat functions a OS has to offer....
This all depends I quess. Do we want progs to be loaded, executed and terminated in a GUI or just be booted up everytime..

well the time it takes to boot up the whole new kernel incl. this GUI and THEN startup the demo would be too long. It's a matter of time. Will nmbios take present on our harddisks in order to be the new enviroment where we run progs from (which use the kernel ofcourse) dunno... my quess..NO!

uhu, ok. nevermind.

Sigh...

This is what has been talked about in another thread about MNBIOS as well...
Advanced coders like you probably prefers to use their own OS or OS-like routines, especially since you already programmed a kernel.
Nobody will force you to use MNBIOS, neither does anyone force you to use MSX-DOS2 or UZIX.

I think MNBIOS is comparable to Windows in the coding aspect; A "Hello world!" program in Windows is also quite long, and a lot more complicated.

Also, MNBIOS and Windows are not GUI's, they're Graphical User ENVIRONMENTs. The creation of a GUI is still up to programmer! He can use GUE provided buildingblocks for making the GUI, or create his own GUI.

Frankly, I don't understand what you're complaining about at all. You seem to have an incomplete notion of what MNBIOS actually is...

ro-----> the KERNEL is a multitasking enviroment... if you program a code without using the full header... the OS will crash when the user press a F key or STOP key or multitasking KEY if you don't want use this... just write only a RET .... but remember... if you don't use the multitasking instance then your program will not be multitasking and then you got a lot of angry users... remember, the idea is never REBOOT the MSX....

I think this is comparable to the MS WINDOWS in the early 80's.... when the core is finish but need add a lot of DLL. and make standards... now is time to that.


And remember, the header got a lot space for credits and release staff info... if you don't want to use that... simply delete that lines... and make sure the code was located starting at 40A0 address. and don't forgot the <BTASK> pointing to a RET for future compability that will go at 409C (the last one).

Quote:

And remember, the header got a lot space for credits and release staff info... if you don't want to use that... simply delete that lines... and make sure the code was located starting at 40A0 address. and don't forgot the <BTASK> pointing to a RET for future compability that will go at 409C (the last one).

Seems like a waste of space to me, all that info about credits and staff... It will never be complete anyway! And what will MNBIOS do with that information? Does it display it?
Really, the user doesn't care who programmed what and at which time the product was finished.
All useless info, and a waste of several dozen bytes that could've been used for CODE, coz MNBIOS already has such a limited window for code (only 32K visible at the same time).

Quote:

Quote: And remember, the header got a lot space for credits and release staff info... if you don't want to use that... simply delete that lines... and make sure the code was located starting at 40A0 address. and don't forgot the <BTASK> pointing to a RET for future compability that will go at 409C (the last one). Seems like a waste of space to me, all that info about credits and staff... It will never be complete anyway! And what will MNBIOS do with that information? Does it display it? Really, the user doesn't care who programmed what and at which time the product was finished. All useless info, and a waste of several dozen bytes that could've been used for CODE, coz MNBIOS already has such a limited window for code (only 32K visible at the same time).

for a properties function was thought... allways in a game staff you can use the same data for display...

FOR APLICATIONS: The window code is 16k (&H4000-7FFF) plus 32k for data window (&H4000-BFFF sharing 16k)... that AT SAME TIME... but allway you can write code so long as 128MB... made CALLs or JP to any other code page... and in a fast way.... and the same or data....so, no limitations indeed....

FOR DRIVERS: The window code and data is the same and is 32k (4000-7FFF).

For DRIVERS and APLICATIONS also got High memory.... &HC400 up to &HFxxx ....

In a future with fasts HD is allowed to do emulated RAM as ms-windows...

dudes, I was merely stating the difference between a kernel/bios and a GUI/GUE. It was not to flame at Flyguy's bios, not at all! gees, whaz up with ya lot. anyway. the question remains: Will be be using this piece?? (and all it's overhead)

l8er