Do you have Propeller Tool compatible version of all of the Sphinx programs available somewhere? It would make it easier to do the keyboard driver switchout that I'm attempting.
OBC
Sphinx should be PropTool-compatible as-is. Well, I guess you have to rename .spn files to .spin, but other than that... Sorry, maybe I don't understand the question.
But there do seem to be a lot of changes within the sphinx TV driver code compared with that older TV demo code. I'm not quite sure where to start.
Sorry to hear of your TV difficulties. The Sphinx TV driver is a horribly hacked version of the standard TV object. It's NTSC-only, btw; could that be the problem here?
I'm not quite sure where to take this next. I have a gut feeling that a self hosted propeller solution can be written on one propeller. But without a screen working for sphinx and with sphinx unable to do VGA, I can't see any solution other than to use sphinx in 'serial port' mode and use another propeller for the display.
Gut feeling? Do you not believe that Sphinx works for [at least some] other people?
I am sure it is close to working. The text is on the screen - it is just rolling very rapidly and there is a lot of noise.
I tried uncommenting a few commented out lines that are in the sphinx code but are working in the palette code. There were some changes in the display but no better.
I guess it is the bits that are different but I don't understand why they have been changed eg, this is from sphinx
' Horizontal sync
'
hsync test _mode,#%0001 wc 'if pal, toggle phaseflip
' if_c xor phaseflip,phasemask
mov vscl,sync_scale1 'do hsync
mov tile,burst'phaseflip
' xor tile,burst
waitvid tile,sync_normal
mov vscl,hvis 'setup in case blank line
mov tile,#0'phaseflip
hsync_ret ret
'
and this is the original code - 3 lines are different
' Horizontal sync
'
hsync test _mode,#%0001 wc 'if pal, toggle phaseflip
if_c xor phaseflip,phasemask
mov vscl,sync_scale1 'do hsync
mov tile,phaseflip
xor tile,burst
waitvid tile,sync_normal
mov vscl,hvis 'setup in case blank line
mov tile,phaseflip
hsync_ret ret
Do you have any intermediate code along the way from the original code to the sphinx code?
Sphinx should be PropTool-compatible as-is. Well, I guess you have to rename .spn files to .spin, but other than that... Sorry, maybe I don't understand the question.
Somehow I thought there was more to it than simply renaming the .spn files .spin. Thanks for clearing my head.
(Guess I've had a few other things on my mind as well this week. )
@Alexis64
I just downloaded the binary precompiled version of C3 Sphinx that I used to post the archive in message #70 and it works fine on my C3. I get a ">" prompt and can certainly run DIR. If you can, try a different SD card.
I've had this version running on both of two C3 boards that I have. I have a Parallax PS/2 keyboard and a little 7" Axion TV. I've also used at least two different SD cards, both 2GB.
@Alexis64
I just downloaded the binary precompiled version of C3 Sphinx that I used to post the archive in message #70 and it works fine on my C3. I get a ">" prompt and can certainly run DIR. If you can, try a different SD card.
I've had this version running on both of two C3 boards that I have. I have a Parallax PS/2 keyboard and a little 7" Axion TV. I've also used at least two different SD cards, both 2GB.
That was it -- very weird -- I used the same cart for other (spin) programs and all worked ok ... I tried another brand 1GB SD and it came straight up ... Thank you for the suggestion ... All is good now ...
Sphinx was designed to have substitutable drivers. I wanted a few extra drivers in there, so I suggested a layout for the rendezvous vestors. That way, sphinx would be aware of stdin, stdout, auxin, auxout, and of course the sd driver. Therefore, we could substitute drivers depending on the base pcb hardware without any recompiling.
Seems the original sphinx framework done by mpark is being ignored here, including those further discussions. It should not matter whether the hardware has 1 or 2 props, separate serial terminal, integrated terminal (TV or VGA & keyboard), or serial to pc emulating a terminal.
Sorry, I don't have the time to dig out the old thread just now. Maybe next week???
Sphinx was designed to have substitutable drivers.
That's one of the reasons why Sphinx looks more interesting to me than other competitors.
I'm paying with a current Sphinx plus Ariba's changes (substituting KBD and TV by using a serial connection over pin30/31).
Looks very promising... and having no TV to play with an unchanged sphinx this is the only way for me to drop an eye on sphinx.
Only sphinx.spn needs to be rebuilt when a different driver setup is needed. I'm thinking of splitting it into the real hardware dependent part (BIOS?) chainloading the "shell" (CCP?). Is that done already in another "fork"? Or would that be a shot in my own knee?
For future versions a filesystem with subdirectories or at least the CP/Mish concept of numbered user(area)s would be great... or does something like that already exist?
Ok... breaking compatibility to the PC's filesystem is not a good idea as long as sphinx only knows one kind of filesystem and so far no application is aware of paths... that's not easily doable in a way not breaking existing application code... just changing a driver is not enough for this point on this wishlist.
Longer filenames would be nice to have too (but in no way essential, so faaaaaar down on the wishlist) but again that is beyond the scope of just changing a "driver" (can we call tis "kenel modules" instead?) again too much application code explicitely expects 8.3 filenames and I'm not really happy when I think about "progra~1" alike workarrounds known from elsewhere...
But... if we are willing to break existing application code, such decissions should be taken as long as there is not too much code to be changed... so the earlier the better...
The 8.3 is standard and means the sd cards can be read/written by the pc, including sub-directories. Sphinx needs to have the new KyeDos SD drivers put in as IIRC there is a bug in something in sphinx that corrupts the FAT file (cannot recall exactly the problem).
IIRC I was working toward a number of rendezvous & pointer locations to allow for 3 I/O devices (remembering they can be separate Input and Output devices or combined I/O devices). I wanted to be simply be able to substitute the StdIn & StdOut device drivers, simply and on the fly. So you could have serial (to pc using P30/31) or Keyboard (standard or my 1 pin) plus TV or VGA or LCD.
I wanted the boot eprom to be just a simple loader to load a binary from the sd card. So essentially, the eeprom never changed so a propplug was not necessarily required. The sd card binary (or autoexec,bat file) can be changed on the pc or the prop. So hardware can be changed without requiring an eeprom change, excepting if the sd pins changed (which is unlikely for that particular piece of hardware). A typical example of this eeprom boot code can be found in my RamBlade (code published).
Taking the boot process further, if the bootable sd binary performed some checks, it is entirely possible to test for the differences to determine if VGA or TV circuit was present (but not the screen) and the keyboard.
...IIRC there is a bug in something in sphinx that corrupts the FAT file (cannot recall exactly the problem).
If anyone comes up with a reliable repro for this, I'd love to see it. As things stand now, no repro = no bug. Nowadays I tend to attribute file corruption to general flakiness in SD cards (I've seen them do some weird things, completely separate from Sphinx). But prove me wrong, please.
@Alexis64
I just downloaded the binary precompiled version of C3 Sphinx that I used to post the archive in message #70 and it works fine on my C3. I get a ">" prompt and can certainly run DIR. If you can, try a different SD card.
I've had this version running on both of two C3 boards that I have. I have a Parallax PS/2 keyboard and a little 7" Axion TV. I've also used at least two different SD cards, both 2GB.
I downloaded your sphinx for C3 from post #70 and it appears to have its .sob files missing from sphinx1 and SphinxDrive. I copied the originals from mpark's archive and it's working on my C3!
mpark: In your release you said there may be a corruption issue. While I did not see it at the time, I later realised that I had a corruption in the fat table. While I also use CPM & ZiCog on the SD, I had never seen a corruption in the FAT table from ZiCog. So, there perhaps is an issue, perhaps not.
Anyway, we need to get it up to the latest SD drivers because everyone is using Kye's nowadays, so at least we should standardise here.
Everyone seems to be going in different directions, and from what I saw, SphinxOS seemed to be the best method, together with some little improvements to make it even more versatile, to become a prop self hosted product.
Comments
Sphinx should be PropTool-compatible as-is. Well, I guess you have to rename .spn files to .spin, but other than that... Sorry, maybe I don't understand the question.
Sorry to hear of your TV difficulties. The Sphinx TV driver is a horribly hacked version of the standard TV object. It's NTSC-only, btw; could that be the problem here?
Gut feeling? Do you not believe that Sphinx works for [at least some] other people?
I am sure it is close to working. The text is on the screen - it is just rolling very rapidly and there is a lot of noise.
I tried uncommenting a few commented out lines that are in the sphinx code but are working in the palette code. There were some changes in the display but no better.
I guess it is the bits that are different but I don't understand why they have been changed eg, this is from sphinx
' Horizontal sync ' hsync test _mode,#%0001 wc 'if pal, toggle phaseflip ' if_c xor phaseflip,phasemask mov vscl,sync_scale1 'do hsync mov tile,burst'phaseflip ' xor tile,burst waitvid tile,sync_normal mov vscl,hvis 'setup in case blank line mov tile,#0'phaseflip hsync_ret ret 'and this is the original code - 3 lines are different
' Horizontal sync ' hsync test _mode,#%0001 wc 'if pal, toggle phaseflip if_c xor phaseflip,phasemask mov vscl,sync_scale1 'do hsync mov tile,phaseflip xor tile,burst waitvid tile,sync_normal mov vscl,hvis 'setup in case blank line mov tile,phaseflip hsync_ret retDo you have any intermediate code along the way from the original code to the sphinx code?
Somehow I thought there was more to it than simply renaming the .spn files .spin. Thanks for clearing my head.
(Guess I've had a few other things on my mind as well this week. )
OBC
Strange, you should be able to fun it if that TV version of KyeDOS I posted worked.
It's a probably a stupid question, but you did think to change the default speed settings in Sphinx didn't you? IIRC, mine defaulted to the Hydra.
OBC
er, no. Not a stupid question at all.
In fact, that solves the problem!!!
Changed pll8x to pll16x and everything works perfectly now.
Ok, now I can test Sphinx. Woot, thanks guys!!
d1,do,clk,cnt,sel 9,10,11,25,8,5 ...
no ">" prompt...
Even if I recompile it, the only way I can get any prompt at all is if I comment out " sxfs.start( sdPins ) and f.close"
I am running it on the C3 ...
any ideas?
I just downloaded the binary precompiled version of C3 Sphinx that I used to post the archive in message #70 and it works fine on my C3. I get a ">" prompt and can certainly run DIR. If you can, try a different SD card.
I've had this version running on both of two C3 boards that I have. I have a Parallax PS/2 keyboard and a little 7" Axion TV. I've also used at least two different SD cards, both 2GB.
That was it -- very weird -- I used the same cart for other (spin) programs and all worked ok ... I tried another brand 1GB SD and it came straight up ... Thank you for the suggestion ... All is good now ...
Seems the original sphinx framework done by mpark is being ignored here, including those further discussions. It should not matter whether the hardware has 1 or 2 props, separate serial terminal, integrated terminal (TV or VGA & keyboard), or serial to pc emulating a terminal.
Sorry, I don't have the time to dig out the old thread just now. Maybe next week???
I'm paying with a current Sphinx plus Ariba's changes (substituting KBD and TV by using a serial connection over pin30/31).
Looks very promising... and having no TV to play with an unchanged sphinx this is the only way for me to drop an eye on sphinx.
Only sphinx.spn needs to be rebuilt when a different driver setup is needed. I'm thinking of splitting it into the real hardware dependent part (BIOS?) chainloading the "shell" (CCP?). Is that done already in another "fork"? Or would that be a shot in my own knee?
For future versions a filesystem with subdirectories or at least the CP/Mish concept of numbered user(area)s would be great... or does something like that already exist?
Ok... breaking compatibility to the PC's filesystem is not a good idea as long as sphinx only knows one kind of filesystem and so far no application is aware of paths... that's not easily doable in a way not breaking existing application code... just changing a driver is not enough for this point on this wishlist.
Longer filenames would be nice to have too (but in no way essential, so faaaaaar down on the wishlist) but again that is beyond the scope of just changing a "driver" (can we call tis "kenel modules" instead?) again too much application code explicitely expects 8.3 filenames and I'm not really happy when I think about "progra~1" alike workarrounds known from elsewhere...
But... if we are willing to break existing application code, such decissions should be taken as long as there is not too much code to be changed... so the earlier the better...
IIRC I was working toward a number of rendezvous & pointer locations to allow for 3 I/O devices (remembering they can be separate Input and Output devices or combined I/O devices). I wanted to be simply be able to substitute the StdIn & StdOut device drivers, simply and on the fly. So you could have serial (to pc using P30/31) or Keyboard (standard or my 1 pin) plus TV or VGA or LCD.
I wanted the boot eprom to be just a simple loader to load a binary from the sd card. So essentially, the eeprom never changed so a propplug was not necessarily required. The sd card binary (or autoexec,bat file) can be changed on the pc or the prop. So hardware can be changed without requiring an eeprom change, excepting if the sd pins changed (which is unlikely for that particular piece of hardware). A typical example of this eeprom boot code can be found in my RamBlade (code published).
Taking the boot process further, if the bootable sd binary performed some checks, it is entirely possible to test for the differences to determine if VGA or TV circuit was present (but not the screen) and the keyboard.
If anyone comes up with a reliable repro for this, I'd love to see it. As things stand now, no repro = no bug. Nowadays I tend to attribute file corruption to general flakiness in SD cards (I've seen them do some weird things, completely separate from Sphinx). But prove me wrong, please.
I downloaded your sphinx for C3 from post #70 and it appears to have its .sob files missing from sphinx1 and SphinxDrive. I copied the originals from mpark's archive and it's working on my C3!
Thought you should know...
Thanks for this port!
Anyway, we need to get it up to the latest SD drivers because everyone is using Kye's nowadays, so at least we should standardise here.
Everyone seems to be going in different directions, and from what I saw, SphinxOS seemed to be the best method, together with some little improvements to make it even more versatile, to become a prop self hosted product.