just getting my feet wet with iProject_3. Added clearmem command, which
calls clearallmemory function from the MMU. Now, we need to get the
memory display to show all memory - not sure how I want to do that yet.
Maybe just one large running list?

I think I might remove some functionality from memory. Let the MMU
manage everything and the "system memory" just allow to be written too
or read from, but does not care about clearing itself out or anything
like that... or maybe it does care but in smaller chunks than "all"
changed clearAllMemory to call a function called clearPartition, which
clears a memory partition. Trying to modularize some code out of memory.
ok...removed everything from host/memory.ts except for read, write and
size. I have decided (hopefully not incorrectly) that the memory module
acting as hardware should just read and write (and maybe report its
size). I will let the MMU handle errors while reading or writting, and
anything else, including display. Which, with all these display stuff
wouldn't it be fun to create a object like "display" ? But, not now.
added schedule to index file (whoops - still a shell tho) and added the
ability to change the quantum -- which we are doing nothing with at the
moment. Was going to do the round robin stuff first, but realized how do
I test it? So, next push will be the ability to load 3 progs into
memory...push after will be the ability to display.
scheudle shell file, created an object memoryranges to hold needed info
for allocating and deallocating memory locations. Interesting ... the
.js file was not created even tho it compiled? Using GULP ... curious
how this plays out, I am going to roll with it for a few minutes.
Updated index file for the new files (yep, even the one that does not
exist).
and now the damn thing shows up...
added ability to allocate and deallocate memory to a PCB, basically
provide the PCB its base and limit numbers. Need to now work on a way to
write these to memory and display the results.
changed write to require the PCB for the base and limits to write too.
Not sure if that is best, but it is how I am doing it for now. Also
cleaned up the display and clear memory functions to allow for the
changes with PCB...need to catch the error of out of memory during load,
and for some reason not writing memory contents to display...think I
just commented it out until I solved the base / limit stuff.
so, I can load two but not the third, it freezes, it should freeze on
the fourth since I am not catching out of memory errors yet. Hmm, must
be a little +1 issue. However, for now we got the display stuff working
and ability to load 2 programs into memory.
fixed the third guy not loading, little +1 type error. Now to toss a "NO
FREE MEMORY" error.
added out of memory irq -- everything seems good however, run is now
broken. I suspect because of how it passes info between queues... Right
now we can load 3 programs into memory and display on the screen. Nice!
so, got the display working kinda... pretty buggy, something is
happening with when I type run it wants to run the latest PID not the
one I put... shouldn't be a big problem. Otherwise, got it to load the 3
programs and update the display accordingly. Also trying to keep track
of the active program globally. Other changes are the memory read, not
accepts a pcb to get the base and limit from.
still latching onto the last pcb state and not the one I am "running"
however the display is getting better.
it was reading from the first block always because I forgot to add the
base when "reading"... However, found a big bug with the way I am taking
in the programs. I cannot pass numbers larger than 99! I know why,
because I am taking in chunks of 2, looks like I will just have to split
on spaces and if someone passes a bad program well, shame on them! Shit,
glad I caught that ... wonder if it will be caught during iProject 2
testing ...
Raised the quantum to a high number because I basically want to
implement RR as FCFS to just get the 3 in memory to run one after the
other. After that, I can tweak the quantim and hope it works well. That
will also give me a head start to iP4 as FCFS will basically be created.
I added an enum to scdeudle of what type of schedule this will be --
also created a few functions "go" which calls the function of whatever
the ENUM type is and RR since we are trying to make a round robin
schedule!
good pushing point. changed global variable to make quantum very high so
it is like fcfs, added functions in schedule to get the scheduling going
and added runall to shell. Right now it works, but we are running into
branching issues - we are branching to incorrect addresses...shouldn't
be a difficult fix.
RUNALL WORKS! There are a few minor bugs I found while doing the debug
to figure out why I could say: load one program type run 0 and it would
work. If I loaded two or three it would fail at run 0 or runall...One of
my hard coded values for 8D inst did not get updated to the global
_ActiveProgram pcb and I was taking the wrong PCB info off the resident
queue! Awesome. Now to fix a few other minor bugs I found...Like do not
think my counter refreshes for every new PCB. Once that works, we can
try to implement the context switch...right now we just have FCFS :)
made a function krnProcessEnd in kernel that will deal with all the end
of process stuff... added a comment in schedule, I have it ready to pop
another pcb off BUT, the way I deal with PCB END IRQ ... we might not
have too... That is where it checks for another job.
context switch function done. that seemed a bit too easy, I suppose when
we add more complex stuff it will be more difficult. It will need to
handle priority and all... I suppose getting that ready now will be a
good idea, since it is built off the assumption we are doing
roundrobin...
so...our PCB display is the resident queue, not the ready queue, but it
is in real time. Leaving for now, but added some commented out code to
attempt the roll over from resident to ready.