Tursi Posted December 31, 2010 Report Share Posted December 31, 2010 Anyone have the actual source for the BJL ROM version (specifically 1.05.01 on mine). I have a couple of loose source codes but they look incomplete and don't match the behaviour I am seeing. Specifically I am seeing the Jaguar pulsing the busy line when I hold strobe low, rather than waiting for me to release Strobe. I want to see if that is in the software or if there is something else going on. Unfortunately I don't have a parallel port anymore so I can't compare to a real BJL setup. But if someone has one and an analyzer, I would also appreciate a sniff of the initial handshake and a byte or two so I can see what should be going on. My adapter is not giving me the results that I expect to see. Thanks! Link to comment Share on other sites More sharing options...
Zerosquare Posted December 31, 2010 Report Share Posted December 31, 2010 I have the source code for 1.05.0, which I got from GT Turbo, that got it by meeting Bastian Schick in person. Unfortunately, I don't know if he's OK with releasing it publicly (I suspect it's not the case, since he didn't put it on his webpage, unlike most of his code) ; and we can't ask him, since he's been unreachable for several years Another problem is that the code is rather puzzle-like, and the comments are in German. Do you have any particular reason for using 1.05 instead of 1.06 ? I did lots of testing for the old Catnip project, but all of it has been on 1.06, and I know that there are some differences in the protocol between both versions (though IIRC, the Catnip worked fine with the BJL-loader built into Protector:SE, which I *think* is pre-1.06). Link to comment Share on other sites More sharing options...
Tursi Posted January 2, 2011 Author Report Share Posted January 2, 2011 That's just the version that I burned into my Jag years ago. I have a working serial->parallel adapter (which I then use through USB->serial), but it's not working against BJL (which is what I made it for), and the signals from the Jaguar are NOT responding in the way that the documentation says that they should. I wanted to look at the code and see why that is, and then maybe I can make some special cases for it. Since parallel ports are becoming very rare, this seemed like a good thing. But if the author isn't going to allow people to work with the protocol, maybe it's better to let it die and use something else. Link to comment Share on other sites More sharing options...
Tursi Posted January 2, 2011 Author Report Share Posted January 2, 2011 Made some progress last night. My original theory was that the protocol was not strictly synchronous as documented, but included undocumented timeouts. That seems to be confirmed, I can now get the Jag to switch into receiver mode. But it's still not taking the program properly. Unfortunately I don't have a working BJL setup or I would just sniff the lines to get the correct timing. Thanks for your reply at least, Zero. Seems like nobody understands the protocol. The more I learn about it, the less I like it. There's not much wrong with the cable (some electrical glitching the way they did it, at least on my Jag, but not critical), but the implementation feels quite arbitrary (at least by looking at the client source code). Due to the fact that the protocol seems not to be truly synchronous, my USB->BJL chain can not work.. latency on the PC and the USB bus is always going to kill it. I verified this experimentally by moving the handshake fully to the uC, only once it was there and the timing was tuned way down did the Jag start switching into receiver mode. Link to comment Share on other sites More sharing options...
Zerosquare Posted January 2, 2011 Report Share Posted January 2, 2011 Yes, as you say, there are undocumented timeouts. IIRC, when uploading a program, you can wait as much as you like between longwords, but the delay between each byte in a longword must be quite short, otherwise the Jag side times out. There is also a different protocol for commands (such as switching automatically to 4-bit or 8-bit mode, dumping memory, etc.) which has even more severe timeouts. Basically, the protocol seems to have been designed for machines with strict timings, and the timeouts were probably introduced so as to provide some sort of sync recovery in case there's a transmission error. It was acceptable in the days of monotasking Atari STs and DOS-based PCs with low-latency hardware access, but it's a real problem on modern multitasking computers with USB devices, which cause unpredictable timings. For the Catnip project, I had to implement the protocol handling in a microcontroller to get reliable results. Link to comment Share on other sites More sharing options...
Tursi Posted January 3, 2011 Author Report Share Posted January 3, 2011 Yeah. I found I do have source code to the '97 version, which covers at least the basics of 4 bit protocol. While changing the protocol to be more reliable is trivial, it's the fact that it's already established which makes it useful. So, no big deal. I dropped the project today (although I did get the switch working -- that part is also bizarre - sending 2 bits at a time starting with bit 1 (instead of bit 0)). I just moved on and picked up an old XP PC for my needs. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now