January 22, 2012

It's been a *long* time, but I'm back. No VM changes, but it's now possible to run Retro on the mbed with a bit more comfort than before. I've altered the image to help make it use less memory, and now it's possible to build a standard (16-bit) image that runs in 10,400 cells. Since the VM provides 14,000 we can fit the image in and still have over 3k cells to play with. To pull this off a couple of minor concessions were made:

• max string length is now 80 characters
• max temporary strings is now 4

Shouldn't be too bad, and this makes it possible to write code in Retro and make use of the mbed's features a bit more. I hope to reduce the memory requirements of the VM a bit to make it possible to map in more of the I/O pins, but I'm pleased with the status. A tarball of the mbed vm code, binary, and image file will be provided on http://rx-core.org soon.

May 21, 2011

After a sizable absence, I'm getting ready to resume work on Retro for mbed. I hope to address a major problem: lack of memory.

A standard Retro image consists of up to 1,000,000 32-bit cells. This requires roughly 20MB of disk space and RAM. We can save a compressed image (40-60k) which takes care of the first problem, but the lack of RAM has prevented me from pursuing more with the mbed.

To this end, I will be significantly altering the way the VM works. Instead of loading the entire image into the small RAM on the mbed, I'll load just a couple thousand cells. References to other cells outside the loaded range will trigger the VM to "slide" the "window" to a new area, writing any changes to an external storage device.

My plan is thus:

• Setup an SD card for external storage (this will become the storage for a simulated memory array)
• On startup, copy the image from the internal memory to the SD card
• Load the first 1k - 2k cells into the internal RAM
• Process execution, sliding the window as needed

This will be significantly slower, but seems like the best bet for fitting a full Retro into an embedded system.

March 20, 2011

I hooked up a red LED to pin 21 and a green LED to pin 22. Then wrote the following code:

with mbed'
: delay time 1+ [ time over <> ] while drop ;
: blink ( p- ) 1 over p! delay 0 swap p! ;

: red P21 blink ;
: green P22 blink ;

: request ( n$- )
  cr puts getToken toNumber = &green &red if ;

: test
  4 "2 + 2 =" request
  8 "5 + 3 =" request
  12 "15 - 3=" request
  9 "2 + 7 =" request
  cr ;

This asks a series of math questions, and flashes the green LED if the answer was correct, or the red one if the answer was wrong. It'd be easy to tie this into the piezo buzzer for audio feedback as well.

March 18, 2011

I hooked up a piezo buzzer and an external LED to pins 29 and 21. Then did the following:

with mbed'
: delay time 1+ [ time over <> ] while drop ;
: blink 5 [ 1 P21 p! delay 0 P21 p! delay ] times ;
blink

: beep 1 P29 p! delay 0 P29 p! ;
beep

These both function as expected. My kids were quite delighted to see this and learn a tiny bit more about how computers and electricity works.

I did notice a bug in the Retro code for reading input from pins. I've corrected this and uploaded a new image. No changes were needed to the VM.

I also tested some limited file i/o stuff (to see if I could do logging). It works ok, but I need to specify the filename and path ("/local/") in lowercase.

This does open up more possibilities (e.g., I can do a smaller image, and load extensions directly on the mbed, or I could prepare a semi-turnkey image, which loads a program from a file on startup.) Much to consider here.

March 17, 2011

with mbed'
: delay time 1+ [ time over <> ] while drop ;
: blink 5 [ 1 LED1 p! delay 0 LED1 p! delay ] times ;
blink

I've revamped the backend code to (theoretically) allow reading and writing to pins 5 - 30 as well as setting LED's 1 - 4. As shown by this code, I can blink the onboard LED's from Retro now.