| |
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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting ZibriSorry but that's just wrong.
First (and again): this is NOT the ninja method.
... Yes, you are right. Please take my apollogies to have brought this up in the first place.
But: there *is* a strong parallel in using appropriate IO regs as a jump vector, by cleverly placing a JMP instruction in a suitable IO register.
Quoting Zibrifor the tape (or timers) you only neeed DC0D.
a JMP instruction in DC0C will unlatch the IRQ (4 cycles saved) and then jmp immediately to DIFFERENT locations depending on the IRQ received.
Example:
lda #$4c
sta $dc0c
lda #$0a
sta $dc0e
Now.. a BRK will cause a jump to $A00
a pulse from tape will cause a jump to $A90
and with timers irq on there will be jumps to:
A01
A02
A03
A04
A05... etc etc
so it makes possible with the right code at $A00
to jump to different locations in your code without even having to check which irq happened.
That I call a HUGE advantage and I never saw that used anywhere in this way. Ok, this post made it clear to me. Thanks! Though I think it might cause problems when having both Timer A and Timer B active, since the routine that will be jumped to is the same, just with one byte offset. Using DC0D as hi-byte of the JMP is not doable, right? Would need a TOD-register with Bits 5/6 active I guess...
Quoting KrillThe JMP saves a few cycles on IRQ dispatch, minimising overall execution time per pulse.
But most of the measurement error would come from unstable ISR latency, i.e. whatever opcode was executing when the interrupt triggered would delay handling it by a variable amount of cycles.
Do you correct for that somehow? If understood this correctly there's no dejittering going on... but..
what about chaining the ninja-method (here I really mean the real dejittering method Ninja came up with long ago) and then jumping to $dc0c which'd handle the different IRQ causes? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: The JMP saves a few cycles on IRQ dispatch, minimising overall execution time per pulse.
But most of the measurement error would come from unstable ISR latency, i.e. whatever opcode was executing when the interrupt triggered would delay handling it by a variable amount of cycles.
Do you correct for that somehow?
No need to correct it.
In my code the amount of cycles is not variable because all "interruptable" code is made of 2 cycle instructions only :D
so whenever the IRQ happens, I get control at the 12 cycle mark. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
@Copyfault: we are slightly off topic here.
but as I said to chain the JMP in dc0c to the timers all is needed is a code like this at XX00:
example:
.C:0a00 70 70 BVS $0A72
.C:0a02 0C 70 70 NOOP $7070
A00 >> A72 ; ON BRK
A01 >> A0F ; ON Timer A
A02 >> A05 ; ON Timer B
A03 >> A75 ; ON Timer A+B
A04 >> A12 ; ON TOD
putting for example (but there are more combinations)
70 70 0C 70 70
will cause a different jump for every situation :D |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZibriNo need to correct it.
In my code the amount of cycles is not variable because all "interruptable" code is made of 2 cycle instructions only :D
so whenever the IRQ happens, I get control at the 12 cycle mark. If the interruptible code is a bunch of NOPs, then you'd have a jitter of 1 cycle. This is quite small, of course, and may not be reducible further. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @Copyfault: we are slightly off topic here.
but as I said to chain the JMP in dc0c to the timers all is needed is a code like this at XX00:
example:
.C:0a00 70 70 BVS $0A72
.C:0a02 0C 70 70 NOOP $7070
A00 >> A72 ; ON BRK
A01 >> A0F ; ON Timer A
A02 >> A05 ; ON Timer B
A03 >> A75 ; ON Timer A+B
A04 >> A12 ; ON TOD
putting for example (but there are more combinations)
70 70 0C 70 70
will cause a different jump for every situation :D
Novel approach! I'll probably use that someday! |
| |
ws
Registered: Apr 2012
Posts: 251 |
Is there any data on how the reliability of reading standard-recorded tapes is affected by this method?
Like does it introduce more noise/errors due to sampling more often, or is this just an overall better way to read from tape?
(If i read a value 3 times more often, it can be wrong 3 times more often, - do i deal with that yes/no&how?) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Is there any data on how the reliability of reading standard-recorded tapes is affected by this method?
Like does it introduce more noise/errors due to sampling more often, or is this just an overall better way to read from tape?
(If i read a value 3 times more often, it can be wrong 3 times more often, - do i deal with that yes/no&how?)
Hmm not exactly...
Imagine this situation: run headalign...
You will see 2 vertical lines on normal turbos (4 in mine).
As you will see they are "separated" by "a space".
Imagine to draw a THIN line bewteen them and assign 4 different values instead of the usual 2.
Now, the ability of my program is to draw those lines perfectly.
It's then up to the real datassette status and alignment and wobbling how variable will be the "data" lines.
Nonetheless every other program I saw add a huge jitter or imprecision in "discerning what is what". My program just does not have that problem and that allows smaller "gaps" between those "lines" without any loss.
Then again if I use the same GAPS (around 96 cycles) commodore uses, I still can achieve 100 times their speed (and 2 times turbo250) preserving the error resilience.
I tried to explain this as simple as I could.
There is no noise involved.
The datassette has a low pass filter in it's amplifier which cuts everything above 10khz (but not abruptly). Frequencies up to 11196 hz (perhaps even 12khz) are possible but a little less reliable and way more dependent on the azimuth.
About the azimuth, the tape head must be perfectly parallel to the magnetic tape.
If it's not, even slightly, higher frequencies will be affected first... then the more it is "slanted" the more frequencies will be "mixed up"...
Anyway, even at lower frequencies my turbo performs greatly.
And there will be parameters so everyone can set it up as they want and you will be very welcome to make tests, improvements , even challenges :D
Before someone asks: why TWO bits at a time and not 3 or 4 or even 8?
Because the speed won't improve by much.
With only 2 bits I can ssigne the more common ones (00 and 11) to the highest frequencies and so to a higher speed.
It the data is not compressed, that achieves a great compression on a frequency level.
I am studying some more improvements before starting to write all the "api", but as far as we tested, more complexity does not affect too much the performance. But I might be wrong on this. We will see.
This is still in the early stages of testing. I just wanted to share with you all what has been done so far. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quoting ZibriNo need to correct it.
In my code the amount of cycles is not variable because all "interruptable" code is made of 2 cycle instructions only :D
so whenever the IRQ happens, I get control at the 12 cycle mark. If the interruptible code is a bunch of NOPs, then you'd have a jitter of 1 cycle. This is quite small, of course, and may not be reducible further.
Yep.. on real hardware that could happen but I don't consider one cycle a "jitter".
I am developing mostly on an emulator and since tap files are quantized by 8 cycles I had to do most of the work on paper.
Anyway, a one cycle jitter won't affect the actual accuracy at all.
I went up to 8 cycle per symbol at 17.5 KHZ on an emulated tape with no problems. On a real tape if it's the datassette writing the file (consider that as a COPY of a master) the maximum speed we achieved was about 12 kilobit or little more than that.
If the master would be written by a professional device I am sure the speed could go way up and still be readable by a standard datassette. And you all will be very welcom to try that.
Also, about that, most programs I saw converting TAP to WAV seem to be wrong IMHO.
I created a tap 2 wav in python which generates a waveform that does not need to be inverted (it's simmatrical on the horizontal axis, and it works nicely with every device I threw it at. More on this later. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
"tap files are quantized by 8 cycles" - I was very annoyed when I found that. Almost annoyed enough to create a more accurate format and add it to an emulator. :) |
| |
morphfrog
Registered: Mar 2002
Posts: 33 |
Quote: 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.
Intresting and very impresssive!
How fast is this compared to the fastet tapeloader I know of Gyrospeed? ( GyroSpeedWin ) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 34 - Next |
