Trying to build a visual novel for MSX1 and looking for suggestions.
You can't really load and play a tune. But loading goes quickly, so why do you need that?
By Google
I recomend you to make the pictures with dither for shades. you can simulate 3 tones of gray.
Indeed if you use monochrome slides with no full screen, the data to load would be less than 4KB, even less if you compress the bitmap; so, why bother with complex music/trackload routines?.
Anyway, of course it can be done; but you must create your own track loader and make a complex timing scheme to find how much data you can load from disk before you need to feed again the PSG. AFAIK there're no published code capable of doing so...
I guess it's not possible to keep VDP interrupts enabled while loading from disk. However what is the tech reason?
Slot issues?
no. The problem is that any manifacturer used its own disk controller. You shoud do a different code for any possible disk hw. Standard fixed only bios calls
Why monochrome images?
This is a game I made, in Pascal, loading images from disk: http://www.youtube.com/watch?v=oZ7h2kFyS-c
In this video, loading times are 'disabled' in the emulator, but they arent bad at all. Running from HD, they're just as fast :)
And see how many pictures the game has, didn't even bother to compress them: each screen has something like 9k (2/3rds of the screen) - and I have 50 of them on a single disk :)
Also... if you want to have music playing while showing the next image, easiest way to do it is to make your game a MegaROM.
Use each 8kb page for a different graphic (or graphics, using some compression) and you'll be able to switch as many graphics you want without having to do some tricky code.
If you reduce your graphics to tiles + tilemap, you can get even better results
make a snatcher sequel and call it sblatcher
If you want to make it look great, I'd go for full colour full screen images. That's 12 KB. And if you want to overlay sprites, that would be roughly 13,440 bytes per image. Adding an efficient compression algorithm could drop that by 50%. Problem here, of course, is that there is no automatic graphic converter that sets up the sprites overlay. If you skip sprite overlay, there are plenty of options out there and they do work great. Say an average of 7 KB/image. In a 360 KB disk, that would made about 50 images. Twice that if you go for 2DD floppies (720 KB).
Once that you have the images, you need some logic. A nice variable width font with a correct blitter routine and the interface that you want to use. And some music and FX would help, of course. Anyway, even if it is an easy project from the technical point of view, it becomes tough when considering the artwork, unless you use the SAC method: Shameless Appropiation of Contents 
By the way: dithering is cool if you happen to use an old CRT. If you use a sharp LCD/LED, I'd suggest to go without dithering: plain colours even if there is some bleeding.
Cool initiative! Congratulations for coming with such an idea. I'd like to know more about the plot, if there's already one.
Why it's not possible to have video interrupts while loading from disk: because each floppy drive model requires different timing, and the timing is done with NOPs (or something) provided by the interface manufacturer's BIOS routines. If you want to have a music playing "track loader" like Amiga, C64, Amstrad CPC etc., you'd have to code your own replacement floppy interface drivers for each and every different floppy drive in existence. I.e. for every BIOS ("diskrom" or whatever) you'll have to have your own version. Maybe it would be possible to make a program which automatically reverse-engineers the BIOS routines and binary-patches them with music playing code...?

By Evhor
Rookie (31)
11-09-2011, 12:31