@hap, what you gonna do with the split screen?
"I didn't add a sprite flickering routine, I need the sprite overflow bit for mid-screen pattern table split later."
Idea:
When you always put 5 sprites at the end of the SAT.
Then you always get 5th sprite.
When it was a game sprite, it doesn't matter.
Take the sprite number and look at its Y. Then you know where the beam is.
The game sprites can be flickered as usual.
I heard there is the problem that on the real machine sometimes the status gets lost. It sounded like one looses a frame. But then, there are 15 more sprite lines to cause 5th sprite, so one rather should lose just a rasterline.
The Y positions above 192, is it known whether some of them are in the upper border?
So I read ROM location 6.
And there is written 0x98. So the retargeting fails!
Well I read slot 0. That is where System ROM is supposed to be, no?
So, is the app supposed to save the slot that is selected in page 0 and assume that to be "System ROM"?
That could fix it.
Is that the answer? Is there maybe a standard citation on that one?
hit9918: I don't understand what you mean...
I'll need mid-screen pattern-table split for vertically sliding in a second screen (as opposed to instantly popping it up). I think I'll just pause the game and poll the statusreg. Indeed it's possible to lose 1 rasterline if you read the statusreg at the same time the VDP sets it (some hw bug), but it's ok in this case.
@manuel,
in the text you quoted, the question is: what is "BIOS calls", what is "System ROM".
Example. Say a VDP cartridge is in slot 1.
But I read ROM address 6 of slot 0.
I take slot 0 because that is what I thought is "the BIOS".
The address returns the 0x98 port of my internal ROM for the internal VDP, the redirection fails.
I could imagine this one:
On app start, you are supposed to save the slot position of page 0.
And that is where is "the BIOS calls", "the System ROM".
So, what I always wanted to know: where is the BIOS
Any standard citations on that one.
@hap
Like, scroll up the info panel in quake console style?
One wobbeling rasterline often was seen on scanline interrupt machines.
When you even dont have a scanline counter, one wobbeling line is no shame.
@sd_snatcher,
"(HB-F1XDJ and HB-F1XV) are known to have slow VDP access."
I wonder how THAT can happen? Someone made a 9958 clone from scratch?
"7T states delay", how to interpret this figure?
The fastest z80 can do is OUT in 12 cycles.
I heard MSX2 takes the 18 cycles outi.
So now I got to guess the 7 cycles figure is meant "add it to the outi", makes 25 cycles.
Such stuff could need mention in the wiki.
@hit9918 - anyone can add and/or edit pages on the wiki, so by all means: feel free to complement the information there!
@snout,
I can't put it into wiki, because I don't know it.
All I can do is to say that the "7 cycles" figure is incomplete, something is missing.
@hit9918
This excellent article on the MSX Assembly Page can make those things clear for you. Too sad the routines shown here are all also based on hardcoded I/O to the 98h/99h ports.
@sd_snatcher,
it is again a claim with padding cycles.
padding specs are incomplete when not telling the IO instruction used AFTER the padding instructions.
But the 7 cycles figure seems to fit some puzzle:
I heard MSX2 can take outi. That is 18 cycles.
Look at this:
out ...
--- start counting here
7 inc de
12 out (0x98),a ;the instruction related to the padding
--
19
There is no 6 cycles instruction, padding with the 5 cycles NOP you would get below 18 cycles, so probably from there comes the 7 cycle figure.
And this should work, too:
out ...
--- start counting here
5 nop
14 out (c),a ;the instruction related to the padding
--
19
All I can make out of this issue is "on MSX2 do not go below 18 cycles (including the IO instruction after the padding instructions)".
I really wonder about the existance of a "slower VDP". I thought there is no 9938 clone VDP.
Maybe maybe the cause of the story is a PAL app crashing in the smaller blank area of NTSC mode.