Wanted to take a min to update my progress on rewriting the kazzo host app and firmware. I've made some decent progress on the goals I set for myself in
this post last Nov.
The biggest 'news' is that I'm officially planning to retire from the atmega164 and bit banged V-usb hardware. I've only got a couple month's supply of the current atmega164 boards on hand and once those are gone, I don't plan on making any more of them. I'm not abandoning them completely though, software updates will continue to support all devices I've shipped to date. I've decided to migrate to the stm32f070 with hardware USB 2.0 Full speed (12Mbps). This new hardware design is not compatible with the original unagi/anago firmware/software. Because of this, I can't actually release the new hardware design until the software makes it at least as capable as current kazzo including the original anago/unagi for dumping purposes, and my current release for flash board programming. So the heat is on for me to finally release my new software/firmware build, in my mind I must release it prior to running out of original kazzo board inventory.
Here's the primary goals of my upcoming release:
-compatible on all previous, current, and planned future hardware designs I've released.
-compatible on windows, mac, and linux
-host scripts to allow adding support for new mappers without need to compile anything.
-host app/scripts are hardware agnostic providing the hardware is physically capable of the task.
-device firmware as hardware/core agnostic as much as possible, at least while the AVR still has rom available.
-all software open sourced
I made lots of strong progress on my rewrite over Nov/Dec of last year, and got to the point where my new build was able to flash and dump NES NROM carts. Once I got to that point I really stumbled on how to implement script support. 100% of the host software (and AVR firmware) was written in C. Aside from personal preference, I chose C because it allowed me to share header files with both the device firmware and host software. C also helped gain compatibility with most OS's along with libusb drivers. But I got pretty hung up when it take time to implement my own scripting engine.
Around the same time I was struggling with scripts, I stumbled upon the beauty that is the stm32 mcu lineup and I fell in love. It became obvious that it was time for me to retire bitbanged V-usb on an 8bit AVR hardware design. I drafted up a new prototype over the spring, and have been making steady progress on the new software over the past month.
Thanks to the
excellent discussion on Lua recently, I opened my mind to using something besides C written almost entirely by myself. I was sold once I realized that the Lua interpreter is actually running in C, and allows me to stick with my cross platform goals. I'm now at the point where all the host app C code I wrote last winter is ported over to Lua. Nearly the entire host application runs in Lua. I've got one low level function that's written in C to interface between Lua and libusb drivers. The executable/main is also still in C, but doesn't do much other than connect to the USB device and pass command line arguments over to Lua. I'm very pleased with Lua, it's quite the perfect match for this project IMO.
It took a solid 2 weeks of effort to get the
low level USB drivers written for the stm32 device. I tried to tinker with some of the cortex mcu software interface standard (CMSIS), and hardware abstraction layer code, but things quickly bloated and the number of function calls needed to toggle a mcu pin quickly became absurd. I'm sure I was probably doing something wrong, but I can't stand IDE's and the driver code was a tangled mess. I opted for writing everything from scratch
starting with my own on baremetal. I struggled in the beginning, but it forced me to become more familiar with the hardware which paid off in the end as it always does..
I'm currently at the point where I've many of of the big ticket goals prior to releasing the software into the wild. I'm about to start working on mapper/memory detection logic, so I can call mapper specific scripts. With that I'll be able to beta release a commandline version on most OS's. Then I'll focus on a gui, currently have my sights set on
wxLua.
Once I've got that released I'll start focusing more on the new hardware release. Getting kind of long winded already, so I'll just tease with some eye candy and follow up with details depending on interest. I haven't fully decided what to call the new hardware, don't think I'll keep with the kazzo name as it's no longer compatible with the original kazzo project. I've named my new software release INLretro, currently thinking the hardware will carry a similar name..