| |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1391 |
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" ? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: 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?
Indeed.
Headlign is a jitter displayer :D
It's code jitters and is totally unstable..
To really understand things I made a C64 "tape to tap" with a resolution of 2,4 or 8 cycles (standard tap file).
And I didn't see so many artifacts as in headalign.
So, indeed a new cycle exact headalign is due...
You can try, but not only you have to use my "irq method" but also be sure the code does not jitter and has even cycles.
Also you must be sure that wehn the IRQ kicks in, the cpu is executing a 2 cycle instruction and not a 3-7 cycle one or it will jitter by that amount.
If anyone wants I can provide the "engine" that get's you the number of cycles of a pulse.
But after that the number should drawn with an even cycle code with no jitter and as short as possible.
Otherwise you won't get the high frequencies.
By my tests, the datassette supports up to 12khz, perhaps a little more.. then the aplifier filter kicks in.
In reality it kicks in at 10khz.. but it has a slow slope.. until 11-12 khz pulse everything is fine... |
| |
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.
hmm 167 + 50*n means a frequency separation of 50 cycles (strange).
That can work but it will be very prone to errors.
In the videos on twitter, the frequency separation is 48 for the fast one (12kilobit/sec) and 96 for the "slow" one (8 kilobit/sec)
As you can see the "slow" one has double the error resilience as the fast one (and Thomas's).
I also tested all other separations. from 32 cycles.. they all work but if you want to be able to WRITE and the READ with a datassette you have to consider a double error.
That leads to a minimum of 40 cycles on a perfect datassette.
48 cycle separation was read 10 times over 10. on a perfect datassette.
If the same file (in wav) is NOT written by a datassette, then also a 32-40 cycle separation will be reliable to read on a datassette and also an intrinsic copy prtotection. Even copying using audio equipment will introduce an error big enough for it not to work anymore :D
Back in the day I would have been rich :/ |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Quoting Zibri...
You can try, but not only you have to use my "irq method" but also be sure the code does not jitter and has even cycles.
... While I do appreciate your effort you have put in to bring the tape topic to new glory I think it's just fair to be careful when it comes to credits. Afaiu your approach is like "Ninja-method goes Tape jitter measuring", so the irq method is definately not yours. This doesn't mean that you copied it from there, I believe you had the idea on you own, but it's just not new.
However, applying this ninja-method to tape measuring hasn't been done before, that I'm pretty sure of.
Have to admit that I still have to sort all the information you give here; currently, the core benefits of this approach are not completely clear to me. Maybe I need more time to find the right path through this;)
What I think to have grasped is the potential to increase tape loading speed. Kudos for the effort, the numbers you tell here are really impressing! |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: what do you mean by "seven pulse length loader" ?
Just as a comparison, with 48 cycles of separation and a starting frequency of 96 cycles (10khz on a pal c64)
my turbo achieves a speed of 11529.61 bit/sec
with a 96 cycles separation (which is as reliable as standard commodore saves) it achieves a speed of 8016.04 bit/sec
With a "sober" 80 cycle separation and 11khz of top "accepted" frequency, it goes at about 9257.72 bit/sec
any combination is possible.
the fastest turbo ever made public was the one used in the (horrible) game "Evil Dead". with the same "unreliability" I can get as high as 12kilobit/sec which is almost 3 times it's speed. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting CopyfaultQuoting Zibri...
You can try, but not only you have to use my "irq method" but also be sure the code does not jitter and has even cycles.
... While I do appreciate your effort you have put in to bring the tape topic to new glory I think it's just fair to be careful when it comes to credits. Afaiu your approach is like "Ninja-method goes Tape jitter measuring", so the irq method is definately not yours. This doesn't mean that you copied it from there, I believe you had the idea on you own, but it's just not new.
However, applying this ninja-method to tape measuring hasn't been done before, that I'm pretty sure of.
Have to admit that I still have to sort all the information you give here; currently, the core benefits of this approach are not completely clear to me. Maybe I need more time to find the right path through this;)
What I think to have grasped is the potential to increase tape loading speed. Kudos for the effort, the numbers you tell here are really impressing!
I never said "nobody did it before", I just said it I made it up and I din't know if it was used or not. But as far as I saw the "ninja method" does not involve a JMP in DC0C but something else.
Which makes it very different because the key is that JMP.
An RTI in DC0E steals too many cycles and needs the stack.
In my turbo I totally trash the stack and don't use it at all. (when needed I restore the tack before jumping to the game start).
I thought about many different implementations of my idea.. using timers or using the JMP in dc0c but still using timers... everything resulted in a longer and way slower code.
I think many people will benefit of this particular IRQ method, expecially in demos.
The advantage is that you start your code exactly at the 12 cycle after the "event" (timer or tape pulse or data from serial or iec).
The IRQ steals 9 cycles (odd) but the JMP is also an odd number.
So you start your code in even cycles. If you keep your code "EVEN" before the IRQ, you'l bee always in perfect sync with no jittering.
Putting instead an RTI in DC0E, requires 9(IRQ)+2(LDA in DC0C)+6(RTI) cycles which is 17 cycles against 12.
Also, not using timers allowed my code to be fast and short.
Timer calculations take cycles.
At the moment in my loader there are always 46 cycles free + 24 cyles 3 times over 4.
Enough for a nice sid tune or some raster effects :D
It's also possible to have the screen on but that would require a different file encoding and little slower throughput. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: correct
(jumping via $dc0d is commonly known as the "ninja method")
I sincerely never heard of it.
But I checked it and it does not do what I do.
I think you refer to put DC0C in the iRQ vector.
That's NOT just what I do.
The difference with my method to the "ninja method" is that I put a JMP in $dc0c
I mean:
lda #$4C
sta $dc0c
lda #$XX
sta $dc0e
and when the irq comes, it first jumps to dc0c and THEN it jumps to XX90 :D
That's what I don't think (I might be wrong) has ever been used. |
| |
Krill
Registered: Apr 2002
Posts: 2871 |
Quoting FranticQuote:(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? Not so sure about that.
The lion's share in jitter production is probably due to tape wobble. Measurement jitter (unstable interrupt-to-ISR latency) adds a bit on top.
Minimising the latter using the Ninja method surely has benefits, but they amount to minimising the already much smaller measurement error. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 34 - Next |
