Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Commodore » Commodore Emulation » Re: Bounty Bob Strikes Back
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Bounty Bob Strikes Back [message #143250 is a reply to message #143247] Sat, 04 November 2006 06:44 Go to previous messageGo to next message
Wolfgang Moser is currently offline  Wolfgang Moser
Messages: 632
Registered: July 2003
Karma: 0
Senior Member
Hello Pete,

Pete Rittwage schrieb:
> Wolfgang Moser wrote:
>> Hello bluebirdpod, you wrote about Bounty Strikes Back! [BBSB!]:
>>>
>>> This is the only UNCOPIABLE program on earth for the Commodore 64,
>> [...]
>> I'm sure that Pete will keep informing us, when he
>> got down to it.
>
> Well, I've analyzed it tonight and Bounty Bob definitely uses true
> halftrack protection.

This is absolutely great news. Whenever you, others and me
discussed about protection systems, either in c.[s|e].c,
emulator/transfer related mailing lists or some forums, we
often used the "halftrack-protection" scheme as argument.

While a halftrack based protection could not be watched in
C64PP until now, BBSB! is a first.

> I rewrote n2g and got halftrack support working properly
> and it now loads further than it did before. It reads about
> 4 segments, then moves to track 1.5 and then freezes.
>
> The disk appears to be mastered such that 1/2 of the track is written
> out, then the head is stepped out one halftrack and the other 1/2 is
> written, etc. This is similar to the "Spiradisk" protection on the
> Apple ][, just not quite as extreme (the Apple could do quarter-tracks).

Pete, you made my day! Yiiieeehaaah! Let me take that as
some sort of "soft proof" that Spiradisk truely does exist
on a C64. Why, you may ask.

Even if the 1541 cannot write to quarter-tracks, here a
technique of writing to the disk while the head is moved
could have been used. This then may _look_like_ the data
you are actually reading from BBSB!. You told me that,
when writing to halftracks, the written data "bleeds" to
neighbored halftracks. Sometimes it bleeds to the lower
halftrack only, sometimes to the upper one.
So, if the track is moved from one halftrack to another
_while_ data is written to the disk, there sometime
comes the moment where the head is on a quarter-track
even on a 1541. Here the data for sure bleeds to both
halftracks that enclose the current (virtual) quarter-
track.
When reading back, due to the "bleeding" and some other
effects, we may not be able to decide, if the both
halftracks were written in pieces of 1/2 half track
round each, or if the pattern was created with a
continuous method with writing while the head moves
(what at least I do call Spiradisk on a 1541).

> So we're getting somewhere for use in emulators, anyway.

Uh, oh, hopefully the emulator authors will not have to
expand their drive emulations to support this scheme.

> It can't be copied without a completely custom routine.

Hmmm, .... how could this protection be described in
a general manner in image formats like G64. I don't
see a way to tell in a G64 that "half of a track round
should not be written at all". We would overwrite the
direct halftrack neighbors through "data bleeding"
(better explained by the tunnel erase R/W heads used in
disk drives), if writing is not completely disabled for
half a track round.
And for true Spiradisk, writing data while the head
moves... I always used that as worst-case szenario for
explaining the limits of G64. It can't described low
level data formatted this way.

For only storing BBSB! G64 is sufficient I believe
since the G64 file format _itself_ does not "support"
that data bleeding effect, for each halftrack it
plays back, what was recorded. When reading data areas
where nothing was written to, it results in a stream
of 0-bits (beside some "random" effects of the 1541
deserializer). But there is a G64 data representation
missing that tells a write routine to not write back
any data for some time.

A practical solution may be to introduce some switches
to tell the writing routine to interprete any 0-bit-
sequences as "don't write" commands or such.


Furthermore precise timing would be needed to adjust
the second half of the 1/2 track round pieces. Hmmm..
An IHS (index hole sensor) could help with adjusting
the data, if an algorithm like the following would be
used:

1. write the 1/2 track round data with the offset

* wait for the IHS pulse
* write ~3150 0x00 bytes as dummy for
counting a decent distance (1/2 half track
round with a given bitrate)
* write the actual 1/2 half track round data
block

2. step to the other halftrack (either up or down)

3. write the 1/2 track round data without offset

* wait for the IHS pulse
* write out the ~3150 data bytes for the
1/2 half track round for this halftrack
* switch to read mode

4. verify _both_ written tracks, repeat at 1, if
needed

By writing the track half with the offset _first_ we
can adjust the "distance" from the IHS pulse very
precisely by byte counting. It shouldn't matter that
data bleeding (tunnel erasing) from the next written
halftrack destroys the written 0x00 bytecount bytes.


Womo
Re: Bounty Bob Strikes Back [message #143252 is a reply to message #143250] Sat, 04 November 2006 08:55 Go to previous messageGo to next message
Pete Rittwage is currently offline  Pete Rittwage
Messages: 444
Registered: March 2005
Karma: 0
Senior Member
Wolfgang Moser wrote:
> Hello Pete,
>
> Pete Rittwage schrieb:
>> Wolfgang Moser wrote:
>>> Hello bluebirdpod, you wrote about Bounty Strikes Back! [BBSB!]:
>>>>
>>>> This is the only UNCOPIABLE program on earth for the Commodore 64,
>>> [...]
>>> I'm sure that Pete will keep informing us, when he
>>> got down to it.
>>
>> Well, I've analyzed it tonight and Bounty Bob definitely uses true
>> halftrack protection.
>
> This is absolutely great news. Whenever you, others and me
> discussed about protection systems, either in c.[s|e].c,
> emulator/transfer related mailing lists or some forums, we
> often used the "halftrack-protection" scheme as argument.
>
> While a halftrack based protection could not be watched in
> C64PP until now, BBSB! is a first.
>

Yep- now we just need to find one with the fabled "laser hole" and we'll
have them all. :)

>> The disk appears to be mastered such that 1/2 of the track is written
>> out, then the head is stepped out one halftrack and the other 1/2 is
>> written, etc. This is similar to the "Spiradisk" protection on the
>> Apple ][, just not quite as extreme (the Apple could do quarter-tracks).
>
> Pete, you made my day! Yiiieeehaaah! Let me take that as
> some sort of "soft proof" that Spiradisk truely does exist
> on a C64. Why, you may ask.
>
> Even if the 1541 cannot write to quarter-tracks, here a
> technique of writing to the disk while the head is moved
> could have been used. This then may _look_like_ the data
> you are actually reading from BBSB!. You told me that,
> when writing to halftracks, the written data "bleeds" to
> neighbored halftracks. Sometimes it bleeds to the lower
> halftrack only, sometimes to the upper one.
> So, if the track is moved from one halftrack to another
> _while_ data is written to the disk, there sometime
> comes the moment where the head is on a quarter-track
> even on a 1541. Here the data for sure bleeds to both
> halftracks that enclose the current (virtual) quarter-
> track.

That is true, but that would seem nearly impossible to read accurately,
since both the spindle and the stepper motor would have to have exactly
the same speed as the mastering drive so it would stay "on the track".
Since SuperCard+ can reproduce this protection (allegedly) then it must
be simpler than first glance. I can't do a skew analysis since there's
no sector0, but if I had to create this protection, I would probably do
it by using a drive with an IHS like you describe.

> Uh, oh, hopefully the emulator authors will not have to
> expand their drive emulations to support this scheme.

We shouldn't. I'm confused as to why the emulation locks up reading
1.5, but I could have some error in my G64 creation still.

>
>> It can't be copied without a completely custom routine.
>
> Hmmm, .... how could this protection be described in
> a general manner in image formats like G64. I don't
> see a way to tell in a G64 that "half of a track round
> should not be written at all". We would overwrite the
> direct halftrack neighbors through "data bleeding"
> (better explained by the tunnel erase R/W heads used in
> disk drives), if writing is not completely disabled for
> half a track round.
> And for true Spiradisk, writing data while the head
> moves... I always used that as worst-case szenario for
> explaining the limits of G64. It can't described low
> level data formatted this way.

Not unless we write some new file format (or expand existing) where the
exact head position is constantly encoded within the data stream. :)


> For only storing BBSB! G64 is sufficient I believe
> since the G64 file format _itself_ does not "support"
> that data bleeding effect, for each halftrack it
> plays back, what was recorded. When reading data areas
> where nothing was written to, it results in a stream
> of 0-bits (beside some "random" effects of the 1541
> deserializer). But there is a G64 data representation
> missing that tells a write routine to not write back
> any data for some time.
>
> A practical solution may be to introduce some switches
> to tell the writing routine to interprete any 0-bit-
> sequences as "don't write" commands or such.
>
>
> Furthermore precise timing would be needed to adjust
> the second half of the 1/2 track round pieces. Hmmm..
> An IHS (index hole sensor) could help with adjusting
> the data, if an algorithm like the following would be
> used:
>
> 1. write the 1/2 track round data with the offset
>
> * wait for the IHS pulse
> * write ~3150 0x00 bytes as dummy for
> counting a decent distance (1/2 half track
> round with a given bitrate)
> * write the actual 1/2 half track round data
> block
>
> 2. step to the other halftrack (either up or down)
>
> 3. write the 1/2 track round data without offset
>
> * wait for the IHS pulse
> * write out the ~3150 data bytes for the
> 1/2 half track round for this halftrack
> * switch to read mode
>
> 4. verify _both_ written tracks, repeat at 1, if
> needed
>
> By writing the track half with the offset _first_ we
> can adjust the "distance" from the IHS pulse very
> precisely by byte counting. It shouldn't matter that
> data bleeding (tunnel erasing) from the next written
> halftrack destroys the written 0x00 bytecount bytes.

I bet this is how the disk was mastered. There are large weak bit
sequences on each halftrack of the original disk.

-
Pete Rittwage
http://rittwage.com

C64 Preservation Project
http://c64preservation.com
Re: Bounty Bob Strikes Back [message #143253 is a reply to message #143252] Sat, 04 November 2006 11:15 Go to previous messageGo to next message
Wolfgang Moser is currently offline  Wolfgang Moser
Messages: 632
Registered: July 2003
Karma: 0
Senior Member
Hi,

Pete Rittwage schrieb:
> Wolfgang Moser wrote:
>>
>> While a halftrack based protection could not be watched in
>> C64PP until now, BBSB! is a first.
>
> Yep- now we just need to find one with the fabled "laser hole" and we'll
> have them all. :)

:-)

>> [mastering Spiradisk]
>> Even if the 1541 cannot write to quarter-tracks, here a
>> technique of writing to the disk while the head is moved
>> could have been used. This then may _look_like_ the data
>> you are actually reading from BBSB!. You told me that,
>> when writing to halftracks, the written data "bleeds" to
>> neighbored halftracks. [...]
>
> That is true, but that would seem nearly impossible to read accurately,
> since both the spindle and the stepper motor would have to have exactly
> the same speed as the mastering drive so it would stay "on the track".

Hmmm, hmmm, .... with the bleeding/diffusion effect
of magnetization in mind, I'm not that sure that
this sort of high accuracy really would be needed.

It's a matter of how tough the protection was
adjusted to check for decent parameters. The more
tough, the higher the risk that it doesn't work on
some bad aligned disk drive with a factory produced
disk.

> Since SuperCard+ can reproduce this protection (allegedly) then it must
> be simpler than first glance.

That's true; as long as the very same effects on
reading back a disk can be simulated with a copy,
the protection does recognize that it's no original.

> I can't do a skew analysis since there's
> no sector0, but if I had to create this protection, I would probably do
> it by using a drive with an IHS like you describe.

I would have told you to use the parameter "-c" along
with cbmrpm41 to select another sector number, but I
saw from the logs that on halftracks 1.0 to 16.5,
there is no single standard DOS sector on it.

>> Uh, oh, hopefully the emulator authors will not have to
>> expand their drive emulations to support this scheme.
>
> We shouldn't. I'm confused as to why the emulation locks up reading
> 1.5, but I could have some error in my G64 creation still.
>
>> [...]
>> And for true Spiradisk, writing data while the head
>> moves... I always used that as worst-case szenario for
>> explaining the limits of G64. It can't described low
>> level data formatted this way.
>
> Not unless we write some new file format (or expand existing) where the
> exact head position is constantly encoded within the data stream. :)

This would need many boring discussions until the top
notch emulation authors as well as conversion and
transfer software programmers may agree on an extension
to G64. There're one or two other issues that could be
improved, but I still vote for collecting more titles
until we start such a discussion.
Having a couple of exceptions that are too difficult
or impossible to image with G64, we may find a generic
extension to handle most if not all of these exceptions
with only one or too extensions. It would be much more
clever to extend the G64 that way instead of
introducing an extension for each little exception that
cannot be handled otherwise.


> [assumpted Spiradisk writing scheme]
>> By writing the track half with the offset _first_ we
>> can adjust the "distance" from the IHS pulse very
>> precisely by byte counting. It shouldn't matter that
>> data bleeding (tunnel erasing) from the next written
>> halftrack destroys the written 0x00 bytecount bytes.
>
> I bet this is how the disk was mastered. There are large weak bit
> sequences on each halftrack of the original disk.

Maybe, we cannot detect, if we read weak bits because
of the track was actually written with 0x00 bytes or
if it was _not_written_ and left unformatted/erased.

You would need to read out that track with a hall
sensor (giant magneto-resitive R/W head, GMR) to see,
if the surface is polarized to a constant direction
or not polarized (and irregular enough to not beeing
detected as 0xFF SYNC bytes).



Womo
Re: Bounty Bob Strikes Back [message #143532 is a reply to message #143253] Fri, 29 December 2006 12:52 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jimdrew

>> Since SuperCard+ can reproduce this protection (allegedly) then it must
>> be simpler than first glance.

I spent a month on this one program! It requires a special copier just
for it, which does in fact duplicate the true 1/2 tracks. There is a
LOT of head stepping (back and forth) necessary to duplicate that disk.
You have to pre-format the normal tracks before you write the half
tracks from what I remember. The data is spaced like this:

1.0 ---------------***************
1.5 ************-------------------
2.0 ---------------***************
2.5 ************-------------------

The margin of error is extremely small. The original program would
load data, step the head and expect to find the next valid sync mark
within 'x' number of bytes. If it wasn't there, it would retry over
and over. In the copier, I wrote code that is similar to what they use
in the original program and test each track and half-track after it is
copied and repeat the copy if it doesn't pass. Fortunately, the amount
of data was really small for this program. We would have been really
screwed if they usd all of each half-track and had long tracks to boot!

In the last week, I have been hounded by C64 people to provide
information about copy protection due to some C64 emulator(s)? that are
trying to support original GCR/MFM images. What someone needs to do is
write a track dump program to a D64 type image. I might do this. I
just went to my warehouse and found all of the THOUSANDS of C64
products (SuperCards, parameter disks, books, ROM boards, etc.) that I
still have, along with source code and master disks for all of the UUI
products and Copy ][64/128 (which I also wrote). I may throw some of
this hardware up on eBay and clean out the warehoue.
Re: Bounty Bob Strikes Back [message #143534 is a reply to message #143532] Fri, 29 December 2006 23:24 Go to previous messageGo to next message
Pete Rittwage is currently offline  Pete Rittwage
Messages: 444
Registered: March 2005
Karma: 0
Senior Member
jimdrew@frontiernet.net wrote:
> In the last week, I have been hounded by C64 people to provide
> information about copy protection due to some C64 emulator(s)? that are
> trying to support original GCR/MFM images. What someone needs to do is
> write a track dump program to a D64 type image. I might do this. I
> just went to my warehouse and found all of the THOUSANDS of C64
> products (SuperCards, parameter disks, books, ROM boards, etc.) that I
> still have, along with source code and master disks for all of the UUI
> products and Copy ][64/128 (which I also wrote). I may throw some of
> this hardware up on eBay and clean out the warehoue.

The track dumping is already worked out, but maybe you have better ideas
on how it could be done on stock hardware? My MNIB program requires the
parallel port connection to the VIA or 8k extra RAM (original
SuperCard style) so that a whole track can be read at once. These can
be converted to G64 and 99% of games run fine with full protection.

There has been talk about breaking it up and stitching it back together
on the PC, but nobody has shown any code to do so.

It would be great to see your old notes and source for your old stuff if
you are going to sell it.

--
-
Pete Rittwage
http://rittwage.com

C64 Preservation Project
http://c64preservation.com
Re: Bounty Bob Strikes Back [message #143536 is a reply to message #143534] Sat, 30 December 2006 12:49 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jimdrew

Pete Rittwage wrote:

> The track dumping is already worked out, but maybe you have better ideas
> on how it could be done on stock hardware? My MNIB program requires the
> parallel port connection to the VIA or 8k extra RAM (original
> SuperCard style) so that a whole track can be read at once. These can
> be converted to G64 and 99% of games run fine with full protection.

How acurate is the CPU clock in the 1541/1571 emulation. I do know
that MANY of the nasty protected games are extremely timing sensitive.
I also know that my own code is that way as well, especially when
spooling GCR data directly from the head. I don't need to look at sync
marks. I figured out a way to clock the data without doing that, but
it relys on a perfect CPU speed, and I had seen some of the 1541-IIs
have a slightly higher than normal CPU speed, like the oscillator parts
were a different brand or tolerence. Also, the sync separator
emulation circuitry would have to be dead on.

What programs will not load? Perhaps I can help determine why.


> There has been talk about breaking it up and stitching it back together
> on the PC, but nobody has shown any code to do so.
>
> It would be great to see your old notes and source for your old stuff if
> you are going to sell it.

I am not sure what I will do with the source code. I have actually had
offers to buy it and the master disks, and rights to all of the
products. Is there really THAT big of an interest in this stuff again?
Re: Bounty Bob Strikes Back [message #143537 is a reply to message #143536] Sat, 30 December 2006 15:39 Go to previous messageGo to next message
Pete Rittwage is currently offline  Pete Rittwage
Messages: 444
Registered: March 2005
Karma: 0
Senior Member
jimdrew@frontiernet.net wrote:
> Pete Rittwage wrote:
>
>> The track dumping is already worked out, but maybe you have better ideas
>> on how it could be done on stock hardware? My MNIB program requires the
>> parallel port connection to the VIA or 8k extra RAM (original
>> SuperCard style) so that a whole track can be read at once. These can
>> be converted to G64 and 99% of games run fine with full protection.
>
> How acurate is the CPU clock in the 1541/1571 emulation. I do know
> that MANY of the nasty protected games are extremely timing sensitive.
> I also know that my own code is that way as well, especially when
> spooling GCR data directly from the head. I don't need to look at sync
> marks. I figured out a way to clock the data without doing that, but
> it relys on a perfect CPU speed, and I had seen some of the 1541-IIs
> have a slightly higher than normal CPU speed, like the oscillator parts
> were a different brand or tolerence. Also, the sync separator
> emulation circuitry would have to be dead on.
>
> What programs will not load? Perhaps I can help determine why.
>

Hi Jim,

There are a few scattered instances of protections that won't load, but
the one that still sticks out most obviously is RAPIDLOK. We can remove
the track 36 key check, but some games still fail on a track sync check.

Also, some earlier (V2) V-MAX! games still check for something past the
long tracks and track 20 loader. Defender of the Crown side 2 for
example, and the original Star Rank Boxing. Remember anything about those?


--
-
Pete Rittwage
http://rittwage.com

C64 Preservation Project
http://c64preservation.com
Re: Bounty Bob Strikes Back [message #143538 is a reply to message #143537] Sat, 30 December 2006 16:31 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jimdrew

Pete Rittwage wrote:

> There are a few scattered instances of protections that won't load, but
> the one that still sticks out most obviously is RAPIDLOK. We can remove
> the track 36 key check, but some games still fail on a track sync check.

RapidLock is one of those that requires precision everything. To
DUPLICATE (not copy mosly and crack the rest as most parameter copiers
did) the protection, you need to use an index hole and line the tracks
up. How do you guys deal with rotational speed and such with the
emulated GCR images? RapidLock expects to find data within a few
milliseconds of a successful head step, which is why some drives don't
load RapidLock until you clean the head rails!

It sounds like to me the reason why RapidLock and Bounty Bob won't load
is that there is no simulation of the rotatiing disk. Do you simulate
the head step time? These are really crucial requirements if you want
everything to work.


> Also, some earlier (V2) V-MAX! games still check for something past the
> long tracks and track 20 loader. Defender of the Crown side 2 for
> example, and the original Star Rank Boxing. Remember anything about those?

Wow.. these were the first of the long track stuff. From what I
recall, you just needed to slow down the drive to copy these. The
first SuperCard (before the plus model) copied these just fine, so they
can't be using track to track timing or anything.

Where can I find these emulations that work with the drive? Is this
done under a GPL? I would be interested in looking at this and helping
resolve the issue.
Re: Bounty Bob Strikes Back [message #143539 is a reply to message #143538] Sat, 30 December 2006 20:06 Go to previous messageGo to next message
Pete Rittwage is currently offline  Pete Rittwage
Messages: 444
Registered: March 2005
Karma: 0
Senior Member
jimdrew@frontiernet.net wrote:
> Pete Rittwage wrote:
>
>> There are a few scattered instances of protections that won't load, but
>> the one that still sticks out most obviously is RAPIDLOK. We can remove
>> the track 36 key check, but some games still fail on a track sync check.
>
> RapidLock is one of those that requires precision everything. To
> DUPLICATE (not copy mosly and crack the rest as most parameter copiers
> did) the protection, you need to use an index hole and line the tracks
> up. How do you guys deal with rotational speed and such with the
> emulated GCR images? RapidLock expects to find data within a few
> milliseconds of a successful head step, which is why some drives don't
> load RapidLock until you clean the head rails!
>
> It sounds like to me the reason why RapidLock and Bounty Bob won't load
> is that there is no simulation of the rotatiing disk. Do you simulate
> the head step time? These are really crucial requirements if you want
> everything to work.
>

Nope, you are spot on. There isn't any simulation of the exact timings,
as far as I know. At least in VICE, the disk routines are being
rewritten so that may change in the future.

There is another emulator called HOXS that is said to be closer, but I
don't have as much luck with that one. For openers, it emulates a PAL
64 only.

--
-
Pete Rittwage
http://rittwage.com

C64 Preservation Project
http://c64preservation.com
Re: Bounty Bob Strikes Back [message #143541 is a reply to message #143536] Sun, 31 December 2006 17:23 Go to previous messageGo to next message
Jerry Kurtz is currently offline  Jerry Kurtz
Messages: 244
Registered: June 2012
Karma: 0
Senior Member
jimdrew@frontiernet.net wrote:

> I am not sure what I will do with the source code. I have actually had
> offers to buy it and the master disks, and rights to all of the
> products. Is there really THAT big of an interest in this stuff again?

There is some interest in this stuff, but not enough where you could
sell thousands of pieces of any given item.
Re: Bounty Bob Strikes Back [message #143555 is a reply to message #143539] Tue, 02 January 2007 17:33 Go to previous messageGo to next message
David Horrocks is currently offline  David Horrocks
Messages: 34
Registered: December 2012
Karma: 0
Member
"Pete Rittwage" <rcade@rittwage.com> wrote in message
news:45970D22.8020509@rittwage.com...
> jimdrew@frontiernet.net wrote:
>> Pete Rittwage wrote:
>>
>>> There are a few scattered instances of protections that won't load, but
>>> the one that still sticks out most obviously is RAPIDLOK. We can remove
>>> the track 36 key check, but some games still fail on a track sync check.
>>
>> RapidLock is one of those that requires precision everything. To
>> DUPLICATE (not copy mosly and crack the rest as most parameter copiers
>> did) the protection, you need to use an index hole and line the tracks
>> up. How do you guys deal with rotational speed and such with the
>> emulated GCR images? RapidLock expects to find data within a few
>> milliseconds of a successful head step, which is why some drives don't
>> load RapidLock until you clean the head rails!

In Hoxs64, the 1541 disk emulation allows the disk head to step from one
half track to the next half track in one clock cycle (one millionth of a
second). This is probably way to quick. I don't know what a real 1541 drive
does if you try to step the disk head serveral tracks too quickly. My guess
is the drive will miss some steps. But it is hard to see how reliable data
can be read while the head is in transist. Does RAPIDLOK expect the previous
track to be readable for a short time whilst the head is in transit? In
Hoxs64, the new track becomes readable and the prevous track becomes not
readable immediately after the controller receives the step command. Are
there any disks images that are failing to load due to suspect step timing?

David

>> It sounds like to me the reason why RapidLock and Bounty Bob won't load
>> is that there is no simulation of the rotatiing disk. Do you simulate
>> the head step time? These are really crucial requirements if you want
>> everything to work.
>>
>
> Nope, you are spot on. There isn't any simulation of the exact timings,
> as far as I know. At least in VICE, the disk routines are being rewritten
> so that may change in the future.

> There is another emulator called HOXS that is said to be closer, but I
> don't have as much luck with that one. For openers, it emulates a PAL 64
> only.

I should look at NTSC. Its has not been a priority for me as the vast
majority of my metal banging software collection is for PAL. Is missing NTSC
the only reason for having problems loading copy protected images?

David
Re: Bounty Bob Strikes Back [message #143557 is a reply to message #143555] Tue, 02 January 2007 20:36 Go to previous message
Pete Rittwage is currently offline  Pete Rittwage
Messages: 444
Registered: March 2005
Karma: 0
Senior Member
David Horrocks wrote:
>> There is another emulator called HOXS that is said to be closer, but I
>> don't have as much luck with that one. For openers, it emulates a PAL 64
>> only.
>
> I should look at NTSC. Its has not been a priority for me as the vast
> majority of my metal banging software collection is for PAL. Is missing NTSC
> the only reason for having problems loading copy protected images?
>
> David
>
>

Most (but not all) of my Rapidlok-protected images are in NTSC. Most of
the disks that I actually get sent to image are NTSC, while of course
most of the ones that others donate are PAL.

It would help and be greatly appreciated- I'm not sure how easy it'd be
to do in your emulator.

--
-
Pete Rittwage
C64 Preservation Project
http://c64preservation.com
Pages (2): [ «    1  2]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: How to create CPM disks
Next Topic: MNIB / C64 Preservation
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 13:46:53 EDT 2024

Total time taken to generate the page: 0.10649 seconds