Quote:

As the VDP and the Z80 don't run in perfect sync, I don't think your findings about the JR vs. JP are applicable always.

That's why I say 1-3 states. It depends on when the HR bit is set. If not the difference would always be 3 states. But since they don't run in sync, it can occur that HR is set just after I read it, in that case my JR takes 2 states longer, and the routine loops till the next JR, then the JR will take 7 states (vs 10 for JP) so I win only 1 state in total. If HR is set just before I read it, I will gain the full 3 states my JR saves. It turns out that this one T-state is the difference between the color-change being done before or in the line... Quite time-critcial as it turns out! Ofcourse now I've run into a whole bunch of different problems which I'll have to iron out next... Sigh...

...AND it save 1 byte uhu.

Tobi: You should REALLY take a look at the colorcycle trick I'v dun in the muzax3 source which I posted here. I use ATLEAST 2 colors to switch on LNI to prevend flickering of colorlines. On each other line I set the color for the next line.

like this:

Suppose I have a background with, oh, 3 colors like this:
1
2
3
1
2
3

etc.

In the LNI on the first line (or 1 before) I start with color 3. So I'll set color 3 BEFORE actually being on the line with color 3. then on the next line I'll set color 1 and on the next set color 2. This cycles until the length of the copperbar (for example)

(hope you get it) this way you won't SEE the split, never.. nada.

timing in this case is ALWAYS critical, but don't get into saving 1 or 2 states since it is a shaky concept (read guyver's post about difference in electrical setup etc) But don't mind about using poert #99 for the VDP. In practise it seems this is THE port to write to in case of VDP actions. Nevermind that odd MSX somewhere in the jungle with VDP on other ports.. it probably got thrown in the trashbin anyway since lotsa software would simply not run on the darn machine...

regards, you BBQ fanatic friend, ro

well it's up to fly when it comes to which port to use for the VDP. Since it's an OS a little more compatibility with obscure MSX setups would be great. Of course, I'm a sinner too, it's probably too bothersome to update the correct port for *every* VDP action. But if you're going by the standards, just update the ports only once, at the init of the VDP lib.

and um Sonic, are D and E constant color values, or can they change for each line? If they change for each line, using OUTI to output color values will reduce the code size a bit.

Quote:

I use ATLEAST 2 colors to switch on LNI to prevend flickering of colorlines.

Hey, that *is* clever... I get it, set the color before it even needs to be set! Cool! But how did you manage to do the copper-bar-muzax-logo-thing like that? Wouldn't it be a real bitch to calcualte both Y-pos, Z-pos and Color like that!? Well, I guess that's off-int ofcourse...

Lemme see if I can incorporate that somehow... Although using the last trick (the early out's and the jr) I did manage to get rid of the flickering. Now the only problem I've still got is the occasional missed interrupt, but I guess I can get rid of that with some polling in the main routine...

Never knew the Z80 was *that* slow though, kinda disappointing

Quote:

and um Sonic, are D and E constant color values, or can they change for each line? If they change for each line, using OUTI to output color values will reduce the code size a bit.

I know, but I'm using B plus OUTI is may be to slow at 16 t-states. I can try tho, would be nice to shave a few bytes off an already way too big screen-split routine. ($200+ bytes already)

And I did indeed do the OUT(C) part cause I thought it would be nicer for a BIOS. I know there's only like 7 people with a VDP that's not at $98, but it just makes a BIOS a little more BIOS. (ie lame : )

Ofcourse it's too bad I had to make 'self-modifying code' (okay, one byte) in two instances. I really wanted to avoid it, but there just wasn't any way around it... But hey, now it's time for the general timing problems... I'm still missing int's now and then... Gotta get the main code in sync with the split-kernel...

Cheers...

Oh, btw, Arjan, you up for a small project one of these days?

if you're missing ints now and then, try to EI it earlier (in another int) when nog VDP needs to be dun anymore (e.g. on calc. routs)

ps. the copperbar is really simple to make... nothing to do with heavy 3D calculation. A sinustable will do. Maybe I'll post an example on how to create copperbars.
Oh, ofcourse REALTIME copperbars (as always in any fuzz demo! no precalc stuff)

Quote:

if you're missing ints now and then, try to EI it earlier (in another int) when nog VDP needs to be dun anymore (e.g. on calc. routs)

Wouldn't that bit a bit of a problem for any other routines that follow mine (the hooks)? Well, I guess it won't matter as long as there's no nesting...

Nesting is no problem (you should have read my earlier posts!)

what to do in ints:
- prio stuff (the things like color cycles etc)
- set new int (other LNI or VBL)
- Enable int
- do not so timing critical stuff (pre calcs etc)

After EI another int might occur, but thaz no problem. not at all (as long as you don't do any VDP stuff for example.... e.g. to make sure your read and write status keeps in check)

Quote:

Never knew the Z80 was *that* slow though, kinda disappointing

3.58MHz vs 21.48MHz... It was to be expected

As for missing ints... Indeed, just enable the interrupts sooner in your interrupt routines. You should realize allowing multiple interrupts opens up a whole new can of possible bugs/problems/horrors you never dreamed possible. So know what you're doing

Quote:

Oh, btw, Arjan, you up for a small project one of these days?

yeah I've got some spare time now I suppose you still have my email addy, if not, just yell in here

huh, guyv.. maybe we should open up a new threat called "masterclasses" or something, we're getting to deep into details. Sonic is in the asm learning stage (no offence) concerning these kinda tricky business. Indeed you gotta know what you're doing.. know it EXACTLY in every detail to sqeeze every hertz left out of the Z80

Get to know howlong every INT will take in screenlines and draw it out on a little paper to check if overlapping occurs. This is when nesting comes at handy. And re arrange your non critical code on all the inst (like a music replayer)

How to know the screenlength of an INT? simple. for example:

(int starts here)
- change backcolor to some hideous color (e.g. green) to REALLY see it
- do your stuff
- reset the background

now while running you can actually SEE (huhu.. u said..) the screenlength of an int. And it can help you figure out if any nesting might occur (and if you still have ints dissabled... why ints are skipped sometimes)

I ALWAYS use this in development stage, just to check the screenlenght of INTS.

Quote:

This is when nesting comes at handy. And re arrange your non critical code on all the inst (like a music replayer)

Lately I've sometimes put a lot of things (like the music player) in the main loop, in stead of the vblank. In order to not run the mainloop too often, I use the following routine to wait for the next vblank:

WaitInt:
ld hl,Jiffy
ld a,[hl]
.wait: halt
cp [hl]
jp z,.wait
ret

This works on the standard BIOS ISR, or on a custom ISR (provided you increase Jiffy each vblank).

Then I keep my interrupt routines (both vblank and line interrupts) as short as possible, really only dealing with VDP tasks.

This way there is less need for allowing overlapping interrupts.

Quote:

(int starts here) - change backcolor to some hideous color (e.g. green) to REALLY see it - do your stuff - reset the background

That's one of the most useful debugging/profiling techniques there is, indeed. I use it all the time too.

Quote:

(provided you increase Jiffy each vblank)

This question is totally off topic, but because there are now many HC coders around, I would like to ask about INTCNT that is neighbour of JIFFY (#FC9E, #FC9A2)

I wondered about it's meaning 10 years ago when I was starting to learn ASM. I got a Finnish translated Canon V-20 BASIC manual (best MSX1 manual ever delivered with a computer) where it was mentioned, but I could not find any reason for this variable to exist.

INTCNT seems to be counting backwards, but is there any routine in MSX-BIOS or MSX-BASIC, that really uses this variable??? (or can you imagine any reason for it to exist?)

Quote:

INTCNT seems to be counting backwards, but is there any routine in MSX-BIOS or MSX-BASIC, that really uses this variable??? (or can you imagine any reason for it to exist?)

INCNT counts backwards until 0, then it's reloaded the INTVAL (F9A0) and a (software) interrupt can be generated.
Sounds to me this is used in ON INTERVAL GOSUB.

Quote:

Sonic is in the asm learning stage (no offence) concerning these kinda tricky business.

Bite Me!