Quote:

It has several advantages, but there's a big disadvantage: emulators are not perfect. Especially critical timing things should definately be checked on a real MSX.

Ok I think it would be good to check on a real MSX when I have have a prototype ready (which is far from where i'm now). Until then openMSX should be fine.

Ok, i'm going to get some sleep now........zzzzzZZZZZZZZZZ
Is this al there is to to set VPD register 1 into screen2?

/*
* tst2.c
*/

static port unsigned char v99 @ 0x99;

main()
{
// Screen2?
v99 = 0x81; // bin 10000001 -- reg 1+128
v99 = 0xd2; // bin 11100010

}

No, you need to set most of the other registers as well. The ones that define the VRAM addresses for the various tables. (You can use the "vdpregs" console command of openmsx to find some example values from your game of choice.)

Thanks for your quick reply! I understand i have to set the other 7 registers. I just wanted to know if the direct port adressing was going to work.

Thanks for the openMSX debug tip! I'll try it right away

About libs at http://jannone.org/gfxlib I have found that they do not compile properly under hitech C v.7.5!

Aha! I was wondering what went wrong with those examples

I must say that the DOS-editor is also causing some problems on my Laptop. It's a 16-bit app that is polling the keyboard constantly; This causes a constant cpu load of oprox. 50% (ntvdm.exe) slowing down all other apps (like openMSX). I'll just have to make a script someday.

About my progress:
Today is my daddy-day (don't know a good word for it) so i'll have some time as my little girl still sleeps a lot.

Plans for today (and Sat- and Sunday)
- Display a simple screen using the pattern tables
- Display a sprite
- Manual movement of sprites (keyboard/mouse)
- Looking into interrupt handling/hooks as I'm not understanding them entirely.

Quote:

I must say that the DOS-editor is also causing some problems on my Laptop. It's a 16-bit app that is polling the keyboard constantly; This causes a constant cpu load of oprox. 50% (ntvdm.exe) slowing down all other apps (like openMSX). I'll just have to make a script someday.

Eh? Why are you using a DOS editor? Try UltraEdit, jEdit, UniRed or one of the other 1000+ more
-or-less free text editors available on the web (Heck, even Notepad should do!)

I suggest TexPad (by helios) or Winedt (http://www.winedt.com/),
the former is ASM/C oriented, the latter is mainly LaTeX oriented but is much more
flexible and powerfull, has tabs, ANSI C and HTML highlights and
I used it for writing my PhD thesis (my judgment could be biased due to the sentimental value .

HOw about VIM?

Very Unix!
I have been using VI for a long, but now I fee too old to bang my head again on its commands.
WYSIWYG has won...

The dos editor is actualy sort of an SDK. Now i just use it to compile. For everything else i'm using ultraedit. Just because I have it an use it al lot for work........

ARTRAG - the other editors you mentioned are also not WYSIWYG. We're not talking about word processing or typesetting, just a text editor... VIM is pretty good at that. And it also has "notepad" mode, default in the Windows installer (Annoying if you're used to VI though...!)

@Huey
do you have the demo version of the compiler that hasn't the online compiler or the full version v7.8 with time limted license?
@manuel
I was thinking to Latex, for coding in C you cannot use WYSIWYG :-)

@ARTRAG
Online compiler? I have a time licensed version (setting the date back solve any restriction though).

when I mean online I mean on command line !
You can run ZC in a msdos command line while edinting the .c text in a different window with your own editor.

About generating Roms for MSX look at this:

5.26.3 The #pragma psect Directive
Normally the object code generated by the compiler is broken into the standard psects as already
documented. This is fine for most applications, but sometimes it is necessary to redirect variables or
code into different psects when a special memory configuration is desired. For example, if the hardware
includes an area of memory which is battery backed, it may be desirable to redirect certain variables
from bss into a psect which is not cleared at startup (although this particular function is provided as a
standard feature). Code and data for any of the standard C psects may be redirected using a #pragma
psect directive. For example, if all executable code generated by a particular C source file is to be
placed into a psect called altcode,the following directive should be used:
#pragma psect text=altcode
This directive tells the compiler that anything which would normally be placed in the text psect should
now be placed in the altcode psect. Any given psect should only be redirected once in a particular
source file, and all psect redirections for a particular source file should be placed at the top of the file,
below any #includes and above any other declarations. For example, to declare a group of
uninitialized variables which are all placed in a psect called xram, the following technique should be
used:
---File XRAM.C
#pragma psect bss=xram
char buffer[20];
int var1, var2, var3;
Any files which need to access the variables defined in XRAM.C should #include the following
header file:
--File XRAM.H
extern char buffer[20];
extern int var1, var2, var3;
The #pragma psect directive allows code and data to be split into arbitrary memory areas.
Definitions of code or data for non-standard psects should be kept in separate source files as documented
above. When linking code which uses non-standard psect names, you will not be able to use the ZC -A
option to specify the link addresses for the new psects, instead you will need to use the ZC -L option to
specify an extra linker option, use the linker manually or use an HPDZ project to compile and link your
code. If you want a nearly standard configuration with the addition of only an extra psect like xram, you
can use the ZC -L option to add an extra -P specification to the linker command. For example:
ZC -L-Pxram=1000h/20000h -A0,8000,8000 test.obj xv.obj
will link TEST.OBJ and NV.OBJ with a standard configuration of ROM at 0h, RAM at 8000h, and the
extra xram psect at 1000h in RAM, but not overlapping any valid ROM load address. If you are using
the HPDZ integrated environment you can set up a project file by selecting Start New Project, add the
names of your four source files using Source Files ... and then modify the linker options to include any
new psects by selecting Linker Options ....

I think that you could generate a 16 byte array for the rom header to be placed at 8000h using a
customized ptsec to be linked at 8000h.
I am not sure but something like

---File XRAM.C
#pragma psect bss=xram
const char buffer[16] = {'A','B',0x10,0x80,0,0,0,0,0,0,0,0,0,0,0,0};

--File XRAM.H
extern char buffer[16];

ZC -L-Pxram=8000h/20000h -A8010,8FFF,8010 test.obj xv.obj

I'm not sure about the other parameters but could work