Must be the difference between demo coding and game coding...
Anyway, care to explain why the JP is a so much bigger optimization than I think?

Sure, Guyver.

The ISR will only handle the LNI if it is one. You'll be FASTER at your LNI subroutine this way and will not include the STACK, so no RET either. And it won't go back to the origin of the ISR just to do the vblank check discovering it will not need to be done yet.

The way I was talking about speed is How soon can I get to the point, you know the faster I get to the LNI routine the better. Than I have it exactly were I wanted it to be.

Line Interrupts are timing critical, no doubt.

The thing about the status reg being already set is something I have to catch up on again (haven't done msx coding last 4 years remember)

Any way, it gives maggoo different options on how to do ISR routines, right G.
Hope he makes good use of our experiences!

Quote:

And it won't go back to the origin of the ISR just to do the vblank check discovering it will not need to be done yet.

Yeah, that's a design decision. I tried to keep close to the MSX specs, which specifies FD9A (H.TIMI) hook is called for EVERY interrupt, that includes vblank.

Quote:

Anyway, it gives maggoo different options on how to do ISR routines, right G. Hope he makes good use of our experiences!

Definitely... As with most things, there's no single best solution. Yours is indeed (marginally ) faster, but mine is more compatible.
It all depends on your needs and purposes which routine is best.

I agree on the H.TIMI thingy, but we decided NOT to hang on to that flaw.
We just use it for a *constant*(!) timer (every 1/50 or 1/60 of a sec)

Some things on MSX bios/analogy were not done greatly so we ended up having our own O.S. which is a REPLACEMENT of the MSX os. So we didn't feel to have it 100% compatible anymore since coders who use the new OS would not care anymore

Ok, back in business, I have a copuple more questions:

At the moment I'm not using the RST38 thingy, but will give it a try probably. If you guys have examples of simple implementations of it, that I can compile and try I'd be eternally gratefull. I'm kinda lazy in the experimenting department

And could anyone point me to a good documentation on how rst38, H.tim, etc works on the MSX ? I've got very limited documentation about it so usually I just disable all interupts and do it all myself...


About Vscreen:

I need about 1 or 2 blank lines for my split because I have to:

1: Change screen mode with R#0
2: Reset R#23 and R#18 for the scrolling
3: Disable sprites (so that enemies don't go over the score bar)
4: Change value of R#2 to display the bar.


What bugs me is that on the MAP page it says that the screen split and blank split (R#1, bit 6) are seemless right ? Well if blank split are seemless (it seems to work on a real MSX2), so why is it that it's not the case in pixel accuracy mode in open MSX ?

I mean, shouldn't the display be turned on or off till the end of the line ?

Again, I greatly appreciate your input. And remember, this is about sharing experience, not about who's approach is the best...

Quote:

And could anyone point me to a good documentation on how rst38, H.tim, etc works on the MSX ? I've got very limited documentation about it so usually I just disable all interupts and do it all myself...

RST38 is the default interrupt handler. Usually it resides in BIOS ROM, the address is 0038h. It can also be called manually by the CPU instruction RST 38h.
In MSX-DOS, RST38 resides in RAM, which is nice, because you can easily replace it with your own. (See previous examples)

H.KEYI, better known as FD9A is a hook that's called by the RST38 ISR (Interrupt Service Routine) for every interrupt that reaches the Z80.
H.TIMI, better known as FD9F is a hook that's called for every VDP Vblank interrupt. The VDP Vblank interrupt is the one enabled by writing '1' to IE0 and is checked and cleared by reading S#0 bit 7. (See my example)
The MSX specification requires S#0 to be selected at all times when interrupts are enabled.

Some software that uses a lot of VDP Command functions likes to select S#2 as the default statusregister, but that requires are custom ISR that switches to S#0 to check the Vblank bit.


Line interrupts (enabled by writing '1' to IE1 in the VDP mode registers) are checked and cleared by reading S#1 bit 0, which is what I do in the FD9A routine to check if the interrupt was a VDP line interrupt or some other (like MIDI, RS232, Moonsound etc).

The beauty of using interrupts is that the routine is always called at approximately the same time during screen buildup.

Quote:

What bugs me is that on the MAP page it says that the screen split and blank split (R#1, bit 6) are seemless right ? Well if blank split are seemless (it seems to work on a real MSX2), so why is it that it's not the case in pixel accuracy mode in open MSX ?

The MAP must be wrong there, because I witnessed trash on 7MHz in my SC8/SC4 split when I handled it too fast. It was VERY stable trash tho
In my experience, openMSX acts very much like a real MSX2, although I haven't used the blanking bit yet.

Quote:

And remember, this is about sharing experience, not about who's approach is the best...

I never claimed my approach was best, I just pointed out a flaw in Ro's ISR when using other interrupts besides VDP interrupts. Didn't expect to be called useless brainwaste for it ^^;

Quote:

The MAP must be wrong there, because I witnessed trash on 7MHz in my SC8/SC4 split when I handled it too fast. It was VERY stable trash tho In my experience, openMSX acts very much like a real MSX2, although I haven't used the blanking bit yet.

Actually the problem was due to the fact that I was setting the screen as blank but not waiting for the end of the line to do the split so it was visible (duh me . This is fixed now but still causing garbage in the emulator. Minor ones tho.

Quote:

>>The MAP must be wrong there, because I witnessed trash on 7MHz in my SC8/SC4 split when I handled it too fast. It was VERY stable trash tho In my experience, openMSX acts very much like a real MSX2, although I haven't used the blanking bit yet.<< Actually the problem was due to the fact that I was setting the screen as blank but not waiting for the end of the line to do the split so it was visible (duh me . This is fixed now but still causing garbage in the emulator. Minor ones tho.

A blank split itself is entirely seemless. Meaning, if you set it, it waits nicely until the hblank before coming into action, and you don't have to take any special action to time it properly. This ofcourse means that the rest of the settings you make (i.e. a scrollsplit) need to be timed to the next HR aswell, otherwise they will be visible *before* the blanksplit comes into action. Once you're done with the other splits, disable the blanking again, and it will start showing the screen again from the next hblank on.

And if possible, it can never hurt to 'sync' your routine on HR or FH checks, so that the split for example won't occur a line earlier on a CPU twice as fast.

The mode split is by the way also seamless, so that's probably why Guyver's split in TVSP looks so nice. Although the r#2 change not showing is either pure chance (well, ok, not that, but it depends on processor timing), or a matter of a cleverly laid-out VRAM which doesn't need r#2 to be changed at all. Judging by the routine posted, it's the latter. Nice, very nice ^_^.

As for ISR's, I think everyone has more or less a different approach. I personally 'hook' at #38, and if I set a line interrupt, it hooks on #38 again (so that the line interrupt check comes before the regular interrupt check and is done asap). For speed considerations, it doesn't really hook but instead the line split routine just jumps to the regular interrupt routine if it's not a linesplit. Ofcourse it properly supports non-v9938 interrupts aswell. On a sidenote, I always keep s#2 set by default, so that the VDP command ready wait loops are faster. But this is regulated by a variable 'DEFAULT_SREG' (or something), which is read out at the end of the interrupts and sets back the status register to the value in that register. This is very useful, as for example most (if not all) BDos and BIOS calls (including disk access) break if the default status register isn't set to register 0.

Oh, did I mention already that I keep my interrupts *enabled* during the regular interrupt routines? This way linesplits etc. don't break if the regular interrupt takes too long. In an even better interrupt model, there would be priorities aswell (so that for example the music replayer interrupt has priority over the regular interrupt but has to wait for the linesplit to finish before being executed). At the moment I still regulate that by keeping the interrupts disabled in the highest-priority interrupt (being the linesplit). Which is nice, but there's no routines for any further prioritizing abilities. Fortunately, as I don't use any other interrupts aside from the regular VDP interrupt, I don't need any atm ^_^. However, if I were to use MBWAVE with the OPL4 interrupts for example, I would need one, I think. Or at least want one .


~Grauw

Quote:

The mode split is by the way also seamless, so that's probably why Guyver's split in TVSP looks so nice. Although the r#2 change not showing is either pure chance (well, ok, not that, but it depends on processor timing), or a matter of a cleverly laid-out VRAM which doesn't need r#2 to be changed at all. Judging by the routine posted, it's the latter. Nice, very nice ^_^.

AH yeah, now I remember. Before I did have R#2 changed and that did cause (very stable) garbage on 7MHz. Could it be R#2 is only read out every 8 pixels or something? (Even in SC8)
All my other splits are either sprite-splits, which delay a line too. BUT, be careful not to change sprite registers during hblank (That is, wait for HR to become 0, or time it some other way), because that's when the VDP reads the sprite data.

With palette splits I just make sure there are black lines on the screen, in stead of forcing a display blanking.

Quote:

Oh, did I mention already that I keep my interrupts *enabled* during the regular interrupt routines?

I do this too.

Quote:

At the moment I still regulate that by keeping the interrupts disabled in the highest-priority interrupt (being the linesplit).

Same for me, these interrupts should be very short and quick.

Quote:

However, if I were to use MBWAVE with the OPL4 interrupts for example, I would need one, I think. Or at least want one .

I think you will want 'if already in interrupt, return', to prevent e.g. a moonsound interrupt to interrupt itself, causing all kinds of foulups.

Quote:

AH yeah, now I remember. Before I did have R#2 changed and that did cause (very stable) garbage on 7MHz. Could it be R#2 is only read out every 8 pixels or something? (Even in SC8)

Hmmm... I'll have to look into that. Perhaps.

[edit]
er... actually, I think not. I think I have seen unstable pagesplits a number of times. But I'll still check it out next time I work on the splits page.
[/edit]

Quote:

All my other splits are either sprite-splits, which delay a line too. BUT, be careful not to change sprite registers during hblank (That is, wait for HR to become 0, or time it some other way), because that's when the VDP reads the sprite data.

In practice you have to multiplex the sprite data displayed on the split line. As was discovered in experiments you made, it is very very difficult to get this timed right otherwise.

Quote:

With palette splits I just make sure there are black lines on the screen, in stead of forcing a display blanking.

Yeah, well, it depends. I usually don't make only a palette split, but a page and scrollsplit at the same time.

Quote:

>>However, if I were to use MBWAVE with the OPL4 interrupts for example, I would need one, I think. Or at least want one .<< I think you will want 'if already in interrupt, return', to prevent e.g. a moonsound interrupt to interrupt itself, causing all kinds of foulups.

Ofcourse, all my interrupt routines with the interrupts enabled have that. If you disable the DI/EI mechanism which prevents an interrupt from occurring before the previous was finished, you have to take other measures to prevent that.

But what I was talking about is, for example, if an MBWAVE interrupt occurs, and the regular interrupt takes precedence. Then the MBWAVE interrupt will return immediately, and be put in a queue, which is executed after the regular interrupt finishes.

One could even code behaviour to decide whether a missed ('double') interrupt (like in the previous example) is dropped, as I do currently, or is put in the queue aswell, so that it is still executed once the current one is done.

Heh, starting to sound pretty much like a real scheduler, eh? Hmm my demo engine is getting more and more multitasking characteristics. Well, makes sense, as it ofcourse kind of multitasks its way through the demo effects.


~Grauw

Quote:

Heh, starting to sound pretty much like a real scheduler, eh? Hmm my demo engine is getting more and more multitasking characteristics. Well, makes sense, as it ofcourse kind of multitasks its way through the demo effects.

Before you know it you're halfway to MSX-DOS3

Heej, I just posted a empty message

I am trying to make a spritesplit in screen 4, and it works seamless as long I don't update the scroll registers. Unfortunatly the screen has to scroll about all the time. Here is the interrupt routine I'm using:
interrupt:
di
push af
in a,(99h)
rlca
jr c,VB
ld a,101111b ; second sprite attribute table
out (99h),a
ld a,5+128
out (99h),a
ld a,1 ; set s#1
out (99h),a
ld a,15+128
out (99h),a
nop
in a,(99h) ; read s#1
xor a ; set s#0
out (99h),a
ld a,15+128
out (99h),a
pop af
ei
ret
VB:
ld a,100111b ; first sprite attribute table
out (99h),a
ld a,5+128
out (99h),a
pop af
ei
ret
Something wrong here, or should I place the scroll-register update routines somewhere else?

remember that when using the scroll register you also have to adjust the LNI line (it will also 'scroll') so add the amount of 'scroll' to the LNI Y position to keep it save...
know what I mean?

btw. you don't need to use the DI command, it's disabled when entering ISR by default