hap: yes, you are right.
Blinky was waaaaaay better, but still had some (very small) graphics corruption... but this time it looks random (sometimes appear in a random screen, sometimes it wont) - but even then it was pretty much playable
Hm, can you give more details about the loader? Is it sector based, msx-dos? Is the game loaded in 1-go, or does it load levels? Is it possible to compare, eg. via a save-state the contents of the ram after loading of the working diskimage with the romimage after loading?
Random, could it be something with interrupts being enabled where you want them to be disabled?
Can you make a screenshot; is the garbling random, or a fixed pattern (like before, white blocks?)
And what about a .cas to .rom ???
Its easy to implement?
I have a Turbo-R with ide interface and Scc-Flash from pazos, and I dream about load .cas files directly from my compact flash.
cas2rom requires patching of the bios; I think it should be possible (I have given it some thought before), though not all cas images will work; some games might not use the bios to load from tape (but use io instead), and some games probably won't like that the bios is placed in a cartridge slot.
Hm, can you give more details about the loader? Is it sector based, msx-dos? Is the game loaded in 1-go, or does it load levels? Is it possible to compare, eg. via a save-state the contents of the ram after loading of the working diskimage with the romimage after loading?
Random, could it be something with interrupts being enabled where you want them to be disabled?
Can you make a screenshot; is the garbling random, or a fixed pattern (like before, white blocks?)
Actually, there's no loader in Blinky, all graphics and music are compressed in the .COM, and expanded when needed, so the loading are pure MSX-DOS.
The garbage is really random, it can appear anywhere on screen... and it appears *after* the screen is drawn (that's the strangest part, since the screen is only drawn once where there's no animated tile)
Maybe is some issue with hook 38h? I use it for the music player...
(I place a JP PLAY_SONG in FD9Ah)
Actually, there's no loader in Blinky, all graphics and music are compressed in the .COM, and expanded when needed, so the loading are pure MSX-DOS.
I don't think it's a problem with the actual loading of the file; I created a test comfile for msxdos with data 00 to ff for about 50kb, and it checks after loading if that data is there; the result was perfect.
A diskrom can include a custom interrupt handler, but this one doesn't; it does look like a problem with interrupts (because after the screen is drawn, and because of the randomness).
Just to be sure, the disk image itself doesn't have this problem? The problem is only after conversion? Can you try out the original dsk image and boot with control to enable just 1 drive (that comes close to environment of the dsk2rom diskrom).
Also, what's the original format of the dsk file (double sided, 720kb, f9)?
I guess it have something to do with the interrupt...
I added a EX (SP),IX / PUSH IX before and a POP IX / EX (SP),IX after the CALL PT3PLAY (The PT3 player) and the bug seems to be gone
The original disk didnt have this problem.
And something I just tried: I killed all empty areas on the DSK (the FFh bytes at the end) and now I have a working Blinky ROM with 73kb
Oh, and one thing to add to the readme, how to make the ROM on MS-DOS:
copy dsk2rom.rom /b + yourdisk.dsk /b myrom.rom
I *think* the /b can be safely removed, but I use them just to be on the safe side
Also, if you plan to add compression, try bitbuster... it even has pc packer/depacker already, so it is halfway done
But I dont know how slower it will be... maybe two different programs, one with compression (for games that load once) and one without (for games that loads several times, even during gameplay)
But just an idea on how bitbuster is good... I bitbusted blinky.dsk, which shrank from 59k to 32k... add 16k from the dsk2rom, it gets to amazing 48k... now any MSX with 64k RAM would be able load it, even without MegaRAM or Mapper
Try pletter also, in my experience it outperforms bitbuster almost all cases
I am going for pletter, the description on the xl2s site convinced me it performs better.