| |
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....
|
| |
ws
Registered: Apr 2012
Posts: 238 |
@ all : i see and understand. and thanks for the links! |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Update:
after a round of successful tests on the loader,
I finished today the first draft of save program (the one that creates on a C64 and on tape, everything needed).
It creates:
the main loader in standard format
the pilot with stable rasterbars
the turbo "data" at 10 different "speeds".
and a short final pilot (ignored by the loader except for the first pulse.. I can remove that but I like to have a small ending gap)
Also the writing program has absolutely NO JITTER and is cycle exact.
Now, after/during the next round of tests on real hardware, I will put some parameters and cleanup the messy first draft.
I have a question for you:
how would you like it wo work?
As of now it works by issuing:
SYSXXXXX"filename",speed (where speed is a number from 0 to 9)
The test program just saves all memnory from 0801 to bfff and the test loader is setup to load and jump to 16384.
What do you think is the best way to go?
I use some zeropage pointers for start,end and jump (so some pokes will be needed before issuing SYSXXXX or what?
I 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.
As of now the loader is 214 bytes.
The same program (which includes the loader) is about 7 hundred.
Any idea?
P.S.
This won't matter much in the future because it will probably go in a cartridge but it could be nice as a standalone utility to load from a disk drive or other device. |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Standalone utility is fine, as is one built into a kernal ROM.
Most practical would be a loader that can take a program of up to 202 blocks and master it to tape (or TAP), much like Gyrospeed, or Richard Bayliss' tape mastering tools. |
| |
Krill
Registered: Apr 2002
Posts: 2871 |
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: 243 |
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: 1997 |
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 |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 34 - Next |
