# MSX 2+ Graphics Modes

Pagina 1/2
| 2

How do Modes 10 - 12 work? And what exactly do the Young Jedi Knights have to do with color signals?

Aangemeld of registreer om reacties te plaatsen

The very short version: YJK is a method of displaying many colors stored in a relative small area. And Starwars has nothing to do with that.

I can't get it to show color, just grayscale based on the Y component.

Dude, that looks more like C++ than it does assembly! Anyhoo, I use the formulas below to calculate the YJK values. You can indeed do cool greyscale tricks using just Y. Remember tho, that the J and K components are spread over 4 bytes. I didn't really look at your source that well, but I'm not sure you're actually spreading J and K over the four bytes correctly. J goes to the lowest 3 bits of the last two bytes and K goes to the lowest 3 bits of the first two bytes. Each pixel (byte) has its own 5-bit Y value, but I guess you're getting that right since you've got greytones. I think the lowest bits of J and K go in the first byte, but I'm not entirely sure... Just try and if not swap them... Lemme know if this helps... Good Luck

```Y = (R/2)+(G/4)+B, J = R - Y, K = G - Y

pixel 0:    YYYYYKKK
pixel 1:    YYYYYKKK
pixel 2:    YYYYYJJJ
pixel 3:    YYYYYJJJ```

Oh, and SCREEN 10/11 works in the very same way, except that bit 3 of each byte (pixel) indicates if YJK or Palette mode should be used for that pixel. If the bit is 1 the pixel will use the standard palette color for that pixel. In that case the YYYY part of the byte will indicate the palette color instead of a Y value.

```YYYY0YJK for YJK mode
CCCC1YJK for palette mode```

Since all the J and K bits of each byte (pixel) remain intact this method of color mapping does not affect the rest of the pixels in a group. It's actually a very handy screenmode and I'm surprised it isn't used more often

Dude, that looks more like C++ than it does assembly!
Your compiler must really deviate from standards, then.

I didn't really look at your source that well...
Debugging tends to go much more smoothly when you do read source code.

Dude, that looks more like C++ than it does assembly!
Your compiler must really deviate from standards, then.

I didn't really look at your source that well...
Debugging tends to go much more smoothly when you do read source code.

Uhm... You do realize I was actually trying to help you, right? Being sarcastic towards someone who's trying to lend you a hand is generally not the way to go... And yes, my compiler does differ from your compiler I guess, because mine is called an assembler. If you already knew the stuff I told I really can't see how your routine could not work, using screen 11/12 is hardly rocket-science you know... And yes, I know reading sources helps in order to track down problems, but it is (a) not my source, (b) not my problem and (c) not like any assembly I've ever seen.

You already know all this, ofcourse, but I suggest you read Alex Wulms' document on the MSX2+ screens first. Just indulge me, the worst that could happen is that you spend 5 minutes reading something you already knew. Then I suggest you try to rewrite that source into something more linear, and easy to understand. Not just for other people, but also for yourself. I'm quite positive the result will be a piece of code that displays all those colors just the way you want them... Good luck...

sarcastic

I had no intention of insulting or slandering you, so it's ironic, if you want to get technical.

And yes, my compiler does differ from your compiler I guess, because mine is called an assembler.

I was of course referring to your hypothetical C++ compiler, to whose syntax my source code was very much alike.

(a) not my source, (b) not my problem and (c) not like any assembly I've ever seen.

How amusing. I see dozens of newbies spam their homework assigments to programming-help message boards, and get hit with replies to the effect of "F.O. and when you've written something, come back and we'll be more than happy to help". So I come with code that will assemble (depends on your assembler, I guess) into a fully working ROM image, and I get "Sorry, but I'm not going to waste my time reading that since I didn't write it."?

Then I suggest you try to rewrite that source into something more linear, and easy to understand. Not just for other people, but also for yourself.

I don't understand what you mean by linear. Do you mean as the opposite of modular? I don't think... If you mean I should comment more, well, yeah, I don't really comment as much as I ought to. But hey, who does? :-)

I had no intention of insulting or slandering you, so it's ironic, if you want to get technical.Uhm, notice how I talk of sarcasm and not insults or slander... They're all quite different, though none of them particularly pleasing. Like I said, I was only trying to help... Generally you'll want your help to be appreciated, even if it wasn't useful. I still insist though, that by reading and implementing the info I gave you you should be able to pixelize <insert favorite naked popstar here> in a matter of minutes.

I was of course referring to your hypothetical C++ compiler, to whose syntax my source code was very much alike.Well, the source isn't very legible, at least not to me, and does suggest you're borrowing 'somewhat' from a C++ structure or something similar. It certainly isn't typical (beginners) assembly and could, at least in my opinion, be done a little clearer.

How amusing. I see dozens of newbies spam their homework assigments to programming-help message boards, and get hit with replies to the effect of "F.O. and when you've written something, come back and we'll be more than happy to help". So I come with code that will assemble (depends on your assembler, I guess) into a fully working ROM image, and I get "Sorry, but I'm not going to waste my time reading that since I didn't write it."?First of all, I doubt you (or anyone else for that matter) have ever been told to fuck off on these forums just because you didn't write a piece of code first. And if you have been talked to like that on these forums, rest assured it wasn't me...

Second, feel free to write a question such as 'How do the MSX2+ modes work?' on these forums any time, as you noticed people will be more than happy to lend you a hand or point you into the right direction. With or without code, it really doesn't matter. Generally, most of us are not all bad.

If you are going to post code however, make sure you don't post a piece of code only you yourself can read. Be sure to either comment your code, or make code that is simple and clear enough to be understood without comments. You can not however, expect someone to spend half an hour trying to figure out what it does or is supposed to do. I spent at least 5 minutes reading your code, and simply couldn't figure out what it was supposed to do. The lack of suggestions and reactions here suggests that other people didn't feel much like figuring it out either. This may ofcourse just be because I'm stupid, but right now Mr. Stupid here is the only one trying to make an effort. So if I tell you to read-up a little on the subject and try to produce a more linear form of code, don't get irritated, but instead take the advice of Mr. Stupid who somehow managed to code a number of routines/demos for the 2+ screens...

I don't understand what you mean by linear. Do you mean as the opposite of modular? I don't think... If you mean I should comment more, well, yeah, I don't really comment as much as I ought to. But hey, who does? :-)By linear I mean something that has a linear flow. This generally means you should be able to read the code much like a book, and produce code with as few calls as possible. Calling to do an OUT is not only going to slow your code down, it also greatly decreases the legibility. You'll also want to comment your code whenever needed, what seems obvious to you might be a complete mystery to someone else.

My suggestions: (if you care)

Try to code for the BASIC environment first. This allows you to use BIOS routines and to test your code with much greater ease. You won't have to worry about ISR's either, which saves some time. I suggest you download the WB-ASS2 assembler/monitor/debugger which is an excellent package for small programs and testing purposes. Either read the info I gave you, or better yet check out Alex Wulms' documents which explain the same in a detailed fashion. Make a few test programs, and I'm sure you'll get the hang of it in no-time...

So, good luck and whatnot, and if you have a question... I'll even try and answer it for you...

I guess by "linear" he means using less macros. When reading other people's code it's easier to understand "ld bc,\$0C9B" than "ld bc, combine(12,vdp_port_3)". But either approach has its advantages and disadvantages; it's also a matter of personal preference.

If your assembler treats these macros the same as the C preprocessor (or if you are using the C preprocessor), you should add braces around all used parameters. That avoids nasty surprises such as "1 + 2" being substituted for x in "x * 3" to form "1 + 2 * 3".

By the way, IM2 doesn't work the way you're trying to use it: all 8 bits on the bus are used. So bit0 is not fixed to 0, even though some docs say it is. In fact, on most MSX machines \$FF is used as the lower byte. However, do not rely on this value, instead make sure your ISR is on an address like \$4545 and your table is 257 bytes long (all \$45 in this example). In practice, it's easier to just keep using IM1, put RAM in page 0 (\$0000-\$3FFF) and put your ISR at \$0038. If you really need a custom ISR at all; usually it's sufficient to just hook into \$FD9F.

I don't know why your program only produces grayscale output. At a first glance, it looks OK. There are some things you could check though:
- if you're using an emulator, check whether other people's YJK graphics are shown correctly (make sure you're not looking at an emulator bug)
- if you're using a real MSX, check whether your TV/monitor can handle NTSC colour encoding (for example, do not turn on YJK and check whether SCREEN8 is in colour)
- use "ld a,8 \ call \$005F" to select SCREEN8 instead of initialising all VDP control registers
- start with a BASIC program with the same functionality as your assembly listing, make sure it works as expected and then replace functionality by assembly calls one part at a time, for example use "SCREEN12" from BASIC but fill VRAM in assembly

Pagina 1/2
| 2