msx2: integrate Sunrise IDE

[balyuf]

MSX2 now can also boot from Sunrise IDE (with or without ROM). There is only room for one blkdev, so either SD or IDE. However we can still include MegaSD for the integrated MegaRAM mapper, as the IDE drive is first probed. I had to move the data of Kernel/dev/blkdev.c to COMMONMEM in MSX2 (hence the initializer). It should not impact other platforms (verified MSX1). I also had to enable RST peephole optimization, to arrive within a some 60 bytes of the 48K boundary.

[balyuf]

Woops, sbcv2 fails in the checks, I notice. I tried manually with and without my changes, and indeed it is the initializer which causes trouble - I will make the initializer conditional ...

[balyuf]

Ok, that fixed it - I am not so happy with this hack, as all I wanted was to have blkop in COMMONMEM, but as the blkdev table is also in the same file, I cannot keep dat one in DATA (uninitialized, as that segment is zeroed out anyway at startup), and as a consequence I can only have one blkdev, not two (as in MSX1) ...

[balyuf]

Good, I had an idea this morning to copy the necessary blk_op fields over to common memory on the fly for sunrise.s ... as we change anyway some fields, except the lba address which is a costly copy (32 bits), but balances a bit against some optimizations I deed. As a result I have now 2 bkldev's (1 IDE and 1 SD) and still more room left in the 48k space!

So I was able to revert the changes to blkdev.c - I wonder if you are bothered with the hoopla (resulting in zero change) that will be in the history of the git repo after importing this branch? Should I recreate the branch to have a more clean commit history, or maybe can you filter out the blkdev commits?

[balyuf]

Hmm, I was looking into enabling the second SD drive, but sdcc does something very strange with this kind of loop:

for(i = 0; i < SD_DRIVE_COUNT; i++) { sd_drive = i; sd_init_drive(); } It will create a decreasing loop, with as a result: SD drive 1: hda: hda1 hda2 hda3 SD drive 0: hdb: hdb1 hdb2 hdb3

What is going on? Have you seen this before? How to avoid?

[balyuf]

Ok, I think I understand why sdcc feels it is at liberty reordering the loop, as the function call does not depend directly on sd_drive, it assumes it cannot harm - I will see to make it a function parameter as it is with Sunrise IDE ...

[balyuf]

Right, so now we have 4 blkdev's in MSX2, to have potentially 2 SD drives and 2 IDE drives (normally the second IDE is a CDROM in openmsx, but in the real world anything goes I suppose) ...

I will let you process the whole circus here, and stop adding changes ;-) ... tell me if I need to redo some stuff ...

[EtchedPixels]

The SD ordering is a bug in that version of sdcc

[EtchedPixels]

Merged - the copying is definitely cleaner