Article View: bit.listserv.coco
Article #43658re: 68340 upgrade
From: Jesse Oberreuter
Date: Fri, 12 Nov 1993 21:40
Date: Fri, 12 Nov 1993 21:40
63 lines
4139 bytes
4139 bytes
On Fri, 12 Nov 1993, Brian (B.C.) White wrote:
> How do you emulate an MMU?
Kinda messy, but for what I want to do, each module effecively never
terminates. Either way, I was going to need some scheme for mapping a
HUGE virtual module space (2^64 bytes minimum) into an arbitrary space.
I'll probably do this w/ indirect pointers. When a routine needs to call
something new, it will pass that address on to the kernal. The kernal
will allocate a pointer, find the requested module in virtual space, place
it somewhere in real space, and then set the allocated pointer to that
address. It is up to the running module, then, to go through the pointer.
If the kernal runs out of real space, it can change the value of that
pointer to a trap routine, and then swap the memory out. If the running
module tries to access that pointer, it ends up in the trap routine that
replaces the memory... A full explaination of how it all works would not
even being to fit here (this is a on object oriented, distributred,
machine independent OS!) W/ out a real MMU, keeping fragmentation down and
stacks from colliding is the challenging part. I figure I'll allocate
stacks by 4k or something, and have them just wind their way through RAM,
w/ each call making sure there is sufficient space, and allocating/moving
to more if necessary. If fragmentation becomes a problem, it would be
interesting to try using DMA to slide blocks that aren't in use around :).
I can't emulate an access violation w/out really slowing things down, but
as long as the local assembler knows what its going, this doesn't happen :)
>
> > Gifshow and iffshow are broken now ... probably a memory mapping
> >problem? If someone wanted to send me the source, I might be willing to
> >fix them. All of my direct screen write code still works!
>
> What is the problem? Does it die with a privileged instruction violation,
> or do the colors just not work right? The version of KWindows that came
> with the 340 has a big bug in it when dealing with Palettes. It seems to
> only take effects if the screen having the changes made is currently
> visible.
Priveledged instruction violation, I think. I noticed wierd palette
stuff from other applications though. I understand that there is a fixed
windio coming soon. It isn't a big concern to me, I just didn't know if
anyone else had noticed it.
> > The new ROMS try to boot from my HD before it is ready (Maxtor
>
> The MM/1 should fail and try again. Mine can do this up to three times
> before succeeding. What is wrong with Break? It works just fine for
> me.
I'll check the HD boot again tonight. My old break (off of the
distribution disks not out of ROM?) just locks the computer and does a
little screen magic... My HD has always had a hard time settling in.
Sometimes it takes right off, other times it goes :access, access, access,
... ok! here we go! Once it is happy, though, it runs flawlessly. I
probably should have sent it in before the year was up, but I thought it
might have been a problem w/ my MM1 (I'd been running w/ a bad PAL before
the upgrade came!)
--
Jesse Oberrueter (KB7PSG)
joberreu@seattleu.edu
kb7psg@n7hfz.wa.usa.na
"For the world is hollow, and I have touched the sky!"
Technical Details
Message-ID:
<Pine.3.07.9311121310.B25119-c100000@bach>Path:
arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!paladin.american.edu!auvm!SEATTLEU.EDU!joberreuShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 110568,c3eaf30d8a152460 X-Google-Attributes: gid110568,public X-Google-ArrivalTime: 1993-11-13 08:46:20 PST Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!paladin.american.edu!auvm!SEATTLEU.EDU!joberreu Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.coco Return-Path: <@AUVM.AMERICAN.EDU:COCO@PUCC.BITNET> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <Pine.3.07.9311121310.B25119-c100000@bach> Date: Fri, 12 Nov 1993 13:40:10 -0800 Reply-To: Jesse Oberreuter <joberreu@SEATTLEU.EDU> Sender: COCO - Tandy Color Computer List <COCO@PUCC.BITNET> From: Jesse Oberreuter <joberreu@SEATTLEU.EDU> Subject: re: 68340 upgrade In-Reply-To: <9311121421.AA24093@bach.seattleu.edu> Lines: 62