Post
by infiniteneslives » Thu Nov 17, 2016 3:19 pm
Just wanted to make some announcements for recent hardware updates and upcoming software updates with our version of the kazzo to make people of interest aware. I made some improvements to the hardware that affected all units shipping out as of a couple weeks ago. And have some software/firmware redesign in the works slated to release within a couple months.
PTC resettable fuse added to incoming USB power. Relieves issue where users could damage SNES boards by inserting them into the kazzo backwards. Also offers some protection from short circuiting the power rails by mishandling a case-less device.
SNES connector pitch correction. As advertised (yet to be updated..) the differing pitch of the SNES connector made the device incompatible with original SNES cartridges and their narrow PCB pins. The previous solution was using a 60pin connector with the 46pin cart slid all the way to the right. The extra over hang of the 60pin female connector also mechanically prevented a SNES cart from being inserted while in it's case. You had to remove the board from the case to flash my SNES boards. The new solution uses the same widely available TE connectivity 60pin connector, but 'centers' the cartridge in the middle of the 60pins. Some bare PCB inserts are wedged in on each side of the female connector to 'trim' the 60pins down to 46pins. The removal of the 'slop' and proper centering removes enough of the pitch error to allow original SNES boards to make proper contact much in the same way that the NES connector does. This also makes it so the SNES cart can be inserted without removing the case. So the hardware will now make it possible to support dumping SNES games and backing up save data.
If there's interest I will entertain the idea of creating a pin adapter for older designs to correct this pitch issue on older devices.
The two changes above will should prevent issues people had accidentally inserting SNES boards backwards into the kazzo and SNES as the board can be left in the case at all times. The PTC fuse will protect if inserted properly into kazzo, and leaving the cartridge case on at all times prevents improper insertion to you SNES.
Minor component rearrangements to better support a case/housing. Some of the previous locations put switches and screw holes in difficult locations to support a case. I've got some prototype case designs made from plexiglass currently. Once I've got the upcoming code updates complete I'll be focusing on offering cases which can also be purchased separately. If there's enough interest I'll try to design some cases to work well enough with the old PCB layout as well.
Beyond the hardware updates above I'm working on a fresh build of the firmware and host app redesigned from the ground up. The code will be open source and I'll be making the project publicly available on github shortly once some basic functionality is complete enough to share. I'm open for suggestions/requests people may have, so feel free to chime in if you'd like and I'll take them into consideration. I'm starting development as I think all things should be with a command line interface only. My goal is to have a working version of this released around new year's 2017. Once basic functionality is complete via command line I'll work on adding a gui for windows at least. Here's some of what I have planned.
Host support for multiple operating systems Previous versions only supported windows XP through 10. I will be continuing windows support of course, but also be developing/testing on linux in tandem. I'm using libusb 1.0 drivers so the source code should support all OS's without much trouble. I don't currently have a mac to work and test with, but will probably pick one up to support a mac once I've released windows and linux.
Scripting support I will be adopting scripting similar to how the original kazzo firmware and anago/unagi works. I don't plan to support the original anago scripts however. Some planned improvements include making things more transparent and better documented compared to anago. Too much was handled behind the scenes and didn't allow user control or debugging. This includes things like rom header creation, rom size detection, etc. Additionally I'm planning to provide commands to directly toggle mcu pins and have user created read/write functions so you can dictate things like if m2 toggles, or EXP0 is controlled during a read/write operation which is can be helpful for certain flash cart operations.
My primary goal with the scripts is to allow features to be added to the app and firmware without necessitating rebuilding the source code for which is what's currently required with my app/fw solution. This structure also supports most of the intelligence to be handled on the host side where it belongs vs on the device side where I previously kept it. I started to reach the point where I exceeded the mcu's program flash and this will resolve that for the foreseeable future.
Support for other programming protocols I have plans to expand programming support beyond parallel memories including JTAG, SPI, I2C, etc. Having JTAG programabilty would allow users to a .svf file on the host and allow them to reconfigure the CPLD/FPGA on a flash cartridge. This ability will open up opportunities for me to offer new flash board products as well as an open programmer for other's to develop hardware with if they'd like. If there's interest I could be convinced to make a few tutorials of how to create a custom mapper from paper through logic synthesis and onto a cartridge along with a programming script to go along with it.
Speed boosts I'm sticking with the current hardware design for now as I don't want to 'discontinue' it, I've sold over a thousand of these programmers to date and I want to provide everyone who already owns one with these updates. Yes big-banging V-USB is slow, but there are many improvements which can be made. Most of these improvements can't be applied to dumping operations though, as they only improve flashing cartridges. Some low hanging fruit is doing things like designating the firmware to flash data into multiple locations to automatically double up a rom image for oversized flash chips. Some modest improvements are also possible with double buffering the mcu.
Another feature I'm considering to boost speed is to avoid erasing the entire flash chip. This will be beneficial for developers especially. If you only tweak one line of code the entire PRG-ROM probably doesn't need to be erased and re-written. Chances are only a few flash sectors are affected. And certainly not the CHR-ROM for this example. So performing a checksum on each sector and verifying it needs erased instead of blindly erasing and reprogramming all memories on board can drastically boost overall speed.
For situations where someone is producing a game and flashing the same rom image onto multiple boards I will providing means to have two cartridges inserted at once. So for example a .nes rom image could be stored on a SNES flash board, and then quickly copied over to a blank NES cartridge.
Auto-detection This is something that effectively doesn't exist in anago as the user must determine the correct script to use. And where it is done for header creation and rom size it's hard to override. My build's firmware used some auto-detection via mirroring tests to determine which flash algorithm to use. However I didn't have a means for the user to manually override and dictate which algorithm to use. The new design will make an attempt to detect what mapper and board config is inserted and notify the user. But then also allow the user a means of input to override things when auto detection isn't behaving as desired. The overall goal will make things easier for both novice and advanced users.
Rom patching I consider this more of a 'nice to have' wish list feature. Providing an option for user to designate a patch file to be applied to the rom. I like the idea of a user being able to insert an original game which gets dumped internally to the app, patch applied to it, and then programmed onto a flash cartridge. This would ride the line of the idea of making a "modified" copy of something to which you own. Legalities are debatable I know and that copy rule doesn't necessarily apply to binary roms, but this would be one of the most legitimate means to enjoy hacks/translations that I can think of. The ultimate legal solution for that would be a game genie like device which might temporarily store a patched copy in RAM or maybe some other ultra fast live patching means. This feature could be a stepping stone to such a device's creation.
Live cartridge probing/debugging This is one of my more advanced features I'd on my wish list, but can't promise I will make it around to this. Basically I'd like something like a terminal interface with the cartridge where commands can be issued in real time and read back. A simpler means of this might be to single step the current script. This would assist in mapper reverse engineering as well as hardware debugging with the addition of a multimeter/logic probe.
As for the future I do have some hardware improvements/additions in mind but I'm not going to fixate on them too much until this new build is released. I've been getting a number of requests to support other systems including but not limited to gameboy, GBA, sega, N64, colecovision, etc. Not certain if/when I'll tackle those and how, but bit banging large N64 roms exceeds my patience and would necessitate a hardware USB solution. I drafted up a design to accommodate that earlier this year, but I'm going to shelf it for the time being. I will say however that any such hardware improvement will be able to take advantage of the DIP socket used for the current mcu. Some basic soldering skills *might* still be required to retrofit older kazzo's, if that's the case I'll also be offering a upgrade service or trade in option for people looking to upgrade their device. Cartridge connector differences will be resolved via pin adapters which could insert into SNES/NES connector(s).
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
) and the epoxy blob for the mapper. No guarantee it's the same mapper as yours, but I think there's a good chance that it is. Cart label seems the same as I remember it.
If that didn't make any sense, my video example will probably give you a better idea of what this does: 
