It is almost impossible to save back .NIB images to real diskettes due to lack of all data in them. Are there any apple2 software titles that are available as NIB images on the net but can be used only with emulators because there are no means to create a physical disks from them?
Anonymous
User login
Please support the defense of Ukraine.
Direct or via Unclutter App
Active forum topics
Recent content
Navigation
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
Well, no - it's almost impossible to save a .nib back to a real disk because of lack of tools. The workflow using SST is laughably difficult; there's dormant code in ADTPro to do it, but it's just not reliable enough to turn on.
A nib image is enough information to give a person skilled in the deprotection arts the ability to make a normalized dsk out of it, if the nib actually houses copy protection to begin with. But one of the most important uses of a nib is to communicate the disk's volume number. That lives in in a sector header - outside of the normal data areas of the disk. Some games used the volume number to tell which disk was inserted at the time, for example. So it doesn't actually help to switch a .nib to a .dsk - unless you initialize the disk with that different volume number first.
Are there many software titles that are available on the net ONLY as NIB images? If yes, then such converter could be useful...So far I am trying to figure out only this...Thanks. I guess that formatting with a specific volume number is only one minor issue with the NIB...Otherwise you would have used the adtpro's format function accordingly. There is a lot to reconstruct in order to recreate a working physical diskette from a NIB image.
I count 789 files on Asimov currently that are .nib. I don't have a way to know (without actually cross-referencing) how many of those don't also have a corresponding normalized crack (and aren't in .nib simply because of the need for a volume number). There may also be more .nibs packed inside of .zip packages, so YMMV.
I'd say that there are fewer and fewer nib-only files out there as deprotectors like Hot Rod, 4am, and others have been very active in recent years normalizing disks, sometimes taking .nibs from Asimov directly and deprotecting those. A potentially more interesting question than these lossy, not particularly useful .nib files is how to integrate support in tools and emulators for a more descriptive "rip" of a disk.
The problem at the heart of all of this is... the standard, Woz-designed Disk II adapter is simply not capable of writing every bit pattern it is capable of reading. Some disks can not be digitized and reconstituted as-is given a standard drive controller.
What controller was used then back in those days to create and duplicate protected diskettes (not speaking about laser holes or other mechanical things? I am able to build the hardware, but I can write software easily only for PCs? Offtopic: most PC serial ports nowadays are capable for speeds like 1Mbit/sec. Do you think it would be useful to make a simple serial port with onboard RAM buffer for apple2 in order to speed-up adtpro? Or, if you reveal the API/hardware layer of LAN cards that adtpro supports I think I could build compatible RS232 card...I found a bug that adtpro has when trying to send a large 32M disk image to PC...
There were plenty of dedicated disk duplicator machines available back in the day that had no particular connection to the Apple II that could duplicate any bit stream. And then there were simple controllers like the EDD+ card that could pass a more-raw data stream back and forth.
Most PCs these days don't have serial ports.
Most of the time is taken up with disk read/writes, not necessarily transmission - which is especially true now that serial can send compressed packets up to 20k at a time. But if you build it, they will come...
All the source code is available on Sourceforge:
http://adtpro.cvs.sourceforge.net/viewvc/adtpro/adtpro/client/src/
The hardware layer for LAN cards is round about here:
http://adtpro.cvs.sourceforge.net/viewvc/adtpro/adtpro/client/src/ip65/drivers/
It's been a while since I sat through a 32M partition... I suppose it's time I do that again.
What exactly cannot be written that can be read? What about IWM that according to specifications is capable of operating with double data rates. Wouldn't this be sufficient to write the data that you say is impossible to be written with an ordinary disk II controller?
More than two zero bytes (at the disk encoded level) in a row. Consult Sather's "Understanding the Apple II," chapter 9.
That's just it... in order to write every possible combination of flux transitions, you need some hardware other than a standard Disk II controller.
And are these consecutive zero BITS (you are wrong ,e.g. they are bits, not bytes!) present in .NIB images that run on an emulator but cannot be saved back to a diskette? I doubt it! This is not the problem...
Well there are several problems around that....:
first raises with manipulated DOS and altered Disk Sync bytes,
next with altered marking bytes to markup begin of data in sector....
another point that also is a trap with even .DSK images is if the drivespeed
has been altered to slower speed to permit more bytes in sector than regular permitted...
not to talk about the cheats wile using half step increments .....
In many such cases ADT will even tell while reading to get the track correct, but will
tell about malfunction when making attept to write back such data if protection hasn´t been cracked....
( i.e. Read O.K. but Write fails )
this is also the reason in former days a emerging bunch of parameter lists
have been distributed by mailboxes for use with Nibbles Away II or with Locksmith 6.0
in sector copy mode with switched sync sector mode or mixing of parameters with
byte copy mode at Central points Copy II Plus.....
in 1986 Nibbles Away II was used in conjunction with a extra parameter Disk,
- for Locksmith 6.0 there have been 2 Disks only with Parameters availiable
- and Copy II plus also was distributed with 2 additional Parameter Disks....
speedyG
Okay. Practical example. In alphabetical order I take the first NIB image which runs in an emulator
http://mirrors.apple2.org.za/ftp.apple.asimov.net/images/games/action/Alcazar%20The%20Forgotten%20Fortress.nib
1. What can be done to use it on a real apple?
2. How can it be saved back to diskette? Even with non-standard hardware?
3. Where can I get a good description of the .NDO/.NIB format?
Hello Georgel,
first of all it´s nearly 30 years ago, that i have been tinkering around with
CPSII, Locksmith 6.0, Nibbles Away II and a Crackshot....
so first question is about your target:
if you just want to play the game from a real disk and create it with ADT from a .DSK image -
well then i´ve i´ve uploaded 2 images to my site that will fit such need:
http://www.appleii-box.de/applefritter/AlcazarCrDJ.dsk
is the .DSK image from the cracked version from Disk Jockey....
and:
http://www.appleii-box.de/applefritter/AlcazarFromCrackshot.dsk
is a .DSK image from a version taken from original disk with a crackshot and
afterwards saved as binary file to a DOS 3.3 Disk....
At the moment i´m too busy with other tasks and i´ve also lost interest
in tinkering around with you like in previous threads....
therefor just some brief points for short besides the explenations given above by David:
Use Ciderpress in Sector Editor Mode to open the .NIB file...
if you start examining the disk with DOS 3.3 view mode the starting tracks from 0 to 7 look well
- but the moment you switch to track 8 the display will show only junk ( empty space )....
to get a visible display again you will have to switch to RDOS view.
This indicates that Alcazar is using a manipulated DOS with altered Headers.....
in such cases often also a switching from 16 sectors to 13 sectors was common behaviour...
( similar like at Broderbund protection switching to 18 sectors )
like David explained :
there is no simple way to "convert" a .NIB to a .DSK format...
the main reason is that no disk-emulation will permit tinkering around with drivespeed and halfsteps etc.
and if nobody will add a emulation of the crackshotcard to the existing emulations, that
would permit to generate a BSAVE of a file in memory to a general DOS 3.3 Disk there will be no other way
to score a "homerun" without taking seat with the original disk and 2 real drives and
tinkering around with the above named copy programs or using a wildcard or a crackshot card
- unless you get a break within the emulation after loading the image from .NIB and change the disk in the emulation to a empty .DSK image and start by yourself to examine in monitor-mode the memory and save from monitor your
memory content to the .DSK image ( in other words doing same thing like the crackshot or the wildcard by
manual task.... )
As explained above i´m at the moment too busy to "dive" in my storage an search for the documentation
about the .NIB specs.... in such case i´d recommend to spend some time with searchmachines ( not only google )
and hunt a bit at the wayback machine....
if i stumble across the .NIB specs within next wintertime i´ll pick it up and scan it
and publish it in my site..... unless someone else puts up here a link...
have a nice day
speedyG
1. It is not of course, only for one game, the question is general.
2. I understood so far that NIB format omits trailing couples of zero bits in sync "bytes", e.g. stores only first 8 bits. Therefore it is very hard to reconstruct these sync bytes since they are needed on magnetic media. On the other hand some floppy drive emulators are doing some reconstruction of this kind in order to work.
3. I also learned that this probably is wrong:
On the contrary, you can write anything, but cannot read everything easily like exactly those trailing zeros of the sync bytes. That's why EDD board was invented to read raw bitstream.
4. The track of a NIB image is exactly 1A00h bytes long which is more than any physical diskette in DISK II drive can store on a track. Depending on how the NIB image was created the duplicating info could be stripped. This could be done easily...The restoration of the sync bytes is quite difficult. Whoever created the .NIB file format was to be blamed about the missing info in it...
I found a good discussion about it here:
https://groups.google.com/forum/#!topic/comp.sys.apple2/xL8LnzheJQM
This video came out on youtube yesterday and it may contain information that can be used to shed some light on this subject:
https://www.youtube.com/watch?v=4EE7Bee5V44