Question about the IEC lines

[Larswad]

Hi nistvan86!

It's kind of funny when I saw your project. Doing a similar one, but as a host for the arduino I will be using the Raspberry Pi instead of a regular PC. Meaning, C64<-->Arduino Uno<-->Raspberry.

I will be using the Uno as well (fits very good, it uses 5V levels so no level conversion is needed). But I'm thinking about the 10 Ohm resistors you mention on your wiki page. Are the reason for these that the c64 uses internal pulldowns? And to be sure, you DID mean 10 Ohm (not 10 kOhms), right?

Obviously you have already tested your design so it works, but I just want to be sure.

Best Regards, Lars

[nistvan86]

Hi Lars!

I'm glad somebody found this project :) I didn't had time to go on with it. I've just got my soldering station and logic analyzer to dig deeper into the problems i came across. But i'm currently investigating something simpler, emulating a dataset using the Arduino.

I think the 10 Ohm resistors are not really required because both the C64 and the Arduino uses TTL levels for communication. I've used them because the SD2IEC schematics used them on the IEC bus. However if you want to be absolutely sure you can use some kind of bus driver IC. I think it's an overkill. The lines inside of the C64 are pulled high using kilo ohm resistors as far as i remember but you can check the schematics in a service guide. So you can't really hurt the Arduino.

Do you have any project site so i can follow your work? :) I thought about doing the same using my Cubieboard but instead of proxying the communication through the Arduino i would use the GPIO ports directly with some extra electronics to translate the voltage levels. It would make things easier. However for a real 1541 emulation you would need a realtime OS (like RT-Linux) so you can be precise on the microsecond level while doing the emulation. Fastloaders and modern demos are very picky about this. I'm aware of this and ar1541 doesn't try to cope with emulating the MOS CPU because it's too slow for that. Instead my original goal was something like SD2IEC but streaming the d64 contents from the PC using the USB bus (something like 1541EMU does on the PC but without the hard timing constraint of the DOS system).

Regards, István

[Larswad]

Hi again! Indeed happy that you answered me! Well, for me this retro-fever started again as I recently bought a 128 on the Swedish ebay site. It seems like I get these attacks regularly now, with a few years between :-) I already had an old C64 in the cellar, but sadly without any cartridge, only a drive and some joysticks and a datasette. First thing was to solder me an S-VIDEO cable so that I could get a decent picture on my TV. I found a very elaborate project about that on the net, it was rather easy to do and the result was quite ok. I do have some 1541 clone "datalogic" or something lying in the cellar, but I have limited space in my appartment and I was hungry for a new project, even if I knew there was sd2iec and the more advanced (and a little more expensive) 1541 ultimate II. I already had the raspberry waiting for a project, but it was not a perfect match, since it was 3.3v, not TTL (though there are some very simple level conversion boards at dx.com to minimize the solder work). I think it would have needed a fixed 5V for that level coersion also on the 64 side, but there is none in the IEC port, only from the cassette port (and I wasn't sure if I would be able to use the fixed 5V on the PI side for that, since it might have had a different ground potential, I guess). Anyhow, there is a different problem: Even if I wasn't to start out with fastloader support, I could not really trust the Pi on microsecond timing. Linux (unless an embedded one or code on driver level) as you might know doesn't really guarantee such delays, they might be way higher than requested. I might have gotten away with some active delay loops using the WiringPi library, but it wasn't really certain. I was about to try anyway and had started to port some of the code from MMC2IEC (using qt framework since I grown quite attached to qt). But then I just for fun bought the Arduino Uno last week and I'm pretty sure it would handle the microsecond timing, well at least if I started out without fast load support, like you have. But then without having to connect an SD card to it directly, I had an idea that the Raspberry could be the host using the serial line at 115200 bps (or perhaps some fancy protocol using GPIO, like the way you mentioned). The pi could even power the arduino itself from one of it's usb port or even it's 5V pin. Or even better up, I have a dual port 2A usb portable battery charger for mobile phones,@to power them both. This rather intricate setup still needs voltage conversion of course, but this time only between the arduino and the Pi serial line (and perhaps the reset line, so that the raspberry could reset it). But I have already ordered a couple of that little simple, but yet very smart bi directional level conversion board at dx.com. So, I have ported most of the IEC handling code on the arduino side, but the arduino and pi needs some sort of protocol for communicating the D64/T64/M2I image data, shouldn't be too complicated though. So, I think I'll at least use your resistors on the three IEC lines then, I dont't mind as much hurting the arduino as my old 128 baby. At the same time I don't want to do to do more complex connections or circuits than absolutely neccessary. It's already quite....odd. Like you say, I should put up my code here. Its already in a couple of git repos on my private server. And I will, I just want to have enough done so that I won't have it in an embarrasing state. But, its comforting to hear that it will be enough to connect the 128 and arduino that way.

My very first thoughts was around using these old x1541 cables to the PC's parallel port, but in these days that wouldn't work too well since most of that software is outdated and DOS based. It also relied on some older parallel port hardware (standard parallel or so), that might not be what you have in your PC.

I will stay around and put something up as I progress. I will let you know, if you don't mind of course. If you have any ideas or some input, I'd be glad if you'd let me know. My time is rather limited though, work, wife, one 3 year old and one 4 month baby. But I do try to steal as much time as I can for this. I also hope that you continue your project here, it looks promising indeed. I have no idea what timing the fastloader support would require, but I had hoped that (if I come that far) around 1 to 2 microsecond would suffice....hmmm

Regards, Lars

[nistvan86]

Emulating 1541 is difficult because it's not just a disk drive, but a secondary computer, has it's own MOS CPU, ROM, RAM. It's funny but it's CPU clock is faster than the C64's main CPU :) The AVR is fast enough to emulate the IEC DOS commands and read the d64 images but fastloaders can optionally upload some code to the drive's RAM for execution. This means that fastloaders can totally redefine the way how the computer and the drive communicate. To correctly emulate this you have to emulate the drive on the MOS assembly level with the correct speed. That's where the AVRs speed and memory space is not sufficient.

By the way i've just found this RPi as an 1541 drive project today: https://plus.google.com/u/0/113594713230778003192/posts/97tjEXemXTF This does exactly what you like to do: use an AVR coprocessor in the middle to do the communication with the drive. The guy used the GPIO PINs of the RPi to communicate with the AVR processor but in the end i think it's very easy to alter the code to run on the Arduino and connect to the RPi with USB.

[Larswad]

Dammit, there goes the originality for my project idea! But, I will continue trying to do it the way I intended anyway. I still need a cheap compact 1541 emulation. I have also added that guy in my circles in case he could provide some nice info.

About the complexity with supporting turboloaders, yes I was aware of all that. But I have seen that the sd2iec project actually does manage that, without doing any real 6510 emulation, still only doing the emulation on the strict signal interface. It does however rely on assembly coded cycle exact timed loops (with nop's). Don't know if it is strictly for the sake of the IEC timing/handskaking stuff or if the actual disk data also needs to be available with that accuracy. If it is I would be screwed using the rpi as a storage server, I would simply have to use an sd card reader and probably an atm644p due to the need of larger code and buffers. But that's a later problem I suppose. For starters I would be happy just with simple D64/T64 support, MMC2IEC style, supporting the regular slow C64's kernal loader.

[Larswad]

Hi again! Just added a repo for my project. It seems to work now! Developed it at first with the following setup: c64-->arduino uno-->raspberry pi Worked just fine. Then I realized that the arduino USB to serial is just as good as the one in the physical gpio-pins. So I simply compiled my Qt host application to Windows target and it also works just fine.

Please try it out, if you have an arduino. You just need to solder the cable with the three pins ATN, CLOCK, DATA as you already know. Then, whatever pins you choose you configure them in the IEC.cpp constructor. I almost forgot, you should comment out anything that is dealing with the max7219 LED display. It is just a fun bonus in my project. Otherwise you can buy that display on dx.com. I will provide a link to it later on.

And..I will also post some pictures soon!

https://github.com/Larswad/uno2iec

Regards, Lars

[nistvan86]

Came here back for the same reason :)

But I have seen that the sd2iec project actually does manage that, without doing any real 6510 emulation.

As far as i remember, SD2IEC's code has autodetecting portions which know when a fastloader tries to switch to it's own protocol. The fastloader's drive code is reimplemented in pure AVR. This works for common fast loader's (like JiffyDOS), but game or demo specific custom vendor loaders will not work since there's no implementation for them in AVR.

Now that I'm about to get my hands on a Raspberry Pi Zero, I think I'll try to resurrect this thing but leaving out the Arduino. I have some level shifters from eBay which will do the conversion, so I can use the RPi0's PINs directly. Also, since we last spoken about it there are some nice articles on the net about bare metal programming the RPi, like: http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/ With this, real time programming is not impossible, but definitely hard.