Quote:

Quote: I choosed graph as ALT because of its position. Currently there is: Select=F6 Stop=F7 Clr/Home=F8 On a MSX computer, F6 is actually Shift+F1, F7 = Shift+F2, F8 = Shift+F3, F9=Shift+F4 and F10 = Shift+F5.

Moreover, not all MSX keyboard layouts are the same. I have an MSX where the stop key is actually on the top left corner of the keyboard, and right of F5 there are (in order) CLS/HOME, INS, DEL and SELECT.

diederick: sounds like a Canon V-20
(But I'm not sure at all, I'm just guessing here by heart...)

Quote:

diederick: sounds like a Canon V-20 (But I'm not sure at all, I'm just guessing here by heart...)

Mitsubishi ML-FX1

It will never run SymbOS, since it's an MSX1. But I'm guessing there are MSX2's and up out there with different keyboards.

Yep, definately. But all this keyboard stuff is pretty unimportant and thus uninteresting, IMO.

Yes, I agree, that keyboard layout should be reconsidered... My (MSX tR) keyboard layout is F1...F5, Stop, CLS/HOME, Select, Ins, Del

To make you even more confused, there are also AZERTY keyboards and for example in russian keyboard you have to write numbers with shift key down.

There is also 4 different ways in use to put ",.+-*/" in number keyboard and not every MSX even have number keyboard.

About the memory detection...

As you know MSX has 4 main slots, that each can be divided to 4 sub-slots. One slot can contain up to 4MB (256*16KB) memory. If you are not able to use memory from different slots, I suggest, that you select the slot, that contains biggest memory mapper.

PLEASE NOTE: when you select sub-slot, you have to select main slot first to #C000-#FFFF area and then write needed value to #FFFF The sub slot selection will affect only "under" the current main slot, so when you select another main slot, there might be different sub-slot selection. You can always read #FFFF and I/O #A8, but remember, that reading #FFFF will cause all bits to be inverted, so you have to execute CPL after reading.

If main slot is not expanded, subslot selection will not do anything. This may cause RAM detection routine to detect same RAM 4 times, if you don't check it correctly.

Most of the memory mappers can return mapper page value when reading I/O #FC-#FF but this is not standard and will cause problems on some machines. Don't do that.

Typically mapper size is 16KB * 2^x but don't trust that. For example in MSX tR last 4 pages are not available in R800 DRAM mode because they contain a copy of BIOS. How ever, you don't have to worry about that with detection routine, because in this mode the RAM is also write & read protected, but the amount of memory in for example standard A1GT is only 448KB in this mode.

I suggest, that you write values 255-0 to some address in mapper pages 255-0 and read the value back starting from page 0 and ending when number does not match.

Another thing about keyboards and lay-outs: maybe it would be wise to make some generic configs -- assuming SymbOS for MSX reads directly from the keyboard matrix, it should check for the locale setting in the BIOS and, depending on that code, apply the right locale. Eventually it might be an idea for users to make a custom keyboard driver by using a nice (GUI!) keyboard calibration program (as in, "Now press down the shift key" and "type the key for 5". Maybe it's a stupid idea, who knows. I'm full of it. That's a sure thing. In either case, the locale-checking thing would fix a lot. Implementing all those different keyboard settings would be a hell of a job, really

Thanx a lot for hints!
Regarding the keyboard: The placement of additional F-keys is not a problem, as you can reconfigure it yourself. In general the only important things are the "special" keys: Shift, Control and Alt, these can't be reconfigured in SymbOS. Another thing is, that shift+F1=F6 would work, but if you want to do alt+f6, you can't do shift+graph+f1, as double pressed "special" keys are not supported in SymbOS yet.
You can redefine the keyboard in the control panel: http://www.symbos.de/gfx/shots/system/symbos-system-controlpanel-keyboard.gif
But I will adapt this screen for the MSX keyboard layout.
Regarding memory detection: I already write different values in the different blocks, but I am still detecting more than 512KB, so I should check, what's going wrong here.

I know, that I'm going way ahead of current development, but these forum posts are not going away, so you can come back here to read these later.

I was just thinking, that if you are going to go to 16 and 256 colors, why not also up to 12499 colors of V9958?

This 12499 color mode is known as "SCREEN 10/11" in MSX world. You can check if it is available by reading VDP status register 1. This is a mixture of RGB mode similar to SCREEN5 and a YJK color mode. I suggest, that windows could use these 16 colors (out of 512) and backround picture could use the full 12499 colors.

screen size in VRAM is the same 53KB as in screen 8 (256 color mode) to place "screen 5 pixel" to screen, you must set bit3 and put color to bits 4-7 the unfortunately thing is, that you have to save bits 0-2 to avoid breaking YJK backround. (You need to use VDP logical operations)

Don't be scared of YJK, you don't even need to know anything else about it. In non window locations just place the backround image data to VRAM and VDP will take care of it.

If you want here you can get more detailed information:
http://web.inter.nl.net/users/A.P.Wulms/Mccm/mccm72/nofrschermen_eng.html

I have a feeling, that you are calculating the number of 16KB blocks correctly, but as you switch 4 blocks at a time you calculate 4 extra blocks from end of the memory too much or something like that.

Ok, seems, that I should think very carefully about extending the colour possibilities. This screen 10/11 is only available on the MSX2+ and TurboR, right? Is this mode more important than the mode(s) of the Graphics9000?
Btw, because of the logic, the desktop background is a complete real window, too, but without border and so on and with the limitation, that it can't be in front of other windows.

I'm not sure how screen 10/11 will work out. You could treat it as an 8-bit mode and only use 16 values representing the palette colours. But the rest of the pixels in the group of four depend on the other bits. So if you actually want to use the yjk features, you will need to use bit magic to plot certain stuff. I don't expect this to be quick. Probably best to do the important stuff first and then see what extras are available.

Well... In theory this is available only in MSX2+ and MSX tR, but there exists also MSX2 users, that have changed their VDP.

If you think about number of users, V9958 support is more important than GFX9000 support, but for usability GFX9000 support may take the OS to "next level" while special V9958 support is just "nice".

Because backround is a window, things may get a bit messy... In this case it would have been much easyer if backround image would be just saved in another page. Maybe you should forget about this at least for a while.

BTW Have you tried to run SymbOS in BlueMSX MSX tR configuration with R800 CPU? Does this effect to speed a lot?

Go to the impotant stuff, colors are only nice extras

Interchangable software! Nice..

On another note: I'd rather see GFX9000 support than v9958. On one hand more people probably have the v9958, but I guess allot of them also have GFX9000, and an OS supporting the GFX would also be a great selling point for new GFX's. Another cool thing is that you can actually use both the GFX and the normal vdp at the same time, which makes allot of interesting possibilities. I.e. you could have a GUI running on the GFX screen for choosing rom/dsk games to run on the normal VDP, cheats etc, kind of like some emulators. You could also have a two screen GUI.

I am for GFX9000 support