| |
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. |
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quite impressive, if it's really as reliable as traditional tape turbos or even the very conservative ROM tape routines.
Can you tell a bit more about the new tricks you apparently came up with? Tech details? Is it more than just shorter pulses, like three or even more pulse lengths? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quite impressive, if it's really as reliable as traditional tape turbos or even the very conservative ROM tape routines.
Can you tell a bit more about the new tricks you apparently came up with? Tech details? Is it more than just shorter pulses, like three or even more pulse lengths?
Yep. Exactly. All of the above.
I use 4 (5 with sync) pulses.
I also assign 00 and 11 to the higher frequency pulses so to achieve a sort of compression (00 and 11 are more frequent in an uncompressed file than 01 or 10 so they are assigned higher frequency pulses.. this is done dynamically and change change depending on the file).
And, hear, hear, I don't use timers :D
I found out that on the tape and cia timers there is a better way to create an interrupt:
By putting $4C in $DC0C and $XX in $DC0E and point the irq to $DC0C will make "magic" :D
IRQ will jump to $dc0c (also unlatching our DC0D in the process) and the JUMPS to $XX90 (for tape irq)
so at $XX90 I have my routine which will start exactly 9+3=12 cycles after the pulse.
Note:
the same can be achieved with timer A, B and TOD on both cias :D
I don't know if anyone ever used this method.. In some demos I saw them using an LDA or $04 in dc0c and an RTI in DC0E.
But the jump I came up with is way better.
An example using timers:
After setting up your timers, disabling and latchiong irqs, disabling roms and putting DC0C in $FFFA/FFFF
LDA #$0C
STA $DC0E
LDA #$4C
STA $DC0C
you could put:
70 70 0c 70 70 in (for example) $0C00
which will achieve this:
C00 >> C72 ; ON BRK
C01 >> C0F ; ON Timer A
C02 >> C05 ; ON Timer B
C03 >> C75 ; ON Timer A+B
C04 >> C12 ; ON TOD
The same can be done on CIA#1 :D
Anyway, I didn't use timers at all.
And the turboloader (differently from the others) is cycle accurate and has no jitter thus achieving a perfect accuracy.
Commodore has about 96 cycles separation between their
pulse frequencies. Using the same separation I can achieve 8 kilobit/sec.
But as the program is very accurate, I can use smaller separations, like many turbos do, but since I have no jitter I don't induce errors all programs so far do (including headalign which mainly shows on screen it's own jitter and not the truth). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Studying the datassette I also found out many important notions I didn't know and most people are confused about:
The datassette has TWO important settings: the one everyone knows is the azimuth and there is another one on the motor.
The azimuth:
azimuth is thought to be something "depending on the tape you are reading". That's totally wrong:
there is a right azimuth and a wrong one.
The right one is when the head is perfectly parallel to the TAPE.
With headalign is not easy to get the right setting and I will soon also make a new alignment program.
The second setting involves the way the datassette manages speed.
Tapes are a pain in the ass because their speed changes depending on how far from the start you are recording.
That speed change is compensated and there is a screw on the motor to better fine tune that.
As you can see in the videos, I made the PILOT frequencies in a way that they create stable raster bars.
If you see them unstable it might depend on the rubber belt between the motor and the spindle, but it also might depend on the setting of this screw.
The guy who is tested the program, aligned his datassette on my advice and then set the screw (recorded and replayed my test pilot) until the bars were as stable as possible.
Now his datassette is almost perfect and he go up to 12 kilobit/second (writing+reading with the same datassette).
That speed could go up even more if the tape would be written by a high quality tape deck.
There are a number of possibilities and different settings.
I could set it up in a way that the result will be readable by a datassette but almost impossible to copy for example.
On a MASTER, this turbo can go up to 16kilobit or more (still haven't tested this)
On an EMULATED tape (ultimate2+, tapuino, etc) the turbo can easily go up to 30-34 kilobit/sec :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quite impressive, if it's really as reliable as traditional tape turbos or even the very conservative ROM tape routines.
Can you tell a bit more about the new tricks you apparently came up with? Tech details? Is it more than just shorter pulses, like three or even more pulse lengths?
About the reliability, it depends only on how you set it.
You will be able to set all parameters easily.
But from the tests done so far, with "wide" settings like 96 cycles separation between frequencies, the reliability is the same as commdore's.
And with the same "unreliability" of turbo250, I can achieve twice (or more) it's speed.
As I said we are still in the early testing stages.
The program is still a standalone PRG to be run over a pre-made TAP file (writte to a normal tape using the ultimate2).
In the next weeks, the loader will be included in the tap file.
After that also a save routine will be written.
As of now I didn't do all that because I already changed all the program twice improving stability and speed.
So until I will be totally satisfied with the final code, we will still be testing :D |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"Tapes are a pain in the ass because their speed changes depending on how far from the start you are recording."
AFAIK the tape is dragged near where it is read by a so called "pinch roller" to make it move at constant speed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
correct
(jumping via $dc0d is commonly known as the "ninja method") |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Quote:(including headalign which mainly shows on screen it's own jitter and not the truth).
Does this mean that a new headalign program would be a meaningful task for someone to take on, or are there already alternatives that work as they "should" in this regard? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Nice work Zibri
Just for reference, Thrust64 (Thomas Jentzsch) was using a seven pulse length loader for his own files 'back in the day' that managed a throughput of around 9kbits/s (using pulse lengths of (167+50*n cycles)), though his was only intended for personal use on his own hardware.
It would be interesting to compare how resilient his and yours are in practice. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: "Tapes are a pain in the ass because their speed changes depending on how far from the start you are recording."
AFAIK the tape is dragged near where it is read by a so called "pinch roller" to make it move at constant speed.
Yep.. to reduce the speed variation.
But there is.
Even with that. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Nice work Zibri
Just for reference, Thrust64 (Thomas Jentzsch) was using a seven pulse length loader for his own files 'back in the day' that managed a throughput of around 9kbits/s (using pulse lengths of (167+50*n cycles)), though his was only intended for personal use on his own hardware.
It would be interesting to compare how resilient his and yours are in practice.
what do you mean by "seven pulse length loader" ? |
... 327 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 34 - Next |
