[CSDb] - User Forums - New life for your underloved datassette unit :D

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-10-21 14:47

chatGPZ

Registered: Dec 2001
Posts: 11386

x64sc is the updated emulator.

2021-10-21 14:49

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: Quoting Zibri
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.
FWIW, Softwired does
.C:dd0c 4C 83 05 JMP $0583
when handling a timer interrupt, acknowledging it while executing the jump, saving a cycle over BIT $DD0D.

Back to the topic.. ok.. I don't know about this 2021 demo.

But anyway nobody used that with tape :P

The strong point of my tyurbo is not the irq ... the irq just saves a few cycles (and I have plenty to spare.. more than 40-60).
The reasons my turbo works are others.

2021-10-21 14:52

Krill

Registered: Apr 2002
Posts: 2980

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?

2021-10-21 14:52

iAN CooG

Registered: May 2002
Posts: 3193

> I wonder why they don't keep x64.exe up to date with x64sc.exe

If it was possibile there would be no need for a x64sc.
X64 uses a faster but inaccurate emulation, x64sc is more accurate but heavier on the host cpu. Choose your destiny.

2021-10-21 14:53

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: x64sc is the updated emulator.

x64sc takes as much as double the cpu time as x64.exe.

except for a few demos, everything I throw at it works.
and it's bugs are the same as in the x64sc version.

What an update!
lol

please. stay on topic anyways. I don't want this to become a circus again.

2021-10-21 14:55

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: > I wonder why they don't keep x64.exe up to date with x64sc.exe

If it was possibile there would be no need for a x64sc.
X64 uses a faster but inaccurate emulation, x64sc is more accurate but heavier on the host cpu. Choose your destiny.

I know.. but most of the times the inaccuracies of x64.exe are irrelevant.
And, personally, I don't find x64sc so much more accurate.
cpu speed still wobbles and is never a "still" 100% even in the sc version.

2021-10-21 14:59

ChristopherJam

Registered: Aug 2004
Posts: 1409

Quoting Zibri

what do you mean by "seven pulse length loader" ?

He used seven different pulse lengths. The shortest outputted a pair of bits, the other six groups of three.

Quote:

hmm 167 + 50*n means a frequency separation of 50 cycles (strange).

That can work but it will be very prone to errors.

Well yes, as I said, he only was using it to load back on the drive he used to record on. Apparently it worked well enough for that purpose.

I mostly wanted to point out that experimenting with frequency separations that low is really not that groundbreaking. We've known for decades that separation 50 is really pushing it, and 100 is pretty safe.

2021-10-21 15:03

Copyfault

Registered: Dec 2001
Posts: 478

Quoting Zibri

Sorry 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 Zibri

for 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 Krill

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?

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?

2021-10-21 15:10

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.

2021-10-21 15:13

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