YAE and YJK have no effect in TEXT1 and TEXT2. In GRAPHIC1 both YJK and YAE indeed makes the screen shift 4 pixels to the right. In YJK mode the characters become a bunch of different coloured stripes on the odd lines, and in YAE mode it also becomes a bit stripey but the characters stay legible.
Btw as for the YJK mode screenshots in that bug you linked, strange, that does resemble what I saw in screen 1, but I was not able to get that kind of striping in screen 0 with the YJK and YAE settings.
Need more than that?
Oops... Forgot we already had this discussion. Though we only had tested the shift registers (26, 27).
So strange the effects that YJK has in all the modes other than G7.
Thanks again
Hello guys. Today I have a question that is a little complex... Regarding the VDP "current line number", as it is being generated and goes round the bottom of the display to the top.
What is important here is the line number that is going to be compared to register[19] (line int).
Assuming we have set to 212 lines, no vertical adjust, and no vertical scroll (reg23 = 0).
I know that the first display line (after the top border) is line 0, and then we go all the way to line 211 which is the last line before the bottom border. Then we go through the bottom border lines from 212 to 219.
So, I have assumed that the TOP border lines start from -8 (F8h) and go up to -1, and then we start again with the first display line which is 0.
BUT, the question is... At which point does that counter "reset"? What happens after 219?
The NTSC signal has more than 255 lines, and the PAL signal has even more. Does the line counter "stops" after line 219 and starts again at line -8 (F8h)?
And, of course, the vertical adjust register must add or subtract from these limits...
Can someone shed a light on this?
PS: I caught this bug in my emulator trying to run "Sonyc". It sets the line interrupt (register19) to FAh, or -5.
I suppose that falls inside the top border lines, right?
Guys, I could not edit the above post, so I write it again with some corrected values. Please disconsider the previous one.
Hello guys. Today I have a question that is a little complex... Regarding the VDP "current line number", as it is being generated and goes round the bottom of the display to the top.
What is important here is the line number that is going to be compared to register[19] (line int).
Assuming we have set to 212 lines, NTSC, no vertical adjust, and no vertical scroll (reg23 = 0).
I know that the first display line (after the top border) is line 0, and then we go all the way to line 211 which is the last line before the bottom border. Then we go through the 15 bottom border lines from 212 to 226.
So, I have assumed that the 16 TOP border lines start from -16 (F0h) and go up to -1, and then we start again with the first display line which is 0.
BUT, the question is... At which point does that counter "reset"? What happens after 226?
The NTSC signal has more than 255 lines, and the PAL signal has even more. What happens when the counter reaches 255? Does it wrap to 0 and then is reset again at some point? OR does the line counter "stops" after 226 and starts again at line -16 (F0h)?
Can someone shed a light on this?
PS: I caught this bug in my emulator trying to run "Sonyc". It sets the line interrupt (register19) to FAh, or -5.
I suppose that falls inside the top border lines, right?
Well, I think I figured it out... Thanks anyway! :-)
It would be nice if you could reply including the answers! Saves the person who found this from looking it up somewhere else. (Nothing is as frustrating as only finding back your question without the answer!)
It would be nice if you could reply including the answers! Saves the person who found this from looking it up somewhere else. (Nothing is as frustrating as only finding back your question without the answer!)
Yes, I would post back explaining how I solved the problem, but unfortunately I discovered my solution was not good enough.
My solution had problems with the program changing LN, NTSC/PAL and Vertical Adjust dynamically in some combinations.
So, I'm back with my question, still without a good answer... :-(
Hello guys!
Just prior to releasing the new version, I changed my default slots configuration to fit more components, and found a very strange problem.
My disk interface is patched. That meas I had to write my own simulated version of the Disk Driver routines.
The disk routines that read/write from memory receive the address to write/read data in the HL register.
BUT, how does the original disk routines know WHERE (in which slot/subslot) the data should be written at HL address?
Like, for example, if the destination address in HL for a read is in the range 4000h-7fffh, the disk routine cannot just write to address in HL because the slot selected at this address would be the disk bios itself while the routine is running.
This gets more complex if expanded slots are involved, and if the Disk Bios itself is in an expanded slot.
How does it work? Does the disk routines just assume they should ALWAYS read/write to RAM? Or is the destination slot/subslot stored somewhere prior to calling the disk bios routines?
I have tried several of the above combinations, but none work for all cases. Now that my slots configuration is more complex and includes several expanded slots, I cannot know for sure where (slot/subslot) to write to or read from during disk access...
Does someone know how it is supposed to work in the original disk routines?
Paulo
Hi Paulo,
I don't have access to my MSX notes & stuff right now, but IIRC, the Disk ROM has a table of RAM slots in memory (F341 to F344 or something). I'm pretty sure the RAM slot for page 4000-7FFF is in F342. When a read or write command is issued, it will be performed on these RAM slots.
Thanks for the answer!
Humm, this would mean that the writes/reads are always from/to RAM...
But I think that is not always the the case.
For example: SD Snatcher seems to perform a Disk READ directly to the SCC-I Cartridge RAM, that is located in a completely different slot than main RAM.
That was how I found the bug. I was always using the addresses you said to discover where the RAM is, and use that.
But this does not work when the program is trying to make a direct Disk access to/from some other slot.
Maybe it just uses the slot/subslot set for the desired address page in HL, and assumes its already selected. But this would make the range 4000h-7fffh prohibited for reads/writes.
Actually, I've never seen a Disk read/write to that region. Maybe that is exactly the answer!
Then, if that is the case, I just do not know what to do if HL comes within 4000h-7fffh.
Paulo