[Oberon] RISC5

Aubrey.McIntosh at Alumni.UTexas.Net Aubrey.McIntosh at Alumni.UTexas.Net
Fri Apr 18 19:14:28 CEST 2014


IMPORT SYSTEM

is a directive to the compiler so that it can do unsafe things.  All of the
procedures are documented in the documentation that comes with the system.
 These are things like type coercion, bit shifts, and a few other very low
level things that are done when talking to the hardware.

I think it is very open.  It is documented everywhere, and has been part of
Wirth's languages for a long time, possibly as early as Modula-2.

It's primary purpose serves documentation and safety.  The compiler will
not emit tricky code unless SYSTEM is in the import list, and you can
quickly search for the string "SYSTEM" + "." to locate everywhere in the
source where these tricks are used.




On Fri, Apr 18, 2014 at 11:05 AM, eas lab <lab.eas at gmail.com> wrote:

> Thanks for the pointers.
>
> Today I tried to trace the M.P route of how eg. ET.* gets to the VGA-port.
> [Like you CAN trace how http* arrives via a serial-port-modem ...etc.]
> For ETH Oberon (2.4.3) for Linux x86   and
> V4/oberon-1.7.02/Source  and my
>  source1, 2, 3.arc  which I guess comes from Native;
> in all cases the path is concealed at: IMPORT SYSTEM.
> Some of us resent that. Oberon may have had a better following if
> it had been open. OTOH perhaps that was not possible?
>
> == Chris Glur.
>
>
> On 4/17/14, Jörg <joerg.straube at iaeth.ch> wrote:
> > Chris
> >
> > 1) The RISCv5 machine has a memory of 1 MByte = 000000H.. 0FFFFFH.
> >    This memory is used to hold your code and store your variables.
> >    A dedicated region at the high end of this memory (namely from
> >    0E7F00H .. 0FFF00H) is called "framebuffer"; this memory region
> >    is used to store all pixels that are displayed on the screen.
> >
> > 2) The module "Display.Mod" provides all low layer routines to
> >    store pixels into this memory region. E.g. the procedure
> >    Display.Dot(col, x, y, mode: INTEGER) "draws" a dot at location
> >    (x/y). But it does not actually draw the point but "just" stores
> >    a bit in this dedicated "framebuffer" memory.
> >
> > 3) In parallel, the video driver "VID" (written in Verilog) permanently
> >    reads this special framebuffer memory and copies all bits over and
> >    over again to the VGA monitor. The whole framebuffer memory
> >    (96 kByte) is copied 70 times per second to the monitor.
> >
> > Hope this helps.
> >
> > br
> > Jörg
> >
> > -----Original Message-----
> > From: Paul Thomas Melville [mailto:ptmelville at gmail.com]
> > Sent: Donnerstag, 17. April 2014 13:46
> > To: ETH Oberon and related systems
> > Subject: Re: [Oberon] RISC5
> >
> > On Thu, Apr 17, 2014 at 10:58 AM, eas lab <lab.eas at gmail.com> wrote:
> >
> >> The hidden/mysterious part for me is the display/textFrames.
> >> Does V5 drive standard VGA?
> >> Where's the code showing;
> >>   VGA -> FrameBuffer -> ETHOviewer.
> >
> > You can find information in section 9.1, 4.5 and 17.2.4 of Project
> Oberon.
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>



-- 
Aubrey McIntosh, Ph.D.
211 E. 5th St.
Morris MN 56267
(512)-348-7401
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20140418/acf2fed5/attachment.html 


More information about the Oberon mailing list