Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Commodore » Commodore 8-bit » Re: Two questions: Trying to do some crossdev
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Two questions: Trying to do some crossdev [message #36882] Tue, 12 February 2013 23:25 Go to next message
Chris Baird is currently offline  Chris Baird
Messages: 172
Registered: December 2011
Karma: 0
Senior Member
> 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
Re: Two questions: Trying to do some crossdev [message #36896 is a reply to message #36882] Wed, 13 February 2013 02:30 Go to previous messageGo to next message
BLuRry is currently offline  BLuRry
Messages: 489
Registered: October 2012
Karma: 0
Senior Member
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
Re: Two questions: Trying to do some crossdev [message #36897 is a reply to message #36896] Wed, 13 February 2013 03:52 Go to previous messageGo to next message
Chris Baird is currently offline  Chris Baird
Messages: 172
Registered: December 2011
Karma: 0
Senior Member
> 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..)

--
Chris
(Seeing a reply means my newsserver is working again too.. :)
Re: Two questions: Trying to do some crossdev [message #36981 is a reply to message #36897] Wed, 13 February 2013 11:59 Go to previous messageGo to next message
BLuRry is currently offline  BLuRry
Messages: 489
Registered: October 2012
Karma: 0
Senior Member
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
Re: Two questions: Trying to do some crossdev [message #37106 is a reply to message #36981] Thu, 14 February 2013 09:17 Go to previous messageGo to next message
Chris Baird is currently offline  Chris Baird
Messages: 172
Registered: December 2011
Karma: 0
Senior Member
>> 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
Re: Two questions: Trying to do some crossdev [message #37107 is a reply to message #37106] Thu, 14 February 2013 11:10 Go to previous message
BLuRry is currently offline  BLuRry
Messages: 489
Registered: October 2012
Karma: 0
Senior Member
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
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: I'm a C64 n00b, looking for help
Next Topic: PDXCUG.org Meeting - Thurs., Feb. 14, 2013 (fwd)
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Apr 19 09:21:25 EDT 2024

Total time taken to generate the page: 0.08861 seconds