Fork/mirror of https://gitlab.com/InfiniteNesLives/INL-retro-progdump
tested and verified on purple, green, and yellow/orange avr kazzos and stm32 inlretro6 proto, and stm32 adapter with yellow kazzo board AVR takes ~17.5sec to dump 256KB -> 1:10 for 1MByte = 14.6KBps STM takes ~8.5sec to dump 1MByte = 120KBps STM32 usb driver is far from optimal as it's setup to be minimal with only 8byte endpoint0 to make an effort to align avr and stm. Larger endpoints and bulk transfers should greatly speed up stm usb transfers refactored firmware buffer.c and implemented most of the required opcodes added check that should cover if device isn't ready for a IN/OUT transfer. Does this by usbFunctionSetup returning zero which causes the device to ignore the host. Don't think I've got the stm32 usb driver setup properly to handle this not sure I fully understand Vusb driver either. Anyway, hopefully it works well enough for now and keep this in mind if issues crop up in future. Still haven't implemented usbFunctionWrite, not sure stm usb driver is setup properly yet either.. build sizes: avr yellow/orange: avr-size build_avr/avr_kazzo.elf text data bss dec hex filename 5602 6 674 6282 188a build_avr/avr_kazzo.elf previous builds of avr code size was ~6.4KB when flashing and dumping was working. AVR bootloader is 1.7KB taking up majority of 2KB boot sector. So AVR has 16KB - 2KB boot = 14KB available, using ~44% of non-boot sector available flash Have 4 buffers defined, and 512B of raw buffer defined so using ~65% SRAM Making pretty good use of the chip just for basic framework. Not a ton of room for board/mapper specific routines, so will have to keep this in mind. Creating more generic routines to save flash will come with a speed hit, but perhaps we shouldn't worry too much about that as devices below really boost speed without even trying. There is some sizable amount of SRAM available could perhaps load temporary routines into SRAM and execute Also have ability to decrease buffer sizes/allocation. Perhaps routines could actually be store *IN* the raw buffers.. ;) stm adapter: arm-none-eabi-size -t build_stm/inlretro_stm.elf text data bss dec hex filename 7324 0 680 8004 1f44 build_stm/inlretro_stm.elf Currently targetting STM32F070C6 which has 32KB flash, 6KB SRAM Could upgrade to STM32F070CB in same LQFP-48 package w/ 128KB/16KB Don't think that'll be of much value though especially with limitation on connectors for adapter. So currently don't have user bootloader, only built in ones. 8KB of 32KB avaiable flash = 25% utilization 680B of 6KB available sram = 11% utilization 32KB device doubles amount of available flash compared to AVR, although stm32 code isn't quite a condensed compared to AVR. stm inlretro6: arm-none-eabi-size -t build_stm/inlretro_stm.elf text data bss dec hex filename 6932 0 680 7612 1dbc build_stm/inlretro_stm.elf Mostly limited to STM32F070RB as choosing device requiring XTAL, and desire large number of i/o. This device provides 128KB flash, 16KB SRAM Currently using 7.6KB/128KB flash = 6% utilization Currently using 680B/16KB SRAM = 4.1% utilization LOTS of room for growth in this device!! Part of why I choose it over crystalless 072 version, as it came with more flash for less cost. Also hardly making use of 1KB of USB dedicated SRAM: 32B buffer table entries 16B endpoint0 IN/OUT 48B of 1024B available = 4.6% utilization |
||
|---|---|---|
| bootloader | ||
| firmware | ||
| hardware | ||
| host | ||
| roms | ||
| shared | ||
| .gitignore | ||
| Readme.txt | ||
Readme.txt
===================
Linux
===================
HOST APPLICATION:
install libusb:
sudo apt-get install libusb-1.0-0-dev
make:
gcc -I include inlretro.c -o inlretro -lusb-1.0
or just run make unix from host folder.
As noted in windows instructions below, lua must be built first
-cd host/source/lua, make o a, then make from host/source
run:
./inlretro
FIRMWARE:
install avr-gcc and avr-libc:
sudo apt-get install gcc-avr
sudo apt-get install avr-libc
BOOTLOADER:
bootloadHID-master:
https://github.com/ajd4096/bootloadHID
fork of original obdev bootloader has option to remove BL switch with timeout.
bootloadHID.2012-12-08:
https://www.obdev.at/products/vusb/bootloadhid.html
the original believe it has more upto date V-USB drivers.
Both have identical commandline folders so they're identical on the host side.
need to have libusb-dev installed can check by typing "libusb-config" in terminal
will present usage options if installed on your system
if not installed should report so with suggestion for apt-get:
sudo apt-get install libusb-dev
then just run 'make' should build sucessfully
With the bootloader commandline app built, the firmware can be loaded
onto the INL retro-programmer via USB:
-place BL/RUN switch in BL
-hit RESET button or plug into USB for first time
-run 'make program_unix' from firmware dir.
If bootloader commandline app was successfully built and you have permission
to access HIDbootloader should have successful output similar to this:
$ make program_unix
../bootloader/commandline/bootloadHID -r main.hex
Warning: could not set configuration: could not set config 1: Device or resource busy
Page size = 128 (0x80)
Device size = 16384 (0x4000); 14336 bytes remaining
Uploading 1920 (0x780) bytes starting at 0 (0x0)
0x00700 ... 0x00780
-take BL switch back to RUN
-enjoy new firmware
===================
Windows
===================
HOST APPLICATION:
Install minGW:
download: http://www.mingw.org/wiki/Getting_Started
launch: Installation manager default settings
select: mingw32-base
(primary need is gcc)
select: msys-base
(primary need is make, basic unix commands are nice to have)
optional: msys-openssh
(helpful if using gitlab to pull updates)
minGW utilities can be easily added or removed at any time with minGW installation manager.
Add C:\MinGW\bin & C:\MinGW\msys\1.0\bin to your PC's enviroment PATH variable
-control panel search: "edit system environment variables
-System properties window, Advanced tab, click Environment Variables...
-System Variables pane: Select and edit "PATH"
-Add new entries below assuming you used default location for minGW
C:\MinGW\bin
C:\MinGW\msys\1.0\bin
-I had troubles once with cp (copy) commands in Makefile
causing a crash, even though the commands works outside of make. Bumping the
mingw path variables to the top of all my path variables corrected this issue.
So that might help if you have similar issues...
Now host app can be built from windows command prompt command make when in host directory
Currently setup to compile lua separate from host app. Need to get better at writing makefiles..
But whatever it works and saves ~12sec of compile time with current setup.
-go to host/source/lua
-make o a
-go back to host
-make
This way lua is compiled separately using it's provided make file.
make clean still deletes lua object files, so this process must be reperformed if cleaned.
FIRMWARE:
Download and Install WinAVR
http://www.webring.org/l/rd?ring=avr;id=59;url=http%3A%2F%2Fwinavr%2Esourceforge%2Enet%2Findex%2Ehtml
optional: install programmer's notepad has handy feature to make clean, all, program in tools menu
this is nifty if you are scared of the command prompt for some strange reason...
installation process should modify PATH environment variables for you.
incase they don't add them just like MinGW above
C:\WinAVR-20100110\bin
C:\WinAVR-20100110\utils\bin
Now firmware can be built from windows command prompt with command "make" when in firmware directory
There is a bootloader installed on all "kazzo" INL retro programmer-dumper's which allows new firmware
builds to be easily flashed on to the device without a avr programmer.
Place BL/RUN switch in BL, then hit reset button in INL retro-prog
from firmware folder run command "make program" this will flash target build onto device using bootloadHID.exe
Take BL/RUN switch back to RUN and device will reset into INL retro-prog you just built.
BOOTLOADER:
If you wish to build bootloader for kazzo (shouldn't be necessary for most ppl) follow the following
Requires you to have an avr programmer to reflash atmega164a mcu
Helpful to download more recent version of avrdude than included with WinAVR.
Download latest version with mingw32.zip from following link:
http://download.savannah.gnu.org/releases/avrdude/
unzip and copy paste both avrdude.exe and avrdude.conf to C:\WinAVR-20100110\bin directory
Assuming the recent build still doesn't support atmega164a..
You'll also have to add a definition for atmega164a in the avrdude.conf file
Copy paste the atmega324P section and rename it atmega164A
Then change the following lines to match:
id = "m164a";
desc = "ATmega164A";
signature = 0x1e 0x94 0x0f;
Now the bootloader can be built and flashed from the bootloadHID/firmware directory with make
If trying to flash mcu from make file you'll have to modify AVRDUDE line to match your avr programmer
Once completed you can make the bootloader and flash it with command "make flash"