There was an error with your request

Hello, I'm a new nibtools user. I just built the necessary equipment and started imaging some disks. But there's a big problem here: I'm only able to use nibtools up to version 0.6.4, because versions r508, r511 and r513 all give me this error: "The procedure entry point cbm_parallel_burst_read_track_var could not be located in the dynamic link library binkw32.dll."
I'm aware that I have to download versions labelled for opencbm4 and that's what I did. OpenCBM 0.4.2 is installed and works perfectly. I tried with two different WinXP installations and I always get the aforementioned error. Please help!
Discuss this entry

---

In trying to analyze a number of the other V-Max V2 titles (Infiltrator II, Into the Eagle's Nest, etc), I've noticed that track 20 in the image is typically bad. This is due to the track having no sync marks, bad GCR that causes a loss of framing, and the imaging routine reading the track across these this bad GCR.

A fix for this would be to insert a function in the 1541 drive code for nibread that waits for a certain string of GCR bytes to match before reading the track in. These header bytes could be obtained in 3 ways:

1. The custom protection handlers could provide this string based on what protection was chosen (ie. V-Max V2 = 5A 55 5A FF 37)

2. The autogap function could find the longest string of bytes, then provide that back to the drive code and re-read that track looking for those bytes. A better method would be to move the autogap function into the drive code and just search for the longest string there before reading in the track. This may still read the track in bit-shifted, but at least it's a consistent shift instead of a mix of different ones.

3. The user could supply it on the command line.

Except for #2, these solutions also ensure that the data doesn't read in bit-shifted incorrectly. Not an issue for remastering, but an issue for emulators.

This would also fix the issue with imaging the newer Vorpal disks.
Discuss this entry

---

I'm using nibtools 0.7.2 under Ubuntu Jaunty, with an XAP1541 cable and a 1541-II. I can read a disk OK using nibread, but nibwrite will always hang just after displaying the 'Density 2...' line, pegging the CPU at 100% and allowing no keyboard/mouse response. I've got to alternate between typing 'Ctrl-c' and toggling the drive's power switch several times to terminate the process. While doing this, I get the 'Density 3...' line, and the rest of the output you can see below.

I've tried it with a .nib file and a .g64 file. Any suggestions on what I might try next?


Thanks,
Ernie


ernie@mard:~/cbm/c64/temp$ nibwrite psi5_trading_co_s2[accolade_1986](rl1)(patched).g64

nibwrite - Commodore 1541/1571 disk image 'remastering' tool
(C) 2004-2010 Peter Rittwage
C64 Preservation Project
[link]
Version 0.7.2 (Built Mar 23 2010 19:26:17)



Reading G64 file...
G64: 333744 total bytes = 42 tracks of 7928 bytes each

Successfully loaded G64 file
Drive Version: 73,CBM DOS V2.6 1541,00,00
Drive type: 1541
Bumping...
Initializing
Uploading floppy-side code...
Starting custom drive code...
Passed basic parallel port checks.

Testing track capacity at each density
--------------------------------------------------
Density 0: 6227 6227 (301.11rpm) margin:0
Density 1: 6642 6642 (301.11rpm) margin:0
Density 2: 7117 7117 (301.09rpm) margin:0
Density 3: 7664 7664 (301.11rpm) margin:0
--------------------------------------------------
Drive motor speed average: 301.11 RPM.
Track capacity margin: 4

cc^C 1.0: (3:7715) [rsync:55 ] (7660) [badgcr: 15] (timeout)
^C^C^C^C^CExit requested by user.
Resetting drive...
ernie@mard:~/cbm/c64/temp$
Discuss this entry

---

I'm running into some more instances where 0.8.0 seems to do a better job than later versions (in this case, 0.8.5.)

I actually dropped down to OpenCBM d64copy to grab Planetfall r20 after I got suspicious, tried the nib I got from 085, and it failed in-game $verify. The OpenCBM d64 works correctly, as does the 080 nib converted to g64. Every attempt to use a g64 from 085 fails $verify. The 080 nib works in-game and nibscan confirms it has the same data as the d64copy.

Attached (spread out over a few replies to deal with the 250K attachment limit):

planetfall.nib - nibread 085, fails
planetfall_try2.nib - nibread 085, fails
planetfall.d64 - d64copy, works
planetfall080.nib - nibread 080, works

To test, load game and enter
$verify
at prompt.
Discuss this entry

---

Is it possible to rip 1571-formatted disks (on a 1571, of course)? I don't see anything in the docs about this and I'm reluctant to specify -E70 or whatever and have the heads jam themselves through the wall. I have what I'm pretty sure is a 1571-formatted disk (Clone Machine for 1571)--based on the large quantity of files and the "631 blocks free" reported in the directory listing, I'd say it's 1571 format.

I ripped it as s1/s2 as usual but if there's a better way, let me know.
Discuss this entry

---

I cannot convince nibread to start reading Jordan Vs. Bird: One on One. It consistently hangs on Initializing. This is the only disk exhibiting this behavior.

nibread - Commodore 1541/1571 disk image nibbler
(C) 2004-2010 Peter Rittwage
C64 Preservation Project
[link]
Version 0.8.5 (Built Jul 18 2010 17:30:50)

Drive Version: 73,JIFFYDOS 6.0 1571,00,00
Drive type: 1571
Bumping...
Initializing (sits here for minutes with no activity, spinning the drive but otherwise not making any sound)

Exit requested by user. Uploading floppy-side code...

Resetting drive...

C:nibtools>
Discuss this entry

---

I've mentioned this in some of my recent rip notes to you, but thought it would be a good idea to see if there's anything to discuss out here.

I'm noticing that nibread 0.8.2 has trouble reading high tracks, particularly 30 onward, spitting out numerous errors. Dropping back to 0.8.0 quiets the errors. I also ran into this with the 0.7.x series until the last couple of editions came out.

My ripping environment is:

1571
XAP cable
Windows XP
Discuss this entry

---

Hello there.
when I try to remaster aussie games side 1 and then load the game, the head keeps bumping at random intervals and the game stops loading. It's as if an invisible hand is holding open the drive door for a few seconds, then closing it again.
Sometimes I might be lucky and the game loads without any problems, but most times, the head bumps and the game freezes.
I tried nibwriting side 1 to both sides of the disk, and I get the same result if I flip the disk and try to load up what's on side 2, so I know it's not the disk itself that's failing.
Here is the original nib file of side 1 of aussie games, and here is what I've tried with nibwrite
nibwrite d:ausAussie Games (Side 1).nib
nibwrite -g d:ausAussie Games (Side 1).nib.
Hope you can help.
Discuss this entry

---

I checked out the svn 'trunk', and when I cd there and issue

make -f GNU/Makefile linux

things seem to go smoothly until the script gets to drive.c, when I see

drive.c: In function `test_par_port':
drive.c:116: warning: implicit declaration of function `cbm_parallel_burst_read_n'
drive.c: In function `send_mnib_cmd':
drive.c:392: warning: implicit declaration of function `cbm_parallel_burst_write_n'
make[1]: *** [drive.o] Error 1
make[1]: Leaving directory `/home/ernie/svn/nibtools/trunk'
make: *** [linux] Error 2

I'm no C whiz--but is the compiler just being picky? I'm using Ubuntu Jaunty, which came with gcc-4.3. The NIBTOOLS build script had originally stalled when it couldn't execute 'gcc-3'. First, I made a 'gcc-3' symlink in /usr/bin to gcc-4.3. Then, I tried installing gcc-3.4 and symlinking to that--both versions encounter the 'implicit declaration' errors and stall there.

Any suggestions?
Discuss this entry

---

I was hoping that I lucked out and got a super sturdy drive, but while nibbing some disks, my drive got out of alignment.

I super cleaned the head, greased the rails, etc.

Still nothing.

I got a hold of an ALPS service disk, but it's just a copy of the .prg, and I have read online that copies of alignment disks are fair at best.

It says to put in a reference disk #97....?

It also calls for the use of an oscilliscope, which I don't have (unfortunately).

Luckily, I swapped my parallel modded board into another newer (Mitsumi) drive.

This is working, but from the amount of disks I still have to do, I really need to figure out how to align my drive correctly.

I've read several articles online, but they vary in scope a lot.

Any tips on how keep my drives healthy?

One more question:

Is the 1541-II more reliable? I have a couple of those, and the mod looks pretty easy for the cable. I even found a couple of 40 pin IC sockets so that I could do a fancy job installing the parallel cable.

Discuss this entry

---

Hi,

I just purchased an adapter from nkc electronics that allows you to connect a db25 cable to one end, the commodore drive cable to the other end, and you can use jumpers to select XE1541 or XM1541.

I have this working in opencbm. The problem I'm having is this:

How do I work a parallel cable from the drive into this mix? I don't have a game port. I'm luck to find a box with a parallel port that works... It ended up being and old emachine laptop with WinXP on it.

I have several copy protected disks that I want to archive before they die, and D64copy isn't working for these disks.

Discuss this entry

---

hello,

is there a difference between the dos and the windows version?
i'm using the dos version and this version works fine, but i'm missing some features like network and
windows c64 emulations like hoax, ccs64 and so on...

- regards pcollins


Discuss this entry

---

Okay, I've finally got my cable working. I figured I should report back here what was going on. It turned out to be an intermittent connection on wire 5 of the DIN plug. That's why it was testing okay when not connected to the PC but wasn't working when connected to the PC. Big thanks to Womo, Joe, and Spiro for all their help.

Now on to my question: When imaging some disks I noticed an oddity that I don't remember being discussed on the forums... On some disks I noticed that mnib would mark some of the tracks weak, even on games that I'm sure don't use weak bits. Does that mean the data on the disk is starting to fade or something else? Here's a small snippet of the log from Last Ninja 2 (original disks, of course):

0.5.2 (Built Jan 9 2008 22:27:15)
'nibread lastninja2_1.nib '
Drive Version: 73,CBM DOS V2.6 1541,00,00
Drive type: 1541

18.0: {0: 0/ 0}{1:209/ 0}{2: 46/20}{3: 1/ 0}(2)
CID: 'Q1'
FID: 'AC'

1.0: {0: 0/ 0}{1: 0/ 0}{2: 11/ 0}{3:226/10}(3) 7816 [DOS] (7816)
2.0: {0: 0/ 0}{1: 1/ 0}{2: 12/ 0}{3:224/10}(3) 7817 [DOS] (7817)
3.0: {0: 0/ 0}{1: 0/ 0}{2: 5/ 0}{3:226/10}(3) 7818 [DOS] (7818)
4.0: {0: 0/ 0}{1: 0/ 0}{2: 12/ 0}{3:218/10}(3) 7816 [DOS] (7816)
5.0: {0: 0/ 0}{1: 0/ 0}{2: 14/ 0}{3:238/10}(3) 7816 [DOS] (7816)
6.0: {0: 0/ 0}{1: 0/ 0}{2: 11/ 0}{3:228/10}(3) 7816 [DOS] (weak:2) (7816)
7.0: {0: 0/ 0}{1: 0/ 0}{2: 10/ 0}{3:231/10}(3) 7817 [DOS] (7817)
8.0: {0: 0/ 0}{1: 0/ 0}{2: 9/ 0}{3:208/10}(3) 7817 [DOS] (7817)
9.0: {0: 0/ 0}{1: 0/ 0}{2: 11/ 0}{3:190/10}(3) 7816 [DOS] (7816)
10.0: {0: 0/ 0}{1: 0/ 0}{2: 17/ 0}{3:197/10}(3) 7816 [DOS] (7816)
11.0: {0: 0/ 0}{1: 0/ 0}{2: 10/ 0}{3:210/10}(3) 7816 [DOS] (weak:2) (7816)
12.0: {0: 0/ 0}{1: 0/ 0}{2: 9/ 0}{3:203/10}(3) 7817 [DOS] (weak:2) (7817)

Discuss this entry

---

I have revisited my approach to implementing a successor to the xu1541. I am now experimenting with a prototype board that will support mnib and be a lot cheaper. The goal is to start simple with xu1541 compatibility + mnib support. Then, things like 1541 emulation with a d64 onboard can be added.

No promises yet because things are very early but I should have more time to work on it in April. I just wanted to start this thread to solicit input from Pete, Womo, and others.
Discuss this entry

---

Okay, I finally finished adding a parallel port to my 1541 and made an XMP1541 cable. I remembered that my sons PC has a parallel port so I didn't need to throw a PC together (from old parts) after all. His PC runs Vista.

So I connected the 1541 to his PC and installed OpenCBM under my account (which is the Administrator acct). When I run the command "cbmctrl reset" the 1541 resets as it should. However, when I run any other command, such as "cbmctrl status 8" or "cbmctrl detect" the drive is not recognized. I triple-checked the XMP cable and it is definitely wired correctly. I double-checked my C64 parallel port and everything looks like it's wired correctly. I can't really test it with a multimeter because I put shrink-tubing over the wires at the legs of the chip to make sure they wouldn't touch. But all the wires are soldered to the correct legs of the VIA (U3).

Is there a program I can use that will tell me if the port and cable are wired correctly? Does OpenCBM run in Vista? I was thinking about booting from a FreeDOS CD and running mnib from there but unfortunately it requires a bit of work because of the way the FreeDOS LiveCD is set up. So I figured I would ask here first to see if anyone had some other suggestions first. If I try to run mnib it completely freezes the PC. Here are the errors I get when running some commands in OpenCBM:

C:\NIBTOOLS>cbmctrl status 8
99, driver error,00,00
status: The system cannot find the file specified.

C:\NIBTOOLS>cbmctrl detect

C:\NIBTOOLS>cbmctrl open 8 15 I0
open: The system cannot find the file specified.


Also, I've tested all my originals on a real C64 and fortunately all but one seem to work - ie. they get to the loading screen. The only one that doesn't, as I mentioned before, is Gauntlet. I must have had trouble with that disk in the 80's because I had used my Action Replay cart to snapshot it and had the snapshot on a separate disk. Playing from the snapshot works (using the original disk for levels) and all the files on the disk appear to be fine. It looks like only the protection is messed up. I have to run an error scan on it to make sure, but if nothing else it will help verify one of the other images that are already in the database.

Discuss this entry

---