Two questions: Trying to do some crossdev

[Brendan Robert]

1) Is there a good cross-dev solution for basic programming? I tried a naive approach of pasting basic code into Vice and it turned all the letters into Petscii... (eww!) I've not found a solution for that yet. Anyone else have/fix that issue?

2) What is the shortest path to getting a virtual PRG or TAP to run on the original hardware, assuming I currently have nothing but a C64, a USB/RS232 adapter and a soldering iron? I thought about possibly hijacking the tape pins to tie to the CTS/RTS serial signals as a sort of poor man's tape emulator. Since I don't have a parallel port and I only need one pin to bitbang, I figure it's either use an RS232 port in a hacky way or grab a raspberry pi and a level shifter to convert the GPIO pins from 3v to 5v. Either solution would be cheaper than trying to obtain any of the better known (and also better quality) solutions already available.

Thanks in advance!

-B

[Payton Byrd]

On Friday, February 8, 2013 3:40:32 PM UTC-6, Brendan Robert wrote:
> 1) Is there a good cross-dev solution for basic programming? I tried a naive approach of pasting basic code into Vice and it turned all the letters into Petscii... (eww!) I've not found a solution for that yet. Anyone else have/fix that issue?
>

CBM Programming Studio -> http://www.ajordison.co.uk/

>
>
> 2) What is the shortest path to getting a virtual PRG or TAP to run on the original hardware, assuming I currently have nothing but a C64, a USB/RS232 adapter and a soldering iron? I thought about possibly hijacking the tape pins to tie to the CTS/RTS serial signals as a sort of poor man's tape emulator. Since I don't have a parallel port and I only need one pin to bitbang, I figure it's either use an RS232 port in a hacky way or grab a raspberry pi and a level shifter to convert the GPIO pins from 3v to 5v. Either solution would be cheaper than trying to obtain any of the better known (and also better quality) solutions already available.

Do you have a 1541 disk drive? If so you can use a ZoomFloppy (< $50) to transfer disks and data to a 5.25" disk drive. If you don't have a 1541 at all then you are pretty screwed until you get SOME disk drive (unlike Apple, getting data to and from a Commodore is a readily available activity). I would say injecting software into a Commodore 64 via Userport or tape port is pretty much the least desired option.


>
>
>
> Thanks in advance!
>
>
>
> -B

[Rami]

1. You could try out the petcat program that comes with Vice. IIRC you can convert your basic programs (written with more modern editor) to PRG files and the other way around.

2. I have no training in electronics, but I easily hacked a data transfer system using the joystick port. :) With User port, cartridge port, joystick ports, serial port and datasette port your options are limitless. Plus there are probably ready-made cables and software somewhere.

[Brendan Robert]

On Friday, February 8, 2013 3:52:06 PM UTC-6, Payton Byrd wrote:
> On Friday, February 8, 2013 3:40:32 PM UTC-6, Brendan Robert wrote:
>
> > 1) Is there a good cross-dev solution for basic programming? I tried a naive approach of pasting basic code into Vice and it turned all the letters into Petscii... (eww!) I've not found a solution for that yet. Anyone else have/fix that issue?
>
> >
>
>
>
> CBM Programming Studio -> http://www.ajordison.co.uk/
>

Sweet! I'll give it a look! Thanks!

>
> > 2) What is the shortest path to getting a virtual PRG or TAP to run on the original hardware, assuming I currently have nothing but a C64, a USB/RS232 adapter and a soldering iron? I thought about possibly hijacking the tape pins to tie to the CTS/RTS serial signals as a sort of poor man's tape emulator. Since I don't have a parallel port and I only need one pin to bitbang, I figure it's either use an RS232 port in a hacky way or grab a raspberry pi and a level shifter to convert the GPIO pins from 3v to 5v. Either solution would be cheaper than trying to obtain any of the better known (and also better quality) solutions already available.
>
>
>
> Do you have a 1541 disk drive? If so you can use a ZoomFloppy (< $50) to transfer disks and data to a 5.25" disk drive. If you don't have a 1541 at all then you are pretty screwed until you get SOME disk drive (unlike Apple, getting data to and from a Commodore is a readily available activity). I would say injecting software into a Commodore 64 via Userport or tape port is pretty much the least desired option.

No, I do not have a 1541 or a datasette. I haven't worked with C64 a lot but it was really dead-simple solve on the Apple side since the Apple tape input port is analog (so you can hook up an MP3 player via its headphone jack) And also, if the apple has a serial port (//c and //gs came stock, the others usually had some sort of serial cards half the time) the firmware accepts serial input as if it were keyboard input, so it is possible to quickly bootstrap via serial. I should have added the caveat that I'm the author of Apple Game Server and I've done this on another 6502 platform already. :-D

Suffice to say I'm just looking for an easy-to-implement solution. I don't necessarily care if it is a fastload-capable one per se. If it gets really bad I can always try to put the invade-a-load stub on my program. But I think that I might have luck trying to emulate the datasette using the GPIO pins of a raspberry pi. Is the 5 volt pin always active on the datasette port?

-B

[Payton Byrd]

Ah, you are actually treading a very lightly traveled path here. I would say the tape port is your best bet for what you want to do. There is already software for sending tape data to the Commodore and hardware kits available that just plug in. Here's a Wikipedia link on the topic: http://en.wikipedia.org/wiki/Commodore_64_disk_/_tape_emulation

[Brendan Robert]

I saw that but I was not too thrilled by the level of detail. The sound format makes sense but most of the project links are dead or outdated. I already have a lot of software components needed to assemble something useful.

Thanks for all the advice folks!

[Clocky]

If you have an old PC with a Parallel port running DOS (or win95/98 DOS
mode) you can knock up a cable like this
http://www.64hdd.com/64hdd/details/c64-xcables.html and use 64HDD.

[Computer Nerd Kev]

Brendan Robert <brendan...@gmail.com> wrote:

>2) What is the shortest path to getting a virtual PRG or TAP to run
>on the original hardware, assuming I currently have nothing but a
>C64, a USB/RS232 adapter and a soldering iron? I thought about
>possibly hijacking the tape pins to tie to the CTS/RTS serial signals
>as a sort of poor man's tape emulator. Since I don't have a parallel
>port and I only need one pin to bitbang, I figure it's either use an
>RS232 port in a hacky way or grab a raspberry pi and a level shifter
>to convert the GPIO pins from 3v to 5v. Either solution would be
>cheaper than trying to obtain any of the better known (and also
>better quality) solutions already available.

Well I suggest you look at building an RS-232 adapter for the User
Port.
This was Commodore's one:
http://www.zimmers.net/cbmpics/xother.html

And here are some DIY designs:
http://www.zimmers.net/anonftp/pub/cbm/documents/projects/rs232/index.html

Once you have that and the right cables, adapters etc., you might
be able to use Over5 to transfer data IF it likes your USB adapter.
If it doesn't, I remember there was a version of Kermit for the C64.
If it is as flexible as the PC versions, it might be able to get
around the limitations of your adapter. Of course you'll have to
work out how to get the client software of these packages onto
your C64 in the first place.

Over5:
http://www.kahlin.net/daniel/over5/

cbmlink is a similar thing too:
http://www.ktverkko.fi/~msmakela/8bit/cbmlink/index.en.html

But really I think the best advice is to simply go and get an
old PC (if you don't already have one). Try second hand stores,
computer stores, friends, family etc. you should be able to
get an old Pentium 1/2 for free easilly enough. Or if you
really insist on using the machine you've got, as long as
it's a desktop you could buy a PCI parallel port card.

Then you could use 64HDD as was mentioned before, or its
free alternatives (VC1541 & 1541EMU), as well as c2n232 which
is more or less what you were thinking of with the the tape
interface.

Along with many of the options listed on this page:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/transfer/transfer.html

VC1541:
http://vc1541.sourceforge.net/vc1541/

1541EMU:
http://www.kotinet.com/1541/

c2n232:
http://www.ktverkko.fi/~msmakela/8bit/c2n232/index.en.html


Oh, or you could use the soundcard2tape set up that can be
found here:
http://www.zimmers.net/anonftp/pub/cbm/documents/projects/
interfaces/index.html

That might work with your modern PC as well. You'll have
to put up with tape speeds though.

--
__ __
#_ < |\| |< _#

[Brendan Robert]

On Tuesday, February 12, 2013 10:25:12 PM UTC-6, Chris Baird wrote:
> > 2) What is the shortest path to getting a virtual PRG or TAP to run
>
> > on the original hardware, assuming I currently have nothing but a
>
> > C64, a USB/RS232 adapter and a soldering iron?
>
>
>

> I have a Userport parallel transfer setup.. I've put-off for years
>
> getting it formally published (comp.binaires.cbm...) In a nutshell, it
>
> connects the Commodore's Userport to a (older..) Linux system's parallel
>
> printer port, and handshakes several kinds of transfers through..
>
>
>
> http://kildall.apana.org.au/~cjb/pp/
>
>
>
> 'In production', I rely on the bootloader code being in a EPROM, so I
>
> can SYS53000 to download files from the Linux server.
>
>
>
> (At this moment I'm working on a VIC20 version-- there I have a
>
> datasette, so it'll be practical to LOAD the short ~200 byte routine as
>
> needed.)
>
>
>
> Another project I've procrastinated on is turning a cheap Arduino into a
>
> IEC simulator. Similarly, there's Andre Fuchat's IEC sim project, that's
>
> a bit further along: https://github.com/fachat/XD2031
>
>
>
> --
>
> Chris

That's along the same lines of what I'd like to do. After some reading, it seems pretty simple to hook up an optocoupler as a buffer between the GPIO pins of a Raspberry Pi and the C64 tape port. Possibly even the 1541 port as well but I've done less reading about that though.

All I'd have to do is mimic the firing pattern of the +5 read signal -- but as an added bonus I could also hook up the tape sense and other pins such that the RPI program can tell when the C64 is trying to start/stop the tape. I have a lot of reading to do to figure out the timing for all of it, but from what I've read so far (and really just looking @ Vice source) I can gather most of what I need.

If that all works, then I can pretty easily do away with the standard rom routines and use a small loader stub and use a very very quick loader borrowing some ideas from stuff that Egan Ford has put together on a different 6502 platform: http://asciiexpress.net/files/c2t.html Something about 8000-9600bps transfers just seems really appealing. :-) Not sure if I can push it that far but here's hoping...

-B

[Brendan Robert]

On Wednesday, February 13, 2013 2:52:36 AM UTC-6, Chris Baird wrote:
> > That's along the same lines of what I'd like to do. After some
>
> > reading, it seems pretty simple to hook up an optocoupler as a buffer
>
> > between the GPIO pins of a Raspberry Pi and the C64 tape port.
>
> > Possibly even the 1541 port as well but I've done less reading about
>
> > that though.
>
>
>

> And don't forget that the RPi has an audio port, so the previous work of
>
> turning 'soundcards' into virtual C2Ns is available as well. (And gets
>
> around the issues of real-time bit-bang sampling under Linux..)

Yes, true. But if I can't get timing under control I can always try converting the UART serial voltages and try to convince the RPI to treat the disk drive or tape drive port as a serial device of some sort. Either way, the nice thing about using RPI as a platform is that if I have to hack some odd kludgy timing mechanism to get it working properly, it is very likely to work the same on another RPI without surprises. I'm going to try to handle this in software as much as I can because it's the domain I'm most comfortable with -- Admittedly, I kind of suck at hardware but I have gotten better at reading data sheets after writing emulation for things like 65c02, 6551, 6552, and AY-3 chips. (See: Jace, the Java Apple Computer Emulator)

-B

[Brendan Robert]

On Thursday, February 14, 2013 8:17:28 AM UTC-6, Chris Baird wrote:
> >> And don't forget that the RPi has an audio port, so the previous work
>

> >> of turning 'soundcards' into virtual C2Ns is available as well [..]
>
>
>
> Something recently discovered along that line of thinking:
>
> https://github.com/windytan/ctape
>
>
>
> --
>
> Chris

Very cool! Thank you!

In the Apple community, it was discovered that because modern MP3 and CD players can achieve a higher fidelity that tape, it is possible to achieve higher bitrate density if the delivery medium is digital. I know that the C64 tape port is not analog, but putting that aside I should be able to push things faster. Quite simply, I can just use one of the extra signal lines as a clock line. Say, for example, the tape write output. Assuming that + is high and - is low, it would look like this:

Line Byte 1 Byte 2 ....
Clock ++--------++-------- (Set by C64)
Read +-++-+++- -------- (Set by R. PI)
Data 101101110 00000000 (LSB first)
Essentially there would be a small delay (probably 8 cpu cycles or less) where the C64 has finished a byte and is ready to get the next byte, at which time it pulses the clock until it sees the first bit. This avoids much longer sync delays. There should be about 110 cycles per bit on the average if I were to get 9000bps -- so a 20kb program would load in 18.2 seconds. The next part is to use a deflate algorithm (where appropriate) and have a depack stub on the front of it to reduce the size of the data payload.

-B

[Silver Dream !]

On 2013-02-08 23:37:59 +0100, Brendan Robert said:

> Suffice to say I'm just looking for an easy-to-implement solution. I
> don't necessarily care if it is a fastload-capable one per se. If it
> gets really bad I can always try to put the invade-a-load stub on my
> program. But I think that I might have luck trying to emulate the
> datasette using the GPIO pins of a raspberry pi.

One can get very fast transfer over CASSETTE port. Marko Mäkelä's
C2N232 with a proper software loaded faster than most other mass
storage devices. So if you are looking for some soldering fun - that's
a good way to go. If you want to get the software runnning on the real
hardware without much effort, get e.g. uIEC

http://store.go4retro.com/categories/Commodore/Hardware/uIEC/

and there you go.

--
SD!