PDA

View Full Version : the Propeller Emulator



Chris Micro
07-04-2009, 10:06 PM
Propeller Emulator
==================


This programm runs propeller code on a pc.
It looks for a file "test.binary". If this is a assembler file,
it should contain the magic number as described below.

V048B:
- windows console
- linux console
- 4 cogs
- 32K hub memory
- dissassembler
- debugger
- speed/cog~3Mips@1.6Hz intel ATOM processor

console commands to start the emulator:

windows: propsim.exe

linux: ./propsim.out

The linux console has the advantage that you can use cursor positoning commands
and color commants like in vga_text.spin.
This is due to the linux console supports escape sequences for an Ansi-Terminal.
The windows console does not support this, so there is only mono color and
no cursor postioning.

option examples

./propsim -h -> help, show options
./propsim -d -> run in debug mode, press 'h'<ret> for help
./propsim -d -a -> run in debug mode and don't try to load and execute spin.binary

Assembler file:
===============
An assembler file which can run on the emulator should have the following start up
sequence with a magic number.




pub xx
'nothing
DAT
magicNumber
long $55AA1133 'magic number as starting point for the cog emulator

org 0
start
' some example code
movs printText,#hello
call #printText
....
....

fit 496






the code for the emulator can be found here (http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=77)

Post Edited (Chris Micro) : 7/13/2009 9:16:00 AM GMT

CassLan
07-04-2009, 10:08 PM
Hey Chris I can't wait to try it out!
Any plans for object/peripheral emulation? Like TV_Text

Rick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Prop Forum Search (Via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)

Chris Micro
07-04-2009, 10:12 PM
TV_Text is emulated in the following sense:

the characters you write to hub memory 0 by wrbyte are displayed.

You can see how it works in the test.spin file.

You can change colors and position the cursor like you do it in TV_Text.

jazzed
07-04-2009, 10:21 PM
Have you tried running Propeller ROM code? ... booter.spin, interpreter.spin, runner.spin

I ran your app on my linux server account and it looks fine. A windows version could be useful
for me since the linux server is not mine (I don't have root privileges).

I see you use the -d argument for debug. Are there interactive commands other than "enter" ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 7/4/2009 3:32:08 PM GMT

Ale
07-04-2009, 10:29 PM
The spin interpreter needs compiling. If you just compile it it will work as it is (with PropTool) if you remove the header, or use this compiled version. I'm using it in pPropellerSim for the Spin interpreter.
Edit: Mac OS adds some silly files that start with a dot, you can remove them from the zip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

jazzed
07-04-2009, 10:33 PM
Ale, are you able to fully boot a Propeller in pPropellerSim ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Ale
07-04-2009, 11:27 PM
jazzed:
In short: No.
Long: I never ran the booting code. It should work if I emulate a i2c eeprom http://forums.parallax.com/images/smilies/smile.gif. The spin interpreter is loaded using the normal HUB reading cycle and Spin is interpreted using it. So a normal Spin program runs and you can spawn new cogs using COGINIT.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

Chris Micro
07-05-2009, 02:43 AM
Hi Ale,

thank you for posting the code.
The spin interpreter has to be called with the register PAR preloaded ( I assume it is the beginning of the propeller program ).
Which is the address I have to preload PAR?

best regards,
chris

Ale
07-05-2009, 03:06 AM
At least for the first one it has to be the number 4.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

Chris Micro
07-05-2009, 03:10 AM
Thanks, thats what I needed. http://forums.parallax.com/images/smilies/smile.gif
I will try to run it tomorrow.

Chris Micro
07-05-2009, 06:11 PM
Hi all,

I posted the new version V048 which loads the file

spin.binary

which is the spin interpreter.
If the file is found, the code will be loaded in COG0 and the cog is started with PAR=4.
I have no experience with the interpreter and it seems that there is some error.

You can debug the interpreter by starting the program with the -d option

./propsim.out -d

pressing return ... will single step through the code.
If you press 'h'<return> you will get a list of the commands in the debugger.

Can someone take a short look into the trace to help me find the error?
This would be very nice,

chris

Chris Micro
07-05-2009, 09:43 PM
Hi there, the first windows version is running,
Any remarks welcome ...

jazzed
07-05-2009, 09:51 PM
Can you add "spin.binary" to your package or tell how you're building it? File interpreter.spin does not have a pub and will not compile.
Thanks for the h command and the windows cmd version. Any reason you are limiting to 4 COGs ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Chris Micro
07-05-2009, 10:07 PM
Ale posted the code in this thread. He named it spin.pasm.bin . You can rename it and use it.
I'm not sure about legal issues, if I would pack the spin code in the zip file. I'm sure that very soon someone from Parallax will comment this in this thread.

>Any reason you are limiting to 4 COGs ?
Only because every COG needs processing time. I estimate that the speed with 4 COGs is about 3Mips/cog on my ATOM 1.6GHz ( yes it is only a NetBook http://forums.parallax.com/images/smilies/smile.gif )

Could you run the emulator with the example code and tell me how fast it is?

It would be very interesting if someone could write a little assembler benchmark program to see the mean speed of the emulator.

Sapieha
07-05-2009, 10:36 PM
Hi Chris Micro.

I'm very interested in Yours Emulator BUT in litle other approach.
No mater if it will be speed isues BUT nessesary it is fuly compatible with Propeller chip.

My question is If it then be posible to adopt this emulator to THAT Simulation program.
http://www.labcenter.co.uk/products/vsm_overview.cfm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

jazzed
07-05-2009, 10:36 PM
Not sure what you mean, but waitcnt appears to be working although your implementation could use a little tweek.



mov timer, delay
add timer, cnt
numberLoop
waitcnt timer,delay
movs printText,#text
call #printText
jmp #numberLoop



Benchmark is a loaded word around here :) I might do some low complexity testing later, but can't promise much today ... we'll see.

I was able to start ALE's file and step through it. I suspect that you need to make a loader for normal spin programs.
Having a -spin <spinfile> agrument and using Propellent to compile would be greatly appreciated.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Chris Micro
07-06-2009, 02:33 AM
> ... your implementation could use a little tweek.
Yes, thank you, I was a little lazy in preloading the timer variable with the cnt value. http://forums.parallax.com/images/smilies/smile.gif

>I suspect that you need to make a loader for normal spin programs.
The "test.spin" file is loaded into the hub memory. I assumed, that the spin interpreter running in COG0 automatically interprets "test.spin" as spin code.

Do you have any useful ideas what should be implemented in the emulator?
I was thinking of laying the keyboard as input on $f002 in the main memory.
Another thing is I want to create sound. But it seems the best if the emulator can write some values in a wav-file.

jazzed
07-06-2009, 08:09 AM
Being able to start the interpreter is not of much value unless you can demonstrate in some way that it is functioning :)

One of the most impressive Propeller Emulator things I've seen (but not run myself) is the TV display produced by running GEAR. Being able to create virtual peripherals for TV, SEEPROM, audio, or other devices without having to change the emulator has value. For me I hope it would be like plugging in a propeller proto-board to my PC and doing work that can easily transfer to real hardware.

Getting a "simulator" to behave exactly like real hardware without connecting anything to the workstation or PC, from compiling and downloading from the propeller tool to running code with the luxury of breaking the main cog execution would be premium. If one could get a virtual COM port to enumerate on the PC (linux driver would be easier:), that would enable virtual downloads. One could create a "memory mapped" TV/VGA display pretty easily on a PC window (I've never tried graphics on linux). Emulating a SEEPROM would not be too hard and I've actually started writing code for that and a larger system that could potentially connect emulated components together.

I guess the question is: "how useful would all of that be?"

When I'm done with my current distraction, I could help you with some of this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Chris Micro
07-07-2009, 01:05 AM
Sapieha said...
My question is If it then be posible to adopt this emulator to THAT Simulation program.
http://www.labcenter.co.uk/products/vsm_overview.cfm


Uhh, that would be hard. I tried to concentrate on the logical structure of the commands not so much on the accurate timing relations.
In the emulator, every command takes exactly one cycle and also every hub access takes exactly one cycle. This is different to the real propeller and also the peripherals are not emulated yet.
I would not say that it is impossible, but it would take really a lot of time to program this. Because it is only a hobby project for me I would not invest that much time in it unless someone pays me for that.


jazzed said...

One of the most impressive Propeller Emulator things I've seen (but not run myself) is the TV display produced by running GEAR.
....
When I'm done with my current distraction, I could help you with some of this.



Interesting, I saw it, tried it and nothing worked. So I thought it is a dead project.

I began this emulator project, because I did another little project (http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=24) where I wanted to see how difficult it is to write a simple emulator.

Than I thought, the propeller instructions are much more powerful than these of the Lapoco-core and will try to implement an emulator for the propeller.
In the early version I ran it on the Atmega32 ( where the memory is to small to run spin ) and afterwards I ran it on an LPC2103 ARM 7 processor.
If spin would be running in the emulator it would be interesting to run it on the ARM7 http://forums.parallax.com/images/smilies/burger.gif
( just for fun, because it will be slow )

I would be very glad if you are interested in this project and like to work with me on it. I will than make it Open Source.

Post Edited (Chris Micro) : 7/6/2009 6:10:51 PM GMT

jazzed
07-07-2009, 12:49 PM
Chris Micro said...
I would be very glad if you are interested in this project and like to work with me on it ....

I'll work with you on making the emulator run Spin programs on Windows and Linux PCs after I finish the COBY DP151 hack. It might be interesting to port the Spin interpreter to another uC and allow interface to another chip's native ASM, but I don't really care to contribute to PASM running emulated on another chip other than the PC.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

MagIO2
07-07-2009, 02:11 PM
Just want to announce that I'm currently writing a Propeller simulator as well. (In fact I started after I read this thread ;o) My version is written in Java, so it will run on any system with a Java-VM available.

I do simulate the whole COG pipeline, so self modifying code has the same restrictions as on the real prop.
Current status is that I load the RAM and ROM (from eeprom-files - don't see a reason for running the boot-loader at the moment) and I start COG 0 with the SPIN interpreter.
The HUB is already doing it's job, so rd / wr are synchronized with the access window.
Actually it's doin nothing but disassembling what it finds in COG-RAM, because next step is to implement the instructions.

Just want to tell you. I do it for the pure interest, so I'll continue anyway. So, if you have anything better to do you might prefere to wait.

Post Edited (MagIO2) : 7/7/2009 7:27:26 AM GMT

Ale
07-07-2009, 04:02 PM
Hei MagIO2: Why you just not extend/improve the one I wrote, also in Java ? It only needs a spin disassembler and some small touches here and there ?

Edit: I'll post the code as soon as I can post it :-(, sadly it failed 4 time to upload here http://forums.parallax.com/images/smilies/rolleyes.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

Post Edited (Ale) : 7/7/2009 2:14:53 PM GMT

Ron Sutcliffe
07-07-2009, 04:57 PM
It would be fantastic if there where a Prop emulator, with virtual TV and KB interface.

An emulator that could boot, load the spin interpreter into cog 0 and load user code from *user.binary*,··
would be very useful
It does,·so lets have another play

Having a virtual Tv.obj with access to the standard tv parameters and memory map Users could load their own version of TV_text or TV_graphics.

Not having to pull out the PDB, screen and PSU’s every time you want to work on something would be really handy. I do use my own version of tv_text often for tracking pointers, debugging and the like and am sure many other do the same.

A virtual com ports would allow users to adopt their own keyboard code or use PST, realterm etc.

Neat.

Ron

Post Edited (Ron Sutcliffe) : 7/7/2009 10:54:33 AM GMT

MagIO2
07-07-2009, 08:05 PM
Don't see a big problem with a virtual display. Actually that's one of my goals. The good thing here is that in the end the output is generated by hardware, the video generator. To simulate the propeller means to simulate the video-generator as well. So, besides driving the virtual pins the simulator can simply generate an image to be displayed.

The keyboard/mouse/serial interface ... is done in software. Currently I don't know how fast the simulator will be in terms of MIPS/COG. Plus, the real execution time per instruction is most likely different for different instructions. So, attaching these virtual pins to some real hardware will be difficult because you can't guarantee the proper timing without a lot of work. Simulating the hardware means a lot of work as well - but could maybe be done by the community.
But maybe it would be easier to have a driver-replacement. For example the driver replacement of the keyboard driver has the same interface for SPIN/PASM but is not really attached to I/O pins. Instead the PCs keyboard input is read. Easy way to inject data into the COG would be to use the not used opcodes which have been reserved for future use.

MagIO2
07-07-2009, 08:10 PM
@Ale: As I said "I do it for the pure interest".

And to be honest ... I think it's easier to do this by myself from scratch than reading tons of code and modify that. Do you already simulate the counters and the video-generator? Did not find this in your COG-class on the first glance.

SPIN disassembler seems to be a bit trickier, isn't it? Because that's compiled into bytecode and the bytecode is not a 1 to 1 relation to SPIN instructions, or is it?

Chris Micro
07-07-2009, 08:22 PM
Ale's Propeller Simulator was very useful to me to learn Spin Assembler. You could easily modify the code and debug through it.

It was available under

http://sourceforge.net/projects/propellersim

Ale
07-07-2009, 09:15 PM
MagIO2: I do not simulate counters or video circuitry. It was not the idea of the sim. The problem with Spin is not exactly Spin, it is how the different things are put together. As soon as I understand it I can implement it, it did not happen till now though. http://forums.parallax.com/images/smilies/lol.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

BradC
07-07-2009, 10:05 PM
MagIO2 said...

SPIN disassembler seems to be a bit trickier, isn't it? Because that's compiled into bytecode and the bytecode is not a 1 to 1 relation to SPIN instructions, or is it?


Yes and no. I wrote a spin disassembler in a night with the Interpreter code as a reference. It's not difficult. This would get you to a bytecode listing you could single-step through.

To disassemble back to a structure resembling original source is a bit harder. Case statements are doable, If/Else is a bit harder and repeat gets a bit complex.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!

jazzed
07-07-2009, 10:34 PM
@Ron, Yes indeed, a virtual COM port so we can just download to the model would be cool :) I wonder if CounterRotatingProps knows how to make one of those for windows. Like I said linux is pretty easy IF you have root access ... I wrote drivers for 2.4/2.6 kernel before.

Clock ticks similar to Verilog in an emulation / simulation model is necessary especially for counters. I actually started designing a software "platform" that would use device model libraries, pin-outs, and net-lists that would run based on ticks. An SEEPROM model would be one of the first implemented followed by a Propeller model (except that I'm distracted by hacking the COBY DP151). Here is a list of files and some "config" samples.



Makefile config e.exe /hashtable netlist.h propeller.h seep.c
arraylist.c devices.c emulator.c main.c propeller.c proper seep.dev
arraylist.h devices.h emulator.h netlist.c propeller.dev prophw.h seep.h



Example .dev and config files are attached.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 7/8/2009 3:57:51 PM GMT

Chris Micro
07-08-2009, 02:21 AM
jazzed said...

Clock ticks similar to Verilog in an emulation / simulation model is necessary especially for counters


uiii, that looks like a lot of work. This looks really professional. At the moment try to correct some errors in the emulator.
Probably you could try to run some assembler commands ( or a little program ) on the emulator to see if it is all working ok.


BradC said...
Case statements are doable, If/Else is a bit harder and repeat gets a bit complex.

Hi Brad, there is exactly my problem: The emulator is now able to run some spin
( which means something easy like outa := 1 .. waitcnt .. and so on ). But wiht the if/Else and repeat instructions there is a problem. It simply ignores them.

Could you run the emulator with

./propsim.out -d

With <ret> there is a single step mode ( and h for help ). Probably you can see in a few steps where it goes the wrong way.

Best regards,
chris

Post Edited (Chris Micro) : 7/8/2009 7:24:26 AM GMT

BradC
07-08-2009, 08:45 AM
Wow, that is hard to follow :)

A completely unrelated point, but you are not decoding the lock instructions




cog0 - 0091 : 5CCBBDDA IF_NC_AND_Z CALL 1DE ,#1DA [dest]5C7C00F8 [source]84FFDE04 Z: 0 C: 1

cog0 - 0092 : 0C480000 IF_NC_AND_Z -------- 000 ,#000 nr [dest]00000000 [source]00000000 Z: 0 C: 1 <---- lockret

cog0 - 0093 : 08480200 IF_NC_AND_Z WRLONG 001 ,#000 nr [dest]00001170 [source]00000000 Z: 0 C: 1





You have some uninitialised memory, or you are writing something somewhere it's not supposed to go.

This code is supposed to write $AA to OUTA, but 50% of the time I run it, it writes $55.

The non-deterministic nature of the fault indicates a bug that is not a logic error, but something more sinister.

I can't really help much further until I can get the same result each time I run the simulator ;)




Local Parameter DBASE:0000 - Result
Local Variable DBASE:0004 - x
Local Variable DBASE:0008 - y
|================================================= ==========================|
2 if 1 == 2
Addr : 0018: 36 : Constant 2 $00000001
Addr : 0019: 37 00 : Constant Mask Y=0 00000002
Addr : 001B: FC : Math Op ==
Addr : 001C: JZ Label0002
Addr : 001C: 0A 06 : jz Address = 0024 6
3 outa := $55
Addr : 001E: 38 55 : Constant 1 Bytes - 55
Addr : 0020: 3F B4 : Register op OUTA Write
Addr : 0022: JMP Label0003
Addr : 0022: 04 04 : Jmp 0028 4
Addr : 0024: Label0002
5 outa := $AA
Addr : 0024: 38 AA : Constant 1 Bytes - AA
Addr : 0026: 3F B4 : Register op OUTA Write
Addr : 0028: Label0004
Addr : 0028: Label0003
Addr : 0028: 32 : Return


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!

Cluso99
07-08-2009, 12:18 PM
Chris:
Not sure if this helps, but I have a debugger that traces both spin and asm. It takes zero footprint (4 longs), so you would have to move that bit as your emulation is probably not going to reproduce that part properly (the shaddow ram underneath the registers $F0-FF).

It may help you to compare your code to real code on a prop.

See the tools link in my signature.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Chris Micro
07-08-2009, 02:21 PM
Cluso said...
Not sure if this helps, but I have a debugger that traces both spin and asm.


Hi Cluso99, thanks for your hint. I will try to use it.


BradC said...
A completely unrelated point, but you are not decoding the lock instructions


Hmm, well, I didn't implement the "lock" instructions yet, because they were not necessary for the basic functions of spin.

>The non-deterministic nature of the fault indicates a bug that is not a logic error, but something more sinister.

That hint is very helpful to me, because on my system the program behaves always the same.
I didn't preinitialize the hub memory with zeros, probably this may make the difference to your system. Now I made a version preinitializing the hub memory to zero ( see attachment ). Probably you could give me a second try.
I now implemented the command 's' in the debugger. It shows the spin registers ( x,y,a,t1,t2 ... ) and interprets some opcodes of spin. Probably this could be very useful for debugging.

Post Edited (Chris Micro) : 7/8/2009 2:47:43 PM GMT

Chris Micro
07-08-2009, 09:48 PM
Uhh, it is more work than I thought.
I corrected some errors in the assembly conditions, now the if/else in spin works.
But ... the repeat is still not working.

I would be very glad if someone could try the emulator and give me a feedback http://forums.parallax.com/images/smilies/blush.gif

jazzed
07-08-2009, 10:53 PM
Chris, I would do more, but I'm kind of tied up now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

BradC
07-09-2009, 07:27 AM
Chris Micro said...
Uhh, it is more work than I thought.
I corrected some errors in the assembly conditions, now the if/else in spin works.
But ... the repeat is still not working.

I would be very glad if someone could try the emulator and give me a feedback http://forums.parallax.com/images/smilies/blush.gif


I'll try and do this today for you if I get the chance. Stepping through the interpreter and correlating the code positions to the original spin source/listfile is somewhat of a headache.

Just a suggestion though, rather than using the spin interpreter to debug the emulator (if you think about it, if the emulation was 100% then the spin interpreter would run perfectly) would we be better knocking up a series of PASM test cases that are easier to step through to improve the accuracy of the cog emulation first?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

Ale
07-09-2009, 12:02 PM
I'm all for BradC's suggestion:

Test all conditions

Test shift instructions
Test bitwise instructions
and so on...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

MagIO2
07-09-2009, 01:33 PM
And check the result including the C and Z flags according to the WZ and WC modifiers. SPIN interpreter is using flags and conditional execution very much.

I would (or will) do it like that (when my emulator is done):
1. check that movd/movi works
2. check that·mov works with the 4 conditions IF_C_AND_Z, IF_NC_AND_Z, IF_C_AND_NZ and IF_NC_AND_NZ
1. and 2. are needed for the test framework

3. Then you can write a test framework for each instruction
··· Well ... the test framework depends on how you implemented the emulator. My emulator for example has some basic stuff. The conditions are checked before running the instruction code. So, I only have to check the conditions once and know that they will work with each instruction. Same with the·WR, WZ and WC - same method to set the flags is called after execution of each instruction (the instructions themselve only·use an internal set of the flags). So the WR, WZ, WC and I flags will also work for each instruction if I prooved that it worked for one.

· In the new Propeller Manual there are nice tables that show which operands lead to wich result including the flags. You only have to run each instruction with all those operands and you directly can compare the result with the Propeller Manual. To check that the flags are correct the IF_... can be used, which simply moves a defined value to a register according to the flags.

·

Ale
07-09-2009, 01:43 PM
Chris where is the source ? I'm on a Mac here http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

Chris Micro
07-09-2009, 03:43 PM
> .. where is the source ? I'm on a Mac here http://forums.parallax.com/images/smilies/smile.gif

It is a liitle bit a mather of documentation. First I wanted to document it a little bit more before I post it.

What do you think of about using Doxygen for Documentation?

http://www.stack.nl/~dimitri/doxygen/

I used it in earlier projects and it's quite good.

heater
07-09-2009, 04:10 PM
I think DoxyGen is an excellent idea.

I find that adopting a system like that encourages one to actually do documentation:) DoxyGen is pretty cool anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
07-09-2009, 09:27 PM
I'm a BIG fan of Doxygen ... even used it in spin a couple of times. It's available for Linux, Windows, and Mac. At minimum use file, param, and returns tags and describe each "public" function. If you use headers (as library API as well as forward declarations, etc...) it's good to put the markup the .h. Otherwise markup in the .c is fine.

BTW: Cluso99's debugger along with mpark's homespun and verbose listings can help you track those spin errors. It's kind of a pain to have to manually resolve the instructions with the source, but the assembly listing output for every spin statement is priceless.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 7/9/2009 2:32:48 PM GMT

Chris Micro
07-09-2009, 11:38 PM
Thank you all for your help till now.

The source code is now online here (http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=77)

I have some problems with doxygen. It seems only to take the *.h files for documention.

jazzed: can you give me some hints or examples how I can improve the documentation for doxygen?

jazzed
07-10-2009, 01:37 AM
You have to add extensions to the Doxyfile FILE_PATTERNS parameter. Also, I believe each file must have a @file <filename> tag in the doxygen markup comment.


/**
* @file myfile.c - example markup
*/


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

MagIO2
07-10-2009, 02:53 AM
@Chris:
Didn''t you forget the
regs->pc++;
for the REV instruction?

Cluso99
07-10-2009, 10:22 AM
Chris, If you use my debugger and you trace where the spin instruction fails, you can turn on the trace to trace the pasm instructions being executed and see which pasm instruction is wrong. Each pasm instruction shows the results of the flags and memory before and after the instruction. Hope this helps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Chris Micro
07-10-2009, 04:54 PM
MagIO2 said...
Didn''t you forget the
regs->pc++;
for the REV instruction?

Hi MagIO2,
congratulation, you are the firs who found one error. http://forums.parallax.com/images/smilies/yeah.gif
I corrected the rev-function before thanks to ALE who helped me. But in my correction i deleted accidentally the regs->pc++. There was an misunderstanding on my side before because because rev reverts 32-n bits instead of n bits.


Cluso99 said...
If you use my debugger and you trace where the spin instruction fails, ...

Thats probably a good idea. At the moment I try to write some test cases.

Chris Micro
07-10-2009, 05:01 PM
Hi together,

the prop emulator is my first real open source project. So, as the project advances, there are some people who want to use the code. Now the question about the license arouses.

I got the following message:

Somebody said...
Do you mind if I use your code in a non-commercial, but not open-source app?

I've been contemplating adding a Prop ... to my ... code...

Your simulator seems like a good fit. I think it'd save me a lot of work.

But, I don't want to give out my .... code...


What do you think how to deal with that question? Is there anybody out there who has experience programming open source?

Ale
07-10-2009, 05:20 PM
It depends on what you think of free.

I normally make my code GPLv2 because I do not want businesses from profiting from my work when they do not compensate me. But of course anyone can just use any code and bundle it without saying anything. That is a really bad practice. LGPL 2 is also a nice alternative.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

heater
07-10-2009, 06:37 PM
Chris you really have to a ask yourself what you want because we can only tell you what we want.
Do you want people to be able to see your code, use it, modify it? Should they be able distribute it in source or binary, modified or not, with attribution in place or not? Do you mind if they sell it for profit or or otherwise? On it's own or in combination with other work. Etc etc etc.

You might want to look over the GPL and LGPL licences and the BSD, MIT licenses for starters. If you want to drive yourself nuts take a look at all the licenses approved by the Open Source Initiative.www.opensource.org/licenses/alphabetical (http://www.opensource.org/licenses/alphabetical)

You can always craft your own license, but I get the feeling we have enough licenses in the world already. May be just as well to pick one that fits your desires and save your users a little confusion.

Nothing stops you releasing your code under more than one license or using an existing license with some of your own exceptions specified.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Ron Sutcliffe
07-10-2009, 06:52 PM
Hi Chris
I just downloaded and compiled your simulator. I can't see how you have handed the pipelining in the hub fetch, execute and write back. It's probably there, I may have missed it. I remember I was intrigued to see how it was handled in Ale's code. Anyway, good job. I am sure you will get some help from Jazzed, but he is going to have to get his finger out if he's going to get his latest toys ready for Christmas. :)

Ron

BTW I will do some testing see what we come up with.

MagIO2
07-10-2009, 06:59 PM
@Ron:
No pipeline. In one of the first posts he mentioned that each instruction needs one clock.

Ale
07-10-2009, 07:12 PM
I told Chris about my almost cycle accurate method. The point is: as his simulator was designed to be run by other processors than a PC, a pipeline and cycle exactness where not necessary. Especially becausee he wanted real time to mean the same time for the host as the simulated processor. I can see some advantages here. I was wondering how fast a COG simulator could be implemented using the XMOS chip. Especially because you have real 8 threads and no simulated ones... I'll have to give it a shot.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

heater
07-10-2009, 07:57 PM
Exact cycle timing is probably not necessary. But I'm sure there are programs out there that will fail if some pipe lining is not implemented. At least the simulation must read the next instructions op code before writing out the results of the current one. Otherwise some self-modifying code may well fail. I don't know if Chris has done that yet.

Simulating a COG on XMOS, that's cheeky!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

MagIO2
07-10-2009, 08:04 PM
I think that the problem is more on propeller-side. If you develop code and first test it in the simulator, then you will find out that the code might not run on the propeller. As we all know about the self modifying code problem we tend to put an instruction between modifying code and execution of the modified code. The case where you rely on the fact that the code has not been modified yet is rare - isn't it?

So, most software written and tested on the prop will run in such a simulator.

heater
07-10-2009, 08:23 PM
"problem" or just "feature". Given the requirements for consistent instruction cycle times and pipe-ling for speed I guess this issue is inevitable.

Now I'm sure you are right in saying that most code tested on the Prop will also run on the simulator. However I maintain that:
1) If the simulator gives different results for an instruction sequence is just wrong. It may be rare in actual use but it's just leaving a little bomb there for someone in the future which will cause a lot of wasted time and head scratching.
2) If the code is already tested and working on the Prop there probably is no need for the simulator.
3) Working in reverse if the code is being debugged on the simulator it is necessary that it is executed accurately other wise those mysterious failures on a real Prop will be unnecessarily hard to find.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

MagIO2
07-10-2009, 08:45 PM
I fully agree with you for the "use the simulator as development tool" usecase. But I think that Chris' usecase is different. He want's to simulate the propeller with other microcontrollers. And there the pipeline is simply a speed issue. Knowing that code written for the prop runs on the simulator is sufficient for that usecase.

My usecase is the development tool usecase as well and that's why I currently write my own simulator which implements the pipeline. Hopefully I can finish the implementation of the instructions this weekend. And I hope Chris left some forum participants that are willing to test 'yet another prop simulator' - YAPS .. nice name. ;o)

heater
07-10-2009, 09:10 PM
Perhaps I don't understand the speed issue or the complexity of getting this pipeline working. But isn't it the case that simply fetching the next instruction prior to writing the current result is sufficient? That would not make the simulator much slower, if at all.

I like this idea of Prop simulator in C for running on other micros.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Ron Sutcliffe
07-10-2009, 09:30 PM
My thoughts for what they are worth.

More often than not Prop applications drive devices in Real Time. Without correct timing the simulator is very limited. I recently used the Gear logic prop to get my External memory driver up and running. I don't think that speed is all that important in a development tool, I think its better to get useful information from it. Users will contribute various interfaces. I found Gear Plugin scripts difficult to use.

Ron

jazzed
07-10-2009, 09:35 PM
YAPS :)

There are not many multi-core micros out there that can emulate the propeller. One core micros can use interrupt context switching to do some of it, but emulating 8 cogs is unlikely. Heater is right about needing the pipeline (or a simulated one) if the simulator is used for Propeller development without needing Propeller hardware.

chCog.c looks so familiar :) I did something very similar in Verilog except that I saved pc increment and destination writing for the end of the switch statement and used flags to determine if those options should be done.

On the licensing front, GPL is a pain for "independent users" since it requires feeding back changes ... if bug fixes are done they would be helpful though :). Just use the MIT license which only requires giving due credit to the original authors (although it does not specify how that is done).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Ron Sutcliffe
07-10-2009, 09:35 PM
@heater
Ale made it look too simple. I would find the code, and post it buts its 1am and its zzzzz time

Ron

Ale
07-10-2009, 09:40 PM
YAPS is a lowsy name. Well I think that every Yet-Another... is a lowsy name. MagicSim or something like that is much nicer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

heater
07-10-2009, 09:45 PM
YALN!

I don't remember the GPL requiring your changes to be fed back to the original authors. But you are required to make your (possibly modified) sources available to anyone you give compiled binaries to. Not such a big deal if you are publishing source code anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
07-10-2009, 10:43 PM
It is effectively the same thing and results in lawsuits for "source users" who don't share that have deep pockets.
If you feed your changes back to the public source tree, you have provided source to the user.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 7/10/2009 5:43:27 PM GMT

MagIO2
07-11-2009, 12:36 AM
For naming it MagicSim it has to be really really good. YAPS itself is some kind of an excusion if nobody else likes it ... Hey dude .. it's just another whatever ;o)

I don't know what to think about this licensing stuff. On one hand I like the Open Source idea. But on the other hand - as long as we live in a world where you have to work for living I don't like the idea that somebody makes money with your code not sharing the money.

heater
07-11-2009, 01:24 AM
@Jazzed: It's not the same thing at all.

Say I make some changes to the GPL'ed project supergizmo and then give you the compiled supergizmo my responsibility under the GPL is to make the sources available to you. It's no good me saying "I sent my changes to the upstream authors". They may have rejected my patches. Or modified the patches. Or maybe used the patches but in a newer version which is no longer the source of what I provided to you.

@MagIO2: Use licenses to suit your purposes. If you have a great prog that you can sell for money then license it as a normal commercial closed product. Why not?

If your having fun hacking something and want others to enjoy then go for GPL or such.

If you don't want anyone to take your code and sell it for profit, perhaps incorporated into some other work, then don't use a BSD style licence.

My own tiny example is ZiCog, which is a) Is very unlikely to be a money earner. b) Has benefited greatly from exposure here and the subsequent suggestions of people who looked at it. I have yet to put any license on that. I need to think about this as well...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
07-11-2009, 02:05 AM
@heater, I accept that and see the advantages, but to provide such a "special release" is of no benefit to the greater community and is often of detriment to users that may want to keep up with the latest "main line" by themselves without support from the initial vendor. So do with it what you can to help you sleep well at night :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

heater
07-11-2009, 03:23 AM
@Jazzed: I agree with what you say about special releases and the wider community. However sometimes you just have to get things done. For example in my last gig we were shipping embedded systems running Linux on custom designed ARM board. That kernel was heavily patched to run on that board. A number of support programs were bug fixed. On my current job we will soon be shipping Linux with additional in house drivers. In none of these cases can we be sure that our changes ever made it back to the main line trees. We have no problem supplying all such sources to our customers if they ask for it. Our application code is a different story though.

Not sure what you meant about "sleep well at night", I don't think we have been bending any license conditions doing all this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
07-11-2009, 03:35 AM
I meant that I hope your customers aren't calling you at 3AM :) Apparently you have a good agreement with them.
When it comes down to it, you ship whatever keeps your customers happy :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

MagIO2
07-11-2009, 05:58 AM
Just started testing my simulator even if not all instructions are implemented yet (only 11 missing). But maybe you are interested in my test program and it is helpful for testing the other simulator:



pub main
cognew( @SimIt, 0 )
dat org 0
xy long $abababab

DAT org 0
SimIt ' check that these instructions work correct
movd test1, #$1ff
movd test2, #$000
movs test3, #$1ff
movs test4, #$000
mov test5, #$000
mov test6, #$1ff
mov test7, #0 WZ, WC, NR
mov test7, test8 WC, NR
if_Z mov test8, #$1ff
if_C mov test9, #$1ff
if_NZ mov test10, #$1ff
if_NC mov test11, #$1ff
add test10, #1

' here comes the test cycle for one instruction
test_loop movd inst, test_pointer
add test_pointer, #1
movs inst, test_pointer
add test_pointer, #1
movd c_flg, test_pointer
add test_pointer, #1
movd z_flg, test_pointer
add test_pointer, #2

' this is the instruction that has to be tested
' =============================================
inst xor test_data, test_data WC, WZ
' =============================================

' show which flag is set
c_flg if_c mov test_data, #$1ff
z_flg if_z mov test_data, #$1ff
djnz test_cases, #test_loop

lp jmp #lp
' test data section for the basic checks
test1 long 0
test2 long $ffff_ffff
test3 long 0
test4 long $ffff_ffff
test5 long $ffff_ffff
test6 long 0
test7 long $ffff_ffff
test8 long $8000_0000
test9 long 0
test10 long 0
test11 long 0
' test data for the instruction test-cycles
' number of test cases
test_cases long 5
' pointer to iterate through the test data
test_pointer long test_data + 1
' this is for finding the data easier in a hex-dump
' first word is a bitpattern, next word is the testcase number
' destination value
' source value
' shows if carry flag and zero flag
' are set
test_data long $a5a5_0001, $0000_000A, 5, 0, 0
long $a5a5_0002, $0000_000A, 7, 0, 0
long $a5a5_0003, $0000_000A, 10, 0, 0
long $a5a5_0004, $0000_000A, 13, 0, 0
long $a5a5_0005, $0000_000A, 15, 0, 0


The first dat section was only to show me where in HUB-RAM the other dat-section starts. Currently I don't load this program with the simulated SPIN. I load the eeprom-file beginning from adress $1c·where the PASM code starts and run it directly.

The test data is simply a copy of the table you can find for each instruction in the Propeller manual. I run the code and check in the memory dump if the result is as expected.


·

VBBSim
07-12-2009, 05:04 AM
So I want to contribute to one of the opensource simulator efforts by wrapping the simulation core in my component plugin and debugging API for VirtualBreadboard ( www.virtualbreadboard.com )

I am new to the propeller and would like to know which of the efforts are the most mature, I guess I need

1) a .net implementation or possibly java which would be compatible with j# or iKVM
2) spin.binary ( the SPIN interpreter ? )
3) a SPIN compiler ( Homespun? or the parallax tool if it can be accessed some how )

I will be hosting the code development environment in the VBB environment as I do with MPASM/Java/pBasic and others, I will call the SPIN compiler to generate the binary image and inject that into the simulation over the VBB debugging API directly.

Can people post links to the relavent resources or send them to me at caska at virtualbreadboard dot com

Thanks.

MagIO2
07-12-2009, 05:33 AM
I improved the test-framework a bit. Now you can test several instructions with one PASM-file.

Just add the instruction with WC,WZ and WR flags set, the number of test-cases and the test cases themselve. Make sure that the number of tests is set correctly.

Ron Sutcliffe
07-12-2009, 09:04 AM
@Vbbsim
There are three mature OS simulators to my knowledge. Gear, pSimulator and Andy's version, the name escapes me at the moment. Gear includes some sophisticated pluggins and scripting facilities. Both Gear and pSimulator do manage pipelining around a clock tick. Not sure about the others, but the ones I know of, are still *infants*
Chris's verson is written in C, MagIO2 version in Java, I think.

@MagI02
Keep up the good work :)

Ron

Cluso99
07-12-2009, 09:14 AM
Some of the links are in the tools section of my signature below

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Chris Micro
07-12-2009, 12:34 PM
Sorry guys, that I didn't answer to the posts yet. I will do it when I have time ..asap..
My code is hosted here (http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=77). As far as I know ALE has a more advanced version of his pSimulator written in Java and if he will be asked, he will post it.

Ale
07-12-2009, 12:43 PM
@VBBsim:

You can use Gear because it is written in C#. If we can ask something, please use Mono to compile your project and Mono's libraries. That will open you to the no m$ world and maybe save you if m$ changes the language again and makes it incompatible, somthing that already happened more than once. J# ? urk! it sounds like J++, avoid it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

VBBSim
07-12-2009, 05:19 PM
At this stage I think I will go with Gear, since is C# and code looks quite nice. Mono is on my product path but I am moving large amounts of legacy code and still need good Mono solutions to some major libraries like DirectX. Mono continues to mature though so maybe the jump will happen sooner than later.

Thanks for your comments, might have a propeller in the next VBB release http://forums.parallax.com/images/smilies/smile.gif will let you know.

Ale
07-12-2009, 06:45 PM
DirectX ? I was talking about the propeller emulator.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)

VBBSim
07-12-2009, 07:14 PM
Oh, what I mean is VBB uses DirectX and I will be wrapping the Gear propeller emulator into a virtual VBB component which you can then drag and drop as a virtual propeller inside the VBB environment. Then you can wire up the virtual propeller to things like virtual servos, LCD's, 7-Segment displays etc. So while the Gear propeller emulator is C# and mono 'ready' VBB itself has other dependencies that are not quite Mono 'ready'. Hope this makes sense.

stevenmess2004
07-12-2009, 07:35 PM
MagIO2 said...
The case where you rely on the fact that the code has not been modified yet is rare - isn't it?


I've used it in something like the following for table lookups




DAT
tableLookup
add :lookup, index
sub :lookup, index 'use pipeline delay to advantage
:lookup
mov tableValue,#tableData
'do stuff

index long 0
tableValue long 0
tableData long 2[ 10]

jazzed
07-12-2009, 10:51 PM
SO COOL !!! http://forums.parallax.com/images/smilies/smile.gif Very nice example.


stevenmess2004 said...
I've used it in something like the following for table lookups




DAT
tableLookup
add :lookup, index
sub :lookup, index 'use pipeline delay to advantage
:lookup
mov tableValue,#tableData
'do stuff

index long 0
tableValue long 0
tableData long 2[ 10]



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

jazzed
07-13-2009, 08:01 AM
I hate posting twice in a row, but ... I'm taking a break from the PocketProp project for now to focus on this for a few days.

I wanted to let you know what my plan is.

The purpose of this effort is to allow sending .binary code to the simulator in a similar way that we send to Propeller. I'm hooking up a Virtual COM Port (VCP) pipe between a Propeller loader and the Simulator. Additionally, given the right set of simulated IO, one could communicate with the simulator over the serial port using FullDuplexSerial.

The main issue with achieving this today is having an interface with the external system states. For the time being, the booter code will start in an independent cog0 process where I can control what bits get put into the INA and fetched from the OUTA registers by the VCP and allow saving and booting any Spin file. The unfortunate part of this is the PropellerTool does not recognize the VCP ports, but the Python propload.py and the standalone pload application I wrote will work with VCP COM1-COM9 (COM10+ will not work in all cases for some reason).

Do you have any updated sources or a diff from the V051b baseline? I'll ask again before I post changes to avoid code conflicts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Ron Sutcliffe
07-13-2009, 08:44 AM
I looked at the problem a slightly different way. The simulator should allow INA bits to be set but masked by DIRA. Comunications with the simulator would then be by Prop Code.

SetOutport(int Pins, Int BasePin)······· .........··· SetOutport(1,31)
// set DIRA bits
// creat mask for outPut
·
·

SetInport( int Pins, int BasePin)·········......······· SetInport(1,30)·
// set DIRA bits
// create mask for input

Parallel output·would look something like SetOutport(8,0)·
Then there is the issue of the wired ORed Pins to take·account·of in the two functions. Like ORing all the cogX.memory[DIRA]·together to test
which cog has·control over the Pin. Too much fun.·
@Steve
Reading your post again I think its more or less the same approach. I have put it aside for now in favour of writing some test code.
Getting the Spin Interpreter to work(the acid test)·seems like the best place to start.
Chris will·need to·think·about some·serious regression·test code first.






Regards

Ron

Post Edited (Ron Sutcliffe) : 7/13/2009 5:57:13 AM GMT

Chris Micro
07-13-2009, 04:25 PM
Somebody said...
Do you mind if I use your code in a non-commercial, but not open-source app?

I've been contemplating adding a Prop ... to my ... code...

Your simulator seems like a good fit. I think it'd save me a lot of work.

But, I don't want to give out my .... code...



heater said...
Chris you really have to a ask yourself what you want because we can only tell you what we want.
Do you want people to be able to see your code, use it, modify it? Should they be able distribute it in source or binary, modified or not, with attribution in place or not? Do you mind if they sell it for profit or or otherwise? On it's own or in combination with other work. Etc etc etc.

You might want to look over the GPL and LGPL licences and the BSD, MIT licenses for starters. If you want to drive yourself nuts take a look at all the licenses approved by the Open Source Initiative.www.opensource.org/licenses/alphabetical


The best thing for the emulator in my point of view would be the following:

- If somebody makes changes to one of the files like chCog.c, chDebug.c ... and so on he has to make the sources open.
the reason for this: if there are some improvements in the emulator code they should go back to the community

- every one is free to implement some interface functions to use the propeller emulator files. In this case there is no need to open up the own code which accesses the emulator code functions
result: if someone includes the emulator code in a larger system simulation, he has not to open up the system simulation code.

Is there any license which covers this?

thanks,
chris

BTW: I'm not sure if my emulator isn't a simulator, shall I rename it?

heater
07-13-2009, 05:23 PM
I guess there is nothing stopping you applying a different licence to different files. It's yours, you created it, you can licence it any how you like.

Interesting though. If you release the emulator code under say GPL. Then your release the interface stuff under say BSD. So far so good. But now if I take that and change the interface I'm a bit stuck if I then want to release only a binary version. BSD allows binary only distribution but I can't do it because it's linked to the GPLed emulator module which says I have to release source of derived works.

OK what about LGPL for the core emulator files?. If I remember correctly that allows people to release binary only closed source applications linked against it. Only if they change LGPLed stuff do they need to release the source. Seems that is your intention here and the core files are basically a library. The rest of the code could be BSD or whatever, I think.

For simplicity I would try to avoid creating a new licence of your own.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro
07-13-2009, 07:36 PM
Somebody said...
OK what about LGPL for the core emulator files?. If I remember correctly that allows people to release binary only closed source applications linked against it. Only if they change LGPLed stuff do they need to release the source. Seems that is your intention here and the core files are basically a library.


Hi heater, thanks for answering. I will read about the LGPL. It seems to fit my needs.

chris

Ron Sutcliffe
07-13-2009, 08:21 PM
Chris
You have released your code under GNU. This tells people what your intentions where at the time of release. Decent people will understand you intentions. Those who would do the wrong thing will do it anyway.

One of the great things about a Forum like this is gives people the opportunity to look at what other people are doing. I have downloaded some of your code. I had previously looked at the code for both Gear and the pSimulator, albeit a while ago so it was interesting to see your approach. I looked at the Gear code when I was getting into C and found so easy to read. Hence my interest in your project.

Some bizarre things are going on when I load Spin but PASM code seems to work fine. It will be very interesting to see what Jazzed comes up with.

Ron

BradC
07-13-2009, 08:21 PM
Chris Micro said...

Somebody said...
OK what about LGPL for the core emulator files?. If I remember correctly that allows people to release binary only closed source applications linked against it. Only if they change LGPLed stuff do they need to release the source. Seems that is your intention here and the core files are basically a library.


Hi heater, thanks for answering. I will read about the LGPL. It seems to fit my needs.

chris


Freepascal uses a really nice modified LGPL license. It has an exception for static linking, so basically you can use any of the RTL code in a commercial product (and link it statically should you wish) and have no need to publish your source, however if you make *any* modifications to the source you must offer the source for the modified components (preferably feed the changes back upstream).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

jazzed
07-14-2009, 03:21 AM
Well, I'm stuck on the Window32 C API for flushing serial input using file. Maybe there are some alternatives that I've missed. For the time being, I'll go do something else :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Chris Micro
07-14-2009, 04:00 PM
Ron Sutcliffe said...
I have downloaded some of your code. ...
Some bizarre things are going on when I load Spin but PASM code seems to work fine. I..


Yes, the assembler code works find. A lot of spin commands work to. But there is an error which I try to find since a few days.

If the fist method calls some other method in the spin object, this method runs only once. The error seems to be the return from the called method seems to be incorrect. This can have to reasons:

1. There is a function in the spin interpreter called "trop anchor" which probably should but the return address to the stack. Perhaps there is an error
2. the return function itself makes the error

Does anybody have a suggestion how to find the bug?

here is my test code, the "a" is not printed.



pub xx
putchar
outa := "a"

pub putchar
outa:="1"

Ron Sutcliffe
07-15-2009, 10:17 AM
Chris,
I would revisit the Propeller manual and have a look at how the OUTA registers of each cog are hard wired to the Prop Pins. Note also how the DIRA registers affect the gating of the OUTA registers. Also have a look at the counters and video registers. Then go back and look at what you have done.

BTW you might have guessed that I had started writing code in C. I want to reflect the architecture of the chip. If will never be a Gear, but I am interested in a different approach to the user interface.

Regards

Ron

Chris Micro
07-16-2009, 03:47 PM
Hello together,

after looking for very difficult to find errors ( not all are faults of mine but errors in the propeller datasheet http://forums.parallax.com/images/smilies/burger.gif

spin is running http://forums.parallax.com/images/smilies/lol.gif

the attachment is the precompild linux version to start with

./propsim.out

you can write your own file, save it as text.binary and run it by starting ./propsim.out

Post Edited (Chris Micro) : 7/16/2009 1:14:31 PM GMT

heater
07-16-2009, 04:25 PM
Sounds like brilliant detective work.

Do tell us what the data sheet errors are. Are they in any errata from Parallax?
Don't forget to tell Parallax.

Does this mean MoCog will now run under ProEmu? I have no time to play now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro
07-16-2009, 08:11 PM
heater said...
Does this mean MoCog will now run under ProEmu? I have no time to play now.


Hi heater, there was just another little error in the emolator regarding the start address in coginit for PAR.

But now ... I just compiled your mocog and I believe it works ....

Ron Sutcliffe
07-16-2009, 08:56 PM
Good work Chris, now I know who to call if I need a little help. :)

Ron

BradC
07-16-2009, 09:08 PM
Chris Micro said...

I just compiled your mocog and I believe it works ....


I have this burning mental image of a 6809 being emulated on an emulated Propeller running on an AVR.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!