the Propeller Emulator
Chris Micro
Posts: 160
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.
the code for the emulator can be found here
Post Edited (Chris Micro) : 7/13/2009 9:16:00 AM GMT
==================
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
Post Edited (Chris Micro) : 7/13/2009 9:16:00 AM GMT
Comments
Any plans for object/peripheral emulation? Like TV_Text
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Forum Search (Via Google)
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.
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://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 7/4/2009 3:32:08 PM GMT
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
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
In short: No.
Long: I never ran the booting code. It should work if I emulate a i2c eeprom
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
I will try to run it tomorrow.
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
Any remarks welcome ...
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://forums.parallax.com/showthread.php?p=788230
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
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.
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
mov timer, delay add timer, cnt numberLoop waitcnt timer,delay movs printText,#text call #printText jmp #numberLoopBenchmark is a loaded word around here [noparse]:)[/noparse] 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://forums.parallax.com/showthread.php?p=788230
Yes, thank you, I was a little lazy in preloading the timer variable with the cnt value.
>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.
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[noparse]:)[/noparse], 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://forums.parallax.com/showthread.php?p=788230
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.
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 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
( 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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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
Edit: I'll post the code as soon as I can post it :-(, sadly it failed 4 time to upload here
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 7/7/2009 2:14:53 PM GMT
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
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.
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?
It was available under
http://sourceforge.net/projects/propellersim
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
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!
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.
Example .dev and config files are attached.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 7/8/2009 3:57:51 PM GMT
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.
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
A completely unrelated point, but you are not decoding the lock instructions
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 [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!