Virtual PV2??
Has there been any thought to creating a "virtual" PV2 to perform "-*test*-('") runs" on in firmware variations?? May help come up with a preview screen solution...... All this stuff reminds me of the Z80 Assembler days...... :wink:

While it's not quite a "virtual pv2", daBass has a simulator for the processor in the pv2 at his website ( http://www.digitalfluff.net/pv2/ ). The missing part of the equation would be making the simulator understand all of the hardware registers that make the pv2 actually do stuff. Such a simulator would have to be incomplete, because we don't understand a good deal of those registers. (not to mention that there are several different hardware versions of the pv2 in the wild, with different sensors and different LCD configuration.)

Interesting...
This is very interesting. Hmm.....sounds like I'll be digging into the code. Now the only question is, will I it be the PV2 first, or the cam :D

I would recommend digging into the PV2 first, because due to the bootloader, they are practically indestructible. PM me if you want a copy of my la-*test*-('") forumer.com/viewtopic.php?t=2485>redistributable scripts to create re-assembleable, bit-identical firmware for four versions of the PV2 and also one version of the FF2.

The virtual (emulated) PV2 has been on my todo list for quite a while now, but due to serious time constraints, I haven't been able to get quite far with it. I think we know enough of the PV2 memory map / memory mapped hardware registers / bank switching to get something going quite quickly. If you have questions about the V8tools, let me know.

I have added a command to the simulator to run until it encounters a BRK in the code. The command is an uppercase "R" and will run until it hits a BRK and then can be run again till it hits another BRK. I did not change the function of the lowercase "r" command and did not make the uppercase "R" command to accept a number of lines to execute, it just keeps running till a BRK.

I am in the process of making the simulator append to a file the register variables whenever it encounters a USR command. I found that the assembler allows for USR R0 through USR R7 and the simulator displays USR R0 as just USR and displays USR R1 through USR R7 as NOP. The documentation on the uRISC it doesn't seem to indicate that there are 8 USR opcodes although there seems to be room for them. For now I will just add functionality to the simulator to append all register contents to a file when it encounters opcode 0xA0 or USR or USR R0. Comments on how it should be done are welcome. I suppose one option would be to use USR2 R0 through USR2 R7 when one wanted to log to a file a single register, but for my purposes right now I just need to be able to throw various inputs at a function and be able to determine what it is doing by analyzing the output. I can email the modified source to anyone who wants it or to someone to post it on sourceforge or wherever.

Ok, I believe I have it working like I wanted to. Upon running, it creates (deleting if already exists) the file v8sim.log and writes "Simulation of" followed by the name of the file being processed and the labels for the output columns. If/when it encounters the USR R0 instruction it appends the register values. Here is example output: Simulation of -*test*-('").pv2 PC SP R0 R1 R2 R3 R4 R5 R6 R7 ZCNI---- 0095 007F 04 03 00 00 00 00 00 00 00010000 0096 007F 04 03 00 00 00 00 00 00 00010000 0097 007F 04 03 00 00 00 00 00 00 00010000 009B 007F 1F 87 00 00 00 00 00 00 00010000 009C 007F 1F 87 00 00 00 00 00 00 00010000 I can email the modified source and binary to anyone who wants it or to someone to post it on sourceforge or wherever. Should I separate the columns with tabs instead of spaces?

Now that I am trying it out, seems I may as well allow the command to run till x number of BRK are reached so that typing command "R 5" will run until reaching BRK five times.

lol look at the timestamp on zapped's posts.

Ok, after having lost my modified source and binaries for v8Tools, I have rewritten the changes I made and posted source and binaries.

A couple of notes: 1) There are two user instructions. Neither are implemented on the PV2. (I did use them to implement some cool instructions on my VHDL model though) They are full opcodes, which means that you can use any register as a source. (ie. USR R1 is perfectly valid) Since the instructions aren't implemented, they end up as NOP's. 2) You don't necessarily need to implement every hardware register for the simulator, though that would be nice. All you really need to do is make sure that the software doesn't "hang" waiting for a register to change state. Once the software seems to run normally, go back and fill in the missing bits. A true simulator will be an iterative process, since we don't have the HDL/schematics of the ASIC.