Errr... I don't want to sound stupid but... how can you make use of the rest of the avaliable VBlank time after the BIOs interrupt routine has finished running?

I mean, how can you detect it is VBlank time? I do intent to replace the BIOS routines with my own, so I'm not really concerned about this, but I am very curious as to how people do that.

I know you can't read the VDP status register, 'cause the BIOS INT routine reads it and clears the VBlank flag... right?

Any light here?

The z80 works in im1. At every int cpu execute a "jsr" jump to 38h. Here is the interrupt routine. The routine do a lot of stuffs:
read the vdp status reg 0
read the keyboard
plays the background music...
... other stupid things

if you replace the 38h bios routine with your own, you can do only the stuff you want, but remember an important thing: when you get an interrupt from vdp YOU MUST READ ONE TIME (not MORE not LESS) the register 0 of VDP. What the reason? because reading it stops the vdp to request interrupts. If you read multiple times the 0 register you get data, but the data you get 2nd, 3th, etc time are different , because after first reading the vdp resets some status 0 bits.


Now, the problem is: how can i replace the original routine, since it is in ROM?

You can do 2 things:

- in msxdos environment all addressable z80 area is ram, poke the 0xc3 ,lowaddress byte ,high address byte in 38h-3ah and JMP (JP in z80) where you have your handler.
- in basic things are a lot complicated, because you need to enable for the first 16Kbytes a page of ram instead of rom

there's lotsa resources to be found in the development department of this great forum, specially about ints and stuff.

Here's a little preview:
Both interrupts (vblank, line) have so called hooks. These "hooks" are called within the bios interrupt to have a user defined int rout.
#FD9A and # FD9F, the latter is the vblank hook yer talking about.
It's 5 bytes long, you can use it to put in a call or jump (a call will take 5 bytes, including the RET comm. hence the 5 bytes) I prefer the jump #xxxx. It's only 3 bytes, needs no stack and is therefor faster

1. save the current 5 bytes
2. dis int
3. put yer jump on the hook
4. ena int.
(5. put back the saved 5 bytes when yer done)

now, go and search the forum!

Quote:

I mean, how can you detect it is VBlank time? I do intent to replace the BIOS routines with my own, so I'm not really concerned about this, but I am very curious as to how people do that.

On MSX1 you don't. On MSX2 you could use a line interrupt. In practise people either don't really care about the vblank time, or have very accurately timed code.

So, what ro said won't work in MSX1? There is no way to (properly) sync to VBlank in MSX1 when using the BIOS? That sure sucks.

Well, it's a good thing that I'm planning on using my own interrupt routines then!

I guess that Edwin has misunderstanding you, you're talking about the TOTAL time of VBlank?, or when this period begins?.
The first one, as Edwin says, only could be calculated by perfect synching of the code (or using the line interrupt on >=MSX2 machines). The second is easy to know, every interrupt must be tested to see if it's a VDP one (by using the right bit on status register). You can wait after a HALT (easy & dirty solution), or use the BIOS hook (FD9F), or even to replace the BIOS and place your code at $38 with your own ISR (as many others had told you before).

There's another way, a bit more messy that involves enabling the Z80 IM2 interrupt mode. Great because you get every T-state of the CPU; but you needs to fill a vector table and looks a bit ugly on typical Z80 machines like MSX, Amstrad or Spectrum machines.

If you don't plan to write very speed-tight code or synchronized code, the BIOS hook will be enough for your needs...

What I meant was: with the BIOS in slot 0 and interrups on, how do you manage to get the rest of VBlank time [b]after[b] the BIOS interrupt routine finishes.

Ah, I see it now... I guess HALT would be the easy way to sync to VBlank (as long as your frame calculations don't go over the time of a frame, or you'll start missing VBlanks and music will slow down, etc). Anything that follows the HALT instruction will be executed after the BIOS routine, right?

I already knew about the ways to replace the BIOS routine altogether, I was wondering about how to let both the BIOS routine and your own exist together.

Yep, you're right.

All the BIOS routines finish with a nice RET. Therefore, the computer itself returns to the program once that the interrupt has been aknowledged and the corresponding routines executed.

About "coexistence", you only need to change the hook in system RAM that is executed when an interrupt occurs to point to your own code. Therefore, it goes like this:

1.- V-blank interrupt occurs
2.- BIOS interrupt routines are executed
3.- You custom interrupt handler is executed
4.- Return to the main program

Happy end.

I guess that this "hook" is the most correct method. What's usually in that spot in RAM (FD9F) when you (programmer) are not using it?

Just one more question for now: Once you disable the BIOS interrupt (by replacing it with your own or whatever), you can use all the avaliable memory, right? I know the BIOS uses some memory by the end of RAM (how much memory exactly?), but if the BIOS is not running you get it all, right?

Thanks again!

The default hook (of a clean system) is just RETs.

And yes, if you never let BIOS be called anymore, you can use all RAM. Except $FFFF of course.

Quote:

I guess that this "hook" is the most correct method. What's usually in that spot in RAM (FD9F) when you (programmer) are not using it? Just one more question for now: Once you disable the BIOS interrupt (by replacing it with your own or whatever), you can use all the avaliable memory, right? I know the BIOS uses some memory by the end of RAM (how much memory exactly?), but if the BIOS is not running you get it all, right? Thanks again!

I do not know about ram, but sure, by replacing bios int you will gain a lot of speed int ints.!

$FFFF is used for secondary slots or something, right? Even on MSX1?

Quote:

$FFFF is used for secondary slots or something, right? Even on MSX1?

As far as I know, yes even on MSX1. Most MSX1 machines (maybe all?) have their internal RAM in non-subslotted slots though, so writing to it would not result in spontaneous resets or hangs although I guess you would still get an inverted value when trying to read back the data that was written there, so not very useful.
I remember having to disassemble and change the loader of an MSX1 cassette game after I'd gotten an 8235 (MSX2), since the loader actually read data from the cassette right up to (and including) $ffff. So, just as the last byte was read the machine would reset

OK, thanks for all the help guys! This helps a lot!

Oh, I almost forgot: what are the drawbacks of putting the Z80 in IM2 mode (as jltursan said)? This is the one where you can choose where in memory the interrupt handler stays, right? How can that be bad (when you use your own routine, that is)?

Quote:

I guess that this "hook" is the most correct method. What's usually in that spot in RAM (FD9F) when you (programmer) are not using it?

Mostly it's just plain RET, but some machines will use it to control the drive-motor spin time, like most sony hitbit computers. So you HAVE to save the FD9F hook (5 bytes) and, pref, re-call them at the end of your own hook to make sure thing will default. (else the drive motor won't stop on them darn hitbits for example)

init:
0. dis int
1. save hook
2. replace hook
3. ena int

on your int:
0. do yer stuff
1. call saved hook
2. ret

out:
0. dis int
1. restore hook
2. ena int

works on ALL msx types. We're talking Vblank here (will occur at the bottom of the screen, at line 212 on msx2 standard screen resolution. not 255 )