| Author: | Thierry (registered user: 4 posts ) |
|---|---|---|
| Date: | Mon, Oct 01st, 2012 @ 05:19 ( . ) |
Hello people, recently built XAP cable 1541 and works perfect, the issue is that acquired the Drean Commodore GEOS v1.2 (Spanish), im use the image nibread to record and nibwrite but not had success, what is the correct command line to make an exact copy of the program? from already thank you very much regards From Argentina |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Oct 03rd, 2012 @ 17:22 ( . ) |
Hola amigo. the correct command line is nibread filename.nib after this has been done, you then must conver it to a g64 and load it up in an emulator nibconv filename.nib filename.g64 Hope this helps. |
| Author: | Thierry (registered user: 4 posts ) |
|---|---|---|
| Date: | Thu, Oct 04th, 2012 @ 06:32 ( . ) |
On 10/03/2012 @ 17:22, hyper active wrote :
Hola amigo. : the correct command line is nibread filename.nib : after this has been done, you then must conver it to a g64 and load it up in an emulator : nibconv filename.nib filename.g64 : Hope this helps. -- Thanks for Reply!! I know the GEOS its a special protection in Track 36 , but i dont know to reproduce it , im use nibread to make a backup of the original disk , but when im put the rip image to a new disk no boot in the real hardware , i need to backup to all protection , i think this is one of a only copy exist here .. take a look [link] thankss |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Oct 04th, 2012 @ 08:12 ( . ) |
There has never been anything special about the GEOS protection in the past, so I don't know what to tell you. Every copy I've made in the past has worked. What does the copy do? Does the image work in VICE or not? |
| Author: | Thierry (registered user: 4 posts ) |
|---|---|---|
| Date: | Thu, Oct 04th, 2012 @ 13:19 ( . ) |
Im try to convert to .g64 and .d64 and in the emulator not working ( Vice, Hox, cc64 etc ) , im try to rip in .nib .nb2 and no luck too , im write to real disk but in the real c64 no work , its back to Basic ,the original boot ok im attach a files |
Attachments: |
| 1349371158_Geos Drean 1.2.rar |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, Oct 05th, 2012 @ 22:03 ( . ) |
Hola Thierry. Can you please email me at whocrazy@gmail.com and I'll try to help you get it working. I think I might know what the problem is, or at least, I might know how to fix it. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Oct 09th, 2012 @ 00:51 ( . ) |
Hello. track 36 consists of a long stream of unformatted data, with a small signature near the start of the track. What nibtools rev 571 seems to have done is to break the signature in half. Half of it has been placed at the beginning of the track and the other half has been stuck on the end of it. When you try and run the software, the loader searches track 36 and obviously expects the signature data to be all in one place and it can't find it all, so you'll then get a crash and a system reset. It's also detected tracks 18 through 24 at the wrong density. This means that it would require the use of a speed controller for your drive's motor to properly remaster the data. Writing the nibbled image back to disk with the motor running at 300rpm would mean geos would crash when you tried to load it up, because the data on the incorrectly detected tracks has become mangled and corrupted due to truncation. the old mnib program is able to read and detect tracks 18, 19, 20, 21, 22, 23 and 24 at the right density, and it can also read the signature on track 36, so this means your dumps can be written back to disk without the need for a speed control device. Here is how mnib interprets the data on track 36 |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Oct 09th, 2012 @ 00:54 ( . ) |
Whoops I forgot to attach the file |
Attachments: |
| 1349758492_track36mnib.zip |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Oct 09th, 2012 @ 00:58 ( . ) |
Here is how nibtools v571 interprets the data on track 36 |
Attachments: |
| 1349758701_track36n571.zip |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Oct 09th, 2012 @ 03:45 ( . ) |
Hi again. I have a copy of defender of the crown and track 20 contains 11 bytes of unformatted data. When I try to dump it with the current version of nibtools, it has terrible trouble reading the track, and the signature often gets scrambled, it can take many tries to get a good read of the track. Mnib on the other hand seems to be able to analyze the track more deeply and produce a good working dump on every try. I think something similar has been done with track 36. nibtools rev 571 gets confused and can't make sense of the information because track 36 is mostly unformatted except for the 600 bytes of signature data at the beginning of the track. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Tue, Oct 09th, 2012 @ 10:52 ( . ) |
The reason for the latter is in how it detects density... In the old versions, it measures for data using density 2 on all tracks. This caused many mis-detected densities on standard tracks, so it was changed to measure at the density the track is "supposed" to be. I can change the behavior back, but it will then have the old problem of detecting wrong density on standard tracks, rather than have trouble with protection tracks. DOTC is likely the same problem. I doubt that you can get a good read every time with old version, as I tried it years ago. There are two versions of it, one with an easy track 20 and one with a hard one with much illegal GCR. It was always hit and miss. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Oct 09th, 2012 @ 19:42 ( . ) |
Hi. Perhaps you could make a commandline switch that makes the new nibread operate and/or mimic old mnib,. That way, if you think your images get dumped incorrectly, you could use this switch. you could also have a commandline switch to use older density detection routines. you know that when you change something to fix one problem, it's more likely to break something else and create another problem, so it would probably be better if you made this behaviour optional. btw: I have the hard to read track 20 version of DOTC, which contains 11 bytes of unformatted data in the middle of the track. newer versions of nibtools have a tougher time reading it than mnib does, I just tried running mnib on the disk twice. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Oct 10th, 2012 @ 17:27 ( . ) |
Sometimes when I boot up DOTC on real hardware, it might take as long as 5 seconds for the loader to find the signature on t20. They made it so hard to copy it that even it's own loader has trouble seeking it out. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Nov 04th, 2012 @ 13:35 ( . ) |
I put the old behavior (scan density always at data rate 2). The side effect of this is that density detection only works exactly at 300RPM. If you read disks with your motor slowed to <300, it will detect wrong density for tracks>25 sometimes. Download in usual place. |