| |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZibriI know I could use: sysXXXX"filename",speed, start,end,jump
but using the kernel to get the parameters uses memory so, as of now I get the parameters manually.
Sure I can do it anyways but it will make the program way bigger. Getting the parameters with ROM calls doesn't take all that much code, actually.
But why is the size so important? Being able to save a 202-blocks program from $0801 to $d000 leaves a lot of space for the save routine.
It could even implement something like MASTER"filename",start,end,entry,speed - or maybe extend the SAVE command with the parameters, for most intuitive usage. |
| |
Peacemaker
Registered: Sep 2004
Posts: 275 |
What a toxic guy. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quoting ZibriI know I could use: sysXXXX"filename",speed, start,end,jump
but using the kernel to get the parameters uses memory so, as of now I get the parameters manually.
Sure I can do it anyways but it will make the program way bigger. Getting the parameters with ROM calls doesn't take all that much code, actually.
But why is the size so important? Being able to save a 202-blocks program from $0801 to $d000 leaves a lot of space for the save routine.
It could even implement something like MASTER"filename",start,end,entry,speed - or maybe extend the SAVE command with the parameters, for most intuitive usage.
well.. let's say you load a file from 0801 to CFFF.
if you call E1D4 to get the parameters from the sys line you will get an out of memory error.
So I didn't call $E1D4 and got the filename and speed (single digit 0-9) by myself.
As of now the "saver" can save anything from $400 to $CFFF.
The next version (which will need a heavy rewrite) will probably support a save from $400 to $FFF0 it's not difficult to do but I need to rewrite and recalculate everything because of how the loader is made.
(An example: the great giana sisters file "1" loads from $820 to $FFF0 and at the moment is not possible).
Works pretty fine with anything in the range $400-$CFFF.
The preliminary version is now sent to my testers and has only the filename and speed parameters, saves from 0801 to cfff and jumps to $16384. Parameters will come immediately after and that's why I asked how would you prefer them.
Here is the updated speed table (test file is pharaoh's curse)
============================================
S | C | B | PAL Bitrate NTSC | Reliability
--------------------------------------------
0 24 24 5154.12 5350.19 Best / Old D
1 23 22 5497.19 5706.31 High / Old D
2 22 20 5889.19 6113.22 High / Any D
3 21 18 6341.39 6582.61 Best / Any D
4 20 16 6868.8 7130.09 Good / Any D
--------------------------------------------
5 19 14 7491.9 7776.9 Best / Same D
6 18 12 8239.33 8552.76 Good / Same D
7 17 10 9152.42 9500.58 Avg / Same D
8 16 8 10293.12 10684.67 Low / Same D
--------------------------------------------
9 15 6 11758.64 12205.94 Low / Master
-------------------------------------------
PAL C Center Freq: 123156 hz / C
NTSC C Center Freq: 127840.875 hz / C
PAL B Badwidth: 123156 hz / B
NTSC B Badwidth: 127840.875 hz / B
-------------------------------------------
File lenght: 47103 bytes.
-------------------------------------------
Note:
On NTSC systems the resulting frequencies will be slightly
higher than on PAL, but there will be more bandwidth for each symbol.
Note:
Speeds 0 to 2 are highly reliable.
Speeds 3 and 4 are more reliable than any other turbo
Speeds 5 to 8 are less reliable and dependent
on a good alignment and fitness of the datassette.
speed 9 worked on a particularly good datassette but it is meant
for masters only.
In our tests, speed 8 was successfully written and read back
by a datassette in good condition.
As usual your mileage may and will vary, but even at it's slowest
speed this turbo beats any other by 50% or more and up to 300%.
For personal archiving (reading and writing with the same datassette)
Speeds 5-8 are suitable.
For compatibility with other (out of speed) datassettes,
speeds 0-4 are more indicated. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Update:
nevermind. I was getting "out of memory" only for the name string. for the numbers no problem so I addes start,end and jump.
As of now the syntax is:
SYS52480"filename",speed(0-9),start,end,entry
P.S.
It still needs some refactoring but as of now I used every single byte of the last 2 pages at $cd00-cfff and every single byte of the 213 bytes of the loader :D
Just tested it and it worked with both archon and pharaoh's curse.
I am sure some games will give problems because the loader does not have the cleanest of the exits (euphemism).
And since it's impossible to forsee any situation,
as of now the loader (which trashes the stack too)
exits in this way:
it pushes the entry point (minus one) to the stack, then
jumps to $FF5B.
I don't have space to do much more than a jump and I think FF5B is a good candidate. If you have better ideas, do tell.
Obviously the loader could expand to the video memory too, but it will take longer to load and I don't like that. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Update:
the new loader seems to work.
It can load from $4C6 to $FFF9 (writing in ram below roms and chips).
Since there is not a universal jump, I setup up a few vectors:
one is the game entry point.
another one is where it jump before "returning" to the program entry point. The default is $FF5B for this one but some games "prefer" $E544 or other "cleanups".
Or you can make your own, save it with the game and jump to it.
I strongly advice not to use crunchers for the game, because the loader already takes care of that in it's own way. And the less compressed the data is the faster it will load.
Update: IT WORKS!
It successfully loaded giana sisters file "1" from 0801 to FFF0 and then started it.
Now it needs some cleaning and polishing.. few more days and it will be ready. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Update:
the new loader seems to work.
It can load from $4C6 to $FFF9 (writing in ram below roms and chips).
Since there is not a universal jump, I setup up a few vectors:
one is the game entry point.
another one is where it jump before "returning" to the program entry point. The default is $FF5B for this one but some games "prefer" $E544 or other "cleanups".
Or you can make your own, save it with the game and jump to it.
I strongly advice not to use crunchers for the game, because the loader already takes care of that in it's own way. And the less compressed the data is the faster it will load.
Update: IT WORKS!
It successfully loaded giana sisters file "1" from 0801 to FFF0 and then started it.
Now it needs some cleaning and polishing.. few more days and it will be ready.
Keep up the good work Zibri! |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
It seems that:
push jumpaddress-1
then
jsr $e518
jmp $ff5b
works for at least: archon, giana sisters and paharoh's curse.
Note for VICE team:
by mistake my saving program inverted the pulse.
On real hardware the result didn't work.
On Vice it works (that's why I didn't notice the silly mistake).
Note:
that's really weird because FF5b has a jsr e518 as first instruction.. hmmm |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Outside of mastering single file autostart programs to turbotape, what about the possibility of archiving a floppy (or D64) to turbotape, for later retrieval.
Kinda like a primitive tape backup system :D
I suppose that's totally impractical these days, but if you're playing around with tapes and tape turbos then it could be an idea that's fun to toy with. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Is your speed table the bitrate when loading uncrunched/unpacked data? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZibriI strongly advice not to use crunchers for the game, because the loader already takes care of that in it's own way. And the less compressed the data is the faster it will load. This is unexpected. Can you expand on that?
Usually you'd expect a tape encoding to assume a uniform distribution of 0 and 1 bits, i.e., high entropy, packed data.
It can then assume a fixed relation of symbol size and frequency, and optimise encoded symbols for that generic case.
The job of the encoding is to provide the shortest possible representation for that "noise", while a good cruncher is expected to provide the high entropy.
Crunching would make the payload data as small as possible, and the encoding would have less data to encode to start with.
Do you mix both somehow, or pick encoded symbols based on the statistics of that one file (not a generic encoding with one loader for multiple files) and does that give higher loading speeds? |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 34 - Next |
