FemtoBasic and Sphinx

Mike Green

I've been working with the Sphinx I/O drivers, so I thought I'd modify FemtoBasic to use them.

Advantages:

This version includes all the necessary drivers from Sphinx, so it can be run standalone. If so, you'll have to modify the TV, keyboard, and SD card I/O pins as well as the clock settings in BasicSph.spin. If you run it under Sphinx, it uses the settings in Sphinx.

There's a variation of the LOAD statement that doesn't clear the existing program first. This allows you to load libraries. Use a plus after the file name like this: LOAD "<file>"+

The FILES and DELETE statements take 'wild-cards'. DELETE asks for permission before deleting anything.

Disadvantages:

There are a lot of small changes to I/O statements that haven't been adequately tested yet. I'll post updates here. I'll also post a stand-alone C3 version. Note that this one will run under the C3 Sphinx that's already posted to the C3 software server, but the SPI SRAM and SPI Flash won't work. The SD card I/O will work. When I post the C3 version, that will include the C3 driver for the SRAM and Flash.

Updated 2011-03-16 23:48 - Fixed REM bug - ***** See Message #4 *****
Updated 2011-03-17 10:17 - Uploaded correct archive
Updated 2011-03-17 12:24 - Added support for SPI SRAM and SPI Flash
Updated 2011-03-17 13:53 - C3 version posted
Updated 2011-03-18 11:30 - C3 and non-C3 versions combined using BST conditional compilation

Humanoido

Very nice work!

Martin Hodge

I must be doing something wrong. When I save a program to SD and reload it, ALL the operands are missing. When I view the file in a text editor it appears there is an extra binary symbol in the text between the commands and the operands which is causing the load process to fail.

Mike Green

Martin,
I must have attached the wrong upload. The Attachment Manager can be confusing. Around line 1200 in BasicSph.spin, there's an older version of the following. Substitute this and it should work.

PRI processSave | a, c, d, ntoks
   ntoks := (@tokx - @toks) / 2
   a := long[userPtr]
   repeat while a+2 < eop
      d := wordat(a)
      WriteDec(d)
      fat.WriteByte(" ")
      d := a + 2
      repeat while c := byte[d++]
         if c => 128
            if (c -= 128) < ntoks
               fat.Write(@@toks[c],strsize(@@toks[c]))
               if c <> 7   ' REM
                  fat.WriteByte(" ")
            else
               fat.WriteByte("{")
               WriteDec(c)
               fat.WriteByte("}")
         else
            fat.WriteByte(c)
      fat.WriteByte(fReturn)
      fat.WriteByte(fLinefeed)
      a += 3 + strsize(a+2)

Mike Green

I added support for SPI SRAM and SPI Flash in that you can read and write 1 to 4 bytes to SRAM and read, write, and erase to Flash like this:

sram[ 5 ] = sram[ 5 ] + 1 : rem to update a byte
sram[ 6, 2 ] = 32760 : rem to store a word value in two bytes

flash[ 23 ] = 31 : rem to write to an erased byte
print flash[ 23 ] : rem to show the resulting value
flash[ 23 ] erase : rem to erase the 4K sector containing byte 23

Note that the DUMP statement can dump SRAM (from $10000 to $1FFFF) and flash (from $20000 and up).

You have to update the I/O pin numbers used for the SPI devices in the constants near the beginning of BasicSph.spin and in the call to win.start in the main method. A -1 for the pin number of either SPI SRAM CS or the SPI Flash CS disables that device.

Oldbitcollector (Jeff)

Incredible work Mike!

With the C3, do we suffer from the same limitation of memory in getting a 40 column or 80 column video driver working with this or could this possibly be done with the extra memory which is onboard? (fingers crossed)

OBC

Mike Green

Sphinx (whether on the C3 or other board) puts its video buffer into cog memory. That does limit it to 40 x 13 and limits how it can be used (in terms of control codes). Sphinx also puts its keyboard buffer into the cog used for the keyboard driver and uses three cogs for disk I/O (low level SPI and two for the FAT filesystem stuff). All this is intended to make the most hub RAM available so the Spin compiler can use all of it. I doubt SPI SRAM is fast enough to do video buffering, particularly on the C3 with the extra time burden of its chip select mechanism. Even if that worked, you wouldn't be able to use the other SPI devices (like flash) most of the time because all of the SPI bandwidth would be used for the display.

The Sphinx compiler / assembler could be rewritten to use the SPI SRAM for some of its tables and that could free up enough memory for a 64 or 80 column display with the display buffer in hub RAM, but that's a lot of work.

Oldbitcollector (Jeff)

I was afraid you might throw water (reality) on that still.

SPI SRAM is really a trade-off of fewer pins for speed, so I guess you and I will have to wait for the next generation to accomplish this. Where additional pins can be easily given up to external ram.

OBC

Mike Green

The C3 version is posted as well. The SD card I/O appears to work, but I haven't really tested the interaction among the different SPI devices. My main concern is that SPI SRAM or SPI Flash use may cause problems with an open SD card file. Statements like FILES or DELETE close any file that they open. The main issue is an OPEN statement without a CLOSE statement being done before doing an SPI SRAM or SPI Flash access.

Martin Hodge

Mike Green wrote: »

Martin, Substitute this and it should work.

Yes, that fixed the problem. Thank you!

Mike Green

Today's update: C3 and non-C3 versions combined using BST's conditional compilation feature. At the start of BasicSph.spin is a #define statement for C3. Leave this in for the C3 version and remove or make it a comment for the non-C3 version. Note that this #define is referenced in sxfs.spin as well as BasicSph.spin. isxspi.spin is the winDriver.spin file used in the non-C3 version.