Jump to content
philexile

Jaguar Dev System

Recommended Posts

- If you can select the parallel port mode (for "real" parallel ports on motherboards, it's in the BIOS setup ; I don't know how it's handled for PCI parallel port cards), choose Bidirectionnal if available, or EPP mode otherwise.

 

- In Device manager, select your parallel port, choose "Never use an interrupt" and disable Plug-and-play detection.

 

- If you're using Windows XP, download and run the patch at the bottom of this page, and reboot your computer (it may also work on other Windows versions -- I'm not sure):

http://melabs.com/support/patches.htm

 

- Make sure you're using the latest version of the uploader program:

http://www.jagware.org/index.php?showtopic=484

 

- Close programs you don't use before sending the game.

 

- Try removing the -8 option from the command line. It will be slower, but it may be more reliable.

 

- Try adding the -n option on the command line. You'll have to press A on the controller before sending the game if you're also using the -8 option, or C otherwise.

 

- If all else fails, add the -w x option. x is a number; start with 1, and go upwards until things improve.

  • Like 2

Share this post


Link to post
Share on other sites

Thank you, Zerosquare. I will do these things and let you know if it works.

 

I have an on-board parallel port to use, but I'm curious: why do USB->Parallel adapters not work?

Share this post


Link to post
Share on other sites
Posted (edited)

Sorry to necro-post, but I was scouring the forums for others' experiences with BJL reliability, and this is the first good thread on it I found.

 

I've found the quality of my BJL adapter/cable affects the success rate quite a bit so far too.  I've built two adapters now in little DB25-DB9 adapter casing kits with the DB9 connector swapped for a DB15 one.  One works nearly flawlessly with -8 -w 2.  The other only works well with 4-bit -w 2.  I'm also using 15-foot parallel cables to with the adapters, which might make things a little less reliable 🙂 I've tried two such cables, and both seem to work about the same.  I might order a 6-foot cable and see if that improves things at all, and I have the parts for one more kit so I might see if I can get better results on the 3rd try, but I'm pretty happy with things as it stands.  I should also note that going from the older lo_inp code (I started out using the binary in Belboz's Linux dev package, which seems to be an older variant) to @Zerosquare's code made a big difference.  The older one would only work with -4 -w 2 even on my "good" adapter.  Not sure if it's the updated routines or just the brute-force nice(-20), but it's a welcome improvement.

 

I'm testing using @Zerosquare's updated lo_inp in Linux with an old-ish motherboard that has an onboard parallel port + the BJL CD-ROM in the Jag.  I can generally upload trivial things like the "hello world" and jag256 examples from Bolboz's old dev environment package with just -8 on both adapters on the first try.  However, I use Gem Race (https://atariage.com/forums/topic/249062-gemrace/) and Fallen Angels (https://atariage.com/forums/topic/211955-fallen-angels/) as stress-tests.  The latter seems to be especially difficult on the cables, and sometimes takes 2 or 3 tries even with the "good" settings for a given cable.

 

@Zerosquare, I also updated your lo_inp code to be 64-bit safe/use fixed-size types so it builds & works right on 64-bit Linux distros without loading up 32-bit compat libraries.  Are you interested in the patches, or would you mind if I just post the whole thing on github?  I haven't tried to rebuild on windows yet, since I don't have an old enough windows install handy at the moment.  This old motherboard's SATA ports are dying, so I can only really boot from USB, which is a bit harder with Windows, especially the older variants.  Anyone successfully used BJL in Win10 64 or 32-bit?

Edited by cubanismo

Share this post


Link to post
Share on other sites
2 hours ago, cubanismo said:

I'm also using 15-foot parallel cables to with the adapters, which might make things a little less reliable 🙂 I've tried two such cables, and both seem to work about the same.  I might order a 6-foot cable and see if that improves things at all

BJL is quite sensitive to the cable length. I'm not really surprised you're having issues at 15-foot ; I wouldn't recommend going beyond 6-foot, and 3-foot would be even better.

 

2 hours ago, cubanismo said:

 

@Zerosquare, I also updated your lo_inp code to be 64-bit safe/use fixed-size types so it builds & works right on 64-bit Linux distros without loading up 32-bit compat libraries.  Are you interested in the patches, or would you mind if I just post the whole thing on github?  I haven't tried to rebuild on windows yet, since I don't have an old enough windows install handy at the moment.  This old motherboard's SATA ports are dying, so I can only really boot from USB, which is a bit harder with Windows, especially the older variants.  Anyone successfully used BJL in Win10 64 or 32-bit?

I've got no issue with you putting the code on Github :)

You may want to ask @42bs as well since he's one of the authors.

I've got no idea if it works with Windows 10... few machines running this OS still have an hardware parallel port, and BJL is rarely used nowadays since there are other options.

Share this post


Link to post
Share on other sites

With BJL I never could upload the native demo until I wrote my own uploader that split the file in chunks and if one of them it's wrong uploads it again.

 

Try to get a skunk-board.

 

Share this post


Link to post
Share on other sites
4 hours ago, cubanismo said:

Sorry to necro-post, but I was scouring the forums for others' experiences with BJL reliability, and this is the first good thread on it I found.

 

I've found the quality of my BJL adapter/cable affects the success rate quite a bit so far too.  I've built two adapters now in little DB25-DB9 adapter casing kits with the DB9 connector 

I wouldn't go for a cable longer then 1.5m/6foot. IIRC the Jaguar has no Schmidt-Trigger inputs and this means the TTL levels on long cables are not clear enough.

I had the best results with an Atari STE.

 

 

Share this post


Link to post
Share on other sites
7 hours ago, swapd0 said:

Try to get a skunk-board.

Yeah, for some odd reason they aren't being shipped to the US right now 🙂  Since I'm doing this all for fun & learning, not so much for doing things the easy/right way, I'm entertaining the idea of trying to build my own based on the schematics, but I believe that requires a BJL-modded Jaguar to bootstrap the board anyway.  I've also never tried to have a PCB manufactured or done any serious electronics debugging since my college years (over a decade ago), so we'll see.  The world may become sane before I ramp up enough to tackle this.  Plenty of things to learn on the software side in the meantime anyway.

9 hours ago, Zerosquare said:

BJL is quite sensitive to the cable length. I'm not really surprised you're having issues at 15-foot ; I wouldn't recommend going beyond 6-foot, and 3-foot would be even better.

 

7 hours ago, 42bs said:

I wouldn't go for a cable longer then 1.5m/6foot. IIRC the Jaguar has no Schmidt-Trigger inputs and this means the TTL levels on long cables are not clear enough.

I had the best results with an Atari STE.

OK, noted.  I'll put in an order for a 6-foot cable (Anything less and I'm going to have to either drag a computer or a TV across the room whenever I want to use it) and see how that goes.  @42bs, any issue with me posting the lo_inp code on github with proper attribution?

 

Share this post


Link to post
Share on other sites
25 minutes ago, cubanismo said:

@42bs, any issue with me posting the lo_inp code on github with proper attribution?

No, please go ahead.

 

You may think of a side project: Use some ESP32 or Arduino with Ethernet/WiFi to do the loading. You can place it right beside the Jaguar and no problems with length of the cables.

PC side it is a simple TCP/IP application then.

  • Like 2

Share this post


Link to post
Share on other sites

Oh, that's a great idea.  I have an unused Rock Pi with built-in WiFi sitting right here.  Overkill, but seems like it should work.  The Jaguar controllers (and parallel ports) use 5v signaling, right?  So I assume I'll need to adjust the voltage of the Pi-style 3v3 GPIOs up/down to 5v, which makes it a little more interesting.  It looks like Arduino can do 5v GPIO natively, so it would probably be a lot easier.

Share this post


Link to post
Share on other sites
50 minutes ago, cubanismo said:

Oh, that's a great idea.  I have an unused Rock Pi with built-in WiFi sitting right here.  Overkill, but seems like it should work.  The Jaguar controllers (and parallel ports) use 5v signaling, right?  So I assume I'll need to adjust the voltage of the Pi-style 3v3 GPIOs up/down to 5v, which makes it a little more interesting.  It looks like Arduino can do 5v GPIO natively, so it would probably be a lot easier.

You can get level-shifter PCBs for a small money at ebay.
grafik.png.f2faf16a794915e9289a47cf9c241292.png

Share this post


Link to post
Share on other sites

I don't recommend using those cheap transistor-based level shifters ; they don't cope well with high speeds. If you want to go that route, use one that has a real level shifting IC.

 

If you don't need Wi-Fi support, I'd recommend using an Arduino instead. It's easier.

  • Thanks 1

Share this post


Link to post
Share on other sites
33 minutes ago, Zerosquare said:

I don't recommend using those cheap transistor-based level shifters ; they don't cope well with high speeds. If you want to go that route, use one that has a real level shifting IC.

 

If you don't need Wi-Fi support, I'd recommend using an Arduino instead. It's easier.

Ok, took the first I found at Amazon. But, yes there seem to be better choices. Thanks for the hint!

Share this post


Link to post
Share on other sites

Yes, Arduino would be much easier, but the board is sitting right here doing nothing, and WiFi is nice 🙂  I assume something like this would be what you mean by a real level-shifting IC https://ebay.us/GGmudI (For posterity, http://www.ti.com/lit/gpn/txs0108e, a Texas Instruments TXS0108E 8-bit Level Shifter)?  Seems fast enough for BJL from the data sheet 🙂

Share this post


Link to post
Share on other sites
17 minutes ago, cubanismo said:

Yes, Arduino would be much easier, but the board is sitting right here doing nothing, and WiFi is nice 🙂  I assume something like this would be what you mean by a real level-shifting IC https://ebay.us/GGmudI (For posterity, http://www.ti.com/lit/gpn/txs0108e, a Texas Instruments TXS0108E 8-bit Level Shifter)?  Seems fast enough for BJL from the data sheet 🙂

Bought just some of them on Amazon. 

Share this post


Link to post
Share on other sites

Those should work (you'll need two of them, since BJL uses 10 signals in total).

 

I'm not sure what kind of timing accuracy you can get with a Raspberry Pi, though. BJL is pretty picky: it won't work if the timings are too fast or too slow.

Share this post


Link to post
Share on other sites
8 minutes ago, Zerosquare said:

Those should work (you'll need two of them, since BJL uses 10 signals in total).

 

I'm not sure what kind of timing accuracy you can get with a Raspberry Pi, though. BJL is pretty picky: it won't work if the timings are too fast or too slow.

🙂

I used an Cortex-M3 with 72MHz w/o problems. So a Cortex-A class CPU should work just fine.

But I'd try first 4-bit mode.

Share this post


Link to post
Share on other sites

Sure, the CPU is certainly fast enough. But the OS is multitasking and may introduce random latency. This is why I added the priority boost code to lo_inp (which did make it more reliable, but not perfect).

Share this post


Link to post
Share on other sites
1 hour ago, Zerosquare said:

Sure, the CPU is certainly fast enough. But the OS is multitasking and may introduce random latency. This is why I added the priority boost code to lo_inp (which did make it more reliable, but not perfect).

I wrote the PC software for a 486 Linux PC. But then, it is Linux *huahaha*

Share this post


Link to post
Share on other sites

I ordered a 5 pack of those off Amazon that should be arriving today, along with some breadboard stuff.  I got Linux up on the Rock Pi last night and tested some code to do basic GPIO twiddling using my multimeter.  I'll try to wire this all up to the lo_inp codebase and see what I can get working.  I haven't actually read the BJL client code for comprehension yet, just blindly slammed "unsigned long" to "uint32_t," and I'm doing this in my "free time" after work and after kids go to sleep, so it might take me a while.

Share this post


Link to post
Share on other sites
1 hour ago, 42bs said:

I wrote the PC software for a 486 Linux PC. But then, it is Linux *huahaha*

Try it on a modern Linux distribution with countless things running at the same time, and see if it still works as well 🤪

  • Haha 1

Share this post


Link to post
Share on other sites
1 hour ago, cubanismo said:

I ordered a 5 pack of those off Amazon that should be arriving today, along with some breadboard stuff.  I got Linux up on the Rock Pi last night and tested some code to do basic GPIO twiddling using my multimeter.  I'll try to wire this all up to the lo_inp codebase and see what I can get working.  I haven't actually read the BJL client code for comprehension yet, just blindly slammed "unsigned long" to "uint32_t," and I'm doing this in my "free time" after work and after kids go to sleep, so it might take me a while.

Here the code from Cortex-M3 (ek-lm3s6965 board):
 

#define PIN4_7 \
  GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7

void sendLong(uint32_t data)
{
  volatile int wait;;
  for(int nibble = 0; nibble < 4; ++nibble){
    while( GPIOPinRead(GPIO_PORTD_BASE, GPIO_PIN_3) == 1<<3 ); /* wait for busy low */
    GPIOPinWrite(GPIO_PORTD_BASE, PIN4_7, data);
    GPIOPinWrite(GPIO_PORTC_BASE, PIN4_7, data<<4);
    for(wait = 40; wait ; --wait);
    GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_4, 0x00);
    while( GPIOPinRead(GPIO_PORTD_BASE, GPIO_PIN_3) == 0 ); /* wait for busy high */
    GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_4, 0x10);
    data >>= 8;
  }

  for(wait = 200; wait ; --wait);
}

void sendWord(uint32_t data)
{
  for(int nibble = 0; nibble < 2; ++nibble){
    while( GPIOPinRead(GPIO_PORTD_BASE, GPIO_PIN_3) == 1<<3 ); /* wait for busy low */
    GPIOPinWrite(GPIO_PORTD_BASE, PIN4_7, data);
    GPIOPinWrite(GPIO_PORTC_BASE, PIN4_7, data<<4);
    GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_4, 0x00);
    while( GPIOPinRead(GPIO_PORTD_BASE, GPIO_PIN_3) == 0 ); /* wait for busy high */
    GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_4, 0x10);
    data >>= 8;
  }
  volatile int wait = 250;
  for(; wait ; --wait);
}

Setup

  /* Data lines */
  GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, PIN4_7);
  GPIOPinTypeGPIOOutput(GPIO_PORTC_BASE, PIN4_7);

  /* nSTROBE */
  GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE,GPIO_PIN_4);

  /* BUSY */
  GPIOPinTypeGPIOInput(GPIO_PORTD_BASE,GPIO_PIN_3);

  GPIOPadConfigSet(GPIO_PORTD_BASE, PIN4_7, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);
  GPIOPadConfigSet(GPIO_PORTC_BASE, PIN4_7, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);
  /* de-assert nSTROBE */
  GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_4, 0x10);

    uint32_t check;
    uint32_t *p = (uint32_t *)tetris;

	sendLong(0x22071970);
    sendLong(0x4000);
    sendLong(sizeof_tetris+4);
    check = 0;
    for(int i = 0; i <  sizeof_tetris/4; ++i){
      uint32_t data = *p++;
      data = __REV(data); /* ARM asm: rev rn,rm => BE <=> LE */
      check -= data;
      sendLong(data);
    }
    sendLong(check);

 

Share this post


Link to post
Share on other sites

It works!  And literally on the first attempt at the wiring and software.  Almost fell out of my chair.  Scares the hell out of me when code works on the first try.

 

I managed to upload the "Hello world" example with -8 and no extra delay (My non-x86 version of "wait()" from ZeroSquare's code just reads a random GPIO pin, as a wild guess at the necessary delay) on the very first run.  The similar jag256 example didn't fare so well, but I walked up a loop of -w values and got it to work a couple of times with -w 7 -8.

 

In 4-bit mode, it's flawless so far, if a slow.  I might try removing the delay entirely and seeing if it still works.  Once I try a few more experiments to tune things and clean up the code a little, I'll push it up to github.  It coexists nicely with the parallel port code, and you can switch between the two at runtime (In theory) if you're using something like an Intel Edison board with both easily accessible GPIO and a parallel port rigged up to it.

 

Ignore the stranded LEDs on the breadboard.  That was from my initial python-based efforts to validate the voltage level shifters 🙂

 

 

bjl-pi-01.jpg

bjl-pi-02.jpg

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, cubanismo said:

I managed to upload the "Hello world" example with -8 and no extra delay (My non-x86 version of "wait()" from ZeroSquare's code just reads a random GPIO pin, as a wild guess at the necessary delay) on the very first run.  The similar jag256 example didn't fare so well, but I walked up a loop of -w values and got it to work a couple of times with -w 7 -8.

Here a note from the 8 bit loader:

                storew r9,(Joystick)            ; switch to input
                                                ; set also BUSY = high
; Note: This works only, because the input-lines are pulled-up to 5V.

So from the electrical point, the 8 bit mode is not really correct.

So if the time between setting STROBE low and waiting for BUSY high is too short for the levels to rise, the transfer fails.

 

Also, be aware, the Jaguar code was written for an STE as host, which runs a 8MHz only. So it contains wait-loops which might be shorter.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji 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.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...