Re: A83: Shells on the 83+

[Prev][Next][Index][Thread]

Re: A83: Shells on the 83+


Robin Kay wrote:
> will gradually decrease as more people get 83+'s and there are more 83+

  I agree that the 83+ has greater potential than it is being let on to,
but, as a community, the 83 will be associated with a 83+ for a long
time to come. The 83 might be phased out, but this generation of user
will have an 83 already. People will constantly want 83+ = 83. The
portability will not decrease until the 83 is phased out of the
community, not out of production...

>      Task Switching - Based on my experience with lightweight

  The allocation of heap for data storage has been around for a while.
The 68k calcs all deal with memory this way. I beleive this would be
feasible, but you must take into account that you will have to have
enough space for every programs heap and unarchiving the program. I
would say that most programs would be small enough to not have a problem
with this. I have more of a problem with the need for a task-swapping
system. What purpose would it serve, other than a nifty feature? And I
admit that it would be cool, but still, most people can handle quitting
a program and running another.

>      Event/IPC Model - Since the shell uses the interrupts it should

  To me an event handler is not a library routine that is run after a
timer resets. A event handler to me would be a interrupt that keep track
of different events, such as key_down and then called a location that
was associated with that event. It could be of use, but I lack an
opinion on this.

>      Virtual Directory Structure - The PDM could be used to store

Again, this is just a nifty feature that would take ram... there is
nothing wrong with all the programs existing in one "folder". That is
why it is a module for ion and not built in.
 
> 83, just using the archive space as a backup storage area. RAM should be
> used more as temporary storage area and the FLASH-ROM more as the
> hard-disk.
[snip]

  I have an 89, and I don't use the flash rom for anything that will be
moved on and off a lot. I don't like the idea of wearing out the flash
rom...

[...unsnip]
> However I still don't understand enough about
> reallocation to try and write that part of it. Program's origins are set
> at 9327h, either when a program is run it is copied to that address in
> memory before it is run or any instructions in the program that use
> absolute addressing are changed at runtime to reflect it's location in
> memory.

The way to do this is to set the origin to $0. Every absolute address
then becomes a offset from the beginning of the program. You could do
that for any newly compiled program. BUT, you still would have to "walk"
the program. You'd have to find all the abosulte opcodes and still not
screw up data, etc.
Otherwise, you would have to know where every reference is. Or, keep a
table and change all the absolutes to a macro that referenced the table
instead instead of absolutely... either way, it is a pain. The z80 lacks
enough relative opcodes.

-- 
Scott "_Wrath_" Dial
wrath@calc.org
ICQ#3608935
TimeCity AI Guy II - www.timecity.org
Member of TCPA - tcpa.calc.org
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
Follow-Ups: References: