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 > New life for your underloved datassette unit :D
2021-10-21 02:22
Zibri
Account closed

Registered: May 2020
Posts: 304
New life for your underloved datassette unit :D

The first phase of testing just ended.
(Still in the packaging and refining phase)

But I wish to share with you all my latest accomplishment.

You might want to check this out:
https://twitter.com/zibri/status/1450979434916417540
and this:
https://twitter.com/zibri/status/1450979005117644800

The fastest example (11 kilobit/sec) has the same (or better) error rlsilience as "turbo250" but it is 3 times faster.

The slowest one (8 kilobit/sec) has the same error resilience as the standard commodore slow "save", but it is 100 times faster and twice as fast as turbo250.

;)

Notes:

1) faster speeds are possible if the tape is written with a professional equipment or hi-fi with a stabilized speed and virtually no wobbling.

2) if the tape is emulated (tapuino or similar projects) the speed can go up to 34 kilobit/sec.

3) even with datassette, higher speeds are possible but the highly depend on the status of the tape, the datassette speed and azimuth.
 
... 327 posts hidden. Click here to view all posts....
 
2021-11-14 17:09
Martin Piper

Registered: Nov 2007
Posts: 722
Well that's the point about how and where to use symbols to encode data combined with their relative error rates given the mechanics of the tapes.
2021-11-14 18:07
Zibri
Account closed

Registered: May 2020
Posts: 304
Quote: Well that's the point about how and where to use symbols to encode data combined with their relative error rates given the mechanics of the tapes.

To have the right calcluation of the "turbo" data, just do this:

SUM all values of the pulses leght from start to end of the turbo section.

Then divide that big number by 123156 and you will get the seconds. Then divide total number of bytes and divide by seconds and you will get BYTES/sec then multiply that by 8 and you will get BIT/sec

In other words. if your SUM of all pulses lenghts in the TAP file (turbo section) is "ttime", the formula is:

bit/s = len(data)*985248 / ttime (for PAL)
bit/s = len(data)*1022727 / ttime (for NTSC)

Let's put it this way:
in your case ($20/$40) it's like having a file made all of $30 on average.
you will have $30 * 8 symbols per BYTE in your TAP file.

in a 2 bit encoding instead, you will have half of them :D
let's say in your 2 bit encoding your 4 symbols will be:
$18 $28 $38 $48
that would be the same as having all $30 on average.
in my turbo that encoding is called "24 16"

it's one of the slowest and more error resilent (the best is 24 24)

On a test file (archon exomized) my 24 16 does:

File size: 22073 bytes
bit/s: 5322.25

Note:
even if you would use the same pulse lenghts and encoding, unless your code will have zero jitter, an error resilence as my turbo is NOT achievable.
To remove (conceal) the jitter you must then use a wider bandwidth and slow everying down a notch or two.
2021-11-14 18:42
Zibri
Account closed

Registered: May 2020
Posts: 304
On other news...

One of my testers just made the newest world record with my turbo:

https://twitter.com/zibri/status/1459938649873784833

That's a load at 11534.22 !!!

Written and loaded by the same datassette of course.

This is what a well serviced datassette can really do with the RIGHT software :D

Update!!!
New world record: 12338.79 bit/sec!!! https://twitter.com/zibri/status/1459981517925593097

As of today, my turbo is the fastest turbo ever made.
It succeeded writing and reading back from a normal commodore DATASSETTE, in perfect owrking order and on a good compact cassette.

Probably there is still a chance he will break to 12989.49.
We will see.

Note:
this is just "how fast can he go?" test.
But at lower speeds the reliability is total (more than commodore's own save method)
2021-11-14 21:44
SLC

Registered: Jan 2002
Posts: 52
While cool, this is not so much about the loader anymore, but the process of writing the tape, not to mention the C2N itself. You should at least be honest enough to mention that :)

If I had a C2N capable of writing the short pulses required for this, I'd be at those speeds too. I was experimenting with write precompensation but lost interest when I realized it wasn't transferrable to other C2Ns so just tweaked a bit more for reliability and left it there. As for a reliability test, I was able to load all 108 test games written to a C90 on one C2N and read on another at an average 7000bit/s (exomized files only)
2021-11-14 22:02
soci

Registered: Sep 2003
Posts: 480
Thanks for trying that. I suspected that was the case but couldn't try it at the time.
2021-11-14 22:33
Neo-Rio
Account closed

Registered: Jan 2004
Posts: 63
Making TAPs that can't be even played back on actual cassette is pretty cool though - if there was some way to master TAPs to CD ROM and to use the rainbow arts CD adapter to play them back digitally and without error!
2021-11-14 22:45
SLC

Registered: Jan 2002
Posts: 52
There is. Convert to .wav and burn as audio. Heck, you can even use mp3...
2021-11-15 02:19
Martin Piper

Registered: Nov 2007
Posts: 722
A perfectly (very) reliable C2N that's been very well serviced or calibrated really isn't a good test however. It would be much better to use a standardised test that alters the TAP file bytes to introduce controlled errors and then check, under emulation, that the TAP with errors still loads.

I do this with my TapeTool which can read the TAP, add controlled errors of specific magnitudes, then runs the TAP to check for correct load behaviour. The emulator's remote debugger can be used to check for all the memory being loaded correctly, which also serves as an integration test of the block checksum code.
2021-11-15 03:44
Neo-Rio
Account closed

Registered: Jan 2004
Posts: 63
Oh yeah, I forgot about audiotap.
I think somebody used to sell those cassette adapters with headphone jacks - like what came with the rainbow arts CD - but I don't think we can get them anymore. Shouldn't be too hard to handcraft one if you have the designs though.
2021-11-15 04:27
Zibri
Account closed

Registered: May 2020
Posts: 304
Quoting SLC
While cool, this is not so much about the loader anymore, but the process of writing the tape, not to mention the C2N itself. You should at least be honest enough to mention that :)

What? Sorry, I don't understand what you mean.
The test tap I passed my testers were all writte unsing a STANDARD C2N and read back using the same device.
And those pulses are not as short as I could make them. But it seems that 40 cycles is the minimum gap to use if you want also to write on a C2N. if You use a recorder using a WAV then I can go as little as 24.
Am I missing something?

And I repeat: BOTH the loader AND the writer must be perfect for this to be possible.

What counts more is that I am able to write sucjh a tape now as I could have been able 39 years years ago.
And this was my challenge (with myself).
And the results speak for themselves.
Previous - 1 | ... | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | ... | 34 - 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
Guests online: 85
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 Graphicians
1 Mirage  (9.8)
2 Archmage  (9.7)
3 Pal  (9.6)
4 Carrion  (9.6)
5 Sulevi  (9.6)

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