/*
* HOME(PROJECTS) || RESUME || LINKS || ABOUT */

Retrochallenge 2018/09, 2019/03


For the Retrochallenge 2019/03, I am continuing the work I started in RC 2018/09 and trying to finish KittyOS into a real operating system, finally making the CAT-644 a real computer.


This project is the creation of an operating system for the Cat-644. (external link to hackday.io) The hardware is a 20 Mhz 8-bit homebrew computer built around an AtMega 644 microcontroller, and features VGA video output. Retrochallenge main page


RC 2019/03 Index



Retrochallenge Close

I did not finished KittyOS, but I did bring it closer. Most of my time was spent on working on the memory allocator. Currently I have a two-tier memory system that can automatically swap objects between the very limited internal SRAM of the Atmega MCU, and the external SRAM. This is a huge feature, because it will allow for large programs or data instead of just simple test programs that can fit entirely on the AVR. There are many optimizations that can be made, but that can be for later.




RC 2018/09 Index

[viewing Newest] . . . |Older >>| . . . |Oldest|
(view all as one document)


SRAM/XRAM Swapping Working

March 20, 2019

A basic implemention of halloc, hgrab, and hrelease is working! I was able to allocate external memory, put data in it, then recall it later by handle. The system now has 2K of SRAM user heap 'cache', and 64k of XRAM.

	/* This is a basic test of halloc, and handle-based SRAM swapping /*

	char* s = "This is a string";
	
	char * hp;
	char * hp2;
	
	//allocate memory, create a handle for it
	u16 h = halloc(strlen(s)+1); 



	/* HP and HP2 should be the same pointer */	
	hp = hgrab(h);
	hp2 = hgrab(h); //get again

	DMESGF("%x %x\r\n", hp, hp2);

	strcpy(hp, s);  //copy it
	
	/* release both grabs on the item */
	hrelease(hp);  /* should dev ref count in sram */
	hrelease(hp2); /* should copy & destroy the buffer */
	
	char* other = mmalloc(10);  /* allocate memory.  Should 'steal' the pointer that was released above */

	DMESGF("%p\r\n",other); 

	hp = hgrab(h); /* Grab the string by handle */
	DMESGF("%p %s\r\n",hp); /* Should print 'This is a test', and it should be at a different physical address than before.  */



And debug output of the allocator is doing what I expect:
OUTPUT                                    Meaning
-------------------------------------------------------------------------------------------------------------
new handle 8001                           created object
8001 not found in heap                    first grab: object not in internal heap yet
xobject size 18
copy from x                               copy from external memory (is uninitialized garbage)
8001 found in heap                        second grab: object still in heap, just add to refcount
hp 0xb52  hp2 0xb52                       shows both grabbed pointers are same physical address
found handle 8001                         first release
found handle 8001                         second release
last reference, copy to x                 the second release trigger writing to external memory
other 0xb52                               a different malloc took our old physical address (b52 above)
8001 not found in heap                    grab the object
xobject size 18
copy from x                               swap into internal ram
hp b5e This is a string                   string still intact; at a different physical address


There are a lot of optimizations that can be done in the future. The last release doesn't have to trigger a copy to external ram; not until another mmalloc needs memory. If an object is only read and not modified, there does not need to be a copyback. Perhaps a mmalloc can succeed, but if a released object is moved instead of copied back. There are a bunch of scenarios, but I am not going to implemenet any of them until actually needed. I just need to keep them in mind so I don't take the design somwhere where the optimizations become impossible.

[viewing Newest] . . . |Older >>| . . . |Oldest|
(view all as one document)