Previous | Next
| From: Crown (all posts)
Date: 1998-05-19
Subject: Tape loading, and others
|
Hi all,
Mike wrote,
>Simply put you sample the whole tape (from 4 to 14megs about..) then
>This avoids LOADS of problems... And these days... 14meg isn't much
>:-)
What are the sampling parameters? I guess it's 8 bit mono 22khz.
A 70 sec game with turbo-loader on tape would need around 1.5 Mb in wav format,
while it's just around 40kb. So I think for completness it's a good feature this tape loading through wav files, but I wouldn't use the wav format for archiving.
What other options do we have?
What I do now, is that I'm using VC1541, it reached a state, where it not only emulates load, but also emulates saves, so I can save my tapes directly to my PC. If somebody doesn't know this util the homepage is:
http://os.inf.tu-dresden.de/~paul/VC1541/
This util turns your PC into a 1541, it wont run fastloaders and such,
but for archiving purpose it is quite usable.
The other option would be a converter which would convert from wav into prg.
>Turbo loaders are usually a custom format thats loaded first... it'll
>be a bugger to get this for all the diff loaders... won't it?
Well, I guess this number is under 20, (I'm just guessing :) ),
and this can be solved with a well specified external config file format.
I'm thinking about a descriptor language here. Levente, I hope that you will do that converter you mentioned, with this kind of external format specification. It would allow to make it support every format one might think of, and would allow tinkering with it :) ...
The third option is Minus4 (with the next release I think). Sampling the tape, loading the wav, cracking it in Minus4, saving it to disk with Minus4 (Freeze not always worked for me, I have some freezed image which wouldn't start).
Solder/Synergy wrote:
>I think from each game on tape exists a cracked version on disk.
>If you need a special
>game on disk ask me or Rüdiger Gerdes (Rüdiger/Unlimited).
I guess you are right, but to crack is fun. For example I'd love to play with that loader with 'Moon Buggy', even that I might have it on disk or on tape, or on CD, because it always a good feeling, when you understand,
how a thing works.
Martijn:
If you give up with Moon Buggy, I would still love to make a shot at it.
I guess we should wait 'till Mike releases the next version of Minus4
with the sample support. I hope you can sample that tape, and can send the wave file to me.
Rachy:
I guess you came later to the list, and missed the TED cycle mapping posting. If you need that, mail me, and I can send it. It contains infos which should enable emulators to correctly run the $ff1e $ff1d defenders.
For this type of defenders to work, both the CPU and the TED emulation must be cycle perfectly syncronized because $ff1e changes in every cycle.
Also interrupt startup position and time must be correct as these defenders using IRQ for startup.
Lion:
>It's high time to put http://c64.rulez.org/plus4 online, with all the
>related links and stuff :) And the TED timing, coz some new users of
>this list didn't get it, and some more dox. I have scanned some Good idea, I already tried the URL some times :-)
Bionic/Synergy:
>btw. check out http://come.to/mdiv2 for artworks last production,
>an experimental and portable demo.
Did that, and fixed two bugs in the VESA code. Should I send you the fix?
Levente: (interlace)
I think the vibrating in the upper lines is happening because there is two line difference between the two frame's Equalize ending position.
I think your routine did the interlace because of this, and not because of the retrace sygnal's moved position. Still have to check it further.
Mike:
>So, anyone HAVE the bit format??? Its not quite the way I thought it
>was thats for sure... Im not even sure a "pulse" is a true 1 or 0!
I have some infos, but I didn't verified it, and didn't dug myself into the ROM-list also.
The header (the sync sygnal) looks this
.5 msec level 0, .5 msec level 1, and this loops.
The data bit format:
bit 0:
250 nsec level0
250 nsec level1
500 nsec level0
500 nsec level1
bit 1:
500 nsec level0
500 nsec level1
250 nsec level0
250 nsec level1
A byte begins with
1 msec level0
1 msec level1
500 nsec level0
500 nsec level1
and from here the bits are coming.
I don't know the logical format, have to dig it out from the ROM-list.
Marko:
>BTW, I crunched some C16 programs with PuCrunch
>http://www.cs.tut.fi/%7Ealbert/Dev/pucrunch/, I ported the decruncher to
>C16/plus4). The games don't work entirely properly, e.g. Roller Kong
>(http://www.funet.fi/pub/cbm/plus4/Games/misc/r/) doesn't play any tunes
>until you loose a life or something. The uncrunched game works fine.
>Could anyone on this list try to figure out what is wrong with the
>decruncher?
When you converted the decruncher to C16, have you changed the zero page registers it used on C64? I checked it only briefly, and not deeply,
but I think some of the zero page regs should be moved to somewhere else,
$d0-$e8 is a usable area (it's not used normally).
Tibor Biczo / Crown of GOTU
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
