pv2devkit (assembler and linker)
Zapped caught a bug in the pv2 assembler where CMP R1 was really assembling as CMP R0. I've fixed the fatfinger in the opcode table, and am now updating some of the examples for a 0.2 release. brite_eye, may I include your memory transfer programs in the devkit, under the BSD license? Anybody else care to add some sample code? Example code doesn't need to necessarily cover pv2 hardware - an example of some more advanced assembly techniques would be welcome as well. Zapped, did you want to contribute a song, so we can sing along? You could even open/close the shutter for a beat track, and pulse the LED for a light show, ending with a flash-strobe finale!!! Show me a commercial cam that can do that! ;) I'm going to try to include some examples with the following functionality: -charge cap, strobe flash -open/close shutter -LED on/off -watchdog disable -instant reboot Any other thoughts? ...keeping in mind the hardware registers that are known. Check morcheeba's memory page if you're unsure: http://www.maushammer.com/systems/dakotadigital/lcd-hardware.html and this thread which has a couple of uncommited updates to morcheeba's page: forumer.com/viewtopic.php?t=84" target="_blank">http://camerahacks.10.forumer.com/viewtopic.php?t=84 Any and all examples contributed will be fully attributed to the author.

Yikes - that was a good catch. Unfortunately, I can't contribute what I have been working on - which is converting the output of disv8 into something that can be "reassembled". I have the common ($90 -> $cfe) and bank 1 ($1000 to $3a34) done, and am tracing through it. The idea is to provide a "compilable" version for -*test*-('")ing that is (at least in the beginning) bit-for-bit identical to the 6550 FW that came with the camera. I hit a snag, though. How do I specify different banks? Bank 1 is easy - it simply maps into the same space as the common code. The other banks, however, will present a problem. Bank 2, for example, starts at $11000, not $4000 (though the diassembler seems to get confused on this as well) BillW - any pointers on how to create banks ala the way the firmware does?

BillW - no problem with snippets. You should include a warning with the flash.s that it doesn't work all the time - especially when executed sequentially without unplugging.

Brite_eye - you got it! Radarman, I started to post something along the lines of "just use multiple .ORG" directives, but then I reread your post. That's going to be tricky! My only thought here is to compile and link the banks as seperate programs, all using the .ORG $1000. Something like... *bank 2 code .ORG $1000 .EMPTYFILL $30 ;just like the pv2 firmware, fill voids with $30 * put the bank's code here .ORG $3fff ;this will pad the bank to the right size .DB $30 Then you can just concatenate all of the banks together. A bit brutish, but it should give you the right results.

You can include any of my stuff, either as is or modified. I am working on redoing the music to be more compact using .DB to define the notes and rests, but don't let me hold up the release of the new devkit.

That's a workable idea, but wouldn't you want to change your .ORG's to $1000, not $4000 - since the bank switch loader will place the bank at those locations. I would think .ORG'ing to $4000 would result in "bad things"? Also, this would mean you would have to do "ghost" JMP's by placing stubs .ORG'ed at the right place, with just a RTS or something. I'm doing that now, and it generates a lot of errors, but it seems to work.

Right, should have been $1000 and $3fff for the 2 ORGs, not $4000 and $6fff :P Basically a kludge to get the adresses right. AFAIK the firmware does the jumps into banks using calculated jumps from the jump table. The other jumps outside of the bank, you can just copy the direct address used by the firmware instead of using a label. (which if I understand you right, is what you're doing now)

BillW – It might be a good idea to put some notes with the examples, particularly with respect to the mechanical shutter. My July 10 post in ‘Camera Discussions’ outlined what I have discovered about the circuit that drives the shutter. The ‘open and ‘close’ signals are both positive pulses of 5 to 10 milli-second duration. I’m not sure if that translates to a zero-one-zero transition at the register level, or vise-versa. (I haven’t looked at the code yet.) But, leaving the shutter ‘energized’ for too long may fry one of the driver transistors. This would be a ‘bad thing’ since it now appears (thanks to dakotamod and teslafreak) that the camera uses the mechanical shutter during exposures! Topaze

No way to disable it completely that we know of. Though if you wanted to check this out you might look for unused memory locations near the watchdog and set them to 0, and see if it disables it. FWIW, writing "too frequently" doesn't hurt anything, other than wasting a few CPU cycles.

Even if you can disable the WDOG timer, I suggest leaving it on. It can be useful when developing new code, as it allows your processor to recover without you having to unplug the camera. What I wish I could find is a real timer interrupt. It would be great if there was a way to get the HW timer to trigger an interrupt. Hmm - I may have to play around with that hardware timer some more... FWIW - you can implement true multi-tasking if you have access to a hardware timer interrupt. I've done my own RTOS for a Motorola 68HC11, and it actually works quite well. (the 68HC11 is an 8-bit CISC microcontroller) Second "hmm" I wonder if you can set the reset vector to point to your multi-tasking kernel, and just let the WDOG timer act like a HW Timer interrupt? Not terribly safe, but possibly doable...

My "tools" are a copy of BeyondCompare, and Ultraedit :) Many of the functions are nearly identical, just located in different locations in memory. BeyondCompare allows me to see this more easily. I'm just now using the simulator - because I'm working on mapping out the banks. I suppose I could share, but since they are already shareware or freeware... Unfortunately, I had a bit of a setback the other day. I accidentally overwrote the first two banks of code with code from my FlatFoto2 - and I haven't had a chance to fix it yet. I was almost done, and when I finally am, I will have a mostly complete firmware.comments for the 6550 - based on Morcheeba's 6410. I've already made significant process on the disassembly - it just isn't commented yet. (the codes there - but Morcheeba's comments aren't) If you want the raw entry points - I can give you that, though. I could certainly use some help mapping the 6410 comments file to the 6550 firmware.

Whatever you can give me would be great. I'd like to help with the 6410 > 6550 mapping if someone has a 6410 I can have or borrow for the duration of the mapping. I've been using vim with the following search and replaces to get the disassembled code into a more assembler friendly state%s/^\([0-9a-f]*:\)\ \(.*\)\ \ \ \(|.*|\)$/DATA\1\r\.DB\ \2\ ;\3/ %s/\(^[A-Za-z].*:\)\(.*\)\(|.*|$\)/\1\r\.DB\2;\3/ %s/\(^[0-9]....................\)\(.*\)/\2\t;\1/ %s/^\*/;/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/\(^.DB\ [,$0-9a-f]*\)\ /\1,\$/ %s/,\$[^0-9a-f ]*\ /\ / %s/\(^.DB\ \)/\1\$/ %s/\ \ \/\//\ \ ;\/\// %s/\(^[^. ;:]*:\)\(\ [^+;]*\)+/\1\r\.DB\2;+/ ...and then wondering if it would be better to rewrite disv8 to output ready to assemble code

Actually, that is a good idea, but I feel my understanding of the firmware has increased by manually creating a "ready to assemble" set of s records. I started at $90, and followed the JMPs, JSRs, and BRanches. When I manually assembled/linked - I caught branches that I had missed. I now have several banks of FF2 firmware done using this method, and an increased understanding of how it works as a result.