search

Larswad / uno2iec

A commodore (CBM) 1541 emulator on the Arduino Uno, using any desktop PC (or raspberry PI with raspbian) as a media host.
http://larswad.github.io/uno2iec/
135 stars 37 forks source link

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

Open biappi opened 9 years ago

biappi commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 =).