Carnivore2 announcements | MSX Resource Center (Page 8/15)

Par enribar

Paragon (1206)

13-08-2020, 16:33

this "someone" is reading this thread, so I hope he'll write some more explanations :-)

Par Wierzbowsky

Guardian (3571)

12-11-2020, 00:13

We've noticed that some people manage to download HTML pages instead of the binary files for utilities, BIOSes and Boot Menu. Such HTML files, written into Carnivore2 make the cartridge unusable (but it is still repairable). So, as the first step, we have changed the download links in the documentation to point to binary files on Github (direct download links). And as the second step, the next version of C2MAN will be verifying the Boot Menu and BIOSes before writing them into the cartridge.

Par Wierzbowsky

Guardian (3571)

14-10-2021, 19:28

We have created the webpage for testers who could enrich the QVL list of compatible (or not) CF cards and SD-CF adapters for Carnivore2. Those, who would like to help, please visit this page:

https://sysadminmosaic.ru/en/msx/carnivore2/for_testers

Par Manuel

Ascended (19332)

14-10-2021, 20:15

What does compatible mean exactly? E.g. my ATP CF Card works fine, but:
- slave detection in the 0.1.7 driver is a bit slow
- 0.1.5 driver is buggy in subtle ways (I wouldn't recommend it for anyone)
No other issues found.

Par Wierzbowsky

Guardian (3571)

15-10-2021, 02:02

This means that if anyone wants to help, he could run the test with the 2 different versions of Nextor's IDE driver and his selection of CF cards and SD CF adapters. This will help us to improve the compatibility list. No need to test the already listed cards though.

As for 0.1.5 driver, it's still included in the Nextor 2.1.0 Release, so I don't see any reason not to use it. I've never had a problem when using this driver.

Par gdx

Enlighted (6127)

15-10-2021, 02:44

I used BIDECMFC.017 (same as Nextor-2.1.0.SunriseIDE.ROM) on my Sunrise CF interface. When i inserted a CF in the slave nothing works anymore (same with previous versions). Actually I use Nextor-2.1.1-beta1.SunriseIDE.ROM. It seems also to work fine but I haven't used a CF in the slave slot yet.

Par Wierzbowsky

Guardian (3571)

20-11-2021, 14:43

We have started the Beta testing of Carnivore2 v2.50
Any volunteers are welcome to download the necessary files from here:

https://rbsc.su/files/Carnivore2_v250_BetaTesting_001.txt
https://rbsc.su/files/Carnivore2_v250_BetaTesting_001.zip

Please read the TXT file - it contains a lot of important information!

WARNING! This is a Beta version, so it may contain bugs and may render your cartridge inoperable. It's recommended to take part in the Beta testing only if your MSX has an internal/separate FDD drive or if you have a separate cartridge that can load MSX-DOS. You may need this hardware if you accidentally brick your Carnivore2 during Beta testing. If you just have Carnivore2 for everyday use - the Beta testing is not for you.

Par Grauw

Ascended (10721)

14-11-2021, 20:00

Hi Alexey, I read in the readme:

Quote:

Dual-PSG support was added; when enabled in PSG menu, Carnivore2's PSG is configured to work on ports #10-#11

Can you also provide read support on port #12? This will make software autodetection possible.

(Btw I thought it already had the 2nd PSG feature? I must’ve misremembered.)

Par Pencioner

Scribe (1549)

14-11-2021, 20:17

Grauw wrote:

(Btw I thought it already had the 2nd PSG feature? I must’ve misremembered.)

It was possible to configure PSG on secondary ports previously, but it was single at the time, not dual

I'm thinking about making patch to vgmplay to detect Carnivore via control port added in this firmware, then software autodetection would not need port #12 read feature (and it is easier since the CPLD utilization is near 100% already)

Par Grauw

Ascended (10721)

14-11-2021, 23:10

Pencioner wrote:

I'm thinking about making patch to vgmplay to detect Carnivore via control port added in this firmware, then software autodetection would not need port #12 read feature (and it is easier since the CPLD utilization is near 100% already)

My objection against that is that I don’t want to have detection for every different hardware which all implements the same sound chip but does so incompletely, without the read port that allows VGMPlay to autodetect them universally. VGMPlay memory utilisation also has limits. Only the MFR gets an exception because it’s out there for a long time and users can’t update the FPGA through software.

Out of consideration for the software which enables the use of its features, I wish for a standard way to access and detect the hardware. If every hardware must be separately detected, software will stay fragmented and won’t be able to support future hardware with a PSG.