text: Welcome to the Parallax Discussion Forums, sign-up to participate.
  #include "simpletools.h" extern int binary_blinkasm_dat_start[]; int main() { cognew((void*)binary_blinkasm_dat_start, (void*)0); while(1) { } }
  pub main dat org 0 loop nop jmp #loop huuhaa long $deadbeef
  There are one or two small bugs in the pPropellerSim which are show stoppers if one is not aware of them.
  1. The Cold Reset menu command is not implemented
  2. hwreset() function in the Java code does not call cog.reset(true) so after first run of any spin/pasm code
  Together these means that is next to impossible to try to run some code and one is totally confused.
  After fixing those I'm able to run a simple spin program that launches a simple .pasm into a separate COG like this:
  However I'm unable to get the almost equally simple C/pasm combo to produce anything in cog 1, cog 0 just spins (no pun intended) in tight loop (maybe pulling something from hub memory and executing it?).
  How is the C code supposed to start executing?
  After reset Propeller loads the spin interpreter to COG 0 which then starts to read and execute SPIN code from hub, so is there some sort of SPIN launcher code to launch the 'kernel' mentioned in propellergcc docs ?
  Is this documented somewhere?
  I even wrote the simplest of C programs but simulating it does not produce anything that makes sense:
  Anyways, emulating the Prop is a bit of a lost cause, it's just kinda too fast, yet reliant on precise timing to get anywhere near 100% real speed. I do most of my debugging on a real chip, printing out values on the serial port.
  Yeah, tried GEAR. That too works with simple spin/pasm but not with the C-code.
  Hard to debug when there is so little info on how the C starts executing and what is and how the kernel that pulls code from the hub memory to cog for execution works.
  The Gear speed is pitiful, after all 20 MPIS/cog is not that fast when I'm running my stuff on 2.6 GHz 8 core i7. PIC gpsim runs at equivalent of 20 MHz which translated to 5 MIPS. I think the problem with Gear is just the screen update, there is no point and need to update the screen so often.
  Also Gears seems to be Windows only at least out of the box.
  I kind of agree with simulation point in general, but still it would be convenient to have good reliable emulator.
  I mainly picked pPropellerSim cause it is Java based and I'm very proficient with all things Java AND it is so much more cross platform than any of the other alternatives. I was able to get the project compile in minutes and debug those above mentioned problems in less than half an hour.
  Projects like this (writing a simulator) are very tempting but I try to steer away from them as this can easily turn into making tools to make tools for a side project of a side project.
  Oh well, I'll give this a rest for a day or two and see if someone has some helpful input.
  cheers Kusti
  If you're writing high-level code in C, I guess it's easier, since you can just compile it with x86 GCC instead of having to roll custom tooling
  On the topic of pPropellerSim, I assume you have version 1.0.0.12?
  Looking at the org.pacito.propeller.Cog class, many of the instructions are implemented very incorrectly. (for example, the Z flag result from MIN/MAX is supposed to be "S==0", not "S==D". The Z flag result from MOVS/MOVD/MOVI is also incorrect. I don't see where the flag outputs for hubram load/store are handled.). In case you want to try fixing it and want to take the fast path, I've attached some relevant source from my above-mentioned bespoke assembler / high-level emulator. It doesn't have every instruction (anything I/O or timing-related is not present) and some pseudo-ops specific to my XMM/LMM kernal, but all the ALU ops are there and as far as I can tell, correct (I've fuzzed each instruction - identical results on real HW). The interesting bits are the ALUINSTRUCTIONS table and the _frame_c method.
  (Stupid forum doesn't like .rb files, so once again, a ZIP)
  I currently have no PropGCC at hand but trying something remotely related with FastSpin yields the expected output.