Sonic: I thought you meant a full checksum on the entire ROM! But, if I understand it correctly, you mean checking a few bytes in the disk ROM, right?

Quote:

@Sonic_aka_T: Maybe there is a way to test the different FDCs without disc access. When switching of the motor and trying to execute a command, you should receive a "drive not ready" error. Maybe this is already enough for the detection. I am afraid, that making all the checksums can be a lot of work.

NOT! I have one better!

because if you replace the MSXBIOS just after that the kernel loads, nobody turnoff the FDD , so the FDC is already turned ON (LED ON / MOTOR ON) that happens with all msx games that don't care about msx1/2 int @ #38.

so


here is other way! and not needs to use a WD command

it is just like, try to turn on/off the motor, and check for the HOLE... that takes time and needs to be inserted a diskette.... the same if you try to do a WD command... mmmm

no, bad idea...


SHIT! i GOT IT

looks for the boot sector IMAGE at ROM, just the LABEL on it!!!!

it normaly varies between one or other brand/model IIRC ... please somebody correctme if I am wrong


But anyway, why to try to test all possible FDC?... and not just let that the user preset what FDC he has? (symbios.ini or something like that) also that means that needs a install instance... allowing to select pre-load others drivers (custom hard) overall knowing that msx is groing and several groups are ensambling his own made in home hardware) allowing to plugging drivers. That is the way that I see how to do that in mnbios.

Prodatron, I suggest you to allow symbos to be started in this way: (manually)

a>SymBios /FDD:WD
a>SymBios /FDD:WDIO
a>SymBios /FDD:AnotherFDDDriver

and later, when you had figured the way to detect

a>SymBios /FDD:Auto
or simply
a>SymBios

Quote:

Regarding rom switching, is it also an usual feature of the disc roms? When I switch between diskrom and cp/m (or nothing), the ports at #7fbx are always available?

I believe you need to map the diskrom in slot 1 to access the FDC ports since they are memory mapped. If you map something else in the slot, like ram, you won't have access to the disk (or did I misunderstand your question?)

Quote:

Quote: Regarding rom switching, is it also an usual feature of the disc roms? When I switch between diskrom and cp/m (or nothing), the ports at #7fbx are always available? I believe you need to map the diskrom in slot 1 to access the FDC ports since they are memory mapped. If you map something else in the slot, like ram, you won't have access to the disk (or did I misunderstand your question?)

that question was about a feature that i commented nothing to do with slots


anyway the real problem to do a auto-detect, is that the fdc can be anywhere about slot sslot (by standard) but in practice there is some few in use.

Quote:

anyway the real problem to do a auto-detect, is that the fdc can be anywhere about slot sslot (by standard) but in practice there is some few in use.

Since SymbOS is loaded from DOS, it is possible to look in the system RAM area to find the slot of the disk ROM(s). There is a table at 0xFB21 which lists the slot IDs and the number of drives in each slot.

Quote:

Sonic: I thought you meant a full checksum on the entire ROM! But, if I understand it correctly, you mean checking a few bytes in the disk ROM, right?

Indeed, something quick and dirty. It's hardly required to calculate a SHA1 or anything. A quick checksum of a few hundred bytes of the ROM should be enough. Checking the actual FDC is of course also a (better) option, but it does require a little more work. Apart from that, as the amount of supported FDCs grows these routines will also become more and more complex/elaborate. If enough drivers are supported you would probably end up loading a bunch of drivers, polling each of them to see if the appropriate FDC was found. While this will work, it's certainly slower than checking the disk ROM for a checksum. I'd think the fastest way would be to first check the ROM (which would work on maybe 95% of the machines) and only checking the FDC itself if the first check fails. In the end of course, it hardly matters, especially at this stage of development.

Quote:

NOT! I have one better! because if you replace the MSXBIOS just after that the kernel loads, nobody turnoff the FDD , so the FDC is already turned ON (LED ON / MOTOR ON) that happens with all msx games that don't care about msx1/2 int @ #38.

Sure, but what happens if the user boots from an IDE/SCSI device? It'd be nice if SymbOS could also properly access other drives than those hooked up to the controller it booted from.

Quote:

Since SymbOS is loaded from DOS, it is possible to look in the system RAM area to find the slot of the disk ROM(s). There is a table at 0xFB21 which lists the slot IDs and the number of drives in each slot.

Indeed, the BIOS makes a nice list of the disk ROMs found, their slot address and the number of (virtual) drives connected. @Prodatron: The addresses should be in the 'initialization' source I sent you.

yes but, prodatron has in mind to be able to replace the msxbios (as he was asked about and replied before), just like mnbios.

it is not too much work, but if you starts adding prev msxbios dependencies for to pre-know thinks it is hard!

And about writting a INI file with hardware detail don't helps in that way because maybe it needs to access first to the device before to read the INI file (same problem with same headaches that I had on mnbios)

one solution (as all computer are msx2 or better) is to write the config in the CMOS. but offcourse WARNING to the user that it will destroy the current config of msx-basic and being aware do not change it

is possible to write a little MSX-BASIC program like setup.bas to do the job of configure the cmos for the O.S., then turn off, switch the ROM to the O.S. and to turn ON.

well prodatron I hope that these ideas helps....

@Sonic_aka_T: Yes, I have the piece of code for getting the diskrom slot table in the init routine you sent me, thank you, I will use this!

Regarding FDC detection: If it's not so trivial I will first take PingPongs suggestion. The user can create a batch file like "sym.bat", which starts "symbos.com" with the correct FDC option. This batch could be created later with an install program, so I don't need to touch the CMOS.

so, you are saying bye bye to the option of to boot from ROM?

Maybe you can patch the rom to set the FDC configuration. This would work at least for internal drives. But not for external once I guess.
But if the config is small you can also save it in the RTC SRAM. Then you could boot from rom, read the config and start up the drives. Not sure how much data you can store there but maybe its enough for FDC info.

Btw, have you had any luck with the FDC on your real MSX?

yes sure I also tought that, but so "bye bye auto-detect"

is needed to concentrate in how to autodetect without dependencies

almost the most popular fdcs

first problem is: not always a disk will be inserted in the floppy drive


Well, "how to detect if the WD chips IS!!!!

i can thinks about

first to write in the TRACK register, then try to read it! if it have the written balue ... there is something, but can be just RAM or a COINCIDENCE with ROM value, or the WD

then to avoid ROM value coincidences, just test with 2 values....

to avoid RAM, sends a STEP + command , and then check if the value of TRACK is changed if it is!!! voilá, it is the WD

note that until here we don't touch the bits of the 7xxC/D/E/F register, have just detected in which range is the WD.... with that knowledge can we try to use it but how to determine between several FDC conf. that uses the same range .... is a headache!

Maybe the best and fastest solution for now:
(mostly mentioned before) Build up a db with checksums with standard and unmodified] disk ROMs. If it's not "detectable", the FDC can be selected somewhere - eg as commandline parameter, or the FDC type is selected by the user at bootup time if SymbOS is started from ROM sometime
And of course save it somewhere for convenience

Everyone, who wants to help him out, can send his disk ROM (or supply an app, which calculates the checksum of diskROM) with the needed info in order to add it to the database