Hello Guys,
If you have games from Firbird using bleepload (even with the musical loader) Please dump as WAV, and send them
to me via mail.
We will process them as cDT :D !
Just checked out Harvey Headbanger and Spikey Harold. I see that they have DRB for the loader part.
Why not use CSW until we figure out how to make proper CDTs ? Kev was looking at BLv3, but I don't know
if he resumed work. I guess it's better than nothing and they work fine, just wondered.
The games I have from Firebird are already CDT.
They all have musical loaders.
You can try them here:
http://cpc-live.com/firebird
Would be great to increase the number of games.
Quote from: specfreak on 00:15, 14 October 09
Just checked out Harvey Headbanger and Spikey Harold. I see that they have DRB for the loader part.
Why not use CSW until we figure out how to make proper CDTs ? Kev was looking at BLv3, but I don't know
if he resumed work. I guess it's better than nothing and they work fine, just wondered.
work was put on hold.
CNGSOFT can make CDT out of any bleepload v3 tape i send him as CSW or WAV. :D
Ah, but I was looking for a proper CDT decode rather than using DRB blocks. I'm going to try a few methods and see if I can suss it out.
I alsmost got Booty to CDT, but I see this also has a DRB for the big data block. There must be a way to make it into proper data.
Like I said, anything is a step in the right direction and as long as we keep WAVs we can revisit at a later date.
I'll keep searching CPC-Power and upload WAVs/CDTs as I find them. I don't know when we'd next update the .TZX Vault with CPC tapes/disks, so CPC-Power is ideal/preferred IMHO. I only wish my French was better.
the main problem is that bleepload v3 scheme requires actually coding knowledge.
Some games uses MFM raw bits stream, or digital pulse. No tool like taper or samp2cdt support this.
CNGSOFT does them all by hand.
Funny is:
TZX2WAV (Or JavaCPC's conversion of it) reads this CDT format correctly and produces correct WAV data.
So, why isn't it be possible to do this in reverse order? To produce a CDT from a WAV file?
I think GNGSOFT is similar to a guy in the Czech Republic called Mikie who get's custom spectrum tapes into the TZX format.
He has made all of the V1.20 TZXs on the TZX Vault. I just wondered if the v1.20 edition of the TZX spec could be used to
handle these troublesome CPC tapes like Gremlin 2 and Bleepload v3 ? Mikie also uses custom tools to create the TZXs,
he might modify a convertor just to do a certain block, but he also adds a custom block "Decode Info" which tells Tapir how to
read/decrypt the TZX block to view in Tapir. This block is optional and ignored by even Spectrum emulators, but it's useful for
TZX/CDT creators/dumpers.
I wish there was a way to update more of the utils, I wish I had more knowledge to write my own, as I've managed to stay in the scene for over 15 years now (mainly spectrum, but I'm very much interested in CPC preservation on Tape and Disk).
Hope those samples/CDTs I put up were of use.
Oh and no disrespect to GNGSoft when I mentioned about DRB blocks.
Keep up the good work, I'm really liking the CPC-Power site (Phenix) ;-)
Andy
Quote from: Devilmarkus on 21:33, 15 October 09
Funny is:
TZX2WAV (Or JavaCPC's conversion of it) reads this CDT format correctly and produces correct WAV data.
So, why isn't it be possible to do this in reverse order? To produce a CDT from a WAV file?
It depends on how the CDT creator made it. If it's a loader catered for by Samp2CDT then it should convert from
CDT->WAV then back to CDT. Some require extra work which isn't possible directly with a utility. Many of use use a variety
of utils to get a working CDT and IMHO the timings are something out. I know that Amstrad used Variable tape speed, but
I still think that the master would have been of a set timings constant (i.e ROM) so all block stored as ROM should be the same
timings and percentage block speed rather than varying from 69% ~ 72%. However, I may have overlooked something and as
I primarily TZX things on the spectrum my perception of CDTing may be influenced by that side of things.
Yes it happened that i had to process back some CDT you did, because it didn't run back on a real machine.
Once converted back to WAV and then passed thru samp2cdt again with the correct decoder, the job was done :)