Post Reply 
newRPL: [UPDATED April 27-2017] Firmware for testing available for download
10-06-2016, 02:22 PM (This post was last modified: 10-06-2016 07:04 PM by Bruno.)
Post: #408
RE: newRPL: [UPDATED September-17-16] Firmware for testing available for download

I'm still working on the MEM command to improve it's accuracy (and to improve my knowledge about newRPL internals Smile ), and I need a little more help please.


I'll summarize here my understand about the memory structure, and how MEM is currently computing the User's free memory.

Firstly I needed to list all the memory regions and there respective sizes, and assess who is the owner (SYSTEM vs USER) :

SYSTEM'S MEMORY - 79KB - fixed size (See boot.c for details) :
- Volatile memory - 32KB
- Persistent memory - 47KB

USER'S MEMORY - 24KB - variable size :

Secondly, I needed to determine how the user's memory is allocated:
-> Each region is allocated as a chunk of n * 4KB blocks, so for a fresh calculator, 6*4=24KB are used.

Thirdly, I needed to determine how to compute the current usage of each chunk (to be more accurate):
-> Using regions pointers

Fourthly, I needed to determine how many blocks are currently unallocated:
-> Using halGetFreePages() function dedicated to that purpose

Some research for a simple result :
    case MEM:

        BINT mem = halGetFreePages() << 12;

        mem += 4096 - ((DSTop - DStk) & 0xFFF);
        mem += 4096 - ((RSTop - RStk) & 0xFFF);
        mem += 4096 - ((LAMs - LAMTop) & 0xFFF);
        mem += 4096 - ((DirsTop - Directories) & 0xFFF);
        mem += 4096 - ((TempBlocksEnd - TempBlocks) & 0xFFF);
        mem += 4096 - ((TempObEnd - TempOb) & 0xFFF);

        rplNewBINTPush((BINT64)mem, DECBINT);


But I still have some interogations :

- halGetFreePages() returns 404KB of free ram, so 108KB of memory allocated for a fresh newRPL installation,
but I've identified 'only' 103KB (79 + 24) of different memory regions, it stay 5KB of unknown memory, what am I missing ?

- My guess about the regions ownership (USER vs SYSTEM) helped me to determine for which regions MEM needs to compute the actual use,
but is it my guess right ?

Of course, any comment, correction and best practice about the code are welcome.

Successives call of MEM : (After each call, from 5 to 9 bytes of memory are used, I don't know why at the moment)
[Image: mini_328544Screenshotfrom20161006155338.png]


I would like to implement the VERSION command, and as a simple demo I try this code :
    case VERSION:
        char version[] = "newRPL alpha0.6.01";
        char copyright[] = "(c) Claudio Lapilli";

        WORDPTR versobj = rplCreateString((BYTEPTR)version, (BYTEPTR)version + stringlen(version));
        if(!versobj) return;

        WORDPTR copyobj = rplCreateString((BYTEPTR)copyright, (BYTEPTR)copyright + stringlen(copyright));
        if(!copyobj) return;


but I was unable to compile the ROM because gcc seems to do an implicit call to 'memcpy' that the linker was unable to resolve :
lib-65-system.o: In function `lib65_handler':
lib-65-system.c:(.text+0x4e0): undefined reference to `memcpy'
Makefile:497: recipe for target 'newrplfw.elf' failed
collect2: error: ld returned 1 exit status

(My guess about the origin of the memcpy is the copy of the string from the ROM to the RAM, but I'm not sure)

As a workaround, I overloaded the memcpy, and the compilation succeeded :
void *memcpy(void *dest,const void *source,int nwords) {
    memcpyb(dest, source, nwords);
    return dest;

[Image: mini_213000Screenshotfrom20161006161247.png]

Any idea about that ?

please, excuse my poor english
Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: newRPL: [UPDATED September-17-16] Firmware for testing available for download - Bruno - 10-06-2016 02:22 PM

User(s) browsing this thread: 2 Guest(s)