Post by hydrophilic on Dec 8, 2014 6:33:18 GMT
OMG, so many issues...
Now I think I understand PsXXX, thanks for clarification.
As far as relocation (etc.), I think I understand now:
* relocatable = moveable within a 'bank'
* outbankable = moveable within a 'bank' and/or across 'banks'
* purgable = deleteable from RAM if read-only and a 'backup' exists somewhere else
As far as 'writeable' goes, your method of CRC seems like it would work semi-reliably... I mean to be 100% bullet-proof it would need to run every time before a new task (perhaps even IRQ) begins... but your periodic / round-ribbon fashion seems like a good compromise between 'bullet-proof' and practicality.
As far as 'executible' goes, it seems a very lame (but not totally useless) form of protection... basically it will prevent the OS from starting a program in 'non-executible' memory, but of course once a program runs it could JMP / JSR *anywhere* due to lack of hardware protection. I guess something is better than nothing -- IF it can be implemented efficiently. Hopefully the OS won't spend a lot of time switching threads/processes, so it sure seems possible!
Almost forgot! So software does not use *real* pointers (directly) but instead gets them by calling some OS function? What function is that? Also here is a summary of my understanding:
* Live 2-byte (6502 pointer in a known/implied 'bank')
* Near 3-byte (6502 pointer + a 'bank' number [could be a KERNAL Bank, an REU Bank, or perhaps a 'file bank')
* Far 4-byte (Near + type [system RAM, REU RAM, disk file, etc.])
* External 5-byte (Network = Near + Net_Node?)
Now I think I understand the MemXXX, thanks for clarification... it seems like we agree that a 'locked/shared' memory remains 'locked' as long as one of the processes are active. Just to be sure, you give an example of one process sharing memory with another process then terminating. So I'm thinking that since the memory is 'locked' and another 'active' process is running (which shares the memory), it will remain in 'active' memory. In other words, I think we have the same idea, but using different methods of description.
You are correct, VDC does not have raster interrupt (for shame), but can be emulated with tricky CIA programming... it is not supported by the KERNAL, but if you want to invoke Raster-type interrupts at all in your OS, then you should support this for VDC too... or else you would have to fork the OS to have VIC-II only stuff. Forking the OS may be the most practical, but surely not the ideal solution.
We agree each IRQ routine needs a head and tail vector
Well you got me in a technicality in regards to forked-files on 'raw' media like SD, CD, DVD, Blu-Ray... I was thinking you could not *directly* implement VLIR-type files on these media (due to no direct block-read/write)... but if you want to invoke SubDirectories to store each fork as a separate file, then yes that would work. Brilliant! How exactly would that work? Maybe a 'file' (from view of OS) called GeoPaintImage which is stored as directory 'GeoPaintImage' and containing files named 'Fork00', 'Fork01'... ?
And just so we are clear... each 'fork' in your VLIR2 format points to the start of REL-type 'side-sectors' so that you have random access to any byte within that fork? That's pretty cool, so I hope that is what you mean! (And NO, this was not clear from your earlier posts... but who cares if we gain an understanding now?)
Ha! You say the concept of 'forked system resources' is orthogonal to the VLIR2 structure. I think that is funny (in a sad misunderstanding kind of way) because if I understand correctly, the OS-Forked-Resource is actually parallel to your VLIR2! (Funny because parallel is *opposite* of orthogonal.) In other words, they both accomplish the same thing (segregate data into multiple streams) although implemented by different methods (OS/pointers or Disk/files).
Well regardless of how you say it, I agree that a 'forked' data steam (OS and/or FS) is a powerful and useful technology.