Strange - the limit should be exactly 31kb (i.e. 31744 bytes). I'll have a look at it on the weekend.
I could add an option for loading 32kb files, but it would of course have to be without the possibility of a command line arguments or using any other Catalyst/Catalina features. I probably won't do so at this point since there are plenty of other options for doing this.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Just figured out what the problem is - it will be easy to fix for the next release. I've also figured out how I could load all 32kb - but as this would be no use for Catalyst/Catalina programs, I'll only include this if I get enough time.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Try the attached 'Catalyst.binary' in place of the one in the DracBlade alpha release - with this version if you enter a command with no arguments (such as 'cpm') Catalyst will not perform the usual argument processing. Catalyst programs deal with arguments automatically - but I forgot that other programs (which will not be expecting any argments anyway!) will not respond properly.
I will include the fixed version in the official release.
Ross.
Edit : fixed version now included in the binary releases at the top of this thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Try the attached 'Catalyst.binary' in place of the one in the DracBlade alpha release - with this version if you enter a command with no arguments (such as 'cpm') Catalyst will not perform the usual argument processing. Catalyst programs deal with arguments automatically - but I forgot that other programs (which will not be expecting any argments anyway!) will not respond properly.
I will include the fixed version in the official release.
Ross.
I'll give that a try now. I've been busy with trying to write a VGA object for the rather low resolution Nascom. Now that it works I'll check out your changes.
Thanks!
Juergen
Edit: Now it runs one step further, i.e. clears the VGA screen buffer, and then it hangs. Unfortunately I have no failure message, so it seems to hang very early in the remaining initialization phase. The same binary downloaded to RAM works, so it isn't me I attach the binary again. It's 30480 bytes in size.
Can you give me some idea (e..g a screenshot or something) about how I can tell if it loads successfully?
At the moment I get exactly the same result whether I load it with Catalyst, with Propellent or with the Parallax Propeller tool. How do you load it that you see some other result, and what is that result?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Alpha binaries of Catalyst for the RamBlade (with the demo programs compiled for the RamBlade's XMM RAM using Catalina). The RamBlade is so fast it even makes Dumbo Basic look good!
I currently only support using a VT100 compatible PC terminal emulator as the HMI on the RamBlade (via a PropPlug connected to pins 22 and 23) - I hope to include full support for Cluso's 1-pin keyboard driver and 1-pin TV driver in the next release of Catalina.
Ross.
EDIT: Binaries removed. See top of thread for latest binaries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
First thanks for taking the time to make a RamBlade version!
I tried it without flashing (as "BOOTPROP.BIN" for autoboot).
- The main binary works just fine, including DIR, CAT, HELP.
- All external commands (not XMM) fail => RamBlade restarts silently.
- Any XMM program keeps on spitting garbage chars indefinitely (even stuff supposed to stop after finishing, like LS).
Tried many baud rates, but none gave anything legible. [noparse]:([/noparse]
Yes ZiCog works. Tried two cards in two ramblades, also swapping pairs.
Also reformatted one of the cards, and put back zicog files and catalyst.bin, ls.bin, dbasic.bin and eliza.bas.
Then tried again, but same result: ZiCog works, Catalyst shows the same behaviour as before.
I'm using two identical·1GB Trascend cards.
The original SanDisk card you sent me must be stored somewhere...
I guess the definition of "safely stored" includes not being able to·find it, so I don't have to worry about wear leveling
The baud rate is fixed at 115200. I use both putty and PropTerm and both work ok. Are you using a standard PropPlug?
It could be a timing problem on the SD card access. Can you tell me what frequency crystal you have installed? I have only tested it with a 6.5MHz crystal (104Mhz). Also, can you tell me how your RamBlade is configured? Do you have any other devices attached?
It could also be that my XMM RAM timing is right on the edge. A sample of one that works (mine!) and one that doesn't (yours!) is not sufficient to tell. Can anyone else confirm success or otherwise? EDIT: just realized it can't be this - because the external commands are all normal SPIN programs, not XMM programs.
However, I'll try slowing down the access of both the SD Card and XMM RAM and post a new binary tonight.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
It is really only 'vi' that requires VT100 support - all the other commands should work ok in any terminal emulator. I'll dig out a list of the VT100 escape codes I use tonight.
Can you confirm whether the external command binaries (such as 'ls.bin') work ok on one of your RamBlades?
Thanks,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I must run up Catalina myself - not today though :-( I am not a C programmer so the libraries and make files etc do not come naturally, so it takes me longer to try this stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
You don't need to have Catalina installed just to run the binaries - in fact Catalyst itself and all the external commands are currently plain old SPIN programs - only the demo programs have been compiled with Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Can you give me some idea (e..g a screenshot or something) about how I can tell if it loads successfully?
At the moment I get exactly the same result whether I load it with Catalyst, with Propellent or with the Parallax Propeller tool. How do you load it that you see some other result, and what is that result?
Ross.
I use the Python script Loader.py that was linked on some Tools page (from the Wiki? Or perhaps Cluso99 links). I'll attach it, just in case.
proploader.py -s /dev/ttyS0 -r cpm.bin
Your port name may vary.
I then use a FAT16 formatted SD card with the attached files on it.
What you get to see is the CP/M boot message:
64K CP/M Version 2.2 (qZ80, BIOS V1.27_Zi04, 3HD, 21-Apr-2010)
SuperSUB V1.1
A>REM ADD COMMANDS TO AUTOEXEC.SUB
REM?
A>
Edit: On the serial port (31, 30) at 115k2 baud there should be some startup messages about loading the BOOT.DSK and checking the other disk files for being continuous.
The baud rate is fixed at 115200. I use both putty and PropTerm and both work ok. Are you using a standard PropPlug?
It could be a timing problem on the SD card access. Can you tell me what frequency crystal you have installed? I have only tested it with a 6.5MHz crystal (104Mhz). Also, can you tell me how your RamBlade is configured? Do you have any other devices attached?
It could also be that my XMM RAM timing is right on the edge. A sample of one that works (mine!) and one that doesn't (yours!) is not sufficient to tell. Can anyone else confirm success or otherwise? EDIT: just realized it can't be this - because the external commands are all normal SPIN programs, not XMM programs.
However, I'll try slowing down the access of both the SD Card and XMM RAM and post a new binary tonight.
Ross.
Hi Ross
I'm using the standard Parallax PropPlug and·PuTTY
My crystal is 6.5Mhz too
EEPROM is still programmed with the original bootloader
No other devices attached (I got two boards, one is in original condition, the other has a 30awg wire tapping CS on uSD to an unused pin on connector, but then nothing is attached to that).
I'd say let's·see what's happening with·external non-xmm commands first, while expecting for other users to report back.
i.e. after "ls" the cursor goes next line, after circa 2 seconds (with no output) the board restarts.
Maybe it would help (re)introduce some debugging output (and delays?), so I can tell you what it does before restarting the board?
Thanks
Alessandro
P.S. if you're going to release the spin sources with next Catalina, I·can also wait to·do those tests myself, there's no big hurry!
Can you please try the enclosed 'ls.bin' file and tell me if it works. I made a change to the SD timing in Kye's FATEngine, but both the new and old version work for me on all the micro-SD Cards I have (SanDisk, and Nokia) so I don't really know if I've fixed anything.
Ross.
EDIT: Binaries removed. See top of thread for latest binaries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The attached zip file contains a binary version of catalyst for the DracBlade that successfully loads CPM. The problem was that CPM expects to always be loaded into cog 0. While this is generally true if you load a program after a prop reset, it may not be true (and wasn't!) if you are using a loader such as Catalyst. I think this points to a problem in the CPM program - it should not matter which cog you get allocated to run in (and doesn't, for most other programs). However, I have modified my loader to always start the loaded program in cog 0, and it now works ok.
Ross.
Edit: fixed version now included in the binary releases at the top of this thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The attached zip file contains a binary version of catalyst for the DracBlade that successfully loads CPM. The problem was that CPM expects to always be loaded into cog 0. While this is generally true if you load a program after a prop reset, it may not be true (and wasn't!) if you are using a loader such as Catalyst. I think this points to a problem in the CPM program - it should not matter which cog you get allocated to run in (and doesn't, for most other programs). However, I have modified my loader to always start the loaded program in cog 0, and it now works ok.
Ross.
I already thought it had to be something along the lines of cog loading. The problem was that there was (or is) no more cog available for the Z80 emulation, which is why in the last step I used coginit(0,) to start it. I guess I could instead use coginit(cogid, ...) to solve the problem on my side.
RossH said...
@Antoine (or anyone else with a RamBlade!)
Can you please try the enclosed 'ls.bin' file and tell me if it works. I made a change to the SD timing in Kye's FATEngine, but both the new and old version work for me on all the micro-SD Cards I have (SanDisk, and Nokia) so I don't really know if I've fixed anything.
Ross.
Just tried the new ls, same result
...but then I've had a very "doh!" moment: it works·when launched·from PropCMD
both new and old ls.bin, also retried all the other spin binaries and (apart from missing parameters) they all work if started directly ·
Ok - thanks for the update. I was looking in the wrong place - obviously I still have a problem with the actual program loader. Can you please tell me how your SD card is formatted? I need to know the file system type and cluster size (aka allocation unit). One way to do this is stick it in a DOS machine and run 'chkdsk' - this is the most useful way to do it because it will also check the file system integrity.
Thanks,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
That's probably it. Normally (i.e. after a reset) cog 0 is the spin interpreter so no other code ever gets loaded in that cog. But any code that assumes this is always true would would break if the loader started (for example) the initial spin interpreter as cog 3 - as the drivers were loaded they would get allocated into cogs 4,5,6,7,0,1,2 instead of the normal 1,2,3,4,5,6,7 - i.e. one of them ends up in cog 0. Then if you explicitly start your main program in cog 0 you are actually overwriting one of your own drivers.
I have modified my loader, but I suspect there may be others out there that will cause the same problem, so you should really change your program so it does not depend on the use of particular cog ids.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ok - thanks for the update. I was looking in the wrong place - obviously I still have a problem with the actual program loader. Can you please tell me how your SD card is formatted? I need to know the file system type and cluster size (aka allocation unit). One way to do this is stick it in a DOS machine and run 'chkdsk' - this is the most useful way to do it because it will also check the file system integrity.
Thanks,
Ross.
Hi Ross
I spare you the funky chkdsk output in italian
filesystem is FAT, cluster size was 16K
I vaguely remember another thread where it was suggested use of 32K ?!?
so I reformatted the card (from DOS command line this time), and redid tests with FAT and 32K cluster, but it made no difference.
Thanks for the information. FAT with 16k cluster size is perfectly ok for both fsrw and FATEngine - it's what I use. I believe some people recommend using 32k cluster for better performance, but it should make no difference to the functionality.
This one is a bit of a mystery. The loader code I use is not specific to Catalyst and it just uses plain old fsrw. This code works on every Propeller platform I have - currently 10 of them (including my RamBlade).
Can you confirm your clock speed? Is It 80Mhz, or 104Mhz? I know some people overclock their RamBlades even faster than that, but I have not tested at any faster speeds.
The only thing I can think of is that the version of fsrw I use (a fairly old one, but quite stable) has some problem that you have uncovered. If so (and given that I can't reproduce it) I may not be able to solve it - but I probably don't need to. My intention is to convert the loader to use FATEngine anyway - which you have confirmed does work on your RamBlade (FATEngine used by 'ls' and all the other external commands - only the Catalyst loader itself uses fsrw).
I will try and get that done this weekend, and post some new binaries for you to try.
In the meantime, I'd really appreciate hearing whether the Catalyst loader doesn't work for anyone else who has a RamBlade.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
yes, the clock is 104MHz = 6.5 x16 on both boards.
What you say make sense, might be the card timing being slightly different from brand to brand.
I have some EZ-Hook clips pluggable into the demo board, but I'm not sure I'm able to spot an SPI timing problem with the simple el-cheapo prop analyzer.
I'll try to find the 2GB SanDisk card, or just go out and buy another.
Just to see if I could reproduce your problem, I went out and bought another micro SD card. I couldn't find any Transcend cards, so I bought a Verbatim.
Worked first time
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH said...
In the meantime, I'd really appreciate hearing whether the Catalyst loader doesn't work for anyone else who has a RamBlade.
OK, I tried an external command (ls.bin) which actually generates output, i.e. an extended listing, then the screen is cleared and the RAMBlade hard-resets. Also, if I run catalyst itself as an external command this works exactly once (I get the prompt again and can execute commands). Doing it a second time will force a reset as for ls.
I was wondering whether this has anything to do with the SD card DO issue discussed here.
My RAMBlade uses a custom bootloader, catalyst is uploaded from the DemoBoard, serial links are hard-wired (feedback counters) directly to the PC serial link.
Comments
Strange - the limit should be exactly 31kb (i.e. 31744 bytes). I'll have a look at it on the weekend.
I could add an option for loading 32kb files, but it would of course have to be without the possibility of a command line arguments or using any other Catalyst/Catalina features. I probably won't do so at this point since there are plenty of other options for doing this.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Just figured out what the problem is - it will be easy to fix for the next release. I've also figured out how I could load all 32kb - but as this would be no use for Catalyst/Catalina programs, I'll only include this if I get enough time.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Try the attached 'Catalyst.binary' in place of the one in the DracBlade alpha release - with this version if you enter a command with no arguments (such as 'cpm') Catalyst will not perform the usual argument processing. Catalyst programs deal with arguments automatically - but I forgot that other programs (which will not be expecting any argments anyway!) will not respond properly.
I will include the fixed version in the official release.
Ross.
Edit : fixed version now included in the binary releases at the top of this thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 6/7/2010 7:47:46 AM GMT
I'll give that a try now. I've been busy with trying to write a VGA object for the rather low resolution Nascom. Now that it works I'll check out your changes.
Thanks!
Juergen
Edit: Now it runs one step further, i.e. clears the VGA screen buffer, and then it hangs. Unfortunately I have no failure message, so it seems to hang very early in the remaining initialization phase. The same binary downloaded to RAM works, so it isn't me
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/2/2010 5:22:15 PM GMT
Can you give me some idea (e..g a screenshot or something) about how I can tell if it loads successfully?
At the moment I get exactly the same result whether I load it with Catalyst, with Propellent or with the Parallax Propeller tool. How do you load it that you see some other result, and what is that result?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Alpha binaries of Catalyst for the RamBlade (with the demo programs compiled for the RamBlade's XMM RAM using Catalina). The RamBlade is so fast it even makes Dumbo Basic look good!
I currently only support using a VT100 compatible PC terminal emulator as the HMI on the RamBlade (via a PropPlug connected to pins 22 and 23) - I hope to include full support for Cluso's 1-pin keyboard driver and 1-pin TV driver in the next release of Catalina.
Ross.
EDIT: Binaries removed. See top of thread for latest binaries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 5/18/2010 11:06:24 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
First thanks for taking the time to make a RamBlade version!
I tried it without flashing (as "BOOTPROP.BIN" for autoboot).
- The main binary works just fine, including DIR, CAT, HELP.
- All external commands (not XMM) fail => RamBlade restarts silently.
- Any XMM program keeps on spitting garbage chars indefinitely (even stuff supposed to stop after finishing, like LS).
Tried many baud rates, but none gave anything legible. [noparse]:([/noparse]
Regards
Alessandro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Also reformatted one of the cards, and put back zicog files and catalyst.bin, ls.bin, dbasic.bin and eliza.bas.
Then tried again, but same result: ZiCog works, Catalyst shows the same behaviour as before.
I'm using two identical·1GB Trascend cards.
The original SanDisk card you sent me must be stored somewhere...
I guess the definition of "safely stored" includes not being able to·find it, so I don't have to worry about wear leveling
The baud rate is fixed at 115200. I use both putty and PropTerm and both work ok. Are you using a standard PropPlug?
It could be a timing problem on the SD card access. Can you tell me what frequency crystal you have installed? I have only tested it with a 6.5MHz crystal (104Mhz). Also, can you tell me how your RamBlade is configured? Do you have any other devices attached?
It could also be that my XMM RAM timing is right on the edge. A sample of one that works (mine!) and one that doesn't (yours!) is not sufficient to tell. Can anyone else confirm success or otherwise? EDIT: just realized it can't be this - because the external commands are all normal SPIN programs, not XMM programs.
However, I'll try slowing down the access of both the SD Card and XMM RAM and post a new binary tonight.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 5/5/2010 11:01:07 PM GMT
It is really only 'vi' that requires VT100 support - all the other commands should work ok in any terminal emulator. I'll dig out a list of the VT100 escape codes I use tonight.
Can you confirm whether the external command binaries (such as 'ls.bin') work ok on one of your RamBlades?
Thanks,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I must run up Catalina myself - not today though :-( I am not a C programmer so the libraries and make files etc do not come naturally, so it takes me longer to try this stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
You don't need to have Catalina installed just to run the binaries - in fact Catalyst itself and all the external commands are currently plain old SPIN programs - only the demo programs have been compiled with Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I use the Python script Loader.py that was linked on some Tools page (from the Wiki? Or perhaps Cluso99 links). I'll attach it, just in case.
proploader.py -s /dev/ttyS0 -r cpm.bin
Your port name may vary.
I then use a FAT16 formatted SD card with the attached files on it.
What you get to see is the CP/M boot message:
64K CP/M Version 2.2 (qZ80, BIOS V1.27_Zi04, 3HD, 21-Apr-2010)
SuperSUB V1.1
A>REM ADD COMMANDS TO AUTOEXEC.SUB
REM?
A>
Edit: On the serial port (31, 30) at 115k2 baud there should be some startup messages about loading the BOOT.DSK and checking the other disk files for being continuous.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/6/2010 2:56:54 AM GMT
Yes, I have used the pyloader program before - I'll try loading your program with that.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm using the standard Parallax PropPlug and·PuTTY
My crystal is 6.5Mhz too
EEPROM is still programmed with the original bootloader
No other devices attached (I got two boards, one is in original condition, the other has a 30awg wire tapping CS on uSD to an unused pin on connector, but then nothing is attached to that).
I'd say let's·see what's happening with·external non-xmm commands first, while expecting for other users to report back.
i.e. after "ls" the cursor goes next line, after circa 2 seconds (with no output) the board restarts.
Maybe it would help (re)introduce some debugging output (and delays?), so I can tell you what it does before restarting the board?
Thanks
Alessandro
P.S. if you're going to release the spin sources with next Catalina, I·can also wait to·do those tests myself, there's no big hurry!
Can you please try the enclosed 'ls.bin' file and tell me if it works. I made a change to the SD timing in Kye's FATEngine, but both the new and old version work for me on all the micro-SD Cards I have (SanDisk, and Nokia) so I don't really know if I've fixed anything.
Ross.
EDIT: Binaries removed. See top of thread for latest binaries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 5/18/2010 11:07:09 AM GMT
The attached zip file contains a binary version of catalyst for the DracBlade that successfully loads CPM. The problem was that CPM expects to always be loaded into cog 0. While this is generally true if you load a program after a prop reset, it may not be true (and wasn't!) if you are using a loader such as Catalyst. I think this points to a problem in the CPM program - it should not matter which cog you get allocated to run in (and doesn't, for most other programs). However, I have modified my loader to always start the loaded program in cog 0, and it now works ok.
Ross.
Edit: fixed version now included in the binary releases at the top of this thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 6/7/2010 7:48:37 AM GMT
I already thought it had to be something along the lines of cog loading. The problem was that there was (or is) no more cog available for the Z80 emulation, which is why in the last step I used coginit(0,) to start it. I guess I could instead use coginit(cogid, ...) to solve the problem on my side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
...but then I've had a very "doh!" moment: it works·when launched·from PropCMD
both new and old ls.bin, also retried all the other spin binaries and (apart from missing parameters) they all work if started directly
·
Ok - thanks for the update. I was looking in the wrong place - obviously I still have a problem with the actual program loader. Can you please tell me how your SD card is formatted? I need to know the file system type and cluster size (aka allocation unit). One way to do this is stick it in a DOS machine and run 'chkdsk' - this is the most useful way to do it because it will also check the file system integrity.
Thanks,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
That's probably it. Normally (i.e. after a reset) cog 0 is the spin interpreter so no other code ever gets loaded in that cog. But any code that assumes this is always true would would break if the loader started (for example) the initial spin interpreter as cog 3 - as the drivers were loaded they would get allocated into cogs 4,5,6,7,0,1,2 instead of the normal 1,2,3,4,5,6,7 - i.e. one of them ends up in cog 0. Then if you explicitly start your main program in cog 0 you are actually overwriting one of your own drivers.
I have modified my loader, but I suspect there may be others out there that will cause the same problem, so you should really change your program so it does not depend on the use of particular cog ids.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 5/6/2010 11:37:53 PM GMT
I spare you the funky chkdsk output in italian
filesystem is FAT, cluster size was 16K
I vaguely remember another thread where it was suggested use of 32K ?!?
so I reformatted the card (from DOS command line this time), and redid tests with FAT and 32K cluster, but it made no difference.
Regards
Alessandro
Thanks for the information. FAT with 16k cluster size is perfectly ok for both fsrw and FATEngine - it's what I use. I believe some people recommend using 32k cluster for better performance, but it should make no difference to the functionality.
This one is a bit of a mystery. The loader code I use is not specific to Catalyst and it just uses plain old fsrw. This code works on every Propeller platform I have - currently 10 of them (including my RamBlade).
Can you confirm your clock speed? Is It 80Mhz, or 104Mhz? I know some people overclock their RamBlades even faster than that, but I have not tested at any faster speeds.
The only thing I can think of is that the version of fsrw I use (a fairly old one, but quite stable) has some problem that you have uncovered. If so (and given that I can't reproduce it) I may not be able to solve it - but I probably don't need to. My intention is to convert the loader to use FATEngine anyway - which you have confirmed does work on your RamBlade (FATEngine used by 'ls' and all the other external commands - only the Catalyst loader itself uses fsrw).
I will try and get that done this weekend, and post some new binaries for you to try.
In the meantime, I'd really appreciate hearing whether the Catalyst loader doesn't work for anyone else who has a RamBlade.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
yes, the clock is 104MHz = 6.5 x16 on both boards.
What you say make sense, might be the card timing being slightly different from brand to brand.
I have some EZ-Hook clips pluggable into the demo board, but I'm not sure I'm able to spot an SPI timing problem with the simple el-cheapo prop analyzer.
I'll try to find the 2GB SanDisk card, or just go out and buy another.
Thanks
Alessandro
Just to see if I could reproduce your problem, I went out and bought another micro SD card. I couldn't find any Transcend cards, so I bought a Verbatim.
Worked first time
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I was wondering whether this has anything to do with the SD card DO issue discussed here.
My RAMBlade uses a custom bootloader, catalyst is uploaded from the DemoBoard, serial links are hard-wired (feedback counters) directly to the PC serial link.
Thanks. Can you confirm that when you first run catalyst, and then use catalyst to run ls.bin, that you get the correct ls output?
I'll read the thread you mention and see it that may be related to Allesandro's problem.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina