Jump to content
Jagware
Sign in to follow this  
Tursi

BJL Source Code?

Recommended Posts

Tursi    0

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!

 

 

Share this post


Link to post
Share on other sites
Zerosquare    10

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

 

 

Share this post


Link to post
Share on other sites
Tursi    0

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.

 

Share this post


Link to post
Share on other sites
Tursi    0

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.

 

Share this post


Link to post
Share on other sites
Zerosquare    10

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.

Share this post


Link to post
Share on other sites
Tursi    0

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

 

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×