| | Repose
Registered: Oct 2010
Posts: 225 |
Simple C64->PC transfer
Hello,
I just wanted to let people know of the simplest way to transfer C64 files to PC. As far as I'm concerned, this is the ONLY way left to transfer files.
1 Intro
2 Proceedure
3 Notes
4 Further directions and question to the community
1 Intro
I just dug out my 25 year old C64 (which still works!!), and was stuck - my modern PC has no serial port, printer/parallel port, floppy disk, or modem, so even though I have an RS232 interface, XA1541 cable, 1581, and modem, these are ALL obsolete. I also have no C2N datassette, nor tape deck!
2 Proceedure
I decided to record the tape output directly to a soundfile. The connection is simple.
Supplies
-3 clip leads (wires with metal clips on each end)
-3.5mm (1/8") male to male stereo audio cable
Preparing the C64 datasette connections
Looking at the Vic20/C64/C128 tape port from behind, from left to right, note that pin 1 is GND, pin 5 is WRITE, and pin 6 is SENSE. You need to clip the leads onto each of these pins. Don't worry, the fingers on both top and bottom are the same signal.
Connecting the audio cable
Plug the audio cable into the BLUE/Line IN of your soundcard. On the other end, connect pin 1 (GND) to the inner most part of the 1/8" plug. Connect pin 5 (WRITE) to the end/tip of the plug. You have now connected the LEFT channel of the soundcard to the tape WRITE.
Preparing for data transfer
-load a program to transfer from disc
-On the Commodore, type SAVE"TEST". It will ask you to press PLAY&RECORD. Next, start recording the line-in from your soundcard, with 44,1KHz sample rate and stereo.
-touch the SENSE (pin 6) to the GND (pin 1) (touch the unconnected lead to the GND that is clipped to the audio plug). This is like pressing the button on the tape. It will save the file header, then ask you to press PLAY&RECORD again. Touch the wires again. You can wait a while for it to finish. Note that I tried leaving SENSE connected, but it didn't work. It may for you.
Saving the audio file
-save the WAV as mono, PCM, 16bit. Ideally, also save only the LEFT channel as the mono wave, however in Audacity I had to use Convert to Mono which averaged the two channels, thus adding some noise from the right channel (anyhow it still worked).
Converting the audio to data
-Download
http://www.retroreview.com/iang/UberCassette/
It has quite a good algorithm for parsing the WAV. I also tried WAV-PRG but it didn't work.
I used the command line:
UberCassette test.wav test.tap -machine c64
Testing the result in an emulator
-attach the test.tap file in VICE and type LOAD, then click Datasette control and Start. Then switch to warp mode, to speed up loading. You can then save the program to a d64 image with SAVE"TEST",8.
3 Notes
-You probably need to see the C64 screen to do this, but you can also do it blind if the keyboard is typing reliably (and you know the filenames). Just listen for the stop of the file header to touch the wires again.
-To save other data files you will have to write a short program. There's probably some poke's you can make to let SAVE work on memory.
-You should let a program save first as a test while you adjust recording levels and make your recording good.
4 Further Directions and Questions
I'd like to see a short program which can save multiple files, or a full disk to tape, and then some unarchiver on the PC side which can extract the files.
The idea is that you have to type it in by hand, so it has to be simple.
Now we need a simple way to upload to c64. Maybe the soundcard is loud enough to trigger the datasette READ pin, or else we can use the PADDLE port to digitize a sound. It will have to be a very simple type-in program, then maybe you could load a more sophisticated program.
I also thought of a way to transfer from c64->PC at 500k/s., and it's dead simple - how do you think I do it? :)
Hint: it uses a TV card to capture a video signal.
Question
What is a short way to transfer more files/disk through this audio method? If you could load a bigger transfer program to C64, how would it work?
I noticed that the short pulses were about 7 samples at 44.1KHz, so you could only go about twice faster in transfer speed.
Since this method actually reads ANY data pin, you can use basic RS232 (at about 1200 baud) to send serial output. This is already twice as fast as the tape protocol. The timing decoding will rely on the start bit.
You can use two bits at a time in a stereo recording. One can even form a clock.
|
|
... 29 posts hidden. Click here to view all posts....
|
| | Six
Registered: Apr 2002
Posts: 289 |
uIEC is cheap, available, and makes moving files back and forth a breeze. |
| | linde
Registered: Jul 2006
Posts: 47 |
Quoting Groepazits one of these features that you wont hide from the customer, because it'd set you apart from other cards that can not do it.
It's also one of those features you'll gladly not advertise/hide/disable at driver/firmware level if it means you can sell a more expensive product using the exact same chipset. Especially when it comes to consumer electronics, the goal with product design is not necessarily to get a superior $$$ per feature ratio. |
| | chatGPZ
Registered: Dec 2001
Posts: 11352 |
thats true, however in this case you will get a YUYV encoded picture (Repose: that means halved color resolution, which is a way of compression) - like what you'd get from oldish cards with bt484 - which again isnt something you'd pay extra money for in a pro environment. it falls into the "doable but not needed by anyone" category, imho. |
| | Repose
Registered: Oct 2010
Posts: 225 |
Aha, YUYV is the maximum uncompressed resolution, according to Rec.601 sampling, so you can't get any more pro that that. There's no such thing as full resolution color because of the way that composite color is encoded as a physical signal. Even HD component is sampled this way.
MPEG2 is even worse, it shares colors across 4 pixels, of a field.
And you probably mean BT848 or 878, now Fusion. This was a popular Brooktree then Connexant chipset in the 90's, the height of the home conversion/analog TV on pc era. |
| | chatGPZ
Registered: Dec 2001
Posts: 11352 |
"MPEG2 is even worse, it shares colors across 4 pixels, of a field."
same here, the color is always mixed 50:50 with the next line (in PAL anyway) |
| | Repose
Registered: Oct 2010
Posts: 225 |
Ok, let me make a more solid argument. My WinTV PVR 150 card has a connexant 25843 which is a wordwide TV decoder. This then sends uncompressed video in the digital bt.656 standard to the input of the CX23416 mpeg-2 encoder. Since the driver lets you change brightness, color etc., that's a function of the first chip. The driver certainly can access both chips. Btw, max bitrate is 15Mb/s. I would argue that they expect the home user has no interest in uncompressed, think of it, adding the mpeg-2 chip was the whole point, otherwise you wouldn't add it! So why advertise uncompressed? That's what all cards did previously, making an extra step and hogging the CPU. Not a feature to be proud of.
So your theory of it being compressed then decompressed might be proved by setting the lowest bitrate, recording some rain scene, and see if it looks horrible. Unfortunately I don't have it installed right now.
I also found a mainboard connector for the printer port, but I tried xctst, xcdtct, x1541, starcommander, opencbm, they didn't work. I tested my cable, it's an XE1541, I bought it from one of the designers. I also tried in safe mode, as some programs would just crash.
So I still have to build something. I just realized I still have one PS/2 port, which you can connect, if you want to UUENCODE keyboard keystrokes to the PC that could work :) Actually barcode readers work this way, as a keyboard input. |
| | Repose
Registered: Oct 2010
Posts: 225 |
Ok, I've done a video test. I get over 3 pixels digitized for every 2 VIC pixels. I can easily distinguish between the 5 shades of this old VIC. I would say I have a good chance of reading out the luma of every pixel of a multicolor screen, just a simple thresholding.
That's 5200 bytes per screen, using just 4 greys in FLI. That's like 152kb/s. In reality, I'll be limited by encoding speed. I could set up a screen mode, and load data directly to the graphics mem, and flip the border for every screenful, it will be instant download.
|
| | MagerValp
Registered: Dec 2001
Posts: 1074 |
FLI is used to have more than four colors in a cell. Why would you need FLI to encode 4 levels of gray? Also, using 70% of the available CPU power to encode graphics would be extremely limiting for a transfer system.
If you want to transfer data using a video capture card you can just display 8000 bytes of bitmap each frame (200 kB/s using 25 fps), but the bottleneck will be the C64's ability to deliver data. |
| | Repose
Registered: Oct 2010
Posts: 225 |
You're right, what was I thinking? Just imagine, you could fill a 512K REU with some disks and dump it all in 2 seconds. You can even backup to DVD recorder.
All I need is multicolor mode.
240k/s...
I've done some measurements, via video I get 47 pixels in the left border, 320 pixels in the screen, 45 pixels in the right border, an extra 30 pixels black. That totals 412 pixels controllable by the VIC.
My luma is evenly spread between black and white.
Now I've got to do some thresholding, morphological operations, and resizing, and I should be able to "idealize" the video into perfect VIC pixels again.
This could be a new way to rip graphics, or compare pixel by pixel emulator vs real and automatically search for differences! I can also do OCR on a given charset.
Color will be harder though, actually I can't work with it right now because some problem with this VIC.
|
| | Repose
Registered: Oct 2010
Posts: 225 |
Update: I got a keyboard cable and I'm going to try interfacing the c64 to the PC. You can use the c64 as a PC keyboard; but most important is to hit a key and send a uuencoded file. On the pc side, just open notepad and let it fill up, then save and run a uudecoder; your c64 file then appears.
Other uses; use a real 1351 mouse with a c64 emulator :)
I found a floppy drive but it didn't work; I found a modem but couldn't connect modem-to-modem directly. Hint for anyone else though, try ATD&C0 to avoid needing to wait for a dial-tone; the other side should type ATA. You may also need a line simulator. I also found a parallel port connector but couldn't get it to work either :( I could dial-up PPP from C64 and telnet my files; but I don't have Novaterm 10 currently on floppy. This is driving me nuts!
I also can't order SD2IEC, I don't have credit card.
I decided on 8 bit binary for video transfer; a charset with horizontal white lines in all combinations. Bytes in screen memory can be directly read out. I wasn't able to read correctly 5 greys every 2 (hires) pixels reliably without more programming effort. |
| Previous - 1 | 2 | 3 | 4 - Next | |
