Quote:

Yes, unbelieveable!!!! This is really crazy! I think I will stay with this config now ( http://www.symbos.de/files/lcdtv-4.jpg ).

Hey, your computer collections promote for peaceful coexistence . It looks like a good way to advertise for world peace.
Since you're a converter to MSX (as wolf_ pointed) can you tell us your impression about MSX especially your "new" MSX TR? How did you like it compared to CPC?

Of course, you can introduce yourself and your first MSX experiences in this forum

@Nyyrikki: I already visited the website and watched the pictures some time ago. Usually I would be in St.Petersburg now and thought about coming to Helsinki for one day, but this time unfortunately the trip was canceled, so I won't be close to you. But I will hurry up with the IDE-fix. Will you have internet at the party place?
@Scratch_disk/D-Tail: Good idea, I will write there something soon

I found the problem in the IDE routines, but currently I am not sure how to solve them.
When I write a higher value in the IDE sector count register (#7e02) for doing multiple sector read/write, the command doesn't read all sectors but stops after an (currently unknown to me) amount of sectors. As I never had this problems with IDE devices on several machines, I am not sure, if this could be a problem of the TurboR. Maybe I am not allowed to write the IDE registers too fast or this register maybe limited somehow? But that all sounds very strange... If I can't solve it soon I will first make a quick-and-dirty solution and replace multiple sector reads/writes with single ones.

How can I switch from R800 to Z80 in MSX-DOS 2? Do I need to download a tool somewhere?
I would like to compare the behaviour of both CPUs, as I still have no idea what's going wrong.

Another questions: When I press the reset button, will the complete 512KB ram be erased or only the first part, which is used by MSX-DOS?
I am thinking about debugging with the help of copying bytes into the upper part of the ram, which hopefully can be read after the machine has been resetted.

Quote:

How can I switch from R800 to Z80 in MSX-DOS 2? Do I need to download a tool somewhere? I would like to compare the behaviour of both CPUs, as I still have no idea what's going wrong.

If you are using COMMAND2 v2.41, you can use the CPU command:

CPU - Get info about the current mode
CPU 0 - Z80 mode
CPU 1 - R800 ROM mode
CPU 2 - R800 DRAM mode (default, fastest)

If you are using other COMMAND2 you can use this tool. However I recommend you to get that command version, it has some nice features. I don't remember now where can you get it, maybe that someone else can tell you.

Hans Otten's MSX Info pages

An invaluable source of MSX knowledge, both hardware and software!

Quote:

How can I switch from R800 to Z80 in MSX-DOS 2? Do I need to download a tool somewhere? I would like to compare the behaviour of both CPUs, as I still have no idea what's going wrong.

Look in those boot/init routines I sent you a while back. It checks if the computer is a turboR and if so turns the R800 on. If you want I could also write a CPU-switch routine for you, but it is fairly complex and will always require a fixed jump vector (eating up some address space). The behaviour of both CPUs should be pretty much identical, by the way. Apart from some undocumented flags it should pretty much behave like a Z80, albeit a pretty fast one.

Quote:

Another questions: When I press the reset button, will the complete 512KB ram be erased or only the first part, which is used by MSX-DOS? I am thinking about debugging with the help of copying bytes into the upper part of the ram, which hopefully can be read after the machine has been resetted.

It only resets the first two bytes of each bank. You may consider using the blueMSX debugger if you have a fast PC. Stepping through routines can often help clear things up, and it's a fairly accurate emu. Once you know what's going on where, you can check timings and whatnot on hardware by inseting a breakpoint at the right place.

Quote:

Will you have internet at the party place?

It seems, that we are not going to have :-(

Quote:

When I write a higher value in the IDE sector count register (#7e02) for doing multiple sector read/write, the command doesn't read all sectors but stops after an (currently unknown to me) amount of sectors.

I think, that you have to execute ATA IDENTIFY DEVICE (#EC) and then check, how many sectors you can read from returned 512 byte block offset #5E

Quote:

How can I switch from R800 to Z80 in MSX-DOS 2? Do I need to download a tool somewhere?

Type:

BASIC
3608 DEFUSR=-32749:IFUSR(0)THENLINE>0COPY0&H80F6OR384BASE!!
SAVE"Z80.COM"
RUN
CALL SYSTEM

Now you are in Z80 mode. Next time it is enough to type: Z80

In assembler you can change to z80 mode like this:

	LD A,128
	RST #30
	DEFB 0
	DEFW #180
	RET

... works in BASIC & DOS environment.

Thanx NYYRIKKI, that Z80 switch works. Still the same problem, so fortunately it's not R800 specific. I will now write a lot of debug information in the extended ram to check them after the reset. What is the "deadline" for uploading an update for the party?

Quote:

It only resets the first two bytes of each bank. You may consider using the blueMSX debugger if you have a fast PC. Stepping through routines can often help clear things up, and it's a fairly accurate emu. Once you know what's going on where, you can check timings and whatnot on hardware by inseting a breakpoint at the right place.

Thanx for the info, so I will write the infos starting from byte 2.
Usually I always use BlueMSX for debugging, as it's easy and comfortable, but unfortunately especially with some FDC problems and now also with the IDE issue I can't reproduce the problem here. It only happens on the real machine, while the emulated TurboR GT does everything fine in BlueMSX.

@Prodatron: As you probably know by now, the emulator doesn't emulate all commands and status bits in the controllers, so there may be something you need to do on a real machine thats not needed in the emulator. And it could also be a timing issue.

If you find out what's different I'd appreciate if you let me know so we can fix it to avoid the same issues in the future. The openMSX implementation is also a bit simplified, similar to blueMSX, so any findings would benifit both emulators.

Deadline is about 8AM GMT so you still have about 9 hours :-)