| |
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....
|
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quoting ZibriAnother small note:
Whithout using tricks, like shortening the original commodore PILOT tone ($6a00 $2f or $30 pulses)
Or the "inter-pilot" ($1a00 $2f/$30 pulses).
I found a way to load my loader in jusy 4 counter clicks.
Also this I didn't see it anywhere.
But if any of you did, please do tell.
I don't think there is a faster way to do it. Perhaps by little (I could make my loader a few bytes shorter) but not much.
Do you mean just autostarting after loading only the first CBM data chunk? That happens for instance if using $029f/$02a0 for autostart and I guess also on ISTOP.
That kind of autostart is pretty common, although I think in most instances the second data block is still there even though it's not used.
For fast startup, keep your loader within the tape buffer and load max 2 bytes to trigger the autostart. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Quote: Another small note:
Whithout using tricks, like shortening the original commodore PILOT tone ($6a00 $2f or $30 pulses)
Or the "inter-pilot" ($1a00 $2f/$30 pulses).
I found a way to load my loader in jusy 4 counter clicks.
Also this I didn't see it anywhere.
But if any of you did, please do tell.
I don't think there is a faster way to do it. Perhaps by little (I could make my loader a few bytes shorter) but not much.
The funny thing:
My loader now is not recognized by VICE (shows an empty tape) but it is recognized by the (emulated and RH) C64 :D
If you mean putting your loader in the tape header and then overloading $029f-$02a0, it's been done before yes, including in my loader that I am very sure you've been peeking at already! |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
Quote: Another small note:
Whithout using tricks, like shortening the original commodore PILOT tone ($6a00 $2f or $30 pulses)
Or the "inter-pilot" ($1a00 $2f/$30 pulses).
I found a way to load my loader in jusy 4 counter clicks.
Also this I didn't see it anywhere.
But if any of you did, please do tell.
I don't think there is a faster way to do it. Perhaps by little (I could make my loader a few bytes shorter) but not much.
The funny thing:
My loader now is not recognized by VICE (shows an empty tape) but it is recognized by the (emulated and RH) C64 :D
Either on a real C64 by copying the kernal into RAM and patching it: https://codebase64.org/doku.php?id=base:autoboot_tape_turbo_loa..
Or using TapeTool to write custom kernal format pulses and this code: https://github.com/martinpiper/C64Public/blob/master/IRQTape/Ta..
It's possible to have a very minimal loader that only uses two bytes to claim the vector at $300/$301, plus bytes in the tape header for the loader code.
This actually loads very quickly because the kernal does not even get to try to verify the memory with the second block as the error handler kicks in. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlr
Do you mean just autostarting after loading only the first CBM data chunk? That happens for instance if using $029f/$02a0 for autostart and I guess also on ISTOP.
No :D
Quoting tlr
That kind of autostart is pretty common, although I think in most instances the second data block is still there even though it's not used.
Indeed. But not in mine.
Quoting tlr
For fast startup, keep your loader within the tape buffer and load max 2 bytes to trigger the autostart.
That's what I did!
1) no double copy of the file.
2) loader inside the tape buffer and already loaded when the "found" appears.
3) loaded 40 more bytes only (which can be reduced a little as I said)
So, after thge "found" message, only 40 bytes are really loaded :D
I can shorten that up of perhaps other 10 bytes. But that won't impact the loading time by much. What does is the single copy of the file on tape.
P.S.
I did this on my own and I didn't read of this anywhere. |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
My method starts the turbo code 1 counter click after the filename is displayed... |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Quote: Quoting tlr
Do you mean just autostarting after loading only the first CBM data chunk? That happens for instance if using $029f/$02a0 for autostart and I guess also on ISTOP.
No :D
Quoting tlr
That kind of autostart is pretty common, although I think in most instances the second data block is still there even though it's not used.
Indeed. But not in mine.
Quoting tlr
For fast startup, keep your loader within the tape buffer and load max 2 bytes to trigger the autostart.
That's what I did!
1) no double copy of the file.
2) loader inside the tape buffer and already loaded when the "found" appears.
3) loaded 40 more bytes only (which can be reduced a little as I said)
So, after thge "found" message, only 40 bytes are really loaded :D
I can shorten that up of perhaps other 10 bytes. But that won't impact the loading time by much. What does is the single copy of the file on tape.
P.S.
I did this on my own and I didn't read of this anywhere.
1. Already been done, allthough not in mine (as I didn't see much gain in that but I was aware of this. Martin Piper have done it and you can see this in many Psytronik releases)
2. Same as in mine and many others.
3. I (and others) did the same.
So, the difference here apparently lies in the vector used for autostart, then... and I'm pretty sure whatever vector you used, it's already been done by others. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Martin Piper
It's possible to have a very minimal loader that only uses two bytes to claim the vector at $300/$301, plus bytes in the tape header for the loader code.
Why $300?
$326-$32D are a better choice imho.
In this way the loader can be saved normally or without the double block.
In this way it's more flexible.
$300 won't be triggered if the loader is saved normally because there won't be a load error.
Also: to write such a loader fom the C64 itselt is tricky.
I can write anyway from C64 my loader in the normal way.
From my tap generator I can create it both the normal both the truncated way and it works with no modification.
About loading 2 bytes only:
in the tape header section there are 191 bytes of which 16 are the file name, start/end address ($14 bytes)
That leaves 171 bytes in the tape buffer for code.
Some loaders load a pre-loader there, then with that they load another piece of the loader and then start the turbo routine.
Instead, I just write from $326 to $350 (filename can be long)
and jump.
That is everything my loader needs. So after that there is directly the turbo data. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting SLC1. Already been done, allthough not in mine (as I didn't see much gain in that but I was aware of this. Martin Piper have done it and you can see this in many Psytronik releases)
2. Same as in mine and many others.
3. I (and others) did the same.
So, the difference here apparently lies in the vector used for autostart, then... and I'm pretty sure whatever vector you used, it's already been done by others.
I saw your loader (briefly):
1) not same at all you load at different addresses.
2) not same as you or any other I saw (not many to say the truth)
3) you absolutely not do the same I do, perhaps you understood it wrongly.
4) my loader allows and uses also another technique and allows the saved "cbm" data to be saved only once (or normally if needed, without any change in the code).
If you think ALL these techniques where used in a single loader, please do tell me which one and I will analyze it and tell you any differences I find. Perhaps there would be even some better ideas there.. I don't know. |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quoting ZibriQuoting tlr
For fast startup, keep your loader within the tape buffer and load max 2 bytes to trigger the autostart.
That's what I did!
1) no double copy of the file.
2) loader inside the tape buffer and already loaded when the "found" appears.
3) loaded 40 more bytes only (which can be reduced a little as I said)
So, after thge "found" message, only 40 bytes are really loaded :D
I can shorten that up of perhaps other 10 bytes. But that won't impact the loading time by much. What does is the single copy of the file on tape.
P.S.
I did this on my own and I didn't read of this anywhere.
Exactly. The details will lay in how you choose to do your autostart.
It's a fun process to find this kind of stuff out for sure!
We all find a lot of stuff out on our own and it often turns out to be already found out by others. Not surprising given the amount of people who have fiddled with this during the years. When you know what has been done, you can choose to apply a new twist on it to make it unique.
My suggestion was 2 bytes, so some more room for improvement. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
Quote:You remind me of him, you just look less skilled than him, and he was a kid at the time.
Now go fix VICE and try to not mess it up any further.
Oh no wait, you are the one pushing 3 commits just to correct comments... what a fullfilling job.
Another carefully crafted ad hominem! Has it's moments! |
| Previous - 1 | ... | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 - Next |
