| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
How to receive a byte in 1541 drivecode?
Imagine this situation:
C64 SIDE:
open 15,8,15,"u3"
print#15,"ABCDE" : rem ANY LENGTH...
print#15,"X"
get#15,S$
close15
1541 side:
I don't understand how can I:
read a byte from IEC, wait for "X" and then send back a string.
Everything I tried failed.. I am missing something.
Can anyone help? |
|
| |
Krill
Registered: Apr 2002
Posts: 2839 |
1541 ROM doesn't appear to have handy subroutines to call for receiving serial bus data with the standard protocol. The code jumps back to ROM idle loop left and right at the drop of a hat.
Since you're running own code at $0500 via U3 anyways, you can deep-copy and modify the relevant bits at http://unusedino.de/ec64/technical/aay/c1541/ro41e85b.htm - but make sure to never let ROM code handle interrupts, lest you'll lose control. |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Would have to handle all the TALK and LISTEN requests, as well as checking for the correct device number etc. Lovely. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
just steal protocol from some 2bit loader, it'll be easier to use and faster too :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: just steal protocol from some 2bit loader, it'll be easier to use and faster too :)
that's not what I need.
Clearly nobody knows the answer to my question.
What I needed is a loop to run:
something like a jsr to a routine like $E85B / $E9C9.
in a loop... trashing every received byte until a certain byte comes in.. then answering. in NORMAL 1 bit protocol. DOS compliant. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: 1541 ROM doesn't appear to have handy subroutines to call for receiving serial bus data with the standard protocol. The code jumps back to ROM idle loop left and right at the drop of a hat.
Since you're running own code at $0500 via U3 anyways, you can deep-copy and modify the relevant bits at http://unusedino.de/ec64/technical/aay/c1541/ro41e85b.htm - but make sure to never let ROM code handle interrupts, lest you'll lose control.
Yep.. exactly.. that's what I meant.
For now I don't have a good result.
Hence my question. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Would have to handle all the TALK and LISTEN requests, as well as checking for the correct device number etc. Lovely. :)
no need to check for the right device number...
One of the purposes would be also to be able to log traffic from c64 to device 8, for example running the code on device 9 and log all sent/received commands in device 9 memory or a disk.
But I also have some other ideas.
But I didn't find any similar code around, they all use 2 bit protocol in different custom ways. While instead I need a DOS compliant way. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
About traffic logging anyway, I fortunately found another way to do it...
Soon I will release another new crack of rubicon based on that method.
Because of a nice challenge with Flavio, I was able to skip the protection check on rubicon in a very "innovative" way.
More on that later... |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Krillyou can deep-copy and modify the relevant bits at http://unusedino.de/ec64/technical/aay/c1541/ro41e85b.htm Quoting ZibriClearly nobody knows the answer to my question. Quoting Krillyou can deep-copy and modify the relevant bits at http://unusedino.de/ec64/technical/aay/c1541/ro41e85b.htm Quoting ZibriYep.. exactly.. that's what I meant.
For now I don't have a good result.
Hence my question. Pretty sure what i said IS an answer. Doing the actual gruntwork of reimplementing the protocol (and also make the code just snoop, not actually talk on the bus, which is a different beast) is left to the reader as an exercise. |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
I did a cartridge version of Summer Games that intercepted the kernal routines some returned the expected error. :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I did a cartridge version of Summer Games that intercepted the kernal routines some returned the expected error. :)
Yep.. I do that often, but no, I was searching for a different thing. If nobody did it until now, the better... I will do it. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillDoing the actual gruntwork of reimplementing the protocol (and also make the code just snoop, not actually talk on the bus, which is a different beast) is left to the reader as an exercise.
Yeah.. sure... that's why I asked. If I were able I would not have asked. But anyway.. ok... nobody clearly did it until now.
I'll see what I come up with. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
If you are writing a passive analyzer it could be made to run on a second c64 connected to the same bus iec-bus. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
I'd just clip the logic analyzer on the bus and then decode the capture, much easier :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting GroepazI'd just clip the logic analyzer on the bus and then decode the capture, much easier :) Doing whatever with early 1980s stock hardware does have its charm, though. :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrIf you are writing a passive analyzer it could be made to run on a second c64 connected to the same bus iec-bus. Maybe, but the C-64's inability to read the state of the ATN line could be a problem. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Quoting tlrIf you are writing a passive analyzer it could be made to run on a second c64 connected to the same bus iec-bus. Maybe, but the C-64's inability to read the state of the ATN line could be a problem.
Good point. Maybe a userport connection instead? A few resistors could be added to minimize the loading and perhaps also sampling $dd01 using a REU. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrGood point. Maybe a userport connection instead? A few resistors could be added to minimize the loading and perhaps also sampling $dd01 using a REU. Yes, either user port or joystick port(s). The latter could also sample real analogue values, perhaps, for a true stock hardware (except the adaptor) homebrew oscilloscope. Not sure how sensible that is, of course. =) |
