Minimum retro

48 views
Skip to first unread message

atilla457

unread,
Feb 21, 2011, 3:30:45 AM2/21/11
to RETRO 10
Hi there,

I'm new to Retro and forth.

I'm porting retro to a small embedded processor (still using uart to
communicate with it).

thanks to the vm, it was very easy to port the retro.c.

however, I am having problems with retroimage file.

I only have 32kb ram available. so I have to make the IMAGE_SIZE =
7000 (this is the max i can fit). the problem is existing retroimage
file does not fit.

1) is it possible to change the int size from 32 bits to 16bits? using
int16_t.
2) is it possible to strip down the retroimage way down (I guess
kernel and words) to a minimum? I still want to be able to define new
words on the fly.

any recommendations?

thank you,

Charles Childers

unread,
Feb 21, 2011, 9:50:55 AM2/21/11
to retr...@googlegroups.com
I uploaded a tarball with the stuff you need to build a 16-bit retroImage to http://rx-core.org/retro16.tar.gz

Some things to note:

- this is not able to metacompile itself
- image conversion is only tested under a 32-bit Linux system
- I included a modified core.rx that can be used to build a < 7k cell image
- VM lacks file support

See the included README for a few notes on building the 16-bit VM and image.

-- crc


--
--
You received this message because you are RETRO 10 discussion group.
To post to this group, send email to retr...@googlegroups.com
To unsubscribe from this group, send email to retro-10-u...@googlegroups.com

atilla457

unread,
Feb 21, 2011, 12:16:50 PM2/21/11
to RETRO 10
Hi Charles,

Thanks for the quick response.

I gave it a quick shot at work, but couldn't get retro16 to run on my
macbook pro (it compiled fine). Don't worry for now; I'll take a more
detailed look at it tonight.

I see what convert.c does.

One question. Is core.rx the whole kernel/operating system? That's
cool.

Thanks,


On Feb 21, 6:50 am, Charles Childers <charles.child...@gmail.com>
wrote:
> I uploaded a tarball with the stuff you need to build a 16-bit retroImage tohttp://rx-core.org/retro16.tar.gz

Charles Childers

unread,
Feb 21, 2011, 1:34:07 PM2/21/11
to retr...@googlegroups.com
I'll look at running it on OS X tonight.

The core.rx is the assembler, metacompiler, kernel, and core language. The main repository has some optional stuff in the library directory, but all the core functionality is in core.rx

One other thing: I reuploaded the retro16.tar.gz (same url as before) with a working metacompiler. With the retro16 vm, it's now possible to build a full or small image:

# full image
  make
  cat full-core.rx | ./retro16

# smaller image
  make
  cat small-core.rx | ./retro16

-- crc

atilla457

unread,
Feb 21, 2011, 5:11:22 PM2/21/11
to RETRO 10
Ok, stole a few minutes from my employeer :) Got retro16 to boot now.

1) changed the input buffer type to 'int' from 'long'.
int input[5000000];

2) changed fread in 'load_image(char *image)' to from int16_t.
x = fread(input, sizeof(int), 5000000, fp);

I'm using a macbook pro, probably it's 64bit vs 32bit or something
like that.

I can now boot retro16.

I tried the following, '.' does not work.

Retro 11.0 (16-bit edition)

ok 1
ok 2
ok +
ok .
. ?

ok bye

Thanks for all your help,



On Feb 21, 10:34 am, Charles Childers <charles.child...@gmail.com>

atilla457

unread,
Feb 21, 2011, 6:39:53 PM2/21/11
to RETRO 10
Alright, i got it all working now thru some manual running of convert/
retro and retro16.

Now I also understand why file operations dont work - because now the
stack is incompatible with file handles.

thanks,

Charles Childers

unread,
Feb 21, 2011, 7:11:44 PM2/21/11
to retr...@googlegroups.com
I've checked in the retro16 code (and a new retro64 vm as well) into the main repository. I applied the fixes you have here, but used int32_t instead of int to hopefully ensure that this will work on more systems.

I also made a small change to the standard core.rx, so it's now possible to create 16bit and 64bit images from the standard 32bit image, and rebuild from any of them.

I'll take a look into getting file I/O back in place now.

-- crc

Charles Childers

unread,
Feb 21, 2011, 7:12:57 PM2/21/11
to retr...@googlegroups.com
Oops; I forgot one more thing: use putn instead of . to display numbers:

ok  1 
ok  2 
ok  + 
ok  putn 3

-- crc


On Mon, Feb 21, 2011 at 5:11 PM, atilla457 <ert...@gmail.com> wrote:

atilla457

unread,
Feb 21, 2011, 8:31:35 PM2/21/11
to RETRO 10
Hi Charles,

I got it working on my embedded environment.

I'll sync and try the repository tonight. I will also suggest you
some changes that you may want to apply.

thanks a bunch!


On Feb 21, 4:12 pm, Charles Childers <charles.child...@gmail.com>
wrote:

atilla457

unread,
Feb 24, 2011, 12:50:38 PM2/24/11
to RETRO 10
HI Charles,

My project is porting retro16 to MBED microcontroller (www.mbed.org).
I really like retro for its simplicity, especially the single file
approach (retro.c and core.rx). And forth is very similar to my hp
50g calculator rpn style :)

1) I modified retro16 files so that it is possible to build it for
MBED by defining __MBED__. What's the best way to send you the files
for review?

2) While reviewing the core.rx in the branch, I got the idea that if
it is possible to have multiple memories? Let me explain. MBED has
512KB flash and 32KB ram. I can maximize ram by putting core.rx in
the flash and all user entered data/words are in the ram.

Let me do some code reading...

thanks,
erturk

Charles Childers

unread,
Feb 24, 2011, 1:10:20 PM2/24/11
to retr...@googlegroups.com
erturk,

You can send the modified files to crc @ rx-core.org. I'll be happy to take a look (and add them to the repository if you want).

Regarding multiple memory spaces; Retro itself isn't setup for this. The VM could remap regions to different memory spaces, though the modified VM would still need to present it to Retro as a flat memory space. This could be somewhat tricky due to the possibility of revectored functions, and data access (e.g., heap, base, and friends in the kernel).

Charles R. Childers

atilla457

unread,
Feb 24, 2011, 1:50:50 PM2/24/11
to RETRO 10

Cool, I'll send you files when I get home.

> Regarding multiple memory spaces;

I was thinking using the most significant bit to differentiate between
flash and rom, but updating anything in flash will be slow (and I
wouldn't want to do it too frequent to prolong the flash life).

thanks,

On Feb 24, 10:10 am, Charles Childers <charles.child...@gmail.com>
Reply all
Reply to author
Forward
0 new messages