Open Wierzbowsky opened 4 years ago
Hi, this seems an issue related to the driver, have you contacted the Carnivore driver developers? Maybe they released an updgrade to the driver with Beta2 that causes the issue?
Carnivore2 doesn't have any drivers. It uses the Sunrise-compatible Nextor BIOS version AS IS. With Alpha2 version the CF cards work without a problem. When upgraded to Beta2 version, some cards stop working, some get detected as Card + Unknown device and stop working as well. The problem is likely with the Nextor Beta2 or one of the drivers that it includes.
Still, I suggest you to contact the Carnivore developers because:
That said:
Nestor, I am Wierzbowsky, the coordinator of RBSC and I write software for Carnivore2 cartridge. We don't have any drivers of our own. There is FPGA firmware, Boot Menu (for selecting games and configurations), Nextor IDE BIOS and FMPAC BIOS. That's all.
The simple test that was performed by me and several other users indicated that changing the Nextor IDE BIOS from Alpha2 to Beta2 brought a few incompatibility issues with certain CF cards and card readers. Maybe it's the driver that is included in the BIOS, I don't know. How to get an alternative driver that you mentioned? Your release has the following files:
We are using the "Nextor-2.1.0-beta2.SunriseIDE.ROM". I will try with the "emulators" ROM, now that I know that this version contains a different IDE driver.
I will arrange the Carnivore2 cartridge for you.
Ok, sorry, I didn't know that you were actually part of the Carnivore team.
The version with the experimental driver is "Nextor-2.1.0-beta2.SunriseIDE.emulators.ROM" (it's called like that because the optimized driver don't recognize the master device on emulators for some reason), please try with that one.
From what I see - the "Nextor-2.1.0-beta2.SunriseIDE.emulators.ROM" uses the older IDE driver v0.1.5 that was previously used in the "Nextor-2.1-alpha2.SunriseIDE.ROM", at least the versions match. The experimental driver 0.1.7 is now located in the "Nextor-2.1.0-beta2.SunriseIDE.ROM" BIOS and we used that one for Carnivore2 July's release, like we previously used the Alpha2 version.
You are right, it's probably the newer IDE driver and not the Nextor BIOS that causes some CF cards to stop working and trigger those double detections. Sorry for blaming the BIOS.
When I switch to older IDE driver in the "Nextor-2.1.0-beta2.SunriseIDE.emulators.ROM", I don't have incompatibility issues. I will ask other guys to do some more tests and if they succeed, we will replace the IDE BIOS with the one that has the older IDE driver.
Awesome! @sdsnatcher did the upgrade from IDE driver v0.1.5 to v0.1.7, maybe he could take a look?
We are making the QVL for various CF cards and SD-CF adapters. It looks like some of them work with v0.1.5 but don't work with v0.1.7 and vice versa.
The QVL document is WIP (work in progress), the community is helping to add more data. When done, it will be added to the Carnivore2's repository: https://sysadminmosaic.ru/msx/carnivore2/qvl_list-en
We collected quite a lot of info on different cards, thanks to the help from the community. Looks like some cards only work with 0.1.5 driver, some cards work only with 0.1.7 driver. Many cards work with both. There's one card that doesn't with with either of the drivers, but that is an anomaly. I am not a hardware guy, so I have no idea why there's such incompatibility between different versions of the IDE driver and different CF cards.
Awesome! @sdsnatcher did the upgrade from IDE driver v0.1.5 to v0.1.7, maybe he could take a look?
I can try, but cut me some slack since it was ages ago. The IDE protocol is a patchwork of legacy features, ambiguous documentation and poor device implementations that requires you to be immersed in it to be able to make things work.
Sadly, I won't have time now to dive that deep again so we'll have to think together to solve any problems.
EDIT: It's important to highlight that on the following messages master/slave will be used to denote devices in the same IDE interface bus, and not for different Nextor interfaces master/slave behaviour.
@Wierzbowsky, you mentioned that some cards are not being detected as slave.
But was there a Master device present on the same bus? This is a requirement of the IDE protocol. There can be no slave without a master.
Yes, I know that some PC motherboards support this out of spec configuration. But this is why they can't do quick automatic detection on every boot like the MSX. They have a huge nonstandard routine that can only be used on the "BIOS Setup Utility", and save a lot of info on nonvolatile memory for later use. Even doing this, there are cases where it will malfunction and give the user headaches.
TL;DR: On IDE/PATA, a slave device requires a master on the same bus or things will malfunction (including detection).
I am not a hardware guy, so I have no idea why there's such incompatibility between different versions of the IDE driver and different CF cards.
It has to do with the "patchwork of legacy features, ambiguous documentation and poor device implementations" problem that I mentioned.
The v0.1.5 did a lot of nonstandard things and was very nonchalant when handling the devices, so it ended up supporting some nonstandard things like an IDE slave without a master. But this did break compatibility with a lot of CF cards and devices that are fully compliant to the standard. Detection was awfully slow too.
The v0.1.7 follows the IDE documentation by the book on every minor detail. This is why it is able to support a lot more cards and devices (including ATAPI) and detect them much quicker, but the price to pay is that it won't support nonstandard configurations like an IDE slave without a master. There's no way to achieve both.
There's always a master device, never a slave (Carnivore2 doesn't support slave devices). The master device is almost always detected correctly, but sometimes driver version 0.1.7 detects the non-existing slave device and it breaks the master's functionality (nothing works after that).
Most of the CF cards work fine with both 0.1.5 and 0.1.7 driver versions. Some cards don't work with one version, but work with the other version. This is quite strange and there should be something particular that is causing this trouble. If this problem could be resolved, the whole community would be grateful.
So, the Carnivore only has a slot for the master device, right? Is it possible there can be noise of some form on the unconnected slave device pins that cause a driver to detect it sometimes?
Or, another question: if a card doesn't work with a version, does it NEVER work? Or does it sometimes work, but often not? You said:
The master device is almost always detected correctly, but sometimes driver version 0.1.7 detects the non-existing slave device and it breaks the master's functionality (nothing works after that).
What if it doesn't work with the 0.1.5 version, do you get a similar effect? If not, what do you see happening?
Carnivore has a single slot for CF card and no pins for slave devices. With driver v0.1.5 the slave detection never happens.
There's only one CF card that doesn't work with any driver version. Most of the cards work with both driver versions. Certain cards work with either 0.1.5 or with 0.1.7 driver version. The failures are stable. If the card doesn't work with the driver from the satrt, there's no way to make it work. The only way is to change the IDE driver/BIOS to a compatible version.
What do you see if a card doesn't work with the 0.1.5 version? It's just ignored?
Usually when an error is shown for the slave device, the master device stops working as well. So a computer boots to Basic and with the "files" command you get the "Disk I/O error" - the IDE disk is not available.
For the 0.1.5 version the IDE autodetecting may stall or a computer will be booted into Basic with no IDE disk available.
So in my case (C2 with ATP 4GB CF card) it is trying to detect the slave device and it fails, but everything works fine after that. That's with 0.1.7.
@sdsnatcher The Carnivore 2 never has a slave device (it only has one CF slot, which maps to the master device). The 0.1.7 driver works fine on my Carnivore 2 with the mentioned ATP 4GB CF card), except that there is a detection of the slave device going on that takes quite some time. If this could be skipped, it would be ideal and has a very fast boot.
Now, I found out that some problems with reading files on the MSX side (that did not occur on the PC side) go away if I start using the 0.1.7 driver. But as it takes some extra time for that slave detection, I was hoping someone could perhaps improve that for better boot times :) (These issues appeared when I was trying the enhanced Salamander and translated Androgynous... they wouldn't probably work in any way and when copying the file to another dir, I did see different file content on the PC. So apparently the MSX was reading different data than the PC. The same files suddenly work fine when using the 0.1.7 IDE driver! As also discussed with @Konamiman )
@Wierzbowsky For me this means there is a critical bug in the 0.1.5 IDE driver... I wouldn't recommend anymore to use it.
I took a peek at the Carnivore2 schematics, and found some things that don't seem to be quite right on the CF connector.
(Note: The pinout naming on the CF connector of the Carnivore2 schematics is not standard. I'll use the standard naming on the description below, since the text is quoted from the official docs. It would be advisable to fix the pinout name on the Carnivore2 schematics too, if we're going try to find where the problem is hiding)
According to the *1 Reference, the IDE/CF host connector should have the following features, that seem to be absent or incorrect on the Carnivore2:
1) "The host shall have a 10K pull-down resistor and NOT a pull-up resistor on DD7 to allow a host to recognise the absence of a device at power-up so that a host shall detect BSY as being cleared when attempting to read the Status register of a device that is not present."
2) The pin-42 (IORDY) isn't connected. Some CF cards are know to be unable to keep up with the R800 data transfers, specially with the 0.1.7 much quicker routines. This pin must have a 4K7 pull-up resistor on the host, and be buffered as an open-collector signal to the /WAIT pin of the MSX slot.
3) Pin-43 (DMARQ) should have a 5K6 pull-down resistor on the host
4) pin-37 (INTRQ) should have a 10K pull-up resistor on the host
5) "The host shall not drive DASP-. If the host connects to DASP- for any purpose, the host shall ensure that the signal level detected on the interface for DASP- shall maintain VoH and VoL compatibility, given the IoH and IoL requirements of the DASP- device drivers." But the Carnivore has a 220R pull-up resistor on pin-45 (DASP-), that might mess with the device 10K pull-up and its VoH/VoL compatibility.
In particular, the items (1) and (2) can cause exactly the kind of detection problems we're seeing here. The other pins might cause other interoperability problems too.
*1 Reference: "Information Technology - AT Attachment with Packet Interface - 6 (ATA/ATAPI-6)", revision 3b, 26 February 2002.
except that there is a detection of the slave device going on that takes quite some time. If this could be skipped, it would be ideal and has a very fast boot.
The slave absence detection on my CIEL IDE interface is very fast. I also tested on a Tecnobytes IDE interface, and it was quick too. On top of that, Piter Punk tested it on a plethora of different IDE interfaces and all of them behaved correctly.
I suspect the problem is on the Carnivore2 CF connector. Meanwhile, are you aware that you can press CTRL+STOP to skip a detection on the boot, right? :)
Meanwhile, are you aware that you can press CTRL+STOP to skip a detection on the boot, right? :)
No, where could I have read this? Still, very annoying to do that each boot... The boot time with the 0.1.7 driver is about 4 to 5 seconds longer than with the 0.1.5 on my system. The slave-not-present-detection also takes a few seconds on the 0.1.5 driver, but it's clearly longer in the 0.1.7 driver. That's why I preferred the 0.1.5 one before I found it contains a critical bug causing wrong file reading as I wrote in my previous post.
Meanwhile, are you aware that you can press CTRL+STOP to skip a detection on the boot, right? :)
No, where could I have read this?
The driver should have an accompanying README, but it seems to be absent from its folder on the Nextor sources here.
@Konamiman , could you please add it there? Otherwise people won't know anything about the new features, or keys to be pressed.
In a nutshell, both the IDE and SDMapper new drivers I wrote have the same set of user interface features:
Still, very annoying to do that each boot... The boot time with the 0.1.7 driver is about 4 to 5 seconds longer than with the 0.1.5 on my system. The slave-not-present-detection also takes a few seconds on the 0.1.5 driver, but it's clearly longer in the 0.1.7 driver. That's why I preferred the 0.1.5 one before I found it contains a critical bug causing wrong file reading as I wrote in my previous post.
4 to 5 seconds it not exactly a huuuge amount of time, but ok.
Maybe the Carnivore2 FPGA firmware could be modified to add a special register at 7FFFh? On normal IDEs, this address will always return FFh, since it's the ROM. A new version could return some special bits for the driver there, to allow me to know things like, cards present, card changed (similar to disk change). This would also allow future support for card hot swapping, like I implemented on the SDMapper.
On boot I wouldn't try to detect any master/slave devices that the 7FFFh register tells me that are not present, making the boot faster.
And this approach would also me allow to keep a single driver for all the devices. No need for special versions, what would take too much time to maintain.
@sdsnatcher Thanks for the pointers. For me, a boot time increase of 4-5 seconds is quite a lot. Total boot time is already more than 10 seconds. Don't forget, this is an MSX, I am used to instant-on! And the hardware is fast enough for an almost instant-on experience, I think.
Anyway, I thought you said that there were hardware problems on the Carnivore 2? If that's true, then I would expect these just need to be addressed and new features for the firmware are not the proper solution.
What abuot a simple configuration patch to turn on/off some features? So, a tiny tool that simply modifies the ROM at a given fixed offset to configure it to match its target usage. One of the bits could be 'detect slave on/off'.
We're talking about 2 or 3 different topics here, so this might be starting to cause some confusion.
1) The original bug report was about CF card compatibility issues
I made my analysis about the possible causes (hardware) and the possible solutions. These problems were probably being masked by the nonstandard way the 0.1.5 used to detect cards. That caused problems on standard interfaces/devices, so it had to be fixed. This is why a lot more cards, drives and IDE interfaces are working fine with the new driver now. Even optical drives are detected just fine now.
But the standard algorithm of detecting IDE devices rely on certain characteristics of the bus, so it must behave as expected. This is why I suspect that the problems that were being masked before started to show up on the Carnivore2.
2) Then, the topic about the slave detection / boot time showed up
I explained my view about the best way, to my experience, to fix the problem without wreaking havoc or breaking the compatibility with the existing fully-fledged IDE interfaces.
And, since we're talking about "this is an MSX", being unable to hot-swap media is one of my biggest annoyances with the MSX CF interfaces.
Please take a look at the two liked videos below. I solved all these issues on that SD-Mapper v2, and now not only it boots "absurdly fast" (as described by some of my friends who have them), but it also supports card hot-swapping, so we won't have to waste time rebooting the MSX needlessly.
SDMapper v2 boot speed on a Panasonic FS-A1ST (MSX TurboR)
SDMapper v2 boot speed on a Panasonic FS-A1 (MSX2)
As we were talking about new features, my suggestion is to solve all the issues of the topic-2 at once, as they're related, to bring the CF interfaces on par with the SDMapper v2 performance/hot-swap features. This will also make it a real flash card interface, and not just an IDE interface in disguise.
Anyway, would you go ahead and open a specific feature request for "quicker CF boot and card maybe hot-swap support"? This way this "off topic" wouldn't derail the CF card compatibility bug report even more.
I talked to our hardware developer about incompatibility with certain CF cards. And he made an experiment. He had a bunch of non-working CF cards at home. He flashed the Nextor 2.0.4 BIOS into Carnivore2 and voila - all problematic cards started to work like a charm. So I would like to repeat what I already said before - the problem is likely to be in the Nextor's BIOS (in the disk driver, to be exact), not in Carnivore's hardware implementation.
I don't have any problematic CF cards in my possession, so if someone could try the older Nextor BIOS (2.0.4 for example) with his problematic card(s) and report the results- that would be great. If those cards indeed work without a problem with the older BIOS, then maybe Nestor or Piter should take a look at this problem. We've sent a brand new Carnivore2 to Nestor as a "thank you" gift for his hard work.
As I don't have issues with my CF card, except for the slave detection to take too long (for my taste), which according to the author of the 0.1.7 driver is a C2 hardware issue, I'm not that motivated to try that old Nextor BIOS myself. @Wierzbowsky Or do you think that the 0.1.7 driver will do faster slave detection with the ancient Nextor 2.0.4 kernel??
Perhaps it helps if you also specify which driver was used in the tests you reported about, the 0.1.7 or the old 0.1.5 driver?
It's version 0.1.5 of the driver as far as I can see. The Nextor BIOS 2.0.4 file that the test was done with is attached.
What about the 0.1.7 version? That one is written according to the standards, according to the author @sdsnatcher . As I said before, the 0.1.5 I would certainly not recommend, as it contains at least one bug which causes files to be read wrongly.
Did 0.1.7 even exist when 2.0.4 Bios was released? I can't even find this version on Github... The point is not to start using the old version, but to verify that the old driver + old Bios didn't have a problem with any CF cards in Carnivore2.
Hi, I am experiencing something that is probably related to this issue. I've recently got a new CF adapter for SD cards that is not detected by my current Carnivore 2 configuration.
After reading the whole thread, I have tried this out:
Now, I have tried to go back to my usual Kingston 8GB CF Elite Pro card, and it has stopped working. It is recognized during the start up, but it won't work with the FDISK command (or a simple FILES command). This is weird since it has worked for years without any issue at all.
Any ideas?
Hi, I am experiencing something that is probably related to this issue. I've recently got a new CF adapter for SD cards that is not detected by my current Carnivore 2 configuration.
After reading the whole thread, I have tried this out:
- I have downgraded the Nextor ROM to the 2.0.4 one.
- Now, the CF card is recognized during the boot process. It shows up as INIC-2051 CompactFlash Card.
- I execute the _FDISK command from BASIC. I select option 1 (Sunrise IDE v.0.1.5 on slot 1-1).
- The MSX freezes badly (it's a FS-A1GT, if it matters).
Now, I have tried to go back to my usual Kingston 8GB CF Elite Pro card, and it has stopped working. It is recognized during the start up, but it won't work with the FDISK command (or a simple FILES command). This is weird since it has worked for years without any issue at all.
Any ideas?
Please try again with the firmware v2.50 and the special Nextor BIOS version for Carnivore2. These files will be put into the repository in just 2 hours.
Please try again with the firmware v2.50 and the special Nextor BIOS version for Carnivore2. These files will be put into the repository in just 2 hours.
Thank you. I have updated the firmware to the v2.50 version and tried all the Nextor BIOS versions. I've managed to go further, but still having problems.
So close, but no cigar.
One more thing. Maybe it could be a hint of what's going on. when the CF is first detected by the Sunrise IDE Driver at boot time, it shows as:
INIC-2051 CompactFlash Card
However, when it appears on FDISK, the identifier randomly suffers different changes:
INIC-2071 CompactFlash Card IOIC-2071 CompactFlash Card IOIC-2051 CompactFlash Card
The "N" is shown as "O" sometimes, and the "5" is shown as "7". It's like if some bits were a bit "dizzy".
Thank you for your support.
Try a different CF card and see if the bit dizziness problem still exists (card's name gets corrupted).
Try a different CF card and see if the bit dizziness problem still exists (card's name gets corrupted).
The usual CF card I use with my Carnivore2 works fine with all versions of the Nextor BIOS. No name corruption. Furthermore, unlike the other CF, it is detected at the first attempt.
I have also tried the problematic CF in a number of other devices: PC, Mac, an Alesis Fusion synthesizer and a Canon DSLR camera. In all of them, it works 100% perfectly.
Hi,
Any news regarding this issue? One year has passed and still at the same point...
Thank you in advance.
Hi, Any news regarding this issue? One year has passed and still at the same point... Thank you in advance.
The compatibility issues with many CF cards have been fixed in v2.50 firmware. Also, update the Nextor IDE BIOS to v2.1.1 Release - the latest file is in the Carnivore2 repository.
Hi, Any news regarding this issue? One year has passed and still at the same point... Thank you in advance.
The compatibility issues with many CF cards have been fixed in v2.50 firmware. Also, update the Nextor IDE BIOS to v2.1.1 Release - the latest file is in the Carnivore2 repository.
Thank you for your response.
As you have probably read, I already updated to v2.50 one year ago with no success. I've also tried Nextor kernel 2.1.1 but, since it includes the Sunrise IDE v0.1.7 driver, my CompactFlash card is not detected at all.
I have got a second Carnivore2 unit and the problem still remains on both cartridges (so it does not seem a hardware related problem).
According to the feedback from users, the compatibility issues are very rare since v2.50 has been released. All my cards now work with Carnivore and the latest Nextor 2.1.1 (master device only). Please get a different brand of CF card from the list of compatible cards. Go for a 4gB one.
According to the feedback from users, the compatibility issues are very rare since v2.50 has been released. All my cards now work with Carnivore and the latest Nextor 2.1.1 (master device only). Please get a different brand of CF card from the list of compatible cards. Go for a 4gB one.
Sorry, but none of the listed compatible cards are useful for me. My main problem is that swapping the CF to transfer data on the Mac/PC is a PITA: most of the CF readers end up with bent pins. I need a CF card that: a) is an SD/MicroSD converter b) the SD slot is placed on top of the CF card (not on the side) so I can insert/extract the SD card without taking the CF card out.
The card I am trying to get working is the only model I found that meets those requirements. If I don't manage to make it work, I'll have to sell my Carnivore 2 cartridge and buy a different product.
With those requirements you may indeed want to switch to MFR or FlashJacks.
MFR is terrible. I can't understand why so much hype for that piece of cr*p. I'll take a look at FlashJacks. Thank you for the recommendation.
By the way, I recognize the issues with CF-cards. I also bent some pins on my previous CF-card reader on my PC. But I managed to get them straight. By being careful I was able to use it as I wanted though. I just bought a new PC with a new card reader and it also seems to be tricky not to bend pins. So I'll remain careful to put it in.
I bought a 4GB ATP CF card, which works perfectly.
It would be great if a SD-enabled Carnivore 3 cartridge ever existed...
Anything may be possible :)
Hi... I've given the C2 another chance with a different CF card.
Again, it does not work. But this time I have used one of the CF cards reported as compatible:
"FC-1307 SD to CF Adapter V1.3"
The symptoms are different right now. Steps to reproduce the problem:
-Install the CF into the C2 cartridge. -Boot the C2 menu and select the default configuration (IDE boot). -The CF is detected by the IDE BIOS. -Go to BASIC. Ejecute CALL FDISK. Select the volume, create one partition for the whole empty space. -Press 'W' to make the changes permanent, respond 'y' to the confirmation question. -Reset the machine. Boot again into BASIC. -Copy the Nextor tools disk (by using the floppy drive) to the newly created partition. -At this point, I'm able to launch the Nextor/DOS2 prompt by doing a _SYSTEM. It seems to work, but... -After resetting or turning the MSX off, the partition has gone! The CF is still detected, as well as the volume, but there aren't any partitions.
Additional considerations: -The machine is an FS-A1GT. -I've tried three different BIOS (the stock one from the latest files on the Carnivore 2 repository, as well as v0.1.5 and v0.1.7). -I've got two Carnivore2 cartridges. The behaviour is exactly the same on both.
I have a Kingston CF card that works perfectly if I follow the previous steps.
Any ideas?
Is R800 mode enabled while you work with CF card and tools? Try to disable it. There are known issues with C2 on TR in R800 mode.
Is R800 mode enabled while you work with CF card and tools? Try to disable it. There are known issues with C2 on TR in R800 mode.
Z80 during the whole process, same result. The partition disappears after the MSX is powered off. If I read the CF card on the PC, the partition and all files are still there (even the files I created on the MSX itself).
EDIT: I've also observed that, if right after creating the partition I use the "test" option on the FDISK tool, I get the following error:
"Error when searching partitions. Invalid disk driver".
However, if I reboot the MSX (by pressing the reset button) for the first time, the partition is there, I can copy the MSX-DOS2 files to it, and I can even do a _SYSTEM. But after the second reboot (or if a power the MSX off) the C2 stops detecting the partition.
You said that you used a different CF card, but the ID matches the CF-to-SD adapter. How is that even possible?
So, you have a Kingston CF card that works perfectly with Carnivore?
Carnivore2 starting from v2.30 (firmware + boot menu) no longer works with some CF cards after upgrading to Nextor v2.1.0 Beta 2. With Alpha 2 version of Nextor everything works fine.
Certain CF cards, for example Kingston 512mb as well as Delock SD to CF adapter are correctly detected as the master IDE, however when detecting the slave IDE, the following error is shown:
detecting.Unknown device 0202h
After this neither master, nor slave devices are accessible. The fault should be in the code, that detects the slave IDE device. As this affects a large number of cartridges (and loosing a lot of nice features by going back to Alpha is not desired), everyone would appreciate a quick fix. Thanks.