i whatch that and i only see the Interrupt switch than recognized the interrupt generated by the Vertical pulse or other kind of interrupt like LINE interrupt.

Sure, that is relevant, but where are preset the line number where the vdp generate interrupt?

how activate the Line interrupt?

which screen-mode split can be made?

can be convinated horizontal split with screen-mode changing?

anyway on vertical splits which screen mode can be convinated? wrote all convinations possibles!.

on splits, what can be changed? ... scrooling... screen mode... what more?

somebody can do a list of all convinations used... in orden of more used first and more weird at last?

Quote:

Sure, that is relevant, but where are preset the line number where the vdp generate interrupt?

R#19

Quote:

how activate the Line interrupt?

set R#0 bit 4

Quote:

which screen-mode split can be made?

any

Quote:

can be convinated horizontal split with screen-mode changing?

no, the screen-mode change will automatically take effect on the NEXT line.

Quote:

anyway on vertical splits which screen mode can be convinated? wrote all convinations possibles!.

As said, any screen-modes can be combined. It's not possible to use interlaced + non-interlaced, but it's possible to use interlace double resolution + interlace normal resolution.

Quote:

on splits, what can be changed? ... scrooling... screen mode... what more?

anything. sprites, palettes, anything!

Quote:

somebody can do a list of all convinations used... in orden of more used first and more weird at last?

that's a nearly impossible task

just remember almost ANY VDP action you do on ISR kinda immediatly takes place (xcept for some command which will take place on the NEXT line)

I'm sorry I forget to include the "set LNI" like routines, but guyver pointed out the registers, now it's your job to RTFM on VDP docs to figure out the reg settings (itz e.z. as 1, 2, 4) Remember to DISable the LNI on your last LNI (yes, you can have more than 1!) (hmm, is it really necessary to dis. the last LNI? Yes, if you want't your next ISR to be a vblank that is)

on the Vblank you might wanna set the first LNI again.. or, if you only want LNI, set the first LNI Y position and code routine on the last LNI
(do I make some sence here )

I'll see if I can dig up some more code for you to examine...

oh, one more thing. You can read out some reg (#14??.. help me guyv) to check if you reached the next line on screen.. by doing this you can make more actions on 1 LNI, line been done on color-cycles, waves etc.) just check demos for hints....

I'm sorry but putting some more code examples here is kinda tricky 'coz the most are written using MIDAS (our kernel remember) and to include those parts would be to much. I simply don't have the time to sort that out into 1 source file... but you should have plenty of usefull info by now.

good luck

Quote:

oh, one more thing. You can read out some reg (#14??.. help me guyv) to check if you reached the next line on screen..

You mean HR, bit 5 in S#2. It gets set when the Horizontal Retrace (Blanking) period starts. In other words, when the VDP gets ready to start drawing the next line. It's reset when the border period of the next line starts.

MIDAS? sorry, i 'am new on international scene...

thank to ro and guyveR800 , that information helpme...


now!!!!

what is more used?



Letme start to develop here...

FUNCTION NAME: SPLIT

IN [A] bit 3-0 = SPLIT type
IN [A] bit 7-4 = Thing to do after split.
IN [BC] = Line or column where do the split.
IN [HLDE] = Value for the thing to do.

Chart values for [A]

SPLIT TYPE
-------------
0 = Disable split mode
1 = Vertical split
2 = Vertical split with black lines ; [C] quantity of lines black
3 = Horizontal split
4 = Horizontal split with black column ; [C] wait loop before enable the bitmap view.
........

THING TO DO AFTER THE SPLIT EVENT
-------------------------------------------
0 = SCROOLING, [BC] = LINE OR COLUMN ; Can be done a horizontal split with scrooling?
1 = SCREEN MODE CHANGE, [C] = alternative screen mode.
2 = PALETTE SET CHANGE, [HL] = RAM where looking for the alternative PALETTE set
[DE] = RAM where looking for the normal palette set
3 = SPRITE???? what are used normally? changing the X and Y positions? design pattern or colour i think not enought speed..
4 = any one got more idea??????
.....



if can be done a horizontal split with sprite X and Y position changing.....

then can be more than 8 sprite per line?

Flyguille, aren't you trying to do the impossible here?

As several others pointed out before, you can do *anything* on an interrupt: I could change instruments for the MoonSound on a VDP line interrupt, or set the palette for the Gfx9000 when my home-made RS-232 interface generates an interrupt, because it received a byte. There is no end to the possibilities and therefore no way that you can capture all possibilities in MNBIOS.

As a programmer, I would rather have the possibility to hook up a routine of my own to each possible interrupt, where MNBIOS can determine which interrupt occured.

Hope this helps,
AuroraMSX

Thanks aurora i will set up hooks for VINT, an LINT and NOT VDP INT

The bigger problem for that is the multitasking system, because all the time PRG pages and DAT pages are switching then is not possible to use hooks for jump directly to a aplication code....

Then I need create a zone land for coding on SYS segment. Maybe i can include assembler code on DATAMEMO structure standard.

DATAMEMO structure is the only "Allways viewed" structure of the mnbios available for aplications and kernel.

Normally all the time the page are switched, by example, when a CHR are printed, (more late when a background process are running), when a driver are called, when a sprite design are use, when a music are played, but, that all things are not time sensitive..

Ofcourse, i can switch on interrupt for view the correct aplication page for get the split routine, but that take time and if the spliting is too time sensitive.....

Because that, actually no exist any kind of hook on mnbios, Exist the ADR (administrator of resources) that is a standard very easy to use and very fast.

Hi MSX Users,
perhaps a flexible way for defining a general split, scroll and so on handler
could be manage a data stream to be passed to ISR by the "client application" (which
could be an ASM game or a BASIC program or what you prefer).
The stream could be something like:
DEFB nextLine for getting line int from Vdp
DEFB Vdp register number
DEFB Vdp register value
...
DEFB EndOfTable

ISR will do stuff and set Vdp to generate Int at the nextLine specified by the stream.
Probably this is not the fastest solution but is general-pourpose.

I too think on that, but that got the limitation of only register changing... no palette. no sprites....

maybe i can do a convination of hooks plus data stream...

but, data-stream need more skills for the aplication programmer..

Unless you are a REALLY good programmer, there's no vertical split on MSX. The darn thing is just too slow... All you can do is split horizontally. Games like Herzog that *look* like they use a vertical split just redraw the entire screen, there's really no splitting being done. You can more or less do a vertical pallette split on MSX, but you'd need to use machine-specific timing (NOPs) which you prolly won't want to do in a BIOS.

I suggest you provide the following BIOS splits, everything other than that the programmer should do himself. I would NOT implement a mode split. Mode splits are usually used for games (using SCREEN 4 mostly) and anyone that can make a game that requires a mode split can prolly make the mode split themselves.

1) Page Split
2) Vertical Scroll Split
3) Pallette Split
4) Pallette Bar

These 4 functions are prolly the most common tricks used. I suggest you use for example REG A to input the type of splits; 1-3 individually or combined in any way OR 4.

1) Page split
Display another VDP bank at the split line. (SET PAGE)

2) Vertical Scroll Split
Display another VDP line at the split line. (VDP24)

3) Pallette Split
Change the current palette at the split line. (COLOR=)

These three can be combined to allow for the full effect. You'd have to check timing on slower MSX computers since I doubt you'll be able to do all of this in one single line.

Remember that if a line-int is requested under say line 16, you should *NOT* use a line int since by the time the normal interupt routine is done that line will have probably passed. You will either need to delay the normal interupt routine or hang that line-int on the normal interupt and poll to see if the line has been reached.

Also remember *I don't know shit* about programming, you'd prolly need to double check this with ro since he did a lot of splitting in the muzax thingies... I think this is pretty much correct tho.

Anyways, I'd suggest a routine like REQ_LININT

IN: [A] %BA0D0BVP (Bank, Disable Screen, Page Split, Vertical Split, Pallette Split)
[B] Line
[C] Vertical Scroll
[D] First Color
[E] Amount of Colors
[HL] New Pallette

REG A, Bit0 would indicate wether a Pallette split is required, Bit1 wether a vertical scroll should be done, Bit2 if we need to switch banks. You should prolly switch bank before you change the display line (VDP24, R#23). Bit's 7 & 6 of register A could hold the requested VRAM Page if bit 2 is high. Maybe use bit 4 of REG A to indicate wether the screen should be disabled until all changes are done.

REG B could indicate the requested line, remember you should decrease it by 1 so your LINEINT occurs *before* the actual line. Then poll and start your routines as soon as you enter HBLANK.

REG C could indicate the display line in case bit1 is high. You should just load this value in VDP(24) or REG#23.

REG D can hold the first color of the pallette to be changed in case bit0 is high. In a line int you would set the palette just as you would normally. I *think* pallete changes are immediate, so the user would have to take into account that the pallete changes will occur somewhere towards the end of the requested line if not even later.

REG E could hold (amount of colors that need to be changed)x2 if bit0 is high.

REG HL could hold the address of the new pallete in the same format as the VDP uses. In that case a few OUTI's would prolly do the trick when setting REG E in REG B.

I don't know, just a suggestion... These are the most common splits that would be used. If you want to implement the Pallette Bar (the trick where the background color is changed gradually) so people can make like selectors and whatnot you'd prolly need to make like a seperate routine. Something like REQ_PALBAR

IN: [A] %00001000 (Pallette Bar Split)
[B] Line
[D] Target Color
[E] Line Count
[HL] Pallette

REG A just holds the code for the Bar Split. By setting bit3 high you could use the same call and just jump to the appropriate routine.

REG B holds your line again, remember to sub one so you'll have a clean split. Just poll until you're in HBLANK again.

REG D can hold the target color, the color you'll wanna change the pallette of.

REG E can hold the amount of lines, basically the height of the bar in pixels.

REG HL could hold the pallette, being the RGB code as the VDP uses it for each line. This means that if there are 16 lines, there must be 16*2 bytes with the corresponding pallete data. Each time you reach a new line you change color [D] to the next color value indicated by [HL] until [E] equals zero.

Well, just a thought... This all shouldn't be too hard to implement. Maybe Guyver and ro would be nice enough to help you out and check your code as you go along. I'd help you myself, but I've lost pretty much all my sources since I had them on diskettes. Too bad, 'cause I would have liked to finish my FD selector. It uses all of the splits described here and I would have been able to check how I did this back then...

Anyways, hope this helps at least a little....

Fly,

You really don't want such things in your Kernel!
These are timing critical routines which the user has to code him/herself on eacht ISR!!
That's the whole purpose of screensplitting. Timing is essential.

Further more, you can't just make some sort of pre-fab coding for things like that to do on ISR. That would be like creating some kinda "demo-maker" program...
It's like creating functions for ppl to use, which also takes away all of the fun and creativity of the user.

A kernel needs to provide the ISR stream, nothing more. The rest is up to the user.
Just build in the darn ISR routine on 0x38 an leave it like that.
An O.S. needs to concern on Memory Management, Interrupt/File/Data handling and that sort of basic code.

I could provide you the whole SETLNI routines I coded back then. It indeed is a table with Y position and Address pointers. But that's home made stuff you really don't want to be in a O.S. (well, you could... but hey)

Focus on the IMPORTANT stuff, not these details which are user defined anyway.

Quote:

I too think on that, but that got the limitation of only register changing... no palette. no sprites....

Why not? Color palette is set through I/O, sprite tables addresses too:
client application should prepare tables in VRAM and ISR should only
change table pointer.

Quote:

but, data-stream need more skills for the aplication programmer..

"Client" only need to specify a sequence of I/O port addresses and values.
Moreover client knows the offset from the beginning of the stream where
changeable values are located so can modify the stream during runtime.

Quote:

Just build in the darn ISR routine on 0x38 an leave it like that.

Why not using interrupt mode 2?
A "Z80 family" peripheral should supply an 8 bit code when its interrupt is
acknowledged.
If MSX has no "Z80 family" chip this supplied code should be always 0xFF (because of bus pull-up) so all actual interrupts are "routed" to the last entry in the interrupt vector table addressed by I.
This should permit developing new application boards/software with specific interrupt handling.

A useful Kernel should be as small as possible as well as solid. If you include lots of things it won't be neither small nor solid, because the VDP timing is a delicate subject. If you want to continue and open this project, please concentrate in the most critical part, this is it, memory management and support as many devices as you can.

Regards,

Ed Robsy

Quote:

A useful Kernel should be as small as possible as well as solid. If you include lots of things it won't be neither small nor solid, because the VDP timing is a delicate subject. If you want to continue and open this project, please concentrate in the most critical part, this is it, memory management and support as many devices as you can.

Actually, as long as you don't use too much memory and keep your interupt routines fast enough, I guess this shouldn't matter too much. A split-service routine shouldn't take up more than half a kilo byte -prolly less- and should end up making BASIC programmers happy enough. CALL LINEINT, anyone?

Lemme see if I can come up with something; it'll prolly suck tho