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... :)

 
... 90 posts hidden. Click here to view all posts....
 
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
A3/AFL
E$G/HF ⭐ 7
slimeysmine
The Syndrom/TIA/Pret..
Walt/Bonzai
Freeze/Blazon
algorithm
iceout/Avatar/HF
Gildan Jondal/Suicyc..
astaroth/TRSI
wil
Steffan/BOOM!
Copyfault/Extend^tsn..
The MeatBall
Guests online: 95
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 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (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 Original Suppliers
1 Derbyshire Ram  (9.7)
2 Fungus  (9.3)
3 Black Beard  (9.2)
4 Baracuda  (9.2)
5 hedning  (9.1)

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