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.
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.
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.
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.
@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 [noparse]:)[/noparse]
@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.
I meant that I hope your customers aren't calling you at 3AM [noparse]:)[/noparse] Apparently you have a good agreement with them.
When it comes down to it, you ship whatever keeps your customers happy [noparse]:)[/noparse]
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.
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
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.
@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 [noparse]:)[/noparse]
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 . 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.
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.
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 will let you know.
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.
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[noparse][[/noparse] 10]
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[noparse][[/noparse] 10]
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.
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[noparse][[/noparse]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
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?
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.
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
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.
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).
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 [noparse]:)[/noparse]
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?
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.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
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.
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://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 7/10/2009 5:43:27 PM GMT
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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.
When it comes down to it, you ship whatever keeps your customers happy [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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, 0The 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.
·
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.
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.
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 [noparse]:)[/noparse]
Ron
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
My code is hosted here . 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.
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
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Thanks for your comments, might have a propeller in the next VBB release
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
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[noparse][[/noparse] 10]▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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://forums.parallax.com/showthread.php?p=788230
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[noparse][[/noparse]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
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?
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.
Hi heater, thanks for answering. I will read about the LGPL. It seems to fit my needs.
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
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!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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.
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