Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

279 Excellent

About cubanismo

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. No. Hmm. Make sure you click on "cubanismo replied to a topic" and not "Create and burn eproms..." The former takes you to my post, the latter to the top of the thread. It's a very old thread, and my post is many pages in (the 2nd to last on it currently).
  2. See the footnotes and posts above. However, since they're all hand assembled, I'm happy to make you one without the extra USB ports if you don't want them for some reason (E.g., if you want to put it in a standard Jaguar cartridge case).
  3. Yes. The prototypes were beveled by me since Osh doesn't do beveling, and if the manufacturer messes up the real ones, I'll just bevel them myself as well since they'll all be hand built, but I'm requesting a 30-degree edge bevel, same as the original skunk runs.
  4. That's not a limit of JCP (I assume you mean the jserve.exe gdb server + gdb stub?) so much as GDB (the open-source debugger). There's an existing 68k build of gdb, but there isn't a version that knows anything about the Jaguar RISC processors AFAIK. If you built that, you'd probably only need minor updates to the jaguar-side debugger stub. All the info you need to add GPU/RISC support is out there. I had written up a rather long explanation of how to build such a debugger, noting @swapd0 already did write one for BeOS, but I'll save that for another thread.
  5. Yes and no. There are two bits off "firmware" on the skunk: The CPLD/FPGA (Codename "Butcher" in the source files) processor configuration, which handles routing data from the cartridge connector to the flash and USB controller, and some bootstrapping stuff, and the BIOS (Codename "Bootcher", get it?), which is some 68k code used to initialize the board when you power on the Jaguar and then listen for input from the joystick on the Jaguar and the PC via USB. As mentioned, I've made modifications to the BIOS to support the Serial EEPROM selection hardware. I have not had any reason to modify the CPLD yet, and don't currently plan to. I'm not clear whether the CPLD is field-programmable (As in, upgradable using JCP while running in the Jaguar, without dedicated programming software and hardware plugged into the JTAG header) with the current PCB layout. It looks like there was at least some effort to route the necessary signals for this, but I haven't tried to really dig in and verify it could be done. They're standard USB host ports like those on the back of any computer, and the skunkboard HW and existing CPLD code are powerful and flexible enough to implement support for arbitrary types of USB devices. I'm mostly interested in the mass storage device class personally, but I don't want to be too specific, as I may or may not have time to complete that project. USB is a very noble and (from what I can tell) well thought-out standard at the specification level, but is a pain in reality, and only works as well as it does on Windows/Linux on the sweat of many, many hard working SW engineers patching up support for all the terrible devices out there in the field (Take a look at the related Linux kernel code to appreciate this). Beyond that, you'll have to use your imagination, and as I say, no guarantees here. If you're ordering, probably safest to assume they'll do nothing. If I do use them for something, I'll definitely be releasing all the code so others could re-use/improve it if desired, just like I'm doing here.
  6. I wanted to feel out interest from others in the Skunkboard: Special Edition (Revision 5): I am fully aware game drives are becoming available (Unless there's some new obstacle, they'll be available very widely before these are) and have more features than skunks do. Before jumping in and responding that you want one of these, please familiarize yourself with the game drive. No matter how much software I stuff in the updated skunk BIOS, it isn't going to rival @SainT's sweet hardware. I'm counting on it in fact, because I can't build *that* many of these. However, I have designed and built a few, adding a few features here and there (See below), but largely for the fun of it. I'm sure at least one other person is going to want one, and I'm only going to order one more batch of PCBs at most, so I want to find out how many I need. Features: Everything Skunkboard v3 had 8MB flash, 2x4MB banks or 1x6MB Mini-USB port to upload ROMs/homebrew/code/raw data/etc. from a computer to the flash or Jaguar RAM, do printf debugging, etc. Two Serial EEPROM (save game/high score) chips One 128 byte for original production run Jag game ROMs One 2048 byte for newer ROMs and probably most new development Selectable using the controller from the boot screen or using JCP. Can also be disabled entirely via JCP. New version 4 and 5 BIOSes to support the Serial EEPROM functionality. Upload/download Serial EEPROM/save game content from your computer using JCP just like you can with ROMs on older skunks. Added back in the other two USB connectors1 Beautiful purple PCBs with updated silkscreens: Special Edition logo Link to the github repo where I'll release the PCB design files Acknowledgements Cartridge edge connector pin numbering on both sides and JTAG header pin labels High-quality PCBs with 30u" thick hard/electrolytic-gold plated 30o beveled cartridge edge connectors2 Individually assembled and tested by me. Price: $100 + shipping, probably tax/VAT/etc. too. Depending on interest, I'm looking into a special edition box & updated hard-copy manual as well. Small runs of boxes are expensive, so there'd be an additional charge for those that wanted a box. I need to find out how many people (if any) are interested before I can quote a price there. For more details on the development of the revision 5 skunkboards, see the Smelly Adventures thread, but don't get too scared by the first few posts: My soldering is much improved. I'm not going to pawn off any mangled boards Footnotes: I may or may not add some stuff to finally make use of the other USB connectors. No guarantees. As far as I know, Rev.1-Rev.3 Skunkboards had hard-gold edge connectors as well, as do the Zaxon ones. The somewhat rare Rev4 PCBs appear to use ENIG. The prototypes pictured here use ENIG, but if I order a production run of these, they'll use hard gold. See here for the benefits of hard gold connectors. Basically, they last much longer.
  7. Got the BIOS-side EZHost GPIO manipulation routine debugged, and have my board flashed to a brand new v4.0.0 BIOS now, which: -Initializes the GPIOs to select the 128B Serial EEPROM bank on boot (Minimum functionality required to make the Rev.5 boards no worse than a Rev. 4 or Zaxon board out of the box). -Lets you select EEPROM 1 by pressing D-Pad Left (Screen will flash yellow to acknowledge) -Lets you select EEPROM 2 by pressing D-Pad Right (Screen will flash deep blue to acknowledge) From there you can use the usual D-Pad Up/Down or JCP upload to boot your EEPROM-aware code using the selected EEPROM. The EEPROM selection can also be toggled from JCP, and JCP can upload/download EEPROM content to the active EEPROM chip. I still need to add the 2048B EEPROM support to the JCP save/restore functions. Currently, the upload/download is still 128B only. The code is written and works when run manually as a stand-alone program, it just needs to be integrated with JCP. Had some fun tonight testing this with @CyranoJ's BIOPEDE in one flash bank, Val d'Isère Skiing and Snowboarding in the other: Pressed Right then Up to launch BIOPEDE with saved high scores (Thank god the defaults are low, or I would have been testing forever. Turns out I'm terrible at this game), Left then Down to launch Skiing & Snowboarding with saved controller configs & run unlocks/progress. JCP to back up/restore the save game data afterwards. Pretty sweet. I'll test this a bit more, make one more cleanup pass, then make a release with this base functionality before I attack utilizing the unused flash regions to store EEPROM selection defaults and/or EEPROM<->flash save/restore from the BIOS. The JCP save/restore functionality will be useful for anyone with EEPROMs on their skunk, the JCP & BIOS EEPROM toggling stuff will only be useful for me unless others want Rev.5 skunks. For the BIOS, my plan is for the currently-working base functionality to be Skunk BIOS 4.x.x, and the enhanced/flash-aware functionality to be Skunk BIOS 5.x.x, conveniently bringing the version number back in line with the board revision number
  8. Protector SE uses a different chip. 93C86. See my post here for details on how to pick the right one (or make the one you got work) from DigiKey/mouser/etc.: This one should work, but you'll have to short the pins like I note in my post above: https://www.digikey.com/en/products/detail/microchip-technology/93C86C-I-P/665630
  9. I want one of those slow-motion fly-by promotional videos of the combo unit showing off the contours. Looks awesome!
  10. Several bits of learning and news to share here. First, the mystery of why skunkbios_3.0.1-noverify.COF failed to flash when I was bootstrapping my first working board is solved, and it's rather silly. It's because it was stuck trying to connect to the jcp console. I realized this when I saw there's also a -noconsole variant in @Tursi's skunk_bios github repository here. I verified plugging in a USB cable while running bjlSkunkFlash and running "jcp -c" when it gets stuck gets the -noverify variant working. Next, why was drag soldering so easy on my practice boards but super-hard on these Skunk PCBs? Because the Skunk PCBs don't have solder mask between the pads and the boards are very likely made using a low-quality substrate. Here's a close-up look at a fresh one (Thanks @Saturn for sending these over): See how the boards are blue everywhere except around the gold pads where chips are mounted? That blue stuff is the solder mask, and it repels solder like oil repels water. However, it is difficult to manufacture boards with tiny solder mask bits between copper pads. The process that lays down the mask layer over the board needs to be precisely aligned or the mask will overlap the copper, giving you bumps that could cause your chip to not cleanly contact the pad. To account for that, you have to widen the "cut-out" for your pads in the solder mask when designing the PCB. Different manufacturers have different abilities, so if you're using a cheap manufacturer, you have to enlarge the opening more than for others. Further, if you try to put down too thin a sliver of solder mask, it might not result in a nice flat line of mask, but rather could splinter or bubble. This also varies, I believe mostly based on the quality of the solder mask material and process used by the manufacturer. Taken together, you basically get some minimum pad spacing for which you can lay down a solder mask between the pads. If the spacing is lower than that, you don't get solder mask between those pads. Some manufacturers will even fix this up for you and remove solder mask regions too small for them to manufacture. These days, good manufacturers can lay down a mask between pads with the relatively fine spacing (0.2mm) used here, but the skunkboard design files were very conservative by today's standards and had a very large clearance around their pads. TL;DR: No solder mask here means solder is more likely to bridge across pins placed on these pads when drag soldering. The "low quality substrate" bit relates to why pads were lifting off these things like crazy. Granted, I was pretty crap at soldering when I started off here and I'm still not great. What that means is I was keeping the iron on the board a lot longer than was ideal, especially when trying to use solder wick to remove solder bridges when I messed up, partially caused by the lack of solder mask. If you're using cheap substrate, such as TG-130/TG-140, it will start to burn pretty quickly, and then the pads will lift right off of it. The owner of Osh Park goes into detail about these and other issues you'll run into manufacturing your boards at a cheap fab in this reddit post. How did I learn all this? Well, I've been busy. I finished laying out my changes to the skunk PCBs and was looking into getting some prototypes built. I learned all of the above while researching and comparing the capabilities of the various PCB manufacturers members here recommended. Ultimately I decided to go with Osh Park for the initial prototype boards, as @grips03 recommended. It didn't hurt that all Osh's boards are purple. My younger daughter's favorite color is purple, and while I cycled through the various solder mask colors in a gerber viewer with her on my lap, she insisted the boards looked best in purple. Everywhere else, purple costs a little extra. At Osh, it's your only option! I sent everything off about a week and a half ago, and got a package from Osh on Monday. Behold, Purple Skunks! Note I couldn't resist tweaking the Skunk logo a little The boards needed a little cleaning up. They had some nibs on them from where they were attached to the others in the panel, and they weren't beveled (Osh doesn't offer beveling). Nothing a little sanding followed by an alcohol wipe couldn't fix: Note I did this outdoors with a respirator on. PCB dust is nasty! As mentioned above, the key to my changes was routing some GPIOs from the EZHost USB controller chip through an AND gate to combine them with the Jaguar's GPIO line used to toggle the chip select line on the Serial EEPROM to allow enabling only one of two Serial EEPROM chips at a time. To fit this on the available sliver of PCB real estate left on the skunk PCBs, I had to use a tiny XSON8 package, and I was pretty nervous about being able to lay down tiny enough globs of solder paste by hand to get this working without shorting pins. However, I got it working. I did short at least one pin on all 3 boards, but I was able to easily clear it by covering the exposed portion of the pads with some flux and touching my soldering iron tip to them. This pulled enough solder out from under the chips to clear the shorts all but once, and in that case, I just applied more flux and hit it with the hot air gun again to get the solder to flow out onto the pads. Here's the chip sitting in a little-but-not-little-enough puddle of solder paste: And after reflow + fixups: As you can see, the whole IC package is about the size of an 0603 SMD component. After soldering all the solder-paste components (This XSON8 IC, which is U7 on my layout, and U4, the USB power regulator IC with a heatsink pad on the bottom), I sprinted through the build of a single board to verify everything was working: Here's a tip if you're doing some drag soldering: After you've tacked the chip in place, hit the pins and pads with the rework hot air gun on a relatively low setting for a few seconds to pre-warm them. Then quickly cover everything in flux and do the drag. Warming the pins and pads seems to prevent the solder from instantly solidifying when it touches them, allowing it to drag along with the iron as desired. This is probably all the more important when working with a relatively cheap iron like I am, since it can't compensate for encountering the thermal mass of a pad connected to a ground plane or even a handful of pins on an IC. If you don't have a hot air gun, don't despair if your first drag across the pins leaves a mess of bridged pins. Just quickly reapply flux if it all burnt up in the first pass, and drag the iron (very lightly tinned, but not naked) over it again to drag the solder away from the gaps. The pins & pads should have been warmed significantly by the first pass, achieving roughly the same affect as pre-warming them with the hot air gun, and you should get a much cleaner drag, with the solder flowing onto the pads and pins and away from the gaps. Repeat if needed. After I got all the critical components on: I stopped to test basic functionality. I was able to find the Cypress chip via USB, flash the CPLD, and flash the BIOS without any hitches, so I soldered on the remaining components: And ran it through the test2.sh bringup test suite, which it passed. I ran it once more to be sure, and went to bed. It took me roughly 4.5 hours /(~2.5 @Shinto Jaguar game-by-game podcasts), of non-stop soldering and futzing with JTAG and stuff to get this far, and I was exhausted by the end of it. This was the first time I'd built an entire board (plus part of two others) in one sitting. The next day, after a good cup of coffee, work, and family stuff, it was time to test the actual changes I'd made. I'd improved on the software I wrote above by integrating the EEPROM dumping and writing directly into a build of JCP, and merging in some code I found by @Songbird (Thanks again!) to support 93C86/2048 byte EEPROMs as well since the board above has one 93C46 (128 byte, standard for non-homebrew Jaguar carts) and one 93C86 (Many newer homebrew carts use this). The updated EEPROM code is already on my e2pmgr github repo, and I'll post the updated jcp code soon. It needs a little cleanup, as I still have to select between 128 and 2048 byte support at build time right now. After a bit of debugging, it all worked flawlessly, so all the new HW functionality has been verified. I'm quite pleased with this, as is my older daughter, who is also fond of purple, and just shouted "PURPLE!" when I showed her the finished board yesterday morning. It's my first attempt at PCB layout and manufacturing, and it went off without a hitch. I took a break to do some non-Jaguar stuff tonight and write this up, and I'm going to read up on all the local candidates and propositions and do my vote-by-mail thing tomorrow night, but the next thing I'm going to attack is the BIOS. I have a scheme worked out to stash EEPROM selection settings in an unused sector of the BIOS area of bank 2 (Or the top 2MB when using 6MB mode), but toggling the GPIOs from the skunk didn't go as smoothly as I'd hoped. You apparently can't write to the EZHost control registers using HPI DMA mode like you can the other on-chip memory addresses. Doing so just locks up the EZHost chip, as it appears someone else already learned, based on comments in usb/main.c in the skunkboard full release archive. Luckily, there's an HPI mailbox protocol you can use for this instead, and skunk CPLD appears to support it. I have all the code written up to do things that way, and it runs without reporting any errors, but... it's not actually toggling the GPIOs for some reason. Debugging needed. Also, at some point, I'll build up the other two boards, and perhaps more if others are interested. If I order more, it'll have to be a relatively large batch to be economical (Basically, it costs about the same to order 50 as it does to order 5), so I'll certainly have spares, and if I can sell a handful or so, the whole project would be self-financed. However, we'll have to see if anyone still wants a skunkboard now that game drives are well and truly just around the corner. Regardless, I'll be pushing my full PCB designs, BOM, updated JCP code, and hopefully, updated BIOS code (once it's working) to github soon as well, along with very, very verbose notes for anyone who really wants to dive into the details (I know, who knew it could get even more verbose than my posts here?), all public domain like the existing skunk files.
  11. I should note I've not worked with Best for repairs so I can't recommend one way or the other. I bought a copy of Super Burnout from them and it was a smooth transaction, but that's a lot simpler than a repair.
  12. One other note on BJL ROM images: I was cleaning out my trove of misc. jaguar docs I downloaded in my "Follow all links & read everything" phase of ramp-up, and came across a file called "Jag_cart_transfer.PDF" with no indication of where it came from. It referenced a BJL ROM image that ran a utility which would checksum and dump Jaguar cartridges over the JagLink/Serial port using Xmodem. Googling for the ROM image name itself found nothing, but Googling for the document found me this directory: ftp://ftp.untergrund.com/users/ggn/temp/jag_cart_trans Which appears to contain the BJL image: ftp://ftp.untergrund.com/users/ggn/temp/jag_cart_trans/bjl0702.bin As well as various other files useful if you're interested in the cartridge dumping functionality. I haven't tested this yet, but it's another option if you're looking for BJL images to burn to your BIOS EEPROM and prefer dumping cartridges over playing a little Marble Madness.
  13. Interesting. DigiKey claims it is 6mm I believe. What I was wondering was what a good knob outer diameter is though, as well as height, material, texture, etc. If you have some pics of the assembled controller, that'd be cool to see as well.
  14. Though if you look at the smelly adventures thread, I'm working on an improved JCP for use with eeprom-stuffed boards like the santosp and Zaxon ones. Not ready yet though.
  • Create New...