Carnivore2 no longer works with some CF cards after upgrading to v2.1.0 beta 2 #60
Comments
|
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: |
|
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. |
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). |
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?
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 :) @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:
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. |
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? :) |
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:
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. 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.
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.
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. 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. 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? |
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 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). |
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. |
Konamiman
added
bug
|
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. |
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: 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. |
|
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. Additional considerations: 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. |
Z80 during the whole process, same result. The partition disappears after the MSX is powered off. 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? |
It is a CF-to-SD card (and according to the documentation, it is compatible), but not the same one I used in my previous attempts. The Kingston card (a regular CF) works perfectly. |
|
I have the same problem as Colpocorto with the FC-1307 SD to CF Adapter V1.3. The partition no longer works after a cold boot. I'm using an NMS-8245. The card appears fine if I insert it into my PC. As a test I tried the reverse and created the partition on my PC and to my surprise I was able to boot into DOS this way from a cold boot (and this partition does not disappear). It also seems to show the correct amount of free space. However, if I then go into FDISK it lists 4 incorrect partitions of varying sizes. It does seem to work though (at least to some degree). |
|
Did you try with the latest released Nextor v2.1.1? It's in our repository. |
|
Nextor 2.1.1 made no difference. However, I just did some tests on Windows with this CF Adapter and I'm getting weird behavior there as well. So I think these adapters are probably just faulty. |
I also think that not enough compatibility tests have been done. Some models seem to work but after some time of use, they stop being recognized or data is lost. If you ask me, this looks like weak or incomplete tests (i.e. "the name of the card appeared at boot time, then it must work... add it to the list"). |
The compatibility list does state In any case, I'm getting some weird behavior in Windows with this adapter. For example, I format the card, remove it and put it back in. And then Windows says it's not formatted. It does not give me a lot of confidence in this adapter. I ordered another one, let's see how that one does... |
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.
The text was updated successfully, but these errors were encountered: