At 06:51 PM 03/26/99 -0300, you wrote:

>Nice to collect games? But if you're a game collector, you'll want a lot
>of games, and cartridges will use too much space in your room. Disks are
>phisically much more compact, and this is a good advantage for game
>collectors.

Disks easily damage, either from magnetic interference or from dust.
Actually, I collect MSX games on PC harddisk or CDs and only write them to
disk when I want to play them.

>> I don't think a commercial company would care if their games are copied in
>> a country where they aren't available in the stores.
>
>I do, else, there's almost no reason for their copy protection.

But making a copy protection costs them money (paying the programmer, more
difficult disk duplication). If no-one Japan copied games, they wouldn't
lose any money if a game were not protected. That's why I believe that
companies were expecting cracking inside Japan.
Other example: why did Konami put the RAM in the SCC+ of Snatcher and SD
Snatcher in different pages? Copy protection is the only reason I can think
of. And both games were released only in Japan.

>> Most of what you pay for a game is not the hardware, but the development.
>> Even if ROM hardware is a lot more expensive than disks, it will make only
>> a small difference on the selling price.
>
>This is true only nowadays. In that time, EPROMs were very expensive.

Games didn't use EPROMs. ROMs in game are not of a programmable type. I
don't know exactly how they are made, but they leave the factory with the
contents already in there.

>> >> Henrik Gilvad once told me.
>> >
>> >Is he the guy that created the IDE interface for MSX?
>> 
>> Yes. And also the MoonSound, GFX9000 and some other hardware.
>
>So, I would say that he is the "Ademir Carchano" from the Neatherlands!
>:-)

Except that he is from Denmark! ;)
He made designs for Sunrise Swiss, and the products were sold by (among
others) Sunrise in the Netherlands.

>> My turbo R already has a HD drive inside, to replace the broken original
>> drive. Other modifications wouldn't be necessary, would they?
>
>To be a replacement, no. But if you want to use the 1.44Mb capabilities of
>your FDC, at least will need to allow the photo-diode signal from your
>drive to be connected to the FDC.

So a kind of "HD detected signal" must be sent to the FDC. The standard
34-pin cable has a wire for HD detection. But where should I connect it to
the main board of the turbo R?

>Remember: this photo-diode indicates if
>a high density (1.44Mb) disk is being used.

Note: my drive uses mechanical switches to detect HD.

>Last year I made a simple test, connecting a 1.44Mb drive in my port based
>interface. With 720kb disks it works, but with 1.44Mb disks it doesn't.
>Perhaps increasing the value of the cristal (i.e., exchanging the cristal)
>it can work. Am I speaking nonsense?

Do the specs of the FDC allow higher clock rates or are you suggesting
overclocking?

>> >My idea was a buffer for an entire track (or maybe cylinder?)
>> 
>> Would that make any difference in performance?
>> I think that if the "read sector" command can be given within the time a
>> sector gap takes to pass the drive head, reading single sectors will
>> already occur at top speed.
>
>The main idea is: I want to make smaller sector gaps, then I can format a
>track with 1 more sector, increasing disk capacity. With small gaps, the
>time won't be enough, and so it would be necessary to make an entire track
>buffer.

Problem with such a format is that it is not compatible with PC disks. Is
the extra space worth the extra trouble?
Besides, even smaller sector gaps might still be large enough to allow a
new sector read command to be issued.

>> A diskROM for 1.44MB disks has two main features:
>> - sector reading using the new floppy interface (easy to make)
>> - support for 1.44MB floppy filesystem (may be difficult?)
>
>Then, your idea is to use a common diskrom, with the least modifications
>possible. The performance won't be very good, because standard disk
>interfaces has poor performance (compare with a PC interface, for
>instance).

Improving the diskROM is something that can be done separately from the HD
upgrade. Anyway, performance of HD disks will be better than before because
of the higher bitrate.

>I was thinking to create an entire new disk interface, but I don't know
>how the disk system variables related to work. So, I don't know how to
>create a better disk interface with backward compatibility.

When I make something, I like to start small, so that I always have a
running system. Once it works, I extend it, debug it, restructure it and I
have something working again.

>Perhaps Henrik Gilvad can implement a 1.44Mb interface using FPGA's. Since
>he has a good MSX hardware experience, he can do it spending much less
>time.

He hasn't designed any MSX hardware since the IDE interface...
He doesn't even update the IDE interface BIOS, Jon does that now.

Bye,
                Maarten



****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****

Reply via email to