COMMODORE FREE
Issue Number 12
September 2007
Free to download magazine dedicated to Commodore Computers
Available from www.commdorefree.com in the formats of PDF TEXT HTML and D64 image
Editor
Well some people may say the edition is over dominated by the SOASC= project. I feel this as an absolutely insane project and totally mad, a superb effort from a dedicated sid fan well done.
What’s this SOASC= project all about? well you need to read the issue and all will be revealed
I am no artist as you can tell and have designed a new logo for the magazine, the old one was really a stop gap because, it was a case of using that or else nothing. I am fairly pleased with the finished logo being a none arty type person.
Time was not with me on this issue
Thanks
Nigel
www.commodorefree.com
HOW CAN I HELP COMMODORE FREE
Ok the best way to help would be “write something about Commodore” (yes for the observant I spelled the company correctly this time) _grin seriously though articles are always welcome,
WHAT ARTICLES DO YOU NEED
Well they vary contact me if you have an idea but I am looking for
Tutorials – (beginners and Expert)
Experiences with Commodore
Why I love Commodore machines
Interviews – maybe you have access to a power user
Thanks Nigel
www.commodorefree
commodorefree@commodorefree.com
Contents
Editorial and contents Page 2
NEWS
Winvice
Winuae Page 3
SCACOM issue 1
DC2n Updates Page 4
PROJECTS
SOASC= Page 5
SOASC= F.A.Q Page 6
SOASC= How it was done Page 10
Minimig Page 20
INTERVIEWS
Stone Oakvalley (SOASC=) Page 14
INFORMATION
Commodore Disk Archive Project Page 22
Commodore 64 Programmers library Page 23
SID
Sid still sounds so special Page 25
PROGRAMMING
Hex files Part 7 Page 28
NEWS
New Version of WinUAE
The Amiga Emulator for windows has been released
http://www.winuae.net/
Wanted: Non-emulated Freezer Cartridges
=======================================
- X-Power Professional 500 (non-v1.2)
- Nordic Power (non-v2.0)
- Bus Stop
- Pro Access
- Action Cartridge loader disks/disk images. (non-v1.3 german)
- Action Replay (non v1.00, v1.50, v2.05, v2.12, v2.14, v3.09, v3.17)
(or cartridge ROM images if you have (EP)ROM reader. Note: ROMs are scrambled.)
WinUAE 1.4.3 (29.07.2007)
=========================
New features:
- Built-in lha/lzh and lzx support.
- Mount archives as a harddrive with transparent, recursive (archives inside archive) decompression. Supported: zip, 7zip, rar (unrar.dll or archiveaccess.dll required), lha/lzh, lzx.
- A3000 Kickstart ROM and SuperKickstart disk support.
- A590/A2091 SCSI, A3000 SCSI and CDTV SCSI expansion harddrive (HDF) emulation (WD33C93 + (Super)DMAC based SCSI hardware).
- Action Cartridge Super IV Professional freezer cartridge emulation.
- X-Power Professional 500 (v1.2) freezer cartridge emulation.
- Nordic Power (v2.0) freezer cartridge emulation.
- Debugger improvements (improved deep trainer, copper memwatch points,CPU-model specific registers can be modified, illegal access logger
improved, process breakpoints etc..)
- Paths-panel default paths selection improved.
- Separate native and Picasso96 vsync setting.
- GUI will "autoscroll" if fullscreen mode is smaller than GUI.
- Improved rtg.library, speeds up Picasso96 in high resolution modes (obsoletes picasso96fix)
Bugs fixed:
- CDTV emulation improved (DOTC2, Xenon2, ChaosInAndromeda CD player)
- CD32 CD emulation improved (Fightin' Spirit, Base Jumpers etc..)
- Ghostscript printing fixed (again).
- Floppy drive sound selection if fdrawcmd.sys was not installed.
- Video recording sound pitch issue.
- -datapath command line parameter fixed (again..)
- uae-configuration JIT on/off switching fixed.
- Sprite attachment fix, fixes "Great Demo" by "The Tremendous Trio" :)
- Some FPU fixes from Aranym.
- Directory filesystem locked files (most commonly s:startup-sequence)
after software reset
- Filesystem emulation not initializing if JIT was enabled and no other
expansions enabled (fast RAM, Z3 fast, etc..)
VICE 1.22 Released
* Changes in VICE 1.22
======================
** C128 changes
---------------
- Added 2 MHz mode support (experimental).
- The cursor keys are mapped differently in C64-mode now.
- Fixed C64-mode autostart support.
** VIC20 changes
----------------
- Improved the sound emulation where the 'volume change click' is
concerned, and normalized the audio output level.
** VIC-II
---------
- The VIC-II border mode can be selected now (normal, full, debug).
- Some sprite fixes needed for Krestage 3 demo.
** Drive changes
----------------
- Improved drive LED emulation.
** Unix changes
---------------
- Fixed the "black screen" bug caused by some X11 library security
update.
- Fixed the usb support for bsd based platforms.
- Changed the preferred libdir and docdir for netbsd and freebsd.
- Xaw/XRandR fullscreen mode is supposed to work.
** MS-Windows changes
---------------------
- Positional keyboard mapping is used as default again.
- New volume slider control.
- The win32 port can now be compiled with openwatcom.
** OS/2 changes
---------------
- The os/2 port can now be compiled with openwatcom.
** RiscOS changes
-----------------
- Added a build script for the RiscOS port and all needed binary files
are now part of the source distribution.
** AmigaOS changes
------------------
- Added netplay support for AmigaOS3 port.
- Added netplay support for AROS port.
- New VICE Volume control for all ports.
** C1541 changes
----------------
- Fixed some unlynx bugs.
http://www.viceteam.org/#vice
SCACOM-Aktuell issue 1
SCACOM-Aktuell issue 1 (August 2007)
SCACOM-Aktuell is a new PDF magazine in German language for Commodore and Amiga fans.
Issue 1 (August 2007) got released today.
Topics are:
A magazine introduces itself...
Who is creating this magazine?
Renderering pictures - part 1
Tutorial - CF cards on Amiga
Where Commodore computers are being used nowadays?
How does Jack Tramiel look like these days?
PSP - The all-rounder
To download it, go to
www.scacom.de.vu,
click SCACOM in the menu on the left, then "SCACOM Aktuell Ausgabe 1 (August 2007)" and finally the link "August 2007".
NEWS Project Update DC2N
> Hi Nigel,
>
> basically what I am still in need of is the design
> tool for the final circuit boards. I have been
> trying to design a cardedge (check the attached
> image) in the CAD I use (eagle by CadSoft) but I
> wasn't able to do so without a trick that requires
> manual cut of the board.
> I will research more on this because an on-board
> cardedge would be the choice for the final board
> (yes the one that will come inside a nice box with
> some buttons, the LCD, all the connectors, and maybe
> a PSU and a serial cable).
>
> It would help if you could show around this picture
> I sent you and ask people to give me help about how
> to design those cardedges in eagle, or have them
> designed with a different CAD software.
> Thank you.
>
> Cheers,
>
> Luigi
Hi Nigel,
I'm afraid there's something more interesting to publish. I told you I designed the missing part of the board, as per below:
http://digilander.libero.it/tcengineer/c64/dc2n/diary.html#29Aug07
Problem is that when we asked for a quote for 25 of them manufactured, they told us it would cost 6.30 pounds each!Way too much to afford them!
It may be helpful to find some hobbyist in UK that can help us to make them, instead of having them manufactured by a company that charges us so much.
Version 1.4 of the base DC2N board will incorporate that card edge connector, so there will not be reason of concern if we'll want to have it manufactured. Question now is: can you please help me to figure out how many persons would like to have a DC2N? It will cost 35-40 pounds about without any external lead or PSU if we manufacture 25 of these new boards (some components come from USA, shipping is 35 USD, customs charged me 18 euros the last time I ordered some parts). Of course, if 50 of them are manufactured, the price would be smaller...
Thank you for your help.
Cheers,
Luigi
The SOASC= project
The SOASC= project is a non-profit and a private project.
The SOASC= project is an automated recording technique invented by me (Stone Oakvalley) in order to mass record music from the legendary Commodore 64 and its SID chips (6581 and 8580).
The goal is to record the entire HVSC SID collection played from REAL Commodore 64's (both old and new) as per collection #46 (January 21 2007.) With PSID64 as the REAL C64 player and 64HHD as fileserver, it all connects to multiple PC's with own tailored software, crude PAR: port control system/C64 keyboard interface and database structure toolswritten in PureBasic. Yes, its actually working.
Also, a strong point to consider in this project is that ALL SIDs are recorded on both Commodore SID chip models regardless of what HVSC or the author of the SID had recommended. Remember: There are people out there that probably NEVER heard the elite sound of the 6581 and its sample/filter defects, but only the sound of 8580 and visa versa. For those people, they ONLY rembember the tune as played by their model. And this is a strong point of the SOASC= project: PRESERVATION for ALL!
If it crackles and pops....well..it's the true and authentic sound of a real Commodore 64! This is what we had in the past, and now the past will be the present for all Commodore 64 fans out there.
It is called AUTHENTIC because the process will NOT attempt to enhance any of the recordings, it is recorded straight plain out from the mono Commodore 64 Audio/Video connector. No stereo, no funny mixes, no compression, no filtering, no remix, no software noise reduction, no crazy SID hacks or other unatural Commodore 64 elements.
If there is a poppy click in the recording its supposed to be there. The SID chip is unique as should be treated as so as well.
I've adjusted DC BIAS to 0 and executed Volume Maximizer with no clipping using NORMALIZE.EXE and SOX.EXE. Noise Reduction was done by improving the physical grounding inside Commodore 64. Thats it!
The final MP3 (224kbps, mono, 44100Hz) will contain all information from the SID itself, sorted in respect of the directory structure as defined by HVSC. Filenaming, title, author, copyright etc.
Forget PlaySID/SIDPlay2w....and all the others
Forget HardSID
Forget ParSID
Forget ReSID
Forget MMC64 (It has an intergrated SID player, for those who wonder)
Forget them ALL!
Just listen to the real deal instead with the help of the SOASC= project!
Note: I _LOVE_ all the software/hardware mentioned above..do not misunderstand me:-)
A project this big shouldn't be done...because it IS insane. But fret not: Because, ONE crazy man called
Stone Oakvalley - will attempt this world record project in music conversion and preservation!
SOASC=
FAQ - Frequently Asked Qestions:
There are bound to be people asking themselves why I did it THAT way? Or just people beeing incredible critical, just because they have a sound system that are 20 years newer and can TODAY bring forward that awful static noise, and details you'd never heard before in authentic Commodore 64 music! This FAQ below will logically answer ALL those questions.
http://www.6581-8580.com/index.htm
A: No, its not. The keyword is "emulate". It means to simulate or reproduce something in another environment that its original environment. An artificial environment. Is this real then? No. Therefore, the music MUST be recorded from the real environment to ensure the authentic and genuine sound of the C64. Recording from hardware cards or software emulators of the newest kind is NOT authentic. That's the easy way, I do it the hard way..so there! But, don't get me wrong. The work done for the software emulation of the SID chips are really a incredible task. Respect!
Another thing is that the SID chips have incoming capacitor lines which are made out of natural elements, and this means that the filters are impossible to simulate on a computer 100%. And do rememeber that 2 similar chips and C64's will NEVER have the exact sound on both! The filters are based on nautral ingredients (which are of the analogic world) and therefore there will naturally be deviations from emulation, clones vs the real thing!
C64 is not living in a digital filter sound world... and thats why the sound is so incredible and this also apply for a lot of old synthesizer equipment from the 80's... like the Roland TB-303. Pure analog sound which is NOT comparable to software clones of today. (But that's another battle story...)
Q: "Cool, real hardware is the way to go, but what chip revisions & batch are you recording on?"
A: The chips used for recording is: "MOS 6581R4 3387 14" (Yes, no AR markings!) and the
"C= CSG 8580R5 2689 25". Hopefully the whole 90000+ tunes will be recorded on these if they do not fail during the 3-4 month process!
Q: "Hey, my favourite tune sounds wrong, I can't remember this version!"
A: In most cases the tune are authentic and is exactly how it sounded when played on a real C64 with 6581
or 8580. Remember that composers designed tunes to be perfect on the 6581, and when 8580 came out a few years later the damage was of course not possible to fix. They could not have known that the filters was changed on the 8580. This is the most important part to remember. Tunes ARE and WAS specifically designed to that of the composer had in his machine. But how the hell can you know what the composer intended? I many cases, you don't - so please use the guidelines below for help! Guidelines for choosing the correct MP3 version to download/listen to:
1: Make sure you download the MP3 file (either 6581 or 8580) as suggested by HVSC and also indicated
in our database. If still not sounding okey, proceed to step 2.
2: Download the SID file instead. Tweak settings in SIDPLAY2w to force 6581 or 8580 model to use. If the same problem (missing sounds or channels) is there, then the SID file is supposed to sound like that on the opposite model or the SID is a bad rip (difficult to determine).
3: There are known differences between 6581 and 8580 recordings. For instance the sample playback on 8580 may be low or missing. Please try the 6581 version instead. Even between revisions of the same chip the sound can be different, so remember that!
4: Please try and remember what kind of C64 you heard the tune on originally "back in the days".
Download the appropriate MP3 file, and that should be it.
5: Also, to confuze you even more. The MOS6581R4 used for recording has some really strong filtering, so if thatis not pleasing or you can't remember, a safe say would be that the MOS6581R2 version is the one you seek!
6: Download all MP3 versions (6581 and 8580) and choose the most suiting one for your ears and stick to that!
General: The sound of C64 is analogic and sounds differently on each chip and even between the same revisions!
So a quick estimate from me:
1982-1988 = Go for the 6581 versions (100%)
1988-1993 = preferred model unknown
1993-2007 = preferred model 8580 (but still not 100% trustable)
BUT also remember that tunes made 1982-2007 WITH samples will not sound correct on 8580 (in most cases) so that too is a little bit confusing I'm afraid. If the problem is still there and you are certain that something HAS gone wrong during the recording, please post the bug and we shall investigate and give feedback.
Why we didn't do this intially during the pre-recording process is simple: People was used to the music they heard on whatever model they had regardless of what the tune was originally composed on "back in the days". So, if a tune was suggested to be played with a 6581 model (like tune 9 in Last Ninja) it would have a special filtersaw string in the background. But, on a 8580 the same sound would not be present. So, for people only listening to tune 9 in Last Ninja on a 8580 model, they would not have recognized the "new" filtersaw string in the background if they downloaded the 6581 MP3 version of today. So, it was a easy decision: We HAD to record everything on both models to suit everybodys childhood memories: )
Q: "Hey, my favourite tune is missing 1 to 0.5 second (start or end), and the looping is not perfect!"
A: The tune lengths were extracted from HVSC own songlengths.txt file which do not contain that much of precision. Furthermore, it is well known that a number of song lenghts are really wrong. The songlengths.txt is a beta project still. But in time, HVSC will probably take care of this, and even adjust the lengths to more precise numbers. Its rounded to the nearest second. I have added about 0.8 second to the recording in my SIDREC software to compensate. This means that your favourite tune or sound effect will either be perfect, missing 0.2 second or having 1.3 second too much making a seamless loop not possible. The other thing you have to remember is that the SOASC= recording is an AUTOMATED process and there is NO WAY I could load each tune into Adobe Audition and manage this for approx 95000 tunes. That is IMPOSSIBLE. BUT, of course such things are irritating, so requests for re-recordings and manual mastering is an option through our FORUMS!
Q: "Hey, my favourite tune is having a click/pop audio problem somewhere!!!!"
A: Some of the SID tunes played on a real C64 contains peaks beyond what you could believe. Its a analogic world on the C64 and things CAN get out of hand. I have not used any software to prevent clipping as this can destroy certain elements of sounds in other tunes probably. Furthermore, the audio in recording volume is ONLY about 25% of the REAL signal. This should prevent clipping in 99.8% of the songs. After the recording a NORMALIZE function is performed on the tune, maximizing it to the fullest volume possible. If the peaks are already recorded with 25% volume, the peak will naturally still be there. The click/pop problem is a minority of the tunes. You should try the 6581 or 8580 version to determine if the problem is on both of them and report back to the FORUMS. Maybe even request a re-recording where the clipping is manually removed by us. And again, remember the SOASC= project is an automatically based project, no human involment to fine tune each SID song. Some sacrifices will be present, but all things can be fixed. There is hope, "keep hope alive" (C) TCM!
Q: "Hey, almost all tunes have an annoying click in the beginning!!! WTF?"
A: Yes, this is the actual software INIT being done by PSID64 for the SID chip. Its just the same click you will hear on a real Commodore 64 if you were to start the actual game or demo yourselves. I tried to fine adjust the recording to avoid this, but there are some minor milliseconds to which to work on, so a lot of tunes were chopped off about 0.1-0.5 seconds in the beginning instead. So, I decided to adjust it back to make sure the tunes were not chopped off in the beginning. Sorry for this, its just the nature of the SID chip....and since the SOASC= is authenthic I guess it have to be in there...uhh. But maybe it wont play on all MP3 players both hardware and software, depends on how for instance you have the fading between songs (ie crossfading in WinAmp) or that your ipod ignores the first 0.1 seconds and skips it...you never know :).
Q: "Hey, Have you guys deleted some recorded files, where are the "_PSID" recordings?!"
A: The _PSID are files that were back in the Amiga days hacked to be played perfectly with samples when using Amiga PlaySID. Today, the result (when played on a real Commodore 64) is sample playback missing or totally screwed up etc by using PSID64 (which the entire SOASC= was used for). I think there are possibilities to record even the PSID files by using MMC64 or another dedicated SID player on the C64 itself, but this has not yet been researched upon. In time I will investigate and prepare them for new re-recording upon the next SOASC= major recording process during 2007. Today, the PSID files resulted in incredible noisy files when processed by the SOASC= recording technique for instance. This is also mentioned in HVSC FAQ, and they have intentions to re-rip all _PSID tunes and make them real C64 ripped files which will be played correctly on a real C64. They are not really suitable and can't be trusted at all, so we filter them out!.
Today, most tunes are duplicated with both the PSID and the regular SID format anyway, so this question will be null and void during time.
Q: "What actions did you take to ensure recording of PAL/NTSC based tunes? "
A: This is a bit of a troublesome point. All tunes were played on both 6581 and 8580 PAL timed machines. This beeing of course that I live in the PAL area and have only access to PAL machines. Furthermore, the PSID64 player (used to playback the tunes in this project) might ignore the NTSC flag bit set in the original SID file. As the "TODO.TXT" in PSID64 states: "compatibility mode for PAL SIDs on a NTSC computer and vice versa."
I guess the development of PSID64 never included that, or was never fully completed. What the result is for the SOASC= is this: The NTSC specifically timed tunes will sound (in the MP3 version) a little bit slower and also be pitched slightly down (factor 1.038). This might also interfere with the "songlengths.txt" which is probably based on the PAL/NTSC timing accordingly and therefore some tunes will be in a sense "wrong" in terms of the AUTHENTIC factor!
So if a tune had a NTSC flag in it by HVSC standard (like "Norman_Paul/ForbiddenForest.sid") it will sound slower and pitched down on a PAL machine (or in the SOASC= MP3 version).
For a PAL specific tune, it would then ofcourse be played faster and pitched up instead if you did compare it to your original NTSC machine or by using SIDPLAY2 with the NTSC flag speed set on.
However I tried "Sidplay64 v0.4" by Glenn Rune Gallefoss / SHAPE / Blues Muz' and that actually played NTSC tunes different from what PSDI64 did, so I'm not sure what effect I will let this have on the current SOASC= collection. If there are numerous reports that certain tunes sound wrong, I might re-record them using the Sidplay64 instead!
Q: "Why the 224Kbps, mono and CBR MP3 coding?"
(I used LAME 3.97 Command line version to convert the recorded wav to MP3)
A: CBR is constant bit ratio which means that a silent period in the MP3 have the same compression factor as a period with sound in it has. This results in larger size MP3, but size is NOT an issue here, and also it's supported by older equipment (which also represents the 224Kbps ratio) such as DVD players, Car Stereo MP3 players, MP3 players both software and hardware. It IS yesterday's compression scheme for sure, but not everybody are hip enough to follow the bandwagon and be cool and buy all the latest ipod MP3 players and do not care about dowloading the latest MP3 player software. SOASC= is about compability in probably all environments and situations. MONO is of course the only choice when recording C64 music. C64 does NOT play STEREO sound out of the AUDIO/VIDEO connector and for the tech freaks, the CHIP inside (6581 and 8580) has only ONE audio output. Please remember, 3 VOICES OUTPUT (as written in the C64 manual) is not the same as STEREO SOUND OUTPUT, and therfore what good will a STEREO MP3 with the same audio in both channels be any point to consider??!
Q: "Why MP3? and not OGG, FLAC, Plain WAV or "that other personal favourite" format, dude?"
A: It was a totally egoistic and personal choice. This is afterall a PRIVATE project intented for my own amusement.
MP3: It's the most common format for all kinds of people and hardware. End of story.
OGG: Might be better with those "unhearable high frequencies that you would NEVER miss if you had nothing to compare too anyway!" End Of Story.
FLAC: Why should I? Better go real WAV instead, and also FLAC is a non-typical format that are not "all over" compatible "all over" everywhere. End Of Story.
WAV: That would be dream, yes. But it would take 10 times as much space. So 400GB x 10 that is. For the years to come, not an option. But in future, why not! :-)
I really can't believe if anybody would be unsatisfied with the SOASC= audio quality of the MP3's. Those higher frequencies you claim to be issue with the MP3 are frequencies in the approx 18000Hz-20000Hz range.
Note that the Hi Freq cutout example was boosted by 17DB, just to get the maximum volume for you to listen too.The Original Recorded WAV (8580) vs The 18000Hz-2000Hz range (you claim you can here this?? Maybe your dog will!)The Processed MP3 Result (8580) vs The 18000Hz-2000Hz range (is there anybody out there at all?) And the best of all. If anybody have better recordings, they are free naturally to enjoy those. But why not do the same thing with the rest of the current available C64 music as well... ohhh don't worry...it's just about 90000 tunes of manual processing work for you. See you in another dimension and in a galaxy VERY far from here! Remember that the SOASC= project is an automated process, and can be restarted anytime, anywhere with any sound specification we would ever dream of. There is no more work involved, there is no problem having the computers and C64 record for 90 days straight with an 30 minute break each 3th day to extract the results. I have no further comments.
Q: "Hmm, I'm not really impressed...I can hear static noise in the recordings!"
A: Again, SOASC= is about the AUTHENTIC and GENUINE sound from real C64's. Its the key factor! The SOASC= project records both music played on a 8580 and 6581 SID CHIPS. It records them EXACTLY out of the AUDIO/VIDEO connector on the Commodore 64 itself...so naturally noise will emerge from the chips inside.
Well, popquiz:
Did you really care about the noise back in the days?
Did you actually hear it and did you hate the C64 for that? Could you really do something about it? Did it REALLY caused so much of a trouble for you? Do you use the same music equipment to listen to C64 music (MP3 version) TODAY as you did BACK then?
No. You were like the rest of us either connected to a crappy television with horrible speakers, or you did actually have a sound system with AUX input. Now....what do you really remember? The NOISE that WAS there (trust me it was, and even more that in the SOASC= recording!) or the music itself? ...the answer is the music of course, so easy!
Anyway, when doing tests during the recording, naturally noise was detected. But, by improving the internal grounding and also connect the AUDIO IN on the SID chip to GROUND, the noise apparent in the recordings was "completely" removed.
By writing "completely" its actually based on the sound material itself. Further studies during the recording showed that tunes did vary in volume. So lower volume means the "normalize" routine had to boost the final output more resulting in more noise, but if the volume was quite high, the noise would be really totally gone!
We could of course do some software post processing to remove the noise, humm etc...but we'd never know what a typical all over setting would do to THAT particular tune, so that idea was totally ignored too!
Furthermore I DID NOT add the -b option to PSID64 (screen blanking)! There were tips about this reducing noise, yes on the 6581 I noticed so just minorly, but a number of songs were detected to be out of sync completely with this option. (It may be due to defective SID files and was confirmed by HVSC that those tunes I noticed on ACTUALLY had bad bytes in them....typically a lot of the VARIOUS\M-R\Nilsen_Ronny\xx.sid).
But since I had already added a better physical grounding as mentioned above, this option did not have any relevance to the SOASC= project and where rejected.Furthermore in the "changelog.txt" for the PSID64 project, it states: "Implemented screen blanking to improve audio quality when using the RF modulated output of your C64.". It specifically mentions "RF modulated" and nothing about the AUDIO/VIDEO out connector! So confusion is here all right.
Q: "Why not build or buy dedicated newer hardware for the purpose, such as HardSID?"
A: Again, SOASC= is about the AUTHENTIC and GENUINE sound from real C64's. Its the key factor!
All the old components and their analogic specifications make up the sound of the C64. Most of the key components around the sound chip is today totally obsolete not to mention the SID itself. You could get 95% close (with hardware) to the real sound of C64, but do I want that? No, I want the 100% real thing and so should others feel too.
Do you think the "AUTHENTIC" word is put into the SOASC= (Stone Oakvalley's Authentic SID Collection) just for fun? Ohh, yeah of course you could canibalize your precious C64 and put all the REAL components on a PCB card and play along, but man... you're destroying a C64 for gods sake, and why bother then when SOASC= MP3's is just what you will get anyway without any PCB contructing and insulting the soul of C64? Use common...no IMPROVED sense!
Q: "But why do you do it? What is the gain? What's the use, its outdated material and old!"
A: For starters, you are missing one word in the end there. It should say; "old school". That is about the things that matter when you grew up, what made you what you are today, your memories and your experiences with the C64 will be back again to say hello with the help of remembering the past and the old school days with crunchy sound and pixels in 8-bit, 16 color. Remember, todays equipment will be old school in 20 years, so its all about remembrance and the joy of "what was". There is no gain, except the result of the real authentic C64 sound:). This was an electronic and inventive challenge that I just HAD to do. Challenges make character, and it is incredible fun to be able to be creative and set no limits, what a boring life if not. Therefore, I just HAD to do it, and also because I have so many good memories from the C64 days that I would like to experience today in other situations and I still get a kick out of it. It's about human exploration and playing with your mind. If you don't understand, you're a zombie and have lost yourself...and that can't be repaired. Sorry.
Anyway, apart from that I do not trust ANYTHING else than the real authentic Commodore 64 playing the SIDS. Everything else is either emulated (by software or hardware) and I do not want to listen to music not intended to be played on anyting else than the original Commodore 64's. A lot of people seem to forget this incredible important detail when discovering the SOASC= project in general. It is just the hunt for the real authentic thing, and I stress that too much. AUTHENTIC SOUND IS ALL!
Q: "What do the future hold for the SOASC= project?"
A: The intial goal of SOASC= was to process the entire HVSC#45 archive, and then continue to update the archive whenever HVSC released a new pack of fixes/new tunes. This is still unchanged as of Feb 2007. Another goal is of course to fix recording errors and issues with the song lengths. This is a bit more tricky and manual work which will take some time to complete. It just has to be fixed when it is discovered, so patience is key.Also remember that this recording project is done entirely by one man, due to the hardware needed to process the tunes!
But there might be a innovative concept beeing presented during 2006: And this involves the possiblity for users to upload SID files to a server, specifiy for instance a new song length and other perferences, add it to recording queue, played and recorded by my automated recording techniques (on both 6581 and 8580), and then the MP3 file beeing presented as is on a different database. Upon manual verification the MP3 file will replace perhaps a bad recording, a wrong songlengths tune or just a plain new tune alltogehter, that are not even in the HVSC collection yet! This will at least let trustable users and friends of the SOASC= project to contribute and help fix the world largest and most authentic Commodore 64 music archive up to a perfect standard! This will without any doubt be a important asset to the SOASC= project....
Q: "Do you guys earn any money on this? And, you know what...you could by adding banners!"
A: Earn money on this project? Are you retarded?
Hosting this kind of massive collection online is really easy...if one cared to do it the right way!
And so we did, no CRAP - just pure, clean, serious and the tunes ready for download. No strings attached, no nags, no ads, no shit. This is a respectful archival project for the SID fans which includes myself and the website should reflect that.
So by bringing in a bunch of Google crap ads, stupid search engines plugins or ANY other kind of third-party webcode/functionalites beyond what I MEAN in my greatest belief would bring my site on a level that would be similar to SO many other archive sites out there is REALLY important. This site should be clean and 100% our design/functionalites only!If something would be added it should benefit the project...like the external embedded link to YouTube movie of the SOASC= project. Just a heads up, that I am VERY aware of what clean and serious concept/projects are all about! Death to banners, commercial ads, google ad crap etc. that DOES NOT benefit the project in question!Earning money on this project (in any way) would be subject to law as we do not own the tunes and are they are of course copyrighted to their respective composers/companies, so there will never be any banners or stuff making us rich on this. NEVER EVER, WE ARE SO CLEVER!
Q: "Are there any world records involved in this project?"
A: Hehe, well not officially recorded by Guiness Records but I guess my Commodore 64 suffered to most resets in the entire history. Each machine will during the entire recording sequence be reset via the userport about 95000 times..Guess that counts for something :) And not to mention the fact that both Commodore 64's will have played about 1450 hours of music during a 4 month period, and doing nuttin else. I guess its also the worlds longest project the Commodore 64 has ever been put through or even suffered through :) It did run for 24/7 with only a 30 minute break (power off) each 5th day. So did the 4 x PC's involved too...but we don't care about those. They are only workhorses, but the Commodore 64 is preciousssssssss...
SOASC= Project
HOW WAS IT DONE
The SOASC= project is an automated recording technique invented by me (Stone Oakvalley) in order to mass record music from the legendary Commodore 64 and its SID chips (6581 and 8580). Realizing this project needed unique hardware solutions and software to back it all up. I spent approx 180 hours on research and how to figure out a plan that would help me automatically record this massive amount of Commodore 64 music. Here is a more or less complete detailed description of all the problems and solutions I encountered.
INTRODUCTION
First download the whole HVSC SID Collection and unpack :-)
PREPARING MADNESS
I then programmed a tool in PureBasic to interpret and extract out the Path+Filename i.e. "/20CC/Conquestador.sid" and then all the subtunes length from the songslength string: "3:28 3:42 4:39 0:01(G) 0:01(G) 0:09(G)" from the file in the HVSC collection "C64Music/DOCUMENTS/Songlengths.txt"
I then made my own database .txt with and looped output like:
20CC/Conquestador.sid
3:28
3:42
4:39
0:01
0:01
0:09
#(Separator)
etc....into a large file containing all song information from the "Songlengths.txt".
MAPPING THE SID'S
Then I binary read each .SID file and checked the amount of sub tunes within it. I hacked the SUB-TUNE bit in the SID file to make the SID file start on this tune when played, and then I made a duplicate
file of it. (This is because the PSID64 SID Player could not be used to skip tunes, and my system did not have any support to send any additional keys
either to the C64. More on this later).Then I extracted out the required information I needed for the SIDREC recorder and when constructing the MP3 tags. I created a own unique .INI file for each SID sub-tune file like this, based on the information from the SID file itself:
Filename: "0000101.INI" etc etc (More about this filename later)
[SID-DATA]
PATH = 20CC/
FILE = Conquestador.sid
TUNE = 01%3:28 (This means Tune 01 is 3:28 long)
;
[MP3-DATA]
MP3-FILE = Conquestador_T01.sid.mp3 (The new filename to indicate Track 01)
MP3-TITL = Conquestador
MP3-AUTH = Edwin van Santen & Falco Paul
MP3-YEAR = 1991
MP3-COPY = German Design Group
With the above procedure the amount of files of course increased to 46668 .SID files and 46668 .INI files
FILENAMES
Then all the files was renamed (both .SID and .INI) into my own charset for usage towards the PAR: Relay C64 keyboard interface. The num of chars used in the filename created in step 3 above needed to be a little bit compressed, due to the fact that there were 50000 unique filenames and I also needed bits in the PAR: ports to send SHIFT and other special C64 keys, including reset and SCROLLLOCK detection for the 64HDD server. Anyway, a filename like "3207101.INI" was renamed to "32O7LOL.INI" Where "1" was replaced by "L" and "0" (zero) was replaced by the letter "O" This renaming caused the recording process to begin not at the top of the alphabet but really in the "VARIOUS/N-R/" directory, which contains approx 23000 tunes. And most of the "VARIOUS" tunes is not really what we all remembered from the good 'ol C64 gaming days! Gimme Rob Hubbard!
BILL GATES AND HIS "oughta's"
After the renaming of approx 95000 files was done, I had to convert each .SID file into Commodore 64's .PRG format by using the excellent PSID64.exe dos software which makes an C64 executable out of a .SID file which can be executed on the real C64 containing player code + textual information from the HVSC tags.
A couple of files was detected as not playing, or had problems being converted during this conversion process. These files will be recorded after the main project is finished using alternative recording methods.Anyway, the amount of files in this project went to a whopping 142134! (.SID, .INI and now .PRG files)
Yeah, working with these amount of files was beginning to slow down Windows XP even. They were later sorted out into 9 different directories just because DOS and WINME on the ServerPC and RecordingPC could not handle this amount of files in one dir. Stupid Bill Gates and his "...oughta be enough for everybody" shit!!! Now, I had to start on the hardware part which was a really painstaking job....
CABLES AND COMMUNICATION
Now all the .PRG files was copied over to the ServerPC HD, and by running the 64HDD software which emulates a 1541 Disk Drive for C64 in DOS, the C64 could now access the files and load+run+play them. A own cable was made (XE1541 see pictures) to support the 64HDD and was connected to the Serial Port of the C64 and the PAR: port on the PC. Getting 64HHD up and running was not the most easiest part (also due to PAR: bios setups), and the diodes used in the XE1541 cable was hard to come by. I had to make 2 of everything, and that added some delays to the project.After 1 week of constant testing and configurating it finally worked like a charm! Also, a Audio/Video 5-pin cable had to be made and was connected to the AUDIO/VIDEO connector at the C64.
KEYBOARD INTERFACE - MAGIC FINGERS TYPIN' ON THE C64'S!
To be able to load automatically on the C64 by real typing chars, an easy and crude solution had to be constructed. The result was the homebuilt Parallel Relay Card connected to the C64 keyboard connector using a IDE 44pin cable (which fits 100% by the way) The interface consists of 8 relays which are each connected to the PAR: port. By programming again in PureBasic I could switch these relays on and off by command, and thus simulating keys to be pressed on the real C64, letting me load all the different filenames including the keys to LOAD & RUN the .PRG file as well on the C64. Since I had limited with PAR: bits to play with, it was a little bit tricky to optimize what chars I needed to get everything run and record automatically in an long lasting loop for about 13 weeks! The PAR: Relay C64 Keyboard Interface was designed as follows, entry after "=" is the actual C64 key:
PAR 01-BIT01 = 2
PAR 01-BIT02 = 3
PAR 01-BIT03 = 4
PAR 01-BIT04 = 5
PAR 01-BIT05 = 6
PAR 01-BIT06 = 7
PAR 01-BIT07 = 8
PAR 01-BIT08 = 9
PAR 02-BIT01 = L - for loading
PAR 02-BIT02 = O - for loading
PAR 02-BIT03 = , - for specify the C64 DEVICE num
PAR 02-BIT04 = : - : because ":" + SHIFT + RUNSTOP = LOAD & RUN in one go at the C64
PAR 02-BIT05 = SHIFT
PAR 02-BIT06 = RUN STOP
PAR 02-BIT07 = HARD RESET C64 - Userport pin 1 & 3...cold reset
PAR 02-BIT08 = SCROLL LOCK - Off when not loading tune, ON when loading on 64HHD Server
So, by resetting C64, loading, waiting and run a SID tune .PRG file, the PureBasic code was like this:
Procedure C64_Load()
; Will write out L+SHIFT+O+"
CallFunctionFast(*out,$378,254) ; KEY L
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,237) ; KEY SHIFT + O
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,239) ; KEY SHIFT ON
Delay(del)
CallFunctionFast(*out,$278,254) ; KEY 2
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
;Will write out the .prg name
;7 letters to check
For a=1 To 7
If Mid(REC$(counter),a,1)="O"
CallFunctionFast(*out,$378,253) ; KEY O
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="L"
CallFunctionFast(*out,$378,254) ; KEY L
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="2"
CallFunctionFast(*out,$278,254) ; KEY 2
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="3"
CallFunctionFast(*out,$278,253) ; KEY 3
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="4"
CallFunctionFast(*out,$278,251) ; KEY 4
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="5"
CallFunctionFast(*out,$278,247) ; KEY 5
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="6"
CallFunctionFast(*out,$278,239) ; KEY 6
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="7"
CallFunctionFast(*out,$278,223) ; KEY 7
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="8"
CallFunctionFast(*out,$278,191) ; KEY 8
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
If Mid(REC$(counter),a,1)="9"
CallFunctionFast(*out,$278,127) ; KEY 9
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
EndIf
Next a
;Will write out the extension part ",9:+SHIFT+RUNSTOP = Auto Load and RUN!
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,239) ; KEY SHIFT ON
Delay(del)
CallFunctionFast(*out,$278,254) ; KEY 2
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,251) ; KEY ,
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$278,127) ; KEY 9
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,247) ; KEY :
Delay(del)
CallFunctionFast(*out,$378,255) ; OFF
Delay(del)
CallFunctionFast(*out,$378,207) ; KEY RUN STOP + SHIFT = LOADING AND RUN!
Delay(del)
CallFunctionFast(*out,$278,255) ; OFF
CallFunctionFast(*out,$378,255) ; OFF
; Here we wait for a signal from C64 server thorugh the SCROLL LOCK which will light when loading is on, and off when done!
MeasureHiResIntervalStart() ; Start a timer to detect endless loop in case the SCROLLLOCK or 64HDD server crashes!
Repeat
Delay(1)
SetGadgetState(#Load,1)
If MeasureHiResIntervalStop()>120 ; Seconds. If timer reached this limit, then 64HDD server is down or the scrolllock is not working!
MessageRequester("INFO","Timeout: No response from 64HDD / SCROLL LOCK - Check connection! - Please restart")
CloseLibrary(0)
End
EndIf
Until CallFunctionFast(*inp,$279)=126 Or CallFunctionFast(*inp,$279)=255 ; ScrollLock (64 server loading) detection on
MeasureHiResIntervalStop()
Delay(1000)
MeasureHiResIntervalStart() ; Start a timer to detect endless loop in case the SCROLLLOCK or 64HDD server crashes!
;Another loop because 64HDD sends a double scroll lock ON/OFF signal quite fast.
Repeat
Delay(1)
SetGadgetState(#Load,1)
If MeasureHiResIntervalStop()>120 ; Seconds. If timer reached this limit, then 64HDD server is down or the scrolllock is not working!
MessageRequester("INFO","Timeout: No response from 64HDD / SCROLL LOCK - Check connection! - Please restart")
End
EndIf
Until CallFunctionFast(*inp,$279)=126 Or CallFunctionFast(*inp,$279)=255 ; ScrollLock (64 server loading) detection on
MeasureHiResIntervalStop()
SetGadgetState(#Load,0)
EndProcedure
Of course there is more code needed, but thats not important, it was just to mess up your reading! Hehe
THE FIRST SETUP
During the first 180 hours of research of the project, The first setup with just 1 pcs 8580 Commodore 64. This setup was used for several weeks while designing the software and constructing the hardware. It was really placed in a bad position and was really annoying to have around... well..that's life.
HARDWARE SETUP - MADNESS MANIFESTS ITSELF
1 x Commodore 64 BreadBox with 6581 SID Chip.
1 x Commodore 64 WhiteyBox with 8580 SID Chip.
2 x Server PC's (33MHz and 233MHz) running in DOS mode with 64HDD as fileserver for the Commodore 64 .prg's.
2 x Recording PC's (800Mhz and 933Mhz) running in WinME with own programmed record software (SIDREC).
2 x 1084 Monitors.
4 x 15 Inch Monitors
2 x Own constructed PAR Relay to Commodore 64 keyboard interface.
2 x Homemade XE1541 Cables.
2 x Homemade Audio/Video Commodore 64 Cables.
12 x 220V Power plug connections needed.
As you can see from the pictures, the hardware setup is a real mess. But if it works, who cares :)
The keyboard and top chassis of the Commodore's are removed.
A own tool called SIDREC (for Windows) was programmed in PureBasic which controls everything and keep track of the recording process. The function of the program is to RESET, LOAD, RECORD, CONVERT, MAKE MP3 (with tags from HVSC .INI files) and go in a loop for about 13+ weeks, 24 hour a day! It also detects when 64HDD has finished loading the .PRG file into the C64, at which point the SIDREC start to record the tune. A ServerPC and a RecordPC was setup (with no cabinets for easier access) and put on a huge table with 6 CRT's and a shitload of power connectors and my god the wires!
Pictures here will tell their own story, you can see all the software running and the 8580 C64 in action.
A fan system (running at 5v) was also made to cool down the SID chip, 2 HD's, C64 power supply and a old crappy 33MHZ SX Processor!
GETTING THE BOXES
Getting hold of Commodore 64's wasn’t as easy you would have thought. I searched some Norwegian net auctions pages, and ended up with a couple of defect C64 breadboxes. My own two C64's had a busted 8580 SID chip and something wrong with the video or char chip. Anyway, during a 2 months time in search for cheap C64's I ended up having 5 pcs 6581 C64's and 4 8580 C64's.. Well, they will make a great addition to my nostalgic showcase cabinet along with the Amiga 500 and Atari 2600 from the 80's together with some old magazines, game box casing and datasettes, disk drives and joysticks..hehe!
FINAL WORDS
Well, here I am - Stone Oakvalley with the most comprehensive and insane project to this date.
Looking on the project I must say the work involved kinda payed off. For who else can claim the throne of producing the most complete, real and authentic Commodore 64 SID music database in the world? From the 19th of November 2006 the SOASC= project will record automatically & process about 1000 tunes each 24 hour session for both the 6581 and 8580 SID models. Expected date of finalizing should be somewhere in March 2007!
FACTS OF PROJECT:
Based upon HVSC #46 SID database, for both 6581+8580
66000 SID Files
97508 Files
178676 Minutes of music
2978 Hours of music
124 Days (24h) of music
One persistant human
End result? - Well: 97508 MP3 files with a total size of approx 300GB of Commodore 64 SID music.
See you around!
Regards Stone Oakvalley,
Interview with “Stein Eikesdal”
a.k.a Stone Oakvalley
The SOASC= Project
http://www.6581-8580.com/index.htm
Q - Please introduce yourself to our reader
A - My name is Stein Eikesdal a.k.a Stone Oakvalley, 33 years old, single for reasons unknown (okey, I live out on the country in a very small “town”) and I have been working as a Graphical Designer in a maritime display/computer manufacturer company since 2000. I have a very creative personal life filled with composing music, making short movies, music videos, designing crazy hardware, co-writing a 300 page black humor book about Norwegians words with lots of "puns intended" and then the latest SOASC= project.
Q - What introduced you to Computing?
A - I was introduced to computing during a Friday evening where my father had borrowed a TV game console at the local gas-station. I guess it was around 1983/84. To this date I can't remember what box that was I only remember a plane going around vertically and rescuing people and flying through cavers. I also remember some kind of base and the letters "FUEL" written somewhere. Later I was naturally hooked and my sister got hold of an Atari 2600 for the family (with PING-PONG, TANKS and the super classic Asteroid cartridges). The crazy thing, I found the Atari console at home during early 2006 and restored it back to life, but my favorite game Asteroids was gone. Well, luckily I got to play some PING-PONG and TANKS!
Q - What is your first experience of Commodore?
A - During 1987 or 1988 I finally got the beloved Commodore 64 Breadbox 6581 machine in my possession. I was so amazed about this machine at the age of 13-14. The first games I had was Sorcery and Winter Games on tape. But it was actually more interesting to read the C64 instruction manual at times than playing the games, because there was some kind of peek and pokes which really interested me. So, I started typing in basic programs and really got the hang of it. At school I would draw sprites on the grid patterned paper and writing down basic routines just out of the blue and when I got home type it into the C64 and created animated sprites and even multi colored sprites. I had a special interest of pixels really, kinda cool to see how just boxes of colors could be drawn to form known objects and humans floating around on the screen. And with the low resolution I think I actually started counting pixels by looking at demos and games. Then, other kids at school also got hold of the Commodore 64's and then the everlasting era of loading turbo tapes and watching demos took off in 1988. I was really amazed about the concept of demos. Just music, raster lines, flashing colors and scroll texts just blew me away. The greatest experience came when I heard real sampled drums on the C64. I could not believe it. I must have heard that tune for so many hours day after day. The demo was made by Lukullus and was on my system named "It's drum
time!". The music was Dulcedo Cogitationis by Mr. Chris Huelsbeck. To this date, this is my most favorite track on the C64. I just love that tune and the drums was so kick ass. Luckily for me I had the 6581 machine, because if that song was played on the 8580 chip I would not hear the drums so much and it would not make the same impression. And having said that, the 6581 sound is of course my preferred choice of today. Funny how just how one moment of music decide everything for the future. Well, suddenly the Amiga 500 came to town in 1989 and just took my soul. I had the C64 for 6 months after that and sold it to a friend. And funny as it goes, this guy is now living in my neighborhood and he still has the box in the Attic.
Some day....some day I will recapture you - my bread boxed friend!!
And to add to the final conclusion, in 1992 I missed the C64 so much that I acquired not only the 6581, but also a 8580 machine including a 1541 disc drive and started playing around again during 1992-93-94, until Commodore died and I sold the A500 and A1200 in 1997 and bought a yuck 100mhz Pentium PC. But the C64s was never sold; they were just so precious so they were stored in the attic. Amazingly enough readers...those exact machines was used in the ENTIRE process of the SOASC= project! I must have had a evil futuristic and subconscious plan for them..hehe.
The Atari, Nintendo, SEGA and PlayStation etc etc never captured me in any way...for me it was always Commodore!
Q - Do you still actively use Commodore machines (apart from the SOASC project)
A - From 1997 until ca. 2000 I was not anywhere near the Commodore 64's. At that time I was composing music on the PC/midi/trackers/with my physical instruments (like TB-303 and Roland JP-8000). The need for hearing and seeing C64 again happened sometime during 2003, and at the end of 2003 I started on a crazy project called SOMAC (Stone Oakvalley's Multi Arcade Console 2000) which was at first intended for MAME games only, but the project just blew out of its bubble and today covers 16 different emulation software and about 26000 games in the database - all with genre specification and title screens along with my own 3D Matrix Core Menu System. And my Arcade Machine is a huge monster...But during 2006 I came over a comparison on emulation vs. hardware recordings of C64 sid music and naturally began the SOASC= project out of that single moment. Now, in the aftermath of the SOASC= project (Mid 2007) I started actually loading up turbo tapes and playing again for real on the C64. It still does the magic for me, and I have played some lovable forgotten games like FireAnt and Lady Tut from the past during my summer vacation 2007. So, I guess I still will be playing on the C64 again and try to pick up more on that in the future. But, naturally the recording of HVSC updates will also require me to work on C64 for some time to come. And..oh.. yeah, just bought the MMC64 too, that is a impressive piece of hardware and it helps me with those cranky SIDs that could not be recorded automatically!
Q - Please tell our reader about SOASC what does it stand for and what did you hope to accomplish
A - SOASC= or SOASC stands for Stone Oakvalley's Authentic SID Collection. The '=' was put in there to recognize the C= brand in some way. I know it’s copyrighted, so I do not rely so much on that on the website. Just as a subtle word/graphic reference. I must point out the the "authentic" word really is what the project was about. My goal was to bring forward the music just as it is heard on the C64 if you hooked a unmodified C64 to your telly/sound system today. It is also a step back from other ideas like "pseudo stereo", stereo-sid mix or other non-natural software processing of the sound itself like software noise reduction or any filters done via software to try and clean up or improve the sound material. I wanted to keep it gritty, noisy and of course authentic. The thing is that these gritty, noisy factors are just what you remember (hopefully) on your crappy old tv from the 80's. When doing test recordings the noise was naturally very present and luckily I found a site giving tips about connecting SID IN pin to GND and thus eliminating a lot or maybe even all noise that you could state as irritating to listen to for longer periods. I accepted that modification. The only other processing done was maximizing volume and adjust bias to 0.0 with DOS software like SOX and Normalize.
But also very important for me was to provide these MP3 files on a clean web database interface with no commercial banners or Google ads. I wanted the site to be just for the project and ONLY about the project. I see so much...cr** these days on other typical sites that provides historical information or have databases about games for old computers. I really want to stand away from all that and provide the entire collection just FREE and clean. FREE on the internet today is a totally messed up concept and been so for a decade at least. Its time to put out an example of what FREE used to mean. Get your stuff you seek and get out. So simple. Nothing more. Leave all the bells and whistles to somebody else.
And so it resulted in the sites we have today, both my own 6581-8580.com site and the pathway to the "file holder" site which holds the core of the online web database engine. The interface and background tools were programmed by Svein Engelsgjerd a.k.a Waxhead and he is still the
maintainer and network guru for the SOASC= project.
Another important thing is that I respect the people who have spent so much of their time on composing SIDs on the C64 during all these years. I have always loved the demo-scene community especially (although I never was a part of it). I want to show my respect for all those composers and to bring forward/present their work in a more suitable music format that we can all share and enjoy without having to type LOAD something and wait 30mins for the tape to finish in the worst case scenario :)
Further it was a crazy project that I also enjoyed for my own personal pleasure and the question of..."could I actually pull it off, or have I reached the limit of insanity just now?". Guess not.
And not to forget, both chips had to be recorded. Not, just my personal favorite 6581. There are people out there which only remember the 8580 of Last Ninja for instance. They would not have recognized the 6581 version where for instance on track 9 there is a filter sound present which is not there on the 8580 :) I just had to support those 8580 people as well. Further even two revisions of the 6581 chip will be recorded since there is a clear difference between R4 and R2 for instance. 6581R3 will be ignored as far as I know today.
Q - So these are automated MP3 tracks recorded live of a REAL machine.
A - Yes, all SIDs and all subtunes/sounds within the SID files was recorded in a automatic recording loop, which basically goes like; reset C64, type and load, run, play, record, reset, create MP3, update current progress and loop it until the end.
Q - the mp3`s are recorded in quite a high quality 224Kbps why did you select this.
A - The MP3 and CBR 224Kbps was chosen because it is in my strongest belief that this is a format suitable for a lot of different hardware and OS's just straight out of the box. DVD players in the living room, car stereo players, old MP3 players from 7 years back and a lot of other peculiar hardware (like MP3 plug-in for the MMC64) should be able to play the MP3's just so. The CBR 224Kbps was chosen because I know that for instance my car stereo player (from 2003) had problems with 320Kbps and also VBR MP3 files. The MP3 was encoded with LAME and the command line: "-c -h -m m -b 224 -q 2 --tg 52 --id3v1-only". Some people will disagree about the 224Kbps and CBR and why not using OGG and FLAC...but for those who say that, I only ask: Can all of your hardware equipment play OGG and FLAC straight out of the box (without any additional plugins) etc?. No, generally not so simple.... but also think of your friends, do they have THAT exact OGG supported MP3 physical player in their pocket when you accidentally give them the classic sound of the C64 for them to listen to? Guess not, ey?
And there you have it, my only point and statement for why choosing CBR 224Kbps MP3. Of course seen from a preservation view WAV should be they only right choice, but the amount of space needed for that is not that simple to deal with....yet.
OGG is claimed to have a better quality of sound vs. file size and really I don't know. I need a OGG plugin for my WinAmp maybe, maybe not…don’t really care about OGG or FLAC formats. Only playable on specific software players with the plugins in place, and do I have hardware that support it, like DVD players, MP3 players..I have no idea and do not care. MP3 forvever. And since OGG is a later format and much more less commercialized, OGG was early on decided not to be used. But, I have made a nice experiment on what frequencies are being cut out from the MP3 files on my FAQ page, I guess there are some sound samples for your dog to listen to.
A quick opinion about the CBR (Constant Bit Ratio) too. PS, I'm no super expert on this, but here goes. It’s like watching today’s TV satellite streams. If you watching fast moving images and especially explosions you will see boxes of graphics shimmering/glimmering while the encoder tries quickly to uncompress the image material. That is the VBR (Variable Bit Ratio) in action. I just don't trust self adjusting real-time compression algorithms...I prefer solid stream of data...even if it takes 200kb for a blank image, I want it. I have worked with video editing, PJEG, MPEG compression on computers for 10 years now, so I’ve seen the dangerous settings to avoid. Variable Bit Rates scares me, so there.
Or, in our case if the MP3 frame is almost dead silence we would save a few k's of bytes by using VBR instead of CBR. For a song, we would maybe save 300-900kb using VBR? Maybe more, did not really check. Well, since most of us are on broadband today, there should be no argument of why not doing it CBR's way. The 224kbps was chosen just out of the hat. I felt that 320kbps was really overkill, 192 could suffice, but lower would be just a waste of effort. So I kept the quality just a bit higher to make sure that if anybody would use the material for something they would at least get more quality than needed. I did not want to skip it down to the bone and optimize my files. Keep them good enough for some post-processing or whatever people would do to the MP3 files in the aftermath.
I guess the meaning of SOASC= is not that people can have all in one pack...like the SIDS. If people did some investigating they would NEVER manage to listen to all the SIDS anyway. You know...the length of the entire HVSC is 2978 Hours of music! People download their favorite or just picks at random. After a few hundred songs I guess most of them stop and just listen to what they have. Between most people, I really think they would have a problem (after lets say 5-10 songs) to tell any difference between 160, 224 and 320kbps. At first people will try as hard as they can to identify defects in the sound material. But, as logic has it people will soon ignore the quality, get used to the quality and just listen to the music anyway. Their brain and ears would focus on other elements like environments or other thoughts. If another person had only lets say 128kbps tunes on their MP3 while jogging they would in just 5-10 minutes after forget about the quality and their ears would adjust to the material and from there... it does not really matter anymore. They'd enjoy the view and the music would in many cases become subconscious vibes of sound and not something to analyze to death or nag about not choosing OGG or FLAC for the purpose of SOASC=.
Q- are all the files recorded in mono or do you plan to have a pseudo stereo version ?
A - No, recorded as intended by both Commodore and 99% of the composers. Plain mono. There will be no other versions recorded or produced.
Q - Although the website lists how it was all done can you give our reader "a brief how to guide" on how you bulk record from a Commodore
A - First you need a stand-alone player/software on the C64 that does not require any user input to play songs and change sub tracks. There are some players for the C64 which can play the RSID and PSID files, but it requires you to press return and use arrow keys. I choose PSID64 v0.7/v0.8 because the player routine is included together with the SID itself. PSID64 creates PRG executable files which start to play instantly. But, some of the tracks lock up the C64 so you can choose sub songs that easily and secure. I then had to duplicate the SID file with the START SONG bit set to increment for each track. Then, by loading them one by one, PSID64 would start playing on that particular sub song. I even think there is some kind of WinAMP plugin that sends
the SID file to a C64 server program and plays it from there.
And so the playing system was really set up. Now comes the hard part. How do you load and run several PRG in a row. Well, first you need to LOAD a file, RUN it and then wait until the song ends and reset the C64. This can't be done without human interaction. Some specific tailored software with its own loading and resetting system would have to be programmed. Since, I don't know any advanced programming on the C64 this was no option. So, I figured I had to simulate key presses and resetting the C64 without me touching it. I drooled on robotics....but the solution was to use 2 x LPT PAR ports as relay triggers. Send a byte to the PAR: port voila you have a connection between a wire and thus simulating a key press. I made a custom relay card (thanks Waxhead for the schematics) and used a regular IDE cable with its original connecter and jacked that into the C64's keyboard connector on the main board. Since the C64 also have a handy reset functionality on the USER PORT I could reset the C64 also by sending a specific byte to the PAR: port. I had to use two PAR: ports, because I needed to type some filenames, reset C64, pressing shift together with : and compressed version of LOAD....which is L+SHIFT+O as you might remember. The physical "char set" I ended up with was; 2,3,4,5,6,7,8,9,L,O,COMMA,:,SHIFT, RUN STOP, USER PORT RESET and SCROLL LOCK detection for 64HDD.
So, where do the files come from? They came from another PC acting as a fileserver in DOS only. I used the freeware version of 64HDD to set up an simulated 1541 device by connecting a XE1541 cable from the PAR: port and to the SERIAL PORT of the C64. The nice thing about the 64HDD is that it tells you when its loading something. It turns on the SCROLL LOCK LED on the PC while loading (its an command line option) so when finished loading the PRG file it turns the LED off again. I then coupled two wires from my SCROLL LOCK LED on the PC keyboard to my own custom made relay PAR: card to detect whenever the LED was on or off. This was really an important factor of the project and without it I would have to estimate the loading time of each PRG and that could resulted in some damaged recordings.
Anyway, with the 64HDD up and running I could type LOAD"453453",9,1 and it all set to go. Then, to be able to control all this in a fluid automatic loop I created my own software which use my own tailored INI files (with actual SID FILE information) and file naming structure. My software (SIDREC) controls the PAR: ports and then typed everything automatically by sending bytes to the PAR: port. My software also uses information found in the HVSC songlengths.txt to determine when the song has finished recording. At that point the C64 is reset by SIDREC and the recorded WAV are converted to MP3 in the background on Windows. After converting, it loads the next INI file in the queue, extracts information about the filename to load, how long the song is, who composed it etc etc and stores that internally in SIDREC and then spits this information back into the MP3 file during encoding. Kinda strange and a akward way of doing it, but it did work.
Q - What were all the songs recorded to
A - Everything was recorded as 44,1Khz, MONO WAV to a 8.4GB and 6.4GB 7200RPM HDs which needed to be emptied out each 3rd day or so for 4 months. After the WAV was recorded it was encoded to MP3 and deleted. The PC hardware used on the project was nearly as old as the C64 themselves. I did not buy or have any large HD's at the time when I started recording. I spent a minimal amount of money on this project. Also, I though It would be a good idea to turn the entire system off (to copy the recorded MP3s) for 30mins each 3rd day to avoid corrupted memory or other issues with the C64 and its chips/power supplies.
Q - Can all the Mp3 be downloaded for your website
A - Yes and no. During March, May, June, July 2007 all was okay with our hosting provider...but in August 2007 they could not can handle us anymore. Actually during 2007 two hosting companies have been promoting false advertising about their accounts and storage capabilities and we had to cancel the accounts. We will alert people about this either through our forum or via hosting review companies and try to spread the word about this false advertising. We told them we intended to use the space and they agreed. Then, after some months of a 300GB packed website and download traffics (but far away from what they claim we are allowed) they asked us to leave etc. They offered us the world, and gave us only a straw....and they were all short!
Q - Have you thought about providing the files on a DVDs - how big are all the songs as mp3`s I read somewhere about 300GB is this accurate
A - The current collection as per August 2007 is 302.8GB which covers the MOS6581R4 and CSG8580R5 chips. We are planning to record the entire HVSC collection also with the MOS6581R2 version since it has a very good popularity in the community. Our 6581R4 chip has a very strong filter which is sometimes too strong, but this filter factors are very common knowledge amongst the hardcore SID lovers :)Well, I think regular DVDs are out of the question. Maybe in time when the HD-DVD or Blu-Ray discs are more common household material, such a solution might be possible?
Q - I notice you have a forum and user have asked for a Bit torrent download will this be available.
A - In fact, I use very rarly Bit Torrent files...for me its just so amazingly slow...if its not popular. So, if that is going to happen or how I have no clue about. As it is today, I'm the only one in the world with the entire collection in one place. When I have fixed some additional errors in the collection and recorded off the HVSC#47 and the MOS6581R2 chip I have some contacts that will be able to get a copy of the entire collection on a 400-500GB HD with the intent of presenting this on a radio stream or more preferable acting as a file mirror.But as it is today during 2007 I will keep the collection being spread minimalistically. I am a perfectionist and I won't give the whole pack away before I am really satisfied with the work.
Q - You must be a perfectionist if you prefer the real machine other than emulation would you like to comment.
A - In fact, before June 2006 I was quite happy with listening to emulated SIDs on the PC with like Sidplay2/w. But, the truth is that I was blown away while surfing to a emulation vs hardware recording site which featured the one and only track that ignited the whole SOASC= project. That track was Gloria by Dane and Mitch. Listening to the extreme cool difference in the beginning of the filter sequence I could not believe it. So, I loaded up my real C64 and recorded it myself and there it was. I started doing my own recordings vs emulation on other songs and found out that there is really a good difference between the real thing and emulation. But, of course in many many cases the emulation was just as the real thing..so respect for the work involved in the emulation world. But, I guess the old saying: "nothing beats the real thing" made my day...or months actually!"If emulation was perfect..." - a wise man stated once.
Q - Will the hardware and software so our reader can DIY the project be available for purchase.
A - No, I don't think so. My SIDREC software was specifically designed to work against a specific setup and it has a lot to do with the PAR: ports and their addresses and what kind of mainboard you'd have. I had a really difficult time finding old enough PC's to work with the 64HDD and to get the PAR: ports work correctly towards the XE1541 cable. The whole thing is somewhat a cruel mess and if you do not have a copy of my brain...you're in for some headaches and troubles.
Q - What was the hardest part of the project?
A - I guess the hardest and most "working against the whole universe" part was to get 64HDD up and running together with the homemade XE1541 cable and a DOS based pc. It was really picky about the main boards, processor and the BIOS setup for the LPT ports. Even the cable and the diodes I had problems finding so I tried some equivalents...nope, did not work too good. I messed with this a whole week before I almost went insane and just had to quit it all...I had no idea that the software could be so tricky to get to work. You just need "that" specific main board with "that" specific command line not to mention "that" specific setup in BIOS. And even, if you'd tried the same thing on another main board it did not work...and that was especially the BIOS/LPT setup part. But, when you finally get it to work I could not have done the project without 64HDD. Love it and its stable as a rock.
Q - What`s next is there more to perfect on the project
A - Next in line during 2007 is to setup a dedicated homemade recording rack where all the hardware (that used to lay on a 3 meters long table). It will also be TCP/IP connectivity this time in both DOS and WINXP for all the PCs. I have smacked together almost all the hardware during July 2007 which consists of: 2 x server DOS PC's, 2 x Recording WINXP PCS's, 1 x 6581 machine, 1 x 8580 Machine, 1 x 14 inch display, 2 x 12inch displays with touch screen, 5 x power supplys, 2 x cd-roms, 2 x floppy drives, 3 x PC keyboards, 1 x VGA switch, 1 x keyboard switch, 4 x HD's, 1 x 7inch CRT TV, 2 x homemade relay PAR: cards, 1 x 5 port hub and a lot of cabling! Its really called the FrankenStein rack for now :) The whole thing has been mounted into and onto a old Fisher stereo rack from the 80-90's..you know those with tape player and a record player on top.Other thing is to record the HVSC collection on a MOS6581R2 chip, just because it has its own filter characteristics which can't be ignored. Other than that I don't know, news will be posted on my site.
Q - When does the process finish is a HSVC update is issued will you re record the whole thing again or just the updates