PRINT#ing multiple times will hang the arduino/c64 combination

[biappi]

using this BASIC program:

10 OPEN 1,8,1,"TEST
20 PRINT#1,"TEST1"
30 PRINT#1,"TEST2"
40 CLOSE1

the c64 will be blocked in execution of line 30 waiting a response from the arduino side.

the problem is that the handleATNCmdCodeOpen will leave its reply in the serial buffer, which is correctly handled the first time handleATNCmdCodeDataListen or handleATNCmdCodeDataTalk are executed, but, if the c64 wants to send more data like in my BASIC example, the arduino code will wrongly wait for another open response on the pc serial communication.

the delayed handling seems pretty much deliberate, fixing this bug would require a bit of different "high level" thinking, that's why i didn't work on a patch. (yanking out the open return handling will make it work, that's as far as i got)

[Larswad]

Yes indeed, things like this really has to be considered.
My current "work package", is to implement real channel support, meaning that for each channel, on the PC side it should maintain a buffer for each channel, part of this is because I need to support this properly to get the command and error channel working properly.
So, I guess part of this will be that I have to rewrite these Open/Listen/Talk routines to get it working.

Indirectly, when I get the error and command channels working I can get all commands implemented, such as the M-R, M-W, M-E commands (those are indirectly needed for detecting what turbo to emulate).

But, time is indeed short for me due to kids and work, but soon its summer and vacation :-)

[biappi]

eheh, yeah.

i did some experimentation in reimplementing the protocol (i prefer to have a command line approach to my debugging) here https://github.com/biappi/iec-py/blob/master/serialproto.py

one thing that i was thinking, maybe it could be worth to have the arduino side completely stateless, and implement it only as a IEC2serial, and implement all the logic on the pc side, this would make things simpler in the embedded side

if one want, it can write an arduino side application that includes the iec2serial as a "library" of sorts, to create more complex or maybe a standalone arduino solution.

but that's just babbling. =)

[Larswad]

Yes, you know I've had the same thoughts too, on and off, and to some extent I think the Arduino side indeed can be simplified. But only that kind of logic that doesn't need to be done in strict microsecond timing, if you know what I mean. It could only work for things that can tolerate the
PC<-->Arduino turnaround. That requires at least a little thinking.

I have also been playing around with some thoughts, that make this projects future a bit shaky.

1. Porting sd2iec to the Mega (+ an sdcard in that case, dropping the PC). Well, I've started and it actually starts up but at first attempt I didn't get any life on the sdcard. Something I have missed (the sdcard works in a regular arduino sketch).
2. The other thing is the previous solution but with an addition: In sd2iec add a new file system driver that babbles over serial line to the PC instead. It would be perfectly possible to do, even for turbo because in between "buffer-filling" there is no real demands on fast timing.
3. Keeping this project's code but redesigning it work with a local sdcard instead. But this is a weak argument since sd2iec already does these things much better.

So, I'm a bit hesitant how to proceed. All I know is that I want to do it with an Arduino, because everyone can buy it everywhere, cheap.

[Larswad]

Hey, looked at the python code now, very cool indeed and very compact (especially for debug purposes). Wow, you have indeed dug down in the code!

[biappi]

for what is worth, i decided to use your project because it was ridiculously easy to assemble the hardware (this is indeed my first hardware project, i have no knowledge of anything at this level) and relative ease of hackability of the code.

i speak from ignorance now, but would makes sense to have the arduino side only deal with the IEC details like TALK/UNTALK/TURNAROUND ecc, like the c64 KERNAL, and maybe implement communication using two ringbuffers, one IEC side and the other serial side, such that everything can be as fast as possible?

judging from page 13-14 of http://www.zimmers.net/anonftp/pub/cbm/programming/serial-bus.pdf it can translate well directly over serial, maybe with the only assumption of having only one device on the bus, i'm not sure. i lack all the knowledge of how to deal with timings and the debug tools to inspect the actual hardware =).