| | 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.
|
|
| | chatGPZ
Registered: Dec 2001
Posts: 11352 |
do you seriosly think this is "simple" compared to just using warpcopy?
the video capture idea has a fundamental problem btw: most (cheap consumer) cards will give you compressed frames and will not work very well with pixelised patterns. |
| | Repose
Registered: Oct 2010
Posts: 225 |
Let me clarify my statement, the ONLY way to cheaply/simply transfer files at home, with a modern PC which has no serial, parallel, floppy, or modem, and you have no datasette or tape deck.
RRNet is currently sold out, besides it costs 49 Euro and I have to order from Europe, which would take a long time for shipping. It's absolutely not an option at this time.
I have been using my method for some hours now, once set up it is really simple to use, however I want to transfer multiple files at once.
Your point about compressed video is well taken, however there's always a way to record uncompressed video (use Virtualdub). Also, I have managed to decode Closed Captions (a US system like Teletext, roughly) (white lines in video) on compressed files with no problem.
I have written this program to transfer multiple PRG files.
-LOAD"$",8
-list only the first 20 filenames
-load my program
-Turn each filename into a data statement; type a line number, followed by dA just before the filename
-You can run my program now
It's a very limited program and very slow.
1 rem enter filenames here, eg data "basic"
99 data"$"
100 restore
108 poke55,0:poke56,16:rem set bastop to $1000
110 readf$
120 iff$="$"thenprint"finished!":end
130 rem copy the file to memory
140 gosub1000
150 rem save the memory section to tape
160 gosub2000
170 goto110
180 close1
1000 rem copy a prg file to memory
1001 print"buffering "+f$
1009 rem set buffer safely beyond this program
1010 ba=16*256
1015 i=0
1020 open1,8,2,f$+",p,r"
1030 get#1,a$
1040 pokeba+i,asc(a$+chr$(0))
1045 i=i+1
1050 ifst=0then1030
1060 print"length was";i
1070 close1
1080 return
2000 rem save buffer to tape
2001 print"saving "+f$
2010 forx=0tolen(f$)
2020 poke49152+x,mid$(f$,x+1,1)
2030 next
2040 poke184,2:poke186,1:poke185,2:rem setlfs
2050 poke187,0:poke188,192:poke183,x:rem setnam
2060 bh=int(ba/256):bl=ba-bh*256
2070 e=ba+i
2080 ch=int(e/256):cl=e-ch*256
2090 poke193,bl:poke194,bh:rem start addr
2100 poke174,cl:poke175,ch:rem end addr
2120 sys62941+13:rem save memory
2130 return
|
| | chatGPZ
Registered: Dec 2001
Posts: 11352 |
Quote:Let me clarify my statement, the ONLY way to cheaply/simply transfer files at home, with a modern PC which has no serial, parallel, floppy, or modem, and you have no datasette or tape deck.
you are mixing up simple and cheap. its not the same thing and usually doesnt come together either.
Quote:Your point about compressed video is well taken, however there's always a way to record uncompressed video (use Virtualdub).
only if you have a very old capture card - new ones usually give you mpeg2 (mine is 10 years old and it does that already) |
| | Bitbreaker
Registered: Oct 2002
Posts: 504 |
Sounds rather bloated in a world where things like 1541u, network or zoomfloppy exist. The stuff will cost some money, but way less time :-)
Still if you stick to the audio-method: You won't be able to save below basic/kernal/io. Whole disktransfer or such would need selfmade routines. |
| | Repose
Registered: Oct 2010
Posts: 225 |
Yes, I also have an mpeg2 card. Yes, there is a way to record uncompressed. http://forum.videohelp.com/threads/342352-Capture-Lossless-with..
1541u is also sold out! Come on people, it's not fair to compare to unavailable projects. I also have 1571 and little red reader, but it's impossible to find 5.25" drive for PC anymore. I like zoomfloppy :) But I can't tell if it's available. I also don't have credit card ;(
I will have to write a whole disk transfer, but that will be so big that it's better I solve the inverse problem first, a simple program to transfer to c64.
I can connect SD card to C64 directly, it's 4 wires, voltage divider and a driver, but then I have to interpret the filesystem also :(
Meanwhile I've recovered old demos I wrote and enjoying them; started to finish a compiler I was working on...
|
| | chatGPZ
Registered: Dec 2001
Posts: 11352 |
Quote:Is there ANY other way to do this, that I can buy right now?
usb->rs232 adapters are widely available and work fine with the respective transfer solutions (over5, serialslave etc pp)
Quote:Yes, there is a way to record uncompressed.
uh well. a forum thread and there is exactly one person who thinks its uncompressed. and another who mailed the manufacturer of the card and got a different answer. not convinced =P |
| | Repose
Registered: Oct 2010
Posts: 225 |
Thanks for the suggestion, however I don't have an RS232 adapter on the C64 side. I thought I had a Swift232 at one point, but I can't find it now.
Good idea though, if I can find a USB printer port that could work, but will it be exactly compatible to DOS parallel port programs ? (at 0x378).
And the HCW2 has a constant data size per pixel, so it can't be compressed, it's an obvious argument. Well, I can't see any blockiness anyhow.
Don't expect tech support at a company to know these details; on the box it says compressed and they just repeated that statement. This is an undocumented feature. |
| | chatGPZ
Registered: Dec 2001
Posts: 11352 |
Quote:Good idea though, if I can find a USB printer port that could work, but will it be exactly compatible to DOS parallel port programs ? (at 0x378).
no. guess why i said rs232 adapter. it will not work with any software that does bitbanging on a portpin.
Quote:And the HCW2 has a constant data size per pixel, so it can't be compressed, it's an obvious argument.
it can (and probably will be) still come out of the encoder, just with "maximum quality" settings. its not raw untouched video. and as someone in that thread said, if the card could really actually do it, it would say so on the box. its 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. |
| | Repose
Registered: Oct 2010
Posts: 225 |
Hmm... rs232 it is. I think some rs232 chips can actually handle 0-5v even though the standard is supposed to be +-12v. Or else I'd have to build a translator.
I've been looking around at the projects you mentioned; I'm afraid some of them are dead. I found a message about 1541u-II dated 2009. I think we really need a simple project like mine that someone can put together in an hour unitl they can order something better.
I even have a portable floppy but it's for some older port, not USB.
About HCW2, your reasoning sounds good, however you're saying the uncompressed output came from a compressed source; that means the card has a decompressor in it as well! That's unlikely.
The simplest theory would be that it's an uncompressed stream that taps into the encoder chip in the very earliest stage of compression; at this point it's just a data rearrangement.
If it is just a high bitrate stream, that's fine for our purposes. I'll try a decoding test on a video transfer technique anyhow. Avisynth is my friend :)
|
| | Bitbreaker
Registered: Oct 2002
Posts: 504 |
Zoomfloppy works fine, as for what i saw (my boss trasnferred his disks with that these days). Also if pondering about serial/parallel, why not obtaining one of those cheap usb<->serial/parallel adaptors?
If thinking about network, the wiznet module can be easily adapted to work with a c64, all you need is a 74ls139 + 3,3v voltage regulator. I'd even have some selfmade adaptors laying around to mount it directly on a clockport without any extra soldering (for e.g. RetroReplay). That is for what i did the new 64net-stuff. |
| | MagerValp
Registered: Dec 2001
Posts: 1074 |
Well modern computers come with a webcam, and the QR generator released the other week got me thinking...
Here's a first very rough test release of QR xfer, which load a file from the C64 and displays it, 32 bytes at a time, as a QR code. Place your laptop with the webcam pointed at the C64 screen (you'll have to turn down the brightness/contrast on the monitor if the room is dark) and press space to advance. All you need is a free QR reader app on your Mac or PC, e.g. http://www.dansl.net/blog/?p=256
It's just a quick proof of concept, and the directory viewer code is buggy, but give it a try: QR xfer
|
| | Repose
Registered: Oct 2010
Posts: 225 |
Brilliant! That's the innovation I had hoped for. There should be a range of solutions, from wires to basic electronics.
Remember, someone said the USB parallel peripherals are not compatible to the old DOS software, maybe we need new software then.
Where's the thrill of solving an engineering problem just for the sake of it, anyhow? What about the DIY spirit of making cables or basic electronics? Modern technology is killing it!
It seems to me that a lot more could be done if we get an xfer to the c64 first, which can allow much more sophisticated transfer. IR transfer? Flashing square on the PC screen, and CdS on the POTX? |
| | Bitbreaker
Registered: Oct 2002
Posts: 504 |
The usage of POTX reminds me of a scanner that i did once with some duct tape, a bent piece of metal, glasfibre, photo-transistor and a needle-printer. A tightrope walk beteen DIY and ghetto-style :-)
As for the adaptors, why stick to dos when even having no pc at hand that has a parallel or serial port? I guess you'll use a modern multitasking enabled OS? Even more when you do your own protocol, you can pretty much cope with delays and interruptions.
And what is so bad about the network idea? There's even wifi modules available meanwhile.
And how's about speed? 32 bytes per space is yet a bit ... slow? :-) |
| | linde
Registered: Jul 2006
Posts: 47 |
I did some sort of transfer interface with a hacked competition pro, transferring four bits at a time. It worked fine at home, but when I tried it with a CRT, after a lot of head scratching, I found that I had to turn off the monitor for it not to generate a lot of errors :). It was quite fast, though! |
| | Repose
Registered: Oct 2010
Posts: 225 |
Bitbreaker,
That's amazing! I had the same thoughts regarding computerized sewing machines. I've even saved the gears and rods from a scanner and bought some stepper motors and a controller. There's so much that can be done with an X/Y scanning mechanism.
As far as an actual scanner, I once made one even simpler - light up dots on the screen one at a time, and measure the total light output. This required a transparency taped against the screen and a hood or dark room. It was further complicated by the fact that one dot couldn't be read, so I lit up various areas and subtracted them, so in fact it turned into some kind of iterative backscatter :) (referring to a similar Computed Tomography algorithm)
I had to look up Competition Pro, this is a German joystick. So you mean you used a 4 bit interface on the joystick port, bits D0-D3 of $DC00 or $DC01, between two computers. Since two computers can connect to one disk drive and everything still works normally, you could make a computer to computer transfer this way too.
There's nothing wrong with making a network interface, and that would be in the medium category of DIY.
There's also nothing wrong with non-DOS compatible USB parallel port, my point was that no existing (legacy) software projects would support it, so someone would have to write new software.
I'm going to do an experiment with video-transfer later, busy right now though, doing my Electrical Engineering homework with MOSFET design :)
|
| | Repose
Registered: Oct 2010
Posts: 225 |
p.s., is there a well-know C64 Wiki where I can post my app (non-demo) related projects? |
| | MagerValp
Registered: Dec 2001
Posts: 1074 |
github. |
| | chatGPZ
Registered: Dec 2001
Posts: 11352 |
"I had to look up Competition Pro"
wtf |
| | Repose
Registered: Oct 2010
Posts: 225 |
G,
I'm from America, I'm starting to guess that this board is dominated by Europeans. I wouldn't have heard of this foreign product. In fact, the only reference I could find to this was on German Wikipedia, which I had to translate. |
| | 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. |
| | Style
Registered: Jun 2004
Posts: 498 |
i like the video capture idea - I wonder if you could use a webcam and some sort of pattern? instead of ~8k per frame, use chars and do ~1k a frame....
|
| | Repose
Registered: Oct 2010
Posts: 225 |
If you didn't read the thread, a simple hack has already been done - 32 bits with 2-dimensional Q-codes. Look above. |
| | MagerValp
Registered: Dec 2001
Posts: 1074 |
Repose: did you try decoding the QR code my transfer program generates? |
| | Repose
Registered: Oct 2010
Posts: 225 |
Mager,
I did try it in an emulator, however I am currently unable to transfer files to my real c64. I think it's cool and would love to try it sometime, though!
|
| | Repose
Registered: Oct 2010
Posts: 225 |
I have a question about The Star Commander. I'm using FreeDOS 1.1, on computer 2 (old one I built just for this). I set preferences to XE1541 cable; turbo mode with async. sc.exe runs, displays a directory on the right-hand side, then crashes (no keys work) and I have to reboot. I've tried different memory configurations (EMS/XMS combinations). What settings could I try? Could there be some imcompatibility with FreeDOS?
Amazingly, I still have to write my own program because nothing else works.
*vent* - I've been working for *days* to find someway to transfer my files. I used self-made cable and program, but didn't work - I think my BIOS is buggy (on computer 1 - main computer), because I set LPT1=$378 in BIOS but tables at $400 don't show this, and none of the ports actually work.
Does Linux take over from BIOS and directly access the Super I/O chip?
Today's job, try new BIOS on computer 1, try self-made programs on computer 2, find other programs to try, try real DOS and Linux on both... |
| | MagerValp
Registered: Dec 2001
Posts: 1074 |
Or you could just buy one of the transfer solutions that work with modern hardware:
http://store.go4retro.com/zoomfloppy/
http://store.go4retro.com/categories/Commodore/Hardware/uIEC/
|
| | Repose
Registered: Oct 2010
Posts: 225 |
No credit card.
|
| | DemongerX
Account closed
Registered: Jun 2002
Posts: 137 |
Cash onto a prepaid card. Works for most purchases like that, online that is. I know they don't work well in some systems, as it sees them as a gift/rebate card, but I've had good luck using them.
DemongerX |
| | Repose
Registered: Oct 2010
Posts: 225 |
Thanks, never heard of prepaid cards, but I can buy it. Problem is, I need to know the total, because the amount is not refundable. I'm happy; I want one. However, I am wondering if there exists software support for direct communication to c64 over IEC to PC? And to use PC as a virtual 1541? Will it work with 64hdd? (for Zoomfloppy)
|
| | Repose
Registered: Oct 2010
Posts: 225 |
Good news! I finally got Star Commander to work. Now my question is, what to do about disk errors? How can I fix them? Should I nibble my images to preserve as much as possible?
I don't need to buy anything anymore, free is good. |
|
