Re: [openMSX-devel] Ok calm down please

[Laurens H. <lh...@st...>]

A few things,

Daniel Vik wrote:
>> It is a difference in perspective. Do you select the 'MoonSound'
>> extension, which can then automatically find the ROM based on SHA1 has=
h,
>> or do you plug in the 'MoonSound' ROM, which then enables the
>> appropriate hardware emulation.
>=20
> The latter. It works exactly as if you'd insert 'space manbow' in a
> cartridge slot. So it really does matter and it is a quite important
> requirement from my side. In fact you can insert the moonsound rom into=
 a
> cart slot and it will start working. like if you insert 'space manbow'.
> You can do the same with some fdc roms.

With regard to what I said, this is of course the same for say, a=20
DiskROM, as you illustrate. So there=E2=80=99s indeed a difference in=20
perspective, but that is actually not what makes a MoonSound ROM *extra*=20
special.

So, as a correction (or perhaps addition) on what I said before, the=20
extra special thing about the MoonSound ROM is that =E2=80=98plugging in=E2=
=80=99 a=20
MoonSound ROM is a bit weird considering that it is not directly plugged=20
into the standard cartridge interface of the MSX, but with some=20
additional logic inbetween, allowing only for indirect access :).

Anyways, I personally don=E2=80=99t see anything wrong with this approach=
 except=20
that it is a different one. From the three options Maarten gave, this is=20
option 1:
> 1. Insert an FDC using that disk ROM, creating a disk interface cartrid=
ge on=20
> the fly

Either option 1 or 2 has to be chosen (and imho either way is equally=20
good although I have a personal preference for the openMSX way), and if=20
the above option 1 is used as blueMSX does, why make an exception for=20
indirectly accessed ROMs.


Maarten ter Huurne wrote:
> <dump state=3D"pure">GoodMSX1</dump>

I indeed think <image> is a better tag. Also, maybe =E2=80=98pure=E2=80=99=
 could be=20
named =E2=80=98original=E2=80=99 instead (as opposed to =E2=80=98modified=
=E2=80=99)?


> Any ideas on an elegant way to express this difference?

With regard to the grouping of images in case of multiple disks, I think=20
this is a good solution:

<software>
    <diskgroup>
       <disk/>
       <disk/>
    </diskgroup>
</software>

Or just <group>, to allow for it to be more generic than just disks=20
(even though I don=E2=80=99t see a use case for that right away, it would=
n=E2=80=99t=20
really harm and be more future-proof).


> Maybe too easy? If the masses would start using funet in such a fashion=
, some=20
> people might take offence.

I guess you are right. An invitation-based filesharing system then! ;p


Daniel Vik wrote:
> If you prefer to call it something like Generic16k it is fine with me.

I personally prefer to name mapper types by their function, and not by=20
the software they use... That=E2=80=99s actually true for all the ROM typ=
es, but=20
I guess that might not really match the current approach :).


Patrick wrote:
> No words but deeds, that's my motto ;) Here's the link
> http://romdb.vampier.net

Lookin=E2=80=99 good, and...


> ps I found a job, but I can give 100% in the weekends ;)=20

Congratulations :).


~Grauw

--=20
Ushiko-san! Kimi wa doushite, Ushiko-san!!