Just posted over at 6502.org: http://www.finitron.ca/Projects/Prj6500 ... 002ppp.htm

I've added the source code and projects docs at [url]http:\www.opencores.org[/url]

Tiny BASIC running on an RTF65002 system.

Very exciting work, Rob! Keep us posted, please!

-- Jeff

Lee Davison's 6502 EhBASIC runs now on the RTF65002 too.

I'm currently working on an SDCard interface, as there's no way to SAVE / LOAD programs yet.
I've been looking for an OS/File system I can port.

I created an ultra simple filing system (usfs) in order to save and load Tiny Basic programs.

The file system consists of a directory located at a fixed position in the SDCard - sector 4,000.
The directory has a limit of 512 entries. Then the files are located at fixed positions in the SDCard. The file location is determined by the file's position in the directory. It's a simple shift and add operation. All files are limited to 64kB.
The first file is located at sector 5,000. The second file at sector 5128, the third at sector 5256, etc.
A directory entry is a 32 character filename followed by four bytes for the size, then paddded out to 64 bytes.
This organization only consumes 33MB.

With this I've been able to save and load Tiny Basic programs to/from an SDCard, using a minimal amount of code.

I'm still working on the software for the OS / FS and other things.

I think FAT is very predictable in where it places files. So if you made a conventional partition table and formatted a first partition with FAT, then created a suitably large single file, it would most likely sit over a contiguous set of blocks near the beginning of the partition (and therefore the device)
Then your usfs usage would all occur within that large file, and you could use the FAT filesystem freely so long as you didn't touch the one true file.
Even better, you can copy that file, and even overwrite the file with alternate contents, on a "normal" computer. (I think you can overwrite a file's content without altering its location on disk)
Cheers
Ed

My test system uses something called the SimpleMMU circuit to provide 6829-like memory management. Basically memory is divided into 512 pages per task (or address space). There are 512 slots per task into which a memory page number may be entered. Pages are 64k bytes in size, so memory is limited to a max of 32MB per address space. There are 2048 total memory pages available (128MB SDRAM). The system memory is managed with a bitmap of 2048 bits (one for each page) indicating whether or not the page is allocated. An address space may be using any one or more of the 2048 pages available.

I am currently coding routines similar to the UNIX brk() and sbrk() routines and seeing how they are related to the library functions like malloc() and free(). The heap functions malloc() and free() work within the memory space assigned to the program by brk() or sbrk().