Sony 700 series FDD behaviour

페이지 1/2
| 2

By Manuel

Ascended (9450)

Manuel의 아바타

03-03-2010, 22:34

Does anyone know why the Sony 700 diskdrive was so slow? Was it just the diskROM? Or is there something weird with the FDC?

Rumor says that not all FDC registers could be read on certain machines (Sony 700 series). The FDC routines of those machines only read the upper two needed for actual data transfer and they didn't bother correctly wiring them up... so those lower addresses should always be pulled up to 255 instead of actually reading the FDC...

But... is this true? Does anyone have an idea? Can someone confirm/deny this?

Login or 등록 to post comments

By Leo

Paragon (1236)

Leo의 아바타

04-03-2010, 06:54

great machine ! rock solid & 256kb ram one of my top dream machine by '89
Bas has fast diskroms for sony700

By kwilting

Expert (75)

kwilting의 아바타

04-03-2010, 08:36

Ik have a Sony 700 with a 'new' fast Diskrom. Works perfect. Like Leo said Bas has fast Diskroms for the 700. If I'm right replacement of the Disk-rom would be enough to improve the speed. I do'nt think it is necessary to make further adjustments. Maybe Bas can give us more details.

By RetroTechie

Paladin (1008)

RetroTechie의 아바타

04-03-2010, 08:37

Purely a software issue - the hardware is basically compatible with the Philips 8250/55/80 FDC circuitry. If you disable the #READY signal, even the Philips 8245's diskROM works fine in a Sony HB-F700.

Rumors are false or talking about other FDC/machines...

By Meits

Scribe (2705)

Meits의 아바타

05-03-2010, 19:04

I got a peppered up Philips 8250 diskrom in my 700...
Just that eprom did it, speedwise... Anyone who knows how slow that original rom was in KB/S?

By Jipe

Paladin (877)

Jipe의 아바타

06-03-2010, 16:35

Philips drive dont verify datas and more fast ( VERIFY ON or OFF on DOS )

POKE &hFD9F,&HC9 = fast speed in basic for the HB700 Drive

By Meits

Scribe (2705)

Meits의 아바타

06-03-2010, 19:32

Philips tends to forget to shut down the drive after loading as well. Have had quite some hot disks... oO

By flyguille

Prophet (2146)

flyguille의 아바타

06-03-2010, 20:05

Philips tends to forget to shut down the drive after loading as well. Have had quite some hot disks... oO

that is not just philips, it is a problem of the MSX software, not hardware.

Because is a matter of the CPU to turn off the floppy motor.

So, normaly the CPU does a time-out countdown of several seconds, before to turn it off... how does?, using the VDP interrupt to perform the countdown, the same interrupt's code that its hooks is OVERRIDEN by any VIDEO GAME poorly written!....

So, is a problem of bad software that triggers the problem.

But it is a poor desing of the controller hardware / disk that ALLOWs to that to be happen!.

Because is too innocent to THINKS that every software developer will do the software right!, so, to delegate to them that fact is too innocent thinking!!!

PD: A fast way to avoid that problem for any video game that by its SIZE and complexity want to take all the control of the msx structure, is to execute the following code before to destroy BIOS DATA/MEMORY CONFIGURATION.

ld b,00
tt: RST38
djnz, tt

it is a FASTFOWARD for countdown or any other activity of the bios, making sure that the floppy motor get the time out by iddling.

By RetroTechie

Paladin (1008)

RetroTechie의 아바타

07-03-2010, 10:09

But it is a poor desing of the controller hardware / disk that ALLOWs to that to be happen!.
Not really - it's totally clear that MSX system isn't foolproof / crashproof or whatever. Especially machinecode software can do everything it wants, and therefore it's the programmer's responsibility to be aware of other things that may 'live' in the MSX ecosystem. Extended system software, software that runs via hooks, add-on cartridges etc. You don't have to do anything with those, just be aware that it may exist, and don't do any crap that may kill/crash those.

A diskROM that uses a timing hook to stop the drive motor is therefore perfectly OK. Doing this in hardware would be nice, but might also increase cost/complexity of a floppy interface (unnecessary).

If you look at typical software that does things like this (often: tapes with badly ported ZX Spectrum stuff), it basically says "fuck MSX standard, we'll control all hardware directly and ignore everything else". Fine, but then also take the blame if that causes issues. In other words: blame (and possibly: fix) that crappy software, not that properly programmed diskROM. FWIW: I don't have any software with this issue in my MSX collection - either I fixed it long ago, or I threw it away. Same thing with that POKE -1,xx crap: a non-issue for me since ages.

By flyguille

Prophet (2146)

flyguille의 아바타

07-03-2010, 19:04

But it is a poor desing of the controller hardware / disk that ALLOWs to that to be happen!.
Not really - it's totally clear that MSX system isn't foolproof / crashproof or whatever. Especially machinecode software can do everything it wants, and therefore it's the programmer's responsibility to be aware of other things that may 'live' in the MSX ecosystem. Extended system software, software that runs via hooks, add-on cartridges etc. You don't have to do anything with those, just be aware that it may exist, and don't do any crap that may kill/crash those.

A diskROM that uses a timing hook to stop the drive motor is therefore perfectly OK. Doing this in hardware would be nice, but might also increase cost/complexity of a floppy interface (unnecessary).

If you look at typical software that does things like this (often: tapes with badly ported ZX Spectrum stuff), it basically says "fuck MSX standard, we'll control all hardware directly and ignore everything else". Fine, but then also take the blame if that causes issues. In other words: blame (and possibly: fix) that crappy software, not that properly programmed diskROM. FWIW: I don't have any software with this issue in my MSX collection - either I fixed it long ago, or I threw it away. Same thing with that POKE -1,xx crap: a non-issue for me since ages.

yes, msx was not foolproof.

yes, it delegates in soft developers in having a good behavior.

about doing the time out in hardware, is not so extra complexity / increasing costs.

About extra hardware, just one CAPACITOR and just 2 resistors (RC constants *fast charge, slow discharge*) the capacitor holding up that SIGNAL a few seconds. Inserted in the LOGIC path of the motor ON/OFF signal, will do the trick.

This only needs that the ROM code, turn the motor on, perfom the RW/SEEK whatever, and shut DOWN the motor before exit the RW/SEEK operation routine. This shut down will take real effect when the capacitor is discharged a lof AFTER.

So , this way you don't needs to hook nothing to the interrupts.

By zeilemaker54

Master (153)

zeilemaker54의 아바타

08-03-2010, 08:22

And this is how the Sony 700 series (and other Sony's) implement the motor off. The Sony drivercode does not need the interrupt routine to stop the disk motor.

See: msxsyssrc.cvs.sourceforge.net/viewvc/msxsyssrc/diskdrvs/hbd-f1/driver.mac?revision=1.2&view=markup, look for lines 728-742.

In the old day's I even made my own drivercode (for pc drives) which implemented the Disk Change signal. The drivercode did not use any interrupt code. See: msxsyssrc.cvs.sourceforge.net/viewvc/msxsyssrc/diskdrvs/hb-f700p-alt/driver.mac?revision=1.2&view=markup, look for lines 206-226.

페이지 1/2
| 2
My MSX profile