Commit Graph

11 Commits

Author SHA1 Message Date
paul eeepc 4b0c340eb1 Creations of operation module and dictionary.
Things appear to be working with some early testing.  Assumption that oper_info elements
are aligned in SRAM linearly appears to hold true.  Researching this I found it probably
was true, but can't be certain esp if gets changed in the future to not be purely 8byte
sized elements.
Still need to provide means to decode function numbers info function pointers.
2016-12-25 13:48:30 -06:00
Paul Molloy 876b526e8c Some timing tests on windows machine. Double buffering was pretty
successful only 1KBps speed drop when actually dumping real cart data.
2016-12-12 22:31:46 -06:00
paul eeepc 49ec51e767 Much of dumping code for PRG-ROM completed but have some bugs with setting buff elements working on debugging... 2016-12-11 20:34:43 -06:00
paul eeepc 4db2929c3b Big overdue commit of past few days effort..
Detecting mirroring code working and tested
Started working on buffer operations from host
Current code compiles but not yet at point where can start testing
Adding cpu page read to nes.c to have faster dumping operations.
moving enums to shared as gets used quite a bit communicating between device and host.
2016-12-11 01:06:41 -06:00
Paul Molloy 132360f305 Updating main command line input args, and libusb logging/debug messages.
now able to accept LIBUSB_LOG_LEVEL from commandline to turn on/off error
messges at runtime.  Also setting level > 0 will print messages during
device discovery and connection.  Still need to permit kazzo firmware
version to be provided on commandline to support K flag.

fixing dictionary call typo with semicolon and setting buffer length
to always be provided with function call instead of dictionary call
deciding what it should be based on the opcode.

Adding some speed notes and other speed related discussions to buffer
dictionary.
2016-12-02 22:59:54 -06:00
Paul Molloy 937435220a Some early dumping functionality working.
buffer opcode updates to transfer payloads
including stuffing two bytes of write transfers in setup packet.
Calling specific buffers with miscdata or opcode.

new dump and flash modules for firmware.

new buffer function update_buffers called during main to monitor and
manage buffer objects when not being loaded/unloaded from USB.
2016-11-30 22:52:43 -06:00
paul eeepc b6164aa3a6 adding buffer element getter and setters to dict and firmware.
Need to add to host support and test operation.
2016-11-30 02:04:07 -06:00
Paul Molloy c256ca6b66 testing some bigger transfer sizes removing some printing. 2016-11-30 00:03:40 -06:00
paul eeepc cb0941e86c usbFunctionWrite support loading incoming write/OUT data to buffer objects.
Still untested, need to write some host code to test things out.
2016-11-29 15:27:31 -06:00
Paul Molloy 80943f7f62 firmware buffer.c reorganization and some intitial testing complete.
moved all buffer operations out of usb.c with new bridge function between
the two files.  Lots of pointing going on and lessons learned..
Thankfully everything seems to be working if you actually call the
functions as I designed them..  Gotta love trouble shooting bugs that
don't exist..  Helped updating allocate output to get returned as error
back to the host.

Moved typedef structs to firmware type.h file as seemed to cause
compilation issues being contained in the files .h file when other .c
files needed those types.

Fixed casting warnings with usbMsgPtr ended up looking at usbdrv.c figured
out how close I got, just shouldn't have been putting the * in there..
2016-11-28 22:16:35 -06:00
Paul Molloy c36313135e Initial firmware implementation of buffer objects and raw sram allocation
complete.  should be able to allocate buffers from host, but haven't got
to testing it yet.  Compiling on firmware though..
Currently have 256 bytes of raw_buffer, and 8 buffer objects/structs
each with ~16 bytes per object.  So could trim things down, but still have
decent amount of SRAM left.  Could have another 256 byte buffer at this
rate..  but might not leave enough SRAM for temporary routines.

Possible that raw buffer space could be dynamically allocated
as either buffer space or temporary routine space...

AVR Memory Usage
----------------
Device: atmega164a

Program:    4094 bytes (25.0% Full)
(.text + .data + .bootloader)

Data:        573 bytes (56.0% Full)
(.data + .bss + .noinit)
2016-11-28 02:01:14 -06:00