RossH said...
Can you confirm that when you first run catalyst, and then use catalyst to run ls.bin, that you get the correct ls output?
The number of files and their sizes are correct, i.e. match the backup on my harddrive. I use PST and had to disable the control codes for Clear Screen, otherwise I can't capture the output.
Apologies, in my initial post I was implying that ls generated output before the system crashed resets (not just a NL and then nothing as Alessandro reported).
Thanks - that's what I would expect. The Clear Screen is probably coming from whatever program you have in EEPROM.
If the Catalyst external commands are compiled to use serial comms as the HMI they do not pause at the end of the command output - they just reset the Prop, expecting to pass control back to catalyst.bin (which they assume will be in EEPROM). However, when a local display HMI option is being used (e.g. TV or VGA) each command finishes with a "Press any key to continue ..." message, so that you can read the final output.
This is all configurable when the commands are compiled.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Kuroneko's post (above) raises a good point - what terminal emulator are you using?
There is a chance the command output is simply being erased before you get a chance to see it. Can you try downloading putty (from here)? Or if you are using the Parallax Serial Terminal, try doing what Kuroneko suggested and disabling the Clear Screen function.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Catalyst.bin itself is not really intended to be run as a command - it is intended to be programmed into EEPROM. If you run it as a command then you can use it - once only - to run another external catalyst command. But once that command completes, it will reset the prop and simply load whatever program you have in EEPROM.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Can you try using Catalyst to run the enclosed program? It is just Cluso's standard RamBlade test program. It works fine on my RamBlade, but if Kuroneko is right about your problem being due to a conflict on pin 24, running this program using Catalyst will fail, whereas running it using Cluso's loader will not.
Ross.
EDIT: binaries removed. See top of thread for latest binaries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Hi Ross
I've been using putty all the time 'til now.
Using putty I had the same impression as kuroneko at first, that·running ls there was some deleted output during the pause just before rebooting. Unfortunately this seems not·my case: the following is from BST serial terminal, on a new Maxell 2GB uSD card:
Also gave it a try with PST, leaving only char 13 enabled, but nothing changed.
RossH said...
Allesandro,
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.
Thanks, but don't get overly mad about this, at least not while it's my case only.
Single tests are mostly good,·the classic kind that's going to·generate big laughs once resolved
Just an observation. As I mentioned, I can start catalystonce from its own prompt. Subsequent calls will reset the RAMBlade. OK, what if I start another external command like this, i.e. first run catalyst (from within itself) then run ls. In this scenario I get the same behaviour as Alessandro, ls doesn't produce output and the RAMBlade is reset. So it looks to me that the way Alessandro starts catalyst is part of the problem here (i.e. spin catalyst).
working
- PropellerLoader style upload of catalyst.bin[noparse][[/noparse]ary]
- run ls.bin -> produces listing, reset (expected)
not working (my setup)
- PropellerLoader style upload of catalyst.bin[noparse][[/noparse]ary]
- run catalyst.bin
- run ls.bin -> no listing, reset
not working (Alessandro's setup)
- spin catalyst
- run ls.bin -> no listing, reset
Just a suggestion - Ross can you add a few instructions to set CS=0 and an output (postedit: no this must be high which is the default with the pullup) and then send some clocks out on the SD Clk pin. Check if the DO input is =1. Keep sending clocks if it is =0 as this is an error condition. If =1, then make it an output and output 0 and readback, disable output in case of conflict and then check that the readback was a 0. This will check the SD card has released DO.
Sorry, I am not up to the task of checking at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think I have managed to reproduce what Kuroneko and Alessandro are seeing, by using Cluso's PropBoot code.
Here is what I see:
Loading Catalyst from EEPROM - always works. Catalyst can be used to load and execute another command (including Catalyst).
Loading PropBoot from Catalyst - always works. PropBoot can then execute another command - EXCEPT Catalyst (see next point).
Loading Catalyst from PropBoot - NEVER WORKS. Catalyst itself gets loaded and displays its prompt ok, and it can itself access the SD card, but any program loaded by Catalyst CANNOT access the SD Card.
I'm not exactly sure what's going on yet, but it seems loading Catalyst any other way than directly from EEPROM after a hard reset leaves the SD card in a peculiar state.
However, now that I can reproduce it, I can add some initialization code to Catalyst (perhaps along the lines suggested by Cluso) to ensure the SD card is initialized to a known state before Catalyst loads another program.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ross, the FATEngine may be incompatible with FSRW because the FSRW block driver makes the SD card go into multiblock mode. My driver does not check for that condition and it could have a difficult time mounting the SD card.
However, my driver should try atleast 8 times before it gives up and returns an error. I have not had problem mounting SD cards but it could be an issue.
Maybe there's a clue in the multiblock mode issue, but the strange thing is that the latest version of Catalyst itself (as well as all the external commands) now use FATEngine exclusively - and Catalyst itself can ALWAYS access the SD card (i.e. the internal 'dir' command always seems to work) but sometimes the external commands cannot.
I'm still working on Cluso's suggestion to make sure the SD card is always being released properly. I think that's where the problem lies.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The bootcode I place in eeprom uses spisdfemto to access the SD. Perhaps, as Kye suggests, we are leaving the SD card in a state that the next SD driver cannot recover from (or fails to recover from).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I can't believe it - bitten by the same bug TWICE in one thread!
The problem with Catalyst on the RamBlade is another case of code that breaks when it is started in a particular cog.
It seems that this is going to be an ongoing problem, so I've changed the Catalyst loader to check what cog it is loaded in when it starts up. If it ever finds itself running in a cog other than cog 0 it now switches itself over to cog 0 before continuing.
I've got a bit of tidying up to do - I'll post a new RamBlade binary tomorrow.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
To ease yor mind a bit, the booting code in the FATEngine follows these steps:
1: Shutdown all cogs other than the cog running the FATEngine SD card driver.
2: Load all 64 sector address or less of the boot file into cog memory.
3: Zero all hub memory.
4: Load the 64 or less sector addresses into main memory.
5: Set the clock to the new clock mode. Since the driver is already running at a high speed I do not wait for the PLL to stablize.
6: Start cog 0 running the spin interpreter with the new program.
7: The SD card driver·then stops itself.
Catalyst has use its own loader since it has to be able not only load normal SPIN and LMM programs, but also to load programs into the external RAM. It also has to be able to load programs into another Propeller in a multi-Prop systems where the SD card is connected to one Prop but the program being loaded must run in another Propeller. It also has to take clock speed changes into account because there is no guarantee that the loaded program wants the same clock speed as the loader. I based my code partially on various other boot loaders and it seems to work reliably.
Interesting that you say your code zeroes all unused Hub RAM - I also found this to be necessary to get a reliable boot, but I don't think it's documented anywhere that this is required, or why. Can you point to a reference?
The only problem with my loader is that the XMM and SIO routines require so much cog space that I can't have the sector buffer in cog RAM the way your loader does - this means I can only load 31k (or 31.5k if I tried a little harder). I have a method in mind to make it possible to load all 32k (basically it involves using another cog as the sector buffer), but it's complex and messy and will take a while to implement.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
there are still some quirks (and a couple of new ones) but...
FANFARE!
> othello
.DSK ZICOG_D8.DSK
ZICOG_E8.DSK ZICOG_F8.DSK ZICOG_G1.DSK
ZICOG_H1.DSK HELLO.PAÿ
REVERSI
You can go first on the first game, then we will take turns.
You will be white - (O)
I will be black - (@).
Select a square for your move by typing a digit for the row
and a letter for the column with no spaces between.
Good luck! Press Enter to start.
a b c d e f g h
+---+---+---+---+---+---+---+---+
01| | | | | | | | |
+---+---+---+---+---+---+---+---+
02| | | | | | | | |
+---+---+---+---+---+---+---+---+
03| | | | | | | | |
+---+---+---+---+---+---+---+---+
04| | | | O | @ | | | |
+---+---+---+---+---+---+---+---+
05| | | | @ | O | | | |
+---+---+---+---+---+---+---+---+
06| | | | | | | | |
+---+---+---+---+---+---+---+---+
07| | | | | | | | |
+---+---+---+---+---+---+---+---+
08| | | | | | | | |
+---+---+---+---+---+---+---+---+
Please enter your move (row column):
I know it's an early test and WIP, but I report even the strangest things just in case it might prove useful to you for debugging:
-·SPIN commands appear to work
- when attemping to type something, sometimes the keyboard goes crazy (i.e. like stuck keys, especially early after catalyst startup)
- then later it seems that the serial receive buffer, or most likely the argument buffer remains dirty with previous commands, and keeps on double executing them
- it took a bit of sweat and tears to start XMM programs (probably because of the previous bugs with keyboard)
- dir was not showing output with putty, but·works with teraterm, and only hex with PST ?!? - this one is strange... had put catalyst in autoexec.bat for ease of use: one of the uSD cards would·boot only once despite of turning power off repeatedly (!), the other with same treatment seems ok (yeah, kinda haunted house, I know· ) the card just need to be reformatted, don't know·if due to my amiga-like disk swapping
- but there's also a pleasant surprise, knowing there was a problem with qz80... IT BOOTS ZICOG!
Many Thanks
Alessandro
Post Edited (AntoineDoinel) : 5/11/2010 12:42:03 AM GMT
Interesting that you say your code zeroes all unused Hub RAM - I also found this to be necessary to get a reliable boot, but I don't think it's documented anywhere that this is required, or why. Can you point to a reference?
Spin code can rely on all global variables being 0 at program start. The .binary is only loaded up to the end of the program segment, but the Propeller bootloader ensures the remainder of ram is zero. If you dump a spin application into a random memory dump this is no longer true. Certainly a number of my programs would break under these conditions as a zero VAR segment is supposed to be guaranteed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
That may explain it. I had the impression (this is from memory, going back quite a few months!) that I couldn't even get the SPIN interpreter to start correctly unless I zeroed the RAM beforehand. But perhaps what was really happening was that it was starting but some SPIN code was immmediately crashing because it was expecting zero in some variable or RAM location and getting rubbish instead. Anyway, I now zero all the unused RAM and I have not seen that particular problem since.
@Alessandro,
That's a relief!. Yes, I know there are still some bugs there - I've introduced quite a few whle trying to track down the loader issue. I just wanted to verify that the loader itself was now working - since I don't load things exactly the same way you and Kuroneko do, I had to just assume that we were in fact seeing the same problem. It seems we were.
With this latest version I also see some strange things on the serial comms occasionally. Also, it seems to be common to all the SD card software (FATEngine, FSRW and DOSFS) that they fail in very peculiar ways if the FAT structures on the SD card ever get corrupted. I rarely reformat my card, but if things start going crazy when I'm testing then I chkdsk the card - it fixes problems surprisingly often.
I'll post a completely new set of RamBlade binaries in a few days.
Ross, since the bootloader is almost always running at the fastest speed you can always slow down with no problem.
That is what I mean by not waiting for the pll to stabalize. You only need to wait for the pll to stabilize when you are turning it on from an off state. I assume your bootloader uses the pll so you don't need to wait for it to stabalize becuase your either just slowing it down or turning it off.
Can you please try the attached catalyst.bin and let me know if it works?
Works for me now. Catalyst can even start itself any number of times. I had the odd issue that the initial prompt appeared halfway down the screen (not at the top) but that may well be something else entirely (most likely PST).
When the prop ROM bootloader downloads code from the PC, it is copied into the hub RAM and when the load completes, any space not initialised is zero filled. Then if a write to eeprom was required, the hub ram (all 32KB) is copied to the eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
New RamBlade binaries attached. Note that I am having some trouble with overclocking on the RamBlade, and have been unable to use the standard RamBlade 6.5Mhz crystal.
The enclosed binaries are compiled for a RamBlade with a 6.25Mhz crystal - this is currently the fastest I can get my RamBlade to work. If you do not have a 6.25Mhz crystal, you will not be able to use these binaries.
Ross.
Edit: binaries now included in the first post of this thread.
The reason othello ran in the previous release was that it does not use either the SRAM or the SD card - that program should in fact run on any Prop that uses pins 22 and 23 for serial I/O. This is why it seems to work fairly reliably at 104Mhz - although I have had it fail occasionally on my RamBlade.
But the fact that everything else also works this time means that we are making progress! I recompiled all the Catalyst programs to run at 100MHz, but the Catalyst loader should still correctly cope with loading programs that run at any clock speed. However, I have to admit I have not tested this code recently - so it may be that in all my messing about I have broken something and the loader no longer correctly reconfigures the prop using the clock information specified in long[ 0 ] and long[ 1 ] of the loaded program.
However, since you say you have recompiled ZiCog to run at 100Mhz anyway, I don't think this is the problem. If you have a binary version of ZiCog which is known to run on your RamBlade at 100Mhz then please post it and I will figure out why it doesn't load under Catalyst.
Now that I seem to have tracked down the major problems , I hope to go back to working on Catalina itself - so the next release should be a full source release of both Catalina and Catalyst, an you can compile all the programs for yourself for any clock speed. But in the meantime if you let me know what clock speed(s) you normally use, I will recompile the binaries for you.
Comments
Apologies, in my initial post I was implying that ls generated output before the system crashed resets (not just a NL and then nothing as Alessandro reported).
Post Edited (kuroneko) : 5/8/2010 5:13:01 AM GMT
Thanks - that's what I would expect. The Clear Screen is probably coming from whatever program you have in EEPROM.
If the Catalyst external commands are compiled to use serial comms as the HMI they do not pause at the end of the command output - they just reset the Prop, expecting to pass control back to catalyst.bin (which they assume will be in EEPROM). However, when a local display HMI option is being used (e.g. TV or VGA) each command finishes with a "Press any key to continue ..." message, so that you can read the final output.
This is all configurable when the commands are compiled.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Kuroneko's post (above) raises a good point - what terminal emulator are you using?
There is a chance the command output is simply being erased before you get a chance to see it. Can you try downloading putty (from here)? Or if you are using the Parallax Serial Terminal, try doing what Kuroneko suggested and disabling the Clear Screen function.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Catalyst.bin itself is not really intended to be run as a command - it is intended to be programmed into EEPROM. If you run it as a command then you can use it - once only - to run another external catalyst command. But once that command completes, it will reset the prop and simply load whatever program you have in EEPROM.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Can you try using Catalyst to run the enclosed program? It is just Cluso's standard RamBlade test program. It works fine on my RamBlade, but if Kuroneko is right about your problem being due to a conflict on pin 24, running this program using Catalyst will fail, whereas running it using Cluso's loader will not.
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:08:20 AM GMT
I've been using putty all the time 'til now.
Using putty I had the same impression as kuroneko at first, that·running ls there was some deleted output during the pause just before rebooting. Unfortunately this seems not·my case: the following is from BST serial terminal, on a new Maxell 2GB uSD card:
---------------------------------------- PropCommand (RamBlade) V0.060 SD:>Hit <esc> to bypass autoexec.bat,etc SD:> SD:> SD:> SD:>spin rb_test ---------------------------------------- RamBlade Tests V1.01 Test input pins P19-21, P24-26, P28-29 for 10K pullups... read $37F80000 pullups $37380000 passed. Test output pins P0-21,24-29... Pin 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,24,25,26,27,28,29, passed. Test address output pins P0-18... (wait) passed. Test data output pins P24-31... passed. Test SRAM... writing... (wait) $00000 10000 20000 30000 40000 50000 60000 70000 reading... (wait) $00000 10000 20000 30000 40000 50000 60000 70000 passed. Testing SD card... A:DRIVE_A2.CPM 109824 8388608 B:DRIVE_B0.CPM -not found- C:DRIVE_C0.CPM -not found- D:DRIVE_D0.CPM -not found- E:DRIVE_E0.CPM -not found- F:DRIVE_F0.CPM -not found- G:DRIVE_G0.CPM -not found- H:DRIVE_H0.CPM -not found- SD card passed. i) RamBlade Passed Tests. [color=red](manual reboot here)[/color] ---------------------------------------- PropCommand (RamBlade) V0.060 SD:>Hit <esc> to bypass autoexec.bat,etc SD:> SD:> SD:>spin ls [color=#ff0000](removed a few entries from this one to make it shorter)[/color] RMDIR.BIN ____A 0000010060 Bytes Access Date= 05/08/2010 Create Time= 12:01:16 05/08/2010 Modify Time= 21:34:00 05/05/2010 RM.BIN ____A 0000010192 Bytes Access Date= 05/08/2010 Create Time= 12:01:16 05/08/2010 Modify Time= 21:34:00 05/05/2010 LS.BIN ____A 0000012148 Bytes Access Date= 05/08/2010 Create Time= 12:01:17 05/08/2010 Modify Time= 21:34:00 05/05/2010 CP.BIN ____A 0000013892 Bytes Access Date= 05/08/2010 Create Time= 12:01:17 05/08/2010 Modify Time= 21:34:00 05/05/2010 CATALYST.BIN ____A 0000012268 Bytes Access Date= 05/08/2010 Create Time= 12:01:17 05/08/2010 Modify Time= 21:34:00 05/05/2010 MV.BIN ____A 0000014184 Bytes Access Date= 05/08/2010 Create Time= 12:01:17 05/08/2010 Modify Time= 21:34:00 05/05/2010 DBASIC.BIN ____A 0000284732 Bytes Access Date= 05/08/2010 Create Time= 12:01:19 05/08/2010 Modify Time= 21:00:00 05/05/2010 VI.BIN ____A 0000358724 Bytes Access Date= 05/08/2010 Create Time= 12:01:21 05/08/2010 Modify Time= 20:52:00 05/05/2010 RAMBLADE.TXT ____A 0000001859 Bytes Access Date= 05/08/2010 Create Time= 12:01:21 05/08/2010 Modify Time= 21:55:00 05/05/2010 CATALYST.TXT ____A 0000009006 Bytes Access Date= 05/08/2010 Create Time= 12:01:21 05/08/2010 Modify Time= 00:44:00 04/28/2010 MKDIR.BIN ____A 0000010088 Bytes Access Date= 05/08/2010 Create Time= 12:01:22 05/08/2010 Modify Time= 21:34:00 05/05/2010 BOOTHDSK.ROM ____A 0000001024 Bytes Access Date= 05/08/2010 Create Time= 12:06:49 05/08/2010 Modify Time= 18:12:00 12/28/2009 BOOTFLOP.ROM ____A 0000001024 Bytes Access Date= 05/08/2010 Create Time= 12:06:49 05/08/2010 Modify Time= 18:12:00 12/28/2009 PROPCMD.BIN ____A 0000011876 Bytes Access Date= 05/08/2010 Create Time= 12:07:58 05/08/2010 Modify Time= 14:44:44 02/12/2010 YMODEM.BIN ____A 0000007684 Bytes Access Date= 05/08/2010 Create Time= 12:07:58 05/08/2010 Modify Time= 10:13:28 04/03/2010 RB_TEST.BIN ____A 0000008280 Bytes Access Date= 05/08/2010 Create Time= 12:14:29 05/08/2010 Modify Time= 15:39:00 05/08/2010 NEWLS.BIN ____A 0000012144 Bytes Access Date= 05/08/2010 Create Time= 12:14:41 05/08/2010 Modify Time= 20:01:00 05/06/2010 ZICOG.BIN ____A 0000017024 Bytes Access Date= 05/08/2010 Create Time= 12:15:40 05/08/2010 Modify Time= 14:38:58 01/11/2010 AUTOEXEC.BAT _HS_A 0000000093 Bytes Access Date= 05/08/2010 Create Time= 12:16:04 05/08/2010 Modify Time= 12:22:02 05/08/2010 BOOTPROP.BIN ____A 0000011876 Bytes Access Date= 05/08/2010 Create Time= 12:16:18 05/08/2010 Modify Time= 14:12:30 01/11/2010 DRIVE_A2.CPM ____A 0008388608 Bytes Access Date= 05/08/2010 Create Time= 12:56:06 05/08/2010 Modify Time= 20:25:00 09/17/2009 ---------------------------------------- PropCommand (RamBlade) V0.060 SD:>Hit <esc> to bypass autoexec.bat,etc SD:> SD:> SD:>spin catalyst Catalyst v1.0 > dir Directory ------------ ------------ ------------ RMDIR.BIN RM.BIN LS.BIN OTHELLO.BIN CP.BIN CATALYST.BIN MV.BIN STARTREK.BAS UT-TREK.BAS SST.DOC TREK15.BAS PINT.BIN JZIP.BIN PCOM.BIN DBASIC.BIN ZORK3.DAT ZORK1.DAT ZORK2.DAT SST.BIN VI.BIN HELLO.PAS SAMPLE.PAS RAMBLADE.TXT DUMBO.TXT CATALYST.TXT HELP.XVI ELIZA.BAS MKDIR.BIN BOOTHDSK.ROM BOOTFLOP.ROM ZICOG_H1.DSK ZICOG_G1.DSK ZICOG_F8.DSK ZICOG_E8.DSK ZICOG_D8.DSK ZICOG_C8.DSK ZICOG_B8.DSK ZICOG_A2.DSK PROPCMD.BIN YMODEM.BIN RB_TEST.BIN NEWLS.BIN ZICOG.BIN AUTOEXEC.BAT BOOTPROP.BIN DRIVE_A2.CPM > > ls ---------------------------------------- [color=red]<= restart[/color] PropCommand (RamBlade) V0.060 SD:>Hit <esc> to bypass autoexec.bat,etc SD:> SD:> SD:> SD:>spin catalyst Catalyst v1.0 > [color=red](switched to hex here, then ran ls)[/color] 6C 73 0D 0D 0D 0A 0D 0A 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 0D 0A 50 72 6F 70 43 6F 6D 6D 61 6E 64 20 28 52 [color=red]<= PropCommand (RamBlade) V0.060 etc.[/color] 61 6D 42 6C 61 64 65 29 20 56 30 2E 30 36 30 0D 0A 53 44 3A 3E 48 69 74 20 3C 65 73 63 3E 20 74 6F 20 62 79 70 61 73 73 20 61 75 74 6F 65 78 65 63 2E 62 61 74 2C 65 74 63 0D 0A 20 4C 6F 63 61 [color=red]...[/color]Also gave it a try with PST, leaving only char 13 enabled, but nothing changed.
Thanks, but don't get overly mad about this, at least not while it's my case only.
Single tests are mostly good,·the classic kind that's going to·generate big laughs once resolved
Alessandro
I'd like to solve it because I'm fairly sure that you won't be the only to have this problem.
Enclosed is a new version of the Catalyst binary that uses FATEngine in place of fsrw. Could you try this one out please?
Thanks,
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:08:59 AM GMT
Post Edited (kuroneko) : 5/8/2010 1:55:35 PM GMT
Sorry, I am not up to the task of checking at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 5/8/2010 2:21:45 PM GMT
Success! Or Failure! Or ... Something!
I think I have managed to reproduce what Kuroneko and Alessandro are seeing, by using Cluso's PropBoot code.
Here is what I see:
- Loading Catalyst from EEPROM - always works. Catalyst can be used to load and execute another command (including Catalyst).
- Loading PropBoot from Catalyst - always works. PropBoot can then execute another command - EXCEPT Catalyst (see next point).
- Loading Catalyst from PropBoot - NEVER WORKS. Catalyst itself gets loaded and displays its prompt ok, and it can itself access the SD card, but any program loaded by Catalyst CANNOT access the SD Card.
I'm not exactly sure what's going on yet, but it seems loading Catalyst any other way than directly from EEPROM after a hard reset leaves the SD card in a peculiar state.However, now that I can reproduce it, I can add some initialization code to Catalyst (perhaps along the lines suggested by Cluso) to ensure the SD card is initialized to a known state before Catalyst loads another program.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
However, my driver should try atleast 8 times before it gives up and returns an error. I have not had problem mounting SD cards but it could be an issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Stranger and stranger!
Maybe there's a clue in the multiblock mode issue, but the strange thing is that the latest version of Catalyst itself (as well as all the external commands) now use FATEngine exclusively - and Catalyst itself can ALWAYS access the SD card (i.e. the internal 'dir' command always seems to work) but sometimes the external commands cannot.
I'm still working on Cluso's suggestion to make sure the SD card is always being released properly. I think that's where the problem lies.
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 can't believe it - bitten by the same bug TWICE in one thread!
The problem with Catalyst on the RamBlade is another case of code that breaks when it is started in a particular cog.
It seems that this is going to be an ongoing problem, so I've changed the Catalyst loader to check what cog it is loaded in when it starts up. If it ever finds itself running in a cog other than cog 0 it now switches itself over to cog 0 before continuing.
I've got a bit of tidying up to do - I'll post a new RamBlade binary tomorrow.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
1: Shutdown all cogs other than the cog running the FATEngine SD card driver.
2: Load all 64 sector address or less of the boot file into cog memory.
3: Zero all hub memory.
4: Load the 64 or less sector addresses into main memory.
5: Set the clock to the new clock mode. Since the driver is already running at a high speed I do not wait for the PLL to stablize.
6: Start cog 0 running the spin interpreter with the new program.
7: The SD card driver·then stops itself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 5/11/2010 1:07:59 AM GMT
Catalyst has use its own loader since it has to be able not only load normal SPIN and LMM programs, but also to load programs into the external RAM. It also has to be able to load programs into another Propeller in a multi-Prop systems where the SD card is connected to one Prop but the program being loaded must run in another Propeller. It also has to take clock speed changes into account because there is no guarantee that the loaded program wants the same clock speed as the loader. I based my code partially on various other boot loaders and it seems to work reliably.
Interesting that you say your code zeroes all unused Hub RAM - I also found this to be necessary to get a reliable boot, but I don't think it's documented anywhere that this is required, or why. Can you point to a reference?
The only problem with my loader is that the XMM and SIO routines require so much cog space that I can't have the sector buffer in cog RAM the way your loader does - this means I can only load 31k (or 31.5k if I tried a little harder). I have a method in mind to make it possible to load all 32k (basically it involves using another cog as the sector buffer), but it's complex and messy and will take a while to implement.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Can you please try the attached catalyst.bin and let me know if it works?
Thanks,
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:09:45 AM GMT
> othello .DSK ZICOG_D8.DSK ZICOG_E8.DSK ZICOG_F8.DSK ZICOG_G1.DSK ZICOG_H1.DSK HELLO.PAÿ REVERSI You can go first on the first game, then we will take turns. You will be white - (O) I will be black - (@). Select a square for your move by typing a digit for the row and a letter for the column with no spaces between. Good luck! Press Enter to start. a b c d e f g h +---+---+---+---+---+---+---+---+ 01| | | | | | | | | +---+---+---+---+---+---+---+---+ 02| | | | | | | | | +---+---+---+---+---+---+---+---+ 03| | | | | | | | | +---+---+---+---+---+---+---+---+ 04| | | | O | @ | | | | +---+---+---+---+---+---+---+---+ 05| | | | @ | O | | | | +---+---+---+---+---+---+---+---+ 06| | | | | | | | | +---+---+---+---+---+---+---+---+ 07| | | | | | | | | +---+---+---+---+---+---+---+---+ 08| | | | | | | | | +---+---+---+---+---+---+---+---+ Please enter your move (row column):I know it's an early test and WIP, but I report even the strangest things just in case it might prove useful to you for debugging:
-·SPIN commands appear to work
- when attemping to type something, sometimes the keyboard goes crazy (i.e. like stuck keys, especially early after catalyst startup)
- then later it seems that the serial receive buffer, or most likely the argument buffer remains dirty with previous commands, and keeps on double executing them
- it took a bit of sweat and tears to start XMM programs (probably because of the previous bugs with keyboard)
- dir was not showing output with putty, but·works with teraterm, and only hex with PST ?!?
- this one is strange... had put catalyst in autoexec.bat for ease of use: one of the uSD cards would·boot only once despite of turning power off repeatedly (!), the other with same treatment seems ok (yeah, kinda haunted house, I know·
the card just need to be reformatted, don't know·if due to my amiga-like disk swapping
- but there's also a pleasant surprise, knowing there was a problem with qz80... IT BOOTS ZICOG!
Many Thanks
Alessandro
Post Edited (AntoineDoinel) : 5/11/2010 12:42:03 AM GMT
Spin code can rely on all global variables being 0 at program start. The .binary is only loaded up to the end of the program segment, but the Propeller bootloader ensures the remainder of ram is zero. If you dump a spin application into a random memory dump this is no longer true. Certainly a number of my programs would break under these conditions as a zero VAR segment is supposed to be guaranteed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
That may explain it. I had the impression (this is from memory, going back quite a few months!) that I couldn't even get the SPIN interpreter to start correctly unless I zeroed the RAM beforehand. But perhaps what was really happening was that it was starting but some SPIN code was immmediately crashing because it was expecting zero in some variable or RAM location and getting rubbish instead. Anyway, I now zero all the unused RAM and I have not seen that particular problem since.
@Alessandro,
That's a relief!. Yes, I know there are still some bugs there - I've introduced quite a few whle trying to track down the loader issue. I just wanted to verify that the loader itself was now working - since I don't load things exactly the same way you and Kuroneko do, I had to just assume that we were in fact seeing the same problem. It seems we were.
With this latest version I also see some strange things on the serial comms occasionally. Also, it seems to be common to all the SD card software (FATEngine, FSRW and DOSFS) that they fail in very peculiar ways if the FAT structures on the SD card ever get corrupted. I rarely reformat my card, but if things start going crazy when I'm testing then I chkdsk the card - it fixes problems surprisingly often.
I'll post a completely new set of RamBlade binaries in a few days.
Ross.
That is what I mean by not waiting for the pll to stabalize. You only need to wait for the pll to stabilize when you are turning it on from an off state. I assume your bootloader uses the pll so you don't need to wait for it to stabalize becuase your either just slowing it down or turning it off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Ok - thanks for the clarification.
Ross.
Thanks!
Ross.
When the prop ROM bootloader downloads code from the PC, it is copied into the hub RAM and when the load completes, any space not initialised is zero filled. Then if a write to eeprom was required, the hub ram (all 32KB) is copied to the eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 5/11/2010 1:46:43 AM GMT
New RamBlade binaries attached. Note that I am having some trouble with overclocking on the RamBlade, and have been unable to use the standard RamBlade 6.5Mhz crystal.
The enclosed binaries are compiled for a RamBlade with a 6.25Mhz crystal - this is currently the fastest I can get my RamBlade to work. If you do not have a 6.25Mhz crystal, you will not be able to use these binaries.
Ross.
Edit: binaries now included in the first post of this thread.
This one is working great at 100MHz!
I tried·most of the XMM·programs, and everything·worked without any problem (only·othello ran in previous release).
ZiCOG and PropCMD won't start anymore from Catalyst, I don't think it's the 4% difference in speed, since both are working (from PropCMD) at 100MHz.
With the next release, could you please include binaries compiled for other speeds too?
The reason othello ran in the previous release was that it does not use either the SRAM or the SD card - that program should in fact run on any Prop that uses pins 22 and 23 for serial I/O. This is why it seems to work fairly reliably at 104Mhz - although I have had it fail occasionally on my RamBlade.
But the fact that everything else also works this time means that we are making progress! I recompiled all the Catalyst programs to run at 100MHz, but the Catalyst loader should still correctly cope with loading programs that run at any clock speed. However, I have to admit I have not tested this code recently - so it may be that in all my messing about I have broken something and the loader no longer correctly reconfigures the prop using the clock information specified in long[ 0 ] and long[ 1 ] of the loaded program.
However, since you say you have recompiled ZiCog to run at 100Mhz anyway, I don't think this is the problem. If you have a binary version of ZiCog which is known to run on your RamBlade at 100Mhz then please post it and I will figure out why it doesn't load under Catalyst.
Now that I seem to have tracked down the major problems , I hope to go back to working on Catalina itself - so the next release should be a full source release of both Catalina and Catalyst, an you can compile all the programs for yourself for any clock speed. But in the meantime if you let me know what clock speed(s) you normally use, I will recompile the binaries for you.
Ross.