Zerosquare

Did you read the post above ?

Right But since we're only looking for the number of buyers (not the percentage), I didn't see the point of including a "No" answer.

Don't be sorry. These posts are the most relevant, and have been translated :http://www.jagware.org/index.php?s=&sh...post&p=3733 http://www.jagware.org/index.php?s=&sh...post&p=3805 http://www.jagware.org/index.php?s=&sh...post&p=5116 No, the JagCF is not required. Although the Catnip Cable can be used to update the JagCF, it is also a standalone USB-based BJL transfer cable. Sorry, I don't understand what you mean ?

(If you do not know what this is about, read this topic.) At this point of the Catnip Cable development, we'd like to know how many people would be interested in buying one. Although this is not a preorder, note that the results will affect the project's future. Consequently, please vote only if you're reasonably sure of your choice. The price should be very approximately around 30 € (that's US $39). We cannot give a more precise estimate at the time, as the production costs are not fully known yet (they depend on the manufacturer we'll choose, on the number of clients, etc.) The poll has been posted on AtariAge, Jagware, and Yaronet, therefore you can vote if you're a member of one of these sites (if you are a member of several, please vote only on one of these).

Yes, but it was used under DOS, isn't it ? I'm not sure you understood me... Even with optimization, I don't think the problem can be completely avoided as long as there are other tasks running in the background...

I think the problem is because of Windows' preemptive multitasking, you can't be sure that your program is not going to be interrupted at a critical time. In particular, the four bytes of a 32-bit BJL word have to be transmitted in a burst-fashion -- if you wait too long between two bytes belonging to the same word (which can happen if the kernel decides to switch to another process at this time), the BJL ROM apparently discards the word. I've done some testing with my Catnip prototype, which allows precise timing, and the transfers work 100% of the time if the delay between bytes of a word are limited to a few microseconds. I've left the delays because when I removed them on the Catnip, it didn't work any longer -- apparently BJL doesn't like too fast transfers either, even if you use the STROBE/BUSY handshaking. But if the transfer is too slow to begin with, it makes sense that removing them would lower the risk of a time-out. You mean Jagmania has the ability to receive data via BJL ? I didn't know that. I'd be wary of using it for testing, though, as the BJL ROM doesn't always behave as you would expect in theory. For example, I've written my own implementation of the BJL receiving-side, and it worked perfectly, even when using the uploader under Windows. Keep up the good work.

Hi Matthias ! That's what I was afraid of. It seems that the method I use is not good enough. On the other hand, now I know it's not a bug I introduced while making the changes. That's very kind of you !I don't know if there is a way to make it more reliable besides writing a custom driver, but maybe you have something else in mind ? Anyways, I really appreciate the help

Yes, that's the one. Thank you.

Argh ! It seems to be less reliable than I thought Could you do me a favor and test the version I posted in this thread (it's the latest "stable" one) ? I've made many changes to the uploader since, and I'd like to know whether your problems are related.

Oh, that's what you meant by "setpath". I thought you were referring to custom environment variables (some compilers need them, for example), not the generic PATH one. Yes, you DO need to add the directory which holds the program -- thanks for mentioning it By the way, sorry for repeating myself, but if the program you have is named lo_ba.exe, then you've got the old, buggy version -- download it again to get the new one, which is named lo_par.exe. Thanks ! I don't understand The syntax is the same as the original BJL uploader. Matthias, many thanks for taking the time to do some testing ! Lost bytes can occur because the BJL protocol is timing-dependant, and can time out if the data is not send quickly enough. Since Windows is not a real-time OS at the application level, it can happen (context switching at the "wrong" time, etc.). Still, I'm surprised you have problems, especially under Windows 98 and when NOT using the -x option. It has always worked fine for me. Do you have a CPU-intensive application running in the background ? The slowdown occurs because when using Inpout32.dll under NT/2000/XP, the system has to switch between application-mode and kernel (driver)-mode on every port access. The severity of the problem seems to be machine-dependant. Both problems could be fixed by writing a custom Windows driver. Unfortunately I don't have the resources to do that now

Have you already found this post ?

Yes, you're right. In fact, inpout32.dll allows access to any port ("port" meaning anything in the processor's I/O port space, not just things like the printer-port), under any Windows OS. The homepage is here, and the license is here (basically, free for non-commercial applications, and donations appreciated otherwise). Great, thanks for testing ! By the way, I see you're using the first version I've uploaded -- be aware that it has a bug which I've fixed since. I've updated the file posted earlier in this thread. Yes, this is a "feature" If you do not use the -x option, the transfer is given maximum priority, so others things (like the display) tend to lag.

Just unzip it into a directory, no particular setup is needed. If you're not interested in the code, you can remove every file except Lo_par.exe and inpout32.dll. Usage is the same as Bastian Schick's BJL uploader (I assume you know how to use it). By the way, here is the doc for the previous version called Lo_inp -- most things are still applicable (I'm too lazy to write a text file for this release, since it's a draft ). Let me know if you need more info. Lo_inp.txt

That depends on whether you're interested in Jag tools development. If you're not, then it's similar in functionality to the modified Windows version of the BJL uploader I posted earlier -- internal code modifications shouldn't affect you. You can help by testing whether it works OK for you (to make sure I didn't break anything while making the changes). If you are, then it's an attempt to create a reusable BJL API, and modify the existing uploader to use it instead of accessing the hardware directly. I'll be glad to hear about what you think of it (any functions I've forgotten, better ways to do stuff, others ideas, etc.).

No comments yet ? NOTE : There was a bug in the previous draft version which could occasionally corrupt transfers. It has been fixed, and the file in the previous post has been updated. The name has also been changed, but it is otherwise the same thing.

Here's the first draft of the API, and a modified uploader using it. It's by no means final or perfect or anything, just something to show what I have in mind. And it's actually functional (under Windows that is - it's supposed to work under Linux too, but I've not tested it at all yet). If you're a Jag developer, please take a look at the sources (bjl_api.h can be used as a summary) and offer your comments and suggestions ! (To swapd0 : I haven't implemented your bit-by-bit input code yet, but I will. Honest ) Don't want to beat my own drum, but I have 0% failure with my BJL-based Catnip Cable too. Anyways, serial may have its advantages, but : The hardware is buggy, and there is no publicly known way of fixing it (though CRC could probably be used as a workaround, as Songbird said) It requires extra hardware. Well BJL does too, but the parallel cable is cheaper and easier to make. It requires new software on the Jag side. BJL is already available, in at least 3 different formats. It requires new software on the PC side. BJL code has been around for years. There is a significant number of BJL users already. I assume you're thinking about JUGS ? Please keep in mind that everybody cannot afford it, and I doubt Scatologic would release the needed technical details. bjl_api_draft.zip

Sorry, I don't understand what you mean. Anyways, I am currently making a draft of the API and converting "lo" (the uploader) to work with it, and I should release it soon. That should give you some pointers on what I'm thinking about

Thanks for the info ! In fact, I didn't realize that you included the full sources for your Packet Loader. Silly me What do you think of the idea ? Would you be interested in releasing the sources for your PC-side debugger program (Jdb), so that you or someone else could create a "universal" version ? (To avoid confusion : if I understood correctly, swapd0 uses BJL only to transfer his Packet Loader program to the Jag, and has written the debugger himself. I believe there are also debugging functions built into the BJL ROM -- that's a different thing.)

Thanks, but by "reverse-engineering" I meant extracting the algorithms from the code, so that they can be reimplemented on other hardware and OS. The C source file for the uploader only handles the standard uploading stuff, all the rest (auto-switching to 8 or 4-bit downloading mode, EEPROM access, debugging, etc.) is done in assembler. Actually I've ported the PC stuff in BJL.s back from ASM to C in this project, but a lot of things have been implemented only on the Atari.

We tried to, but he stopped responding to e-mail several months ago

I'm pretty sure that's possible. There are more programs available on the Atari platform (GT Turbo showed me a debugger, and started to reverse-engineer it a while ago), the problem is that many parts of the BJL protocol are not documented. So anyone willing to analyze 68000 ASM code is welcome to join the effort

As some of you may know, I am currently developing a USB BJL gizmo (Catnip Cable). Ray suggested I should team up with swapd0, because he has written a real-time debugger, and it would be fine to have both working in cooperation. That gave me an idea : we have different hardware, and different operating systems, but a lot of us use BJL (either the ROM version, the CD version, or Protector:SE's built-in version). Wouldn't it be cool to create a hardware and OS-independant BJL API, so that tools we create (uploaders, debuggers, etc.) could run everywhere ? Besides, that kind of cooperation would allow everybody to focus on his/her abilities without having to reinvent the wheel -- for example, I can work on hardware and PC software, but I know very little about actual Jag coding (yet ). Here are a few initial suggestions for the API and related projects : Open-source (not necessarily GPL, but the source should be public) In C (plain ANSI whenever possible) Reasonably simple And here is what I can contribute : Windows code for the standard BJL cable, and the Catnip cable (partly done already). Limited Linux testing. Reverse-engineering of the BJL protocol (partly done already, also). Any comments ?

Hi, Your link is broken. You meant http://www.freewebs.com/swapd0/, I assume. This looks very interesting !

Use the D-pad to move the atom. Press <A> or <C> to select the atom. Press <*> to reset the level. Press <PAUSE> to view the molecule you have to create, and press it again to go back to the game. Type a level number, then press <#> to jump to this level. (actually, it's explained in the intro ) Here's a hint for the first level. Get your atoms in this configuration (beware : the two Hs are not the same, they have different "bonds") : The rest should be obvious . And don't feel bad if you have trouble completing the levels, I suck at this game too

Yes, Win9x/2000/WinXP will be supported out-of-the-box, Linux should work too (not tested yet, but supposed to be OK). And if somebody's willing to do it, it should be portable easily to MacOS. You're welcome. Can you add a link to the original thread on Jagware too (http://jagware.org/index.php?s=&showtopic=37), in case I release a new version ?