Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Disabling AR freeze button
2003-02-20 22:19
6R6

Registered: Feb 2002
Posts: 245
Disabling AR freeze button

Is it possible to disable the Action
Replay freeze function 100% ?

In that case, please enlighten me... :)

 
... 83 posts hidden. Click here to view all posts....
 
2018-10-05 20:51
AlexC

Registered: Jan 2008
Posts: 299
Quote: I still think you can master a tape that will always load but never on emulator. I should maybe give that a try :)

But will you be able to duplicate during manufacturing process? I remember that company duplicating Rubicon tapes had such problems.

Very interesting challenge indeed :)
2018-10-08 03:30
chancer

Registered: Apr 2003
Posts: 347
I'm sure there have been a number of things that have tripped up folk over the years, exile by audigenic comes to mind and more. I guess being subtle about it, instead of "FU you ain't getting it to work" , is a better approach / catches out more folk.
2018-10-08 12:07
chatGPZ

Registered: Dec 2001
Posts: 11386
thats a totally different thing :) but indeed, subtle ingame protections are the only ones that *really* work. (spyro on ps1 comes to mind... what a fucking bitch)
2018-10-08 12:40
oziphantom

Registered: Oct 2014
Posts: 490
or go RA2... everything is fine, 10mins in to a match and every unit and every building just explodes ;)
2018-10-09 14:57
AlexC

Registered: Jan 2008
Posts: 299
Please note that I am not an expert on tape mastering hardware but I wonder did anyone ever did a tape protection scheme that would load on original C64 with stock Datasette but would fail on duplicate done with hardware like Datel Clonemaster?
2018-10-09 16:12
oziphantom

Registered: Oct 2014
Posts: 490
seems they did https://www.lemon64.com/forum/viewtopic.php?t=69305
2018-10-09 18:24
AlexC

Registered: Jan 2008
Posts: 299
Quote: seems they did https://www.lemon64.com/forum/viewtopic.php?t=69305

I've seen this topic but I am not sure it was copy protection issue - I mean it could be one of the possible reasons. I never took a peek into how those devices operate but they must be very simple looking at the PCB.
2018-10-09 18:27
chatGPZ

Registered: Dec 2001
Posts: 11386
with high quality tape decks there is very little you can do about dubbing. the usual problems with dual tape copies were almost all related to phase-inverting and some silly auto-gain stuff. both problems do not exist when using two datasettes (but then, you dont have high quality tape decks..)
2019-01-02 11:35
Highlander (HLD)
Account closed

Registered: Dec 2018
Posts: 3
Quote: even then - you never want to do this. in hardware you always want to do small things in regular intervals, never one huge operation that has to happen "now".

What could work here would be to make the compression format actually be based on a vector of the magnetic phase change information for all tracks, i.e., indicating if a phase change occurs on each given track (or possibly half-track) at each time step. It probably wouldn't compress as well as doing it track-by-track, but I think it would solve the problems that have been raised, in particular, being insensitive to the current bit rate on a given track at a given point in time, and keeping all tracks in sync. It doesn't solve the question of how you acquire the image, but it should at least be implementable in an FPGA easily, and allow regular SD reads to feed it. For writeability, the compression would have to be carefully thought out, so that the compressed size is relatively constant, but the in-memory requirement for the whole disk would at least be solved, assuming you can write to the SD card fast enough, which might be a problem, since 6 complete revolutions per second x ~80 half tracks x ~1MHz sample rate = 480mbit/second (= ~60MiB/second!) raw. Since flux change rates are reasonably low, and limited over a given time period, it should be possible to reduce that figure by some reasonable factor. It might still be impractical. My feeling is that ~1MiB/sec would be required for practicality, which means ~60x compression being required. I'll have to think about the numbers more, as well as what the flux change density is etc, to see if it could be done.
2019-01-02 21:26
chatGPZ

Registered: Dec 2001
Posts: 11386
waste of time imho. just give the device enough RAM and use raw flux pulses.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mike
Derision/Longshot
Case/Padua
rexbeng
Honcho
katon/Lepsi De
Fred/Channel 4
Guests online: 79
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Party Elk 2  (9.6)
4 Cubic Dream  (9.6)
5 Copper Booze  (9.6)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Diskmag Editors
1 Magic  (9.8)
2 hedning  (9.6)
3 Jazzcat  (9.5)
4 Elwix  (9.1)
5 Remix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.048 sec.