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)

The missed int's were actually caused by some BIOS routines I was using in the main program. Syncing the main with the ints and getting rid of the BIOS code (reading keyboard) got rid of that...

I still get the occasional flicker in the bar routine, but this is as good as it gets I guess. I much like the color-cylce idea, but I think it's a bit too limiting for fly's BIOS. Maybe I can add it as an option, but the screen-split thingy is already way to big at 600 bytes...

I think I made the whole thing clear enough for fly to have a look at. It now works, supports 8 user-programmable line ints which are either a color bar or page-split and/or vertical-split and/or palette-split.

The user can now define:

1) Where the split occurs
2) Wether the screen should be disabled or not
3) Wether to do a page split or not
4) Wether to do a vertical-offset (whatever...) split or not
5) Wether to do a palette split or not
6) OR a color-bar split instead of 3-5

I more or less tested it on hardware (frikkin Turbo-R won't read a single disk I have) and the color bar was indeed a bit jitter-ish at times, but hey... Don't much feel like implementing the color cycle... Mostly cause it's not known to the kernel where the bar will be located and what the color will be on each line. I would then have to write a whole routine that checks the colors one each line to figure out how to cycle them. I could ofcourse fix them, but I think that's too restrictive for a BIOS...

Anyways, I guess it is indeed not all that easy to make a general-purpose splitter, but atleast I was able to comeup with something. As long as splits aren't placed too close together it all works pretty much okay... Fly seems to be a good programmer as well so he should at least be able to deduct enough from this example to come up with something even better himself...

Thanks for the input tho, and I hope to see some of it put in practice (again) in the upcoming MB-Muzax 4 ...

Hey, if we ever BBQ again, I now have a beer-tap in my living room

(No, not one of the lame Krups/Heineken thingy's, a real one...)

Cheerz........

Quote:

- change backcolor to some hideous color (e.g. green) to REALLY see it

I remeber doing that once to check how fast the MB-WAVE player was... I was sure I did something wrong when the entire screen turned green. I didn't do anything wrong!

Quote:

Lately I've sometimes put a lot of things (like the music player) in the main loop, in stead of the vblank.

Nods, thats the only way I ever got the MB-WAVE player to work. It was my main program... Everything else was on the int! talk about weird shit...

Quote:

The user can now define: 1) Where the split occurs 2) Wether the screen should be disabled or not 3) Wether to do a page split or not 4) Wether to do a vertical-offset (whatever...) split or not 5) Wether to do a palette split or not 6) OR a color-bar split instead of 3-5

What !! no, set_adjust routine??!
Still think this is NON-bios stuff.... you should create a demomaker (check the Red Sector one...)

Quote:

Thanks for the input tho, and I hope to see some of it put in practice (again) in the upcoming MB-Muzax 4 ...

Talk to Wolf, he ain't interrested.. whuhuhhaaha. Nah, 3 is more than enough.

Quote:

Hey, if we ever BBQ again, I now have a beer-tap in my living room (No, not one of the lame Krups/Heineken thingy's, a real one...)

Whoh, cool! Why, you live in a bar or sumpf'n? I'll bring da meat!


Hope you or anybody else learned a thing or two here about using ints and stuff

Quote:

What !! no, set_adjust routine??! Still think this is NON-bios stuff.... you should create a demomaker (check the Red Sector one...)

***grumble***

Quote:

Talk to Wolf, he ain't interrested.. whuhuhhaaha. Nah, 3 is more than enough.

Come on! At least something... I suggest Muzax cause you can throw one together in a couple of weekends using the F-Kernel... If you prefer you can finish Radical Raymond though...

Quote:

Whoh, cool! Why, you live in a bar or sumpf'n? I'll bring da meat!

In a bar!?!?! Whats wrong with you!?!?! Of course not!!! Who lives in a bar???
Actually, it's the bar of a restaurant... Well, it used to be... It is now my home... Yeh!!

pretty nifty dude!

yeah, still working on both the Kernel (the boot routine has to be totally updated.. to lazy at the momen. I just let it compile eacht time (only 2 minutes) and start the enviroment sessions from there..) radical raymond aka fubsy still in progress. I'm having new ideas every week and still can't decide on what to to whith them.. darn.
I even thought about making it msx2+ required (for the scrolling part) but dunno, have to rewrite some stuff anyway.

loater!

Sonic_aka_T wrote on March 16 2004

Quote:

... Then I had to do something *HORRIBLE*. After all the effort I had put in not making self-modifying code I *HAD TO*. That kinda sucks, but I had no way out. So the IN A,(C) was replaced by a IN A,(n) which allows me to take the INC C out. The result is: LD A,C LD (WAITLP+1),A INC C OUT (C),E LD E,%00100000 WAIT_L: IN A,($99) AND E JR Z,WAIT_L OUT (C),D DEC C DJNZ BAR_LP This just about seems to work with not a microsec to spare... Me happy... Thanks for your input by the way....

If you have some freedom in the place of your code in the memory and need not preserve hl, you may use `computed jumps`.

	LD A.C
	LD (xx01h),A
	INC C
	LD H,xxh
	LD E,%00100000
xx00:	IN A,($99)  ; jump here if L=0
	AND E
	LD L,A ;  8 T-states
	JP (HL) ;     together 
; some space left here
xx20:	OUT (C),D ; jump here if L=%00100000
	DEC C
	DJNZ BAR_LP

This way of jumping conditionaly is 2 T-states faster than an ordinary jp (1 if we take the waitstate in M1 into account), and only 1 (2 with waitstate) T-state slower than a conditional jr if the condition is not met.
The restriction on the place of the code easily leads to spilling memory though.