Quote:

However, if you format a (DD) Disk on a PC, no matter what OS-version you have (don't know about Linux, tho), it won't be bootable by MSX although it is readable by MSX. Probably has something to do with the bootsector.

This is actually caused by the fact, that MSX boot code starts from offset #1E From MS-DOS 4 this space is used by Extended BIOS Parameter Block. Earlyer versions used this space for Boot code, but as this code is for x86 and not Z80, it will not run correctly. If you want the disk to be bootable on PC and MSX, you need to put Z80 code to #1E, PC code after that and correct the PC jump command at offset 0.

As you propably don't need custom PC boot code, you can just take MSX boot sector and change the first byte to #C3 that is a RET instruction for x86. After that you can boot from the disk on PC as well as on MSX.

This is because the boot code on MSX and PC, both do the same thing, they are use to display message "Boot error, press anykey for retry", "Non-System disk or disk error, Replace and strike any key when ready" or something similar... As these codes are really used only in error situation, (If no error, the codes just execute RET) you propably don't really need either of the boot codes. If you want to be creative, you can use this space for something more usefull, like MSX frequency selector or to notify PC user, that they are trying to boot from MSX floppy or something... There is "plenty" of space, so you can do your own custom boot codes for both machines.

I know I talk here, like FAT would be the only systems for MSX and PC... If you want PC Linux to boot from same floppy as some MSX program, you need to work a bit more, but even that is possible, you just need to forget the FAT then. Just remember, that MSX starts from #1E and PC from 0

That's a whole lot more explanation than just

Quote:

Duh, that's completely the fault of the bootsector.

Thanks!

Quote:

FIXDISK will solve this, as will manually writing an MSX bootsector to the disk with a disk editor like DiskView.

I usually don't even use a program to copy correct boot sector to disk. I Just insert disk, I want to copy from and write "A$=DSKI$(0,0)" then insert disk, I want to copy to and write "DSKO$ 0,0"

WARNING!: Don't use this method, if you don't know what you are doing. If source and destination disks have different size or settings, you will mess up the whole disk!

Fiath: Sorry my mistakes, thanks to come here

But as i stated before, i'm more interesting in preserve Tapes, because they're older than disks, and worse for storage(they get damaged soon). I think that many tapes have been lost. This is why i want to see some emulators(openMSX, BlueMSX, NLMSX,....) to develop a new container format(or adapt TZX) to preserve all tapes, like Spectrum or CPC comunity does. I'm not a MSX expert and i haven't got enough knowledge so i cant do it right.

As far as i know, only mars2000you from blueMSX team seems to be interested in.

Thanks.

No problem! :-)

Yes, I agree, tapes are very important, as you say, its just not an area we will focus on. There are very good projects that are working on it, TZX in particular.

Perhaps while you are waiting for a container format to arrive for MSX in particular, you could start preserving them now by sampling them (at high quality of course)? If space is a problem, perhaps something like the lossless compression system FLAC could help to some extent? I can't see any issues with that (apart from storage space!), unless there are technical issues I don't know about?

I believe the C64 community uses .TAP (not T64) for accurate preservation of tapes. I think that could also be a usable format? It'd be an advantage because of the already exisiting large amount of C64 utils.

A noise-free digital conversion system, like MSXWAV or WAVER, produces huge WAV files, that is true. But if then you ZIP them, they will be less that twice the original size.

For example, a 32 KB ROM converted using WAVeR and packed then with ZIP, would be about 50 KB. I think that this is a fair size for the files. And it has a big advantage: you can load it in the REAL SYSTEM. CAS files used in most MSX emulators are not that flexible. You need special tools to reload them into the real hardware and some effects are then lost.

Regards,

Edward Robsy

Nyyrikki: did you make up that #C3 thing yourself or did you steal it from my DOS3 page? ^___^

~Grauw

Quote:

Nyyrikki: did you make up that #C3 thing yourself or did you steal it from my DOS3 page? ^___^

No, I used a program, that luckily is still delivered with Windows. It is called DEBUG