Integrate recent changes done to the amiga branch. Includes support
for the '40.
This commit is contained in:
parent
036641804e
commit
faf29d9800
|
@ -1,5 +1,5 @@
|
|||
# from: @(#)Makefile 7.3 (Berkeley) 6/9/91
|
||||
# $Id: Makefile,v 1.3 1993/10/30 23:40:05 mw Exp $
|
||||
# $Id: Makefile,v 1.4 1994/01/26 21:00:13 mw Exp $
|
||||
|
||||
COMM= ../net/*.[ch] ../netimp/*.[ch] ../netinet/*.[ch] ../netns/*.[ch] \
|
||||
../netiso/*.[ch] ../netccitt/*.[ch] \
|
||||
|
|
|
@ -0,0 +1,45 @@
|
|||
This version of NetBSD now includes support for the 68040. This version
|
||||
should support both the 68030 and 68040 processors with a single kernel.
|
||||
|
||||
The config option FPSP will include the full Floating Point Support
|
||||
Package to provide emulation of the floating point instructions not
|
||||
implemented by the 68040. If the FPSP option is not used, then a
|
||||
dummy file is included that will cause a panic if any FPSP routine
|
||||
is called. This allows building a smaller kernel specifically for
|
||||
the 68030.
|
||||
|
||||
The FPSP is provided as an object file. The FPSP was ported to gas by
|
||||
Eric Norum (eric@skatter.usask.ca) and is available by anonymous ftp from:
|
||||
ftp.usask.ca /pub/software/fpsp/fpsp_gas.tar.gz
|
||||
Note: Motorola still holds the title and all rights to the FPSP.
|
||||
|
||||
Support for the Progressive Peripherals Incorporated Zeus SCSI interface
|
||||
is also included. If the configuration file does not include support for
|
||||
the A3000/A2091/GVP11 drivers, then including the "zeusscsi" driver will
|
||||
configure the driver to use the sd (disk) and st (tape) devices. If any
|
||||
of the A3000/A2091/GVP11 drivers are configured, then including the zeusscsi
|
||||
driver will be configured to use a second set of scsi devices: rz (disk)
|
||||
and tz (tape). The rz and tz devices have different major device numbers:
|
||||
rz - 5 = block, 9 = character
|
||||
tz - 8 = block, 23 = character
|
||||
WARNING: since the PPI Zeus SCSI uses the level 6 interrupt, the kernel
|
||||
must be compiled with the splbio() macro defined as spl6(). If not,
|
||||
then then random kernel hangs will occur. One bad side effect of changing
|
||||
splbio() is that it will also block the clock interrupts, which can
|
||||
result in incorrect timing. The 53C710 driver (siop.c) also includes
|
||||
support the the CSA Magnum 40, but this has not been tested yet.
|
||||
|
||||
The 68040 MMU implementation is not optimal at this time. It was added
|
||||
in a manner to fit in with the current 68030 MMU setup without needing
|
||||
to completely rewrite the MMU routines. The existing 68030 MMU layout
|
||||
was implemented using a two level table: a segment table, and a page
|
||||
table. The 68040 MMU can only use a three level table. To simulate a
|
||||
two level table, the top level descriptor table is set up and the full
|
||||
level 2 descriptor table is allocated and used as the "segment" table.
|
||||
This results in 9 pages, or 72K bytes, being allocated for the initial
|
||||
page table for each process.
|
||||
|
||||
The reboot command does not work for some reason. It appears to do the
|
||||
reset instruction, but doesn't seem to do anything after that.
|
||||
|
||||
Michael Hitch
|
|
@ -0,0 +1,83 @@
|
|||
The reason I chose 804, thats 709 plus my local version increments since
|
||||
709.
|
||||
|
||||
Ok first let me say that this is just a beta. There are known cosmetic
|
||||
(small) bugs with some of the code. I felt it was necsesary to get
|
||||
this stuff into the public ASAP. For instance the X window people
|
||||
really need to be using the new graphics system. I am very concerned
|
||||
that they have spent alot of time on code they will be re-writing now.
|
||||
I asked them to drop me a note but no one replied.
|
||||
|
||||
Anyway, there are few patches to the main amiga source tree all of
|
||||
which were nec. and proper. Note however that I made a patch to
|
||||
the main sources, sys/sys/ioctl.h had a bug (IOCBASECMD(x) was incorrect.)
|
||||
my code depends on this being right so I included my change.
|
||||
|
||||
I did not get to clean up my include messiness in amiga/cc_* stuff
|
||||
or in grf_cc stuff, however I did switch the grf_* stuff over to
|
||||
the BSD style of users including what they need.
|
||||
|
||||
This release is a major update in the area of graphics. All parts
|
||||
are not fully done yet but they work and work solidly. The interface
|
||||
(grf) for monitors can be considered frozen (we may add cosmetics
|
||||
later but nothing funcitonal.) So that people wishing to write
|
||||
monitor code can do so now.
|
||||
|
||||
If you are going to write a monitor you can use my code as an example
|
||||
it may get complex and overwhelming though because of the complexity
|
||||
of supporting the custom chips. So you may want to start of only
|
||||
with the grf_* stuff and then consult the grf_cc stuff when needed.
|
||||
|
||||
In the area of the ite. I have consolidated all the monitor dependent
|
||||
files into a single ite_std.c file. This was possible due to the
|
||||
new view device (more on that in a little bit) The ite now has
|
||||
support for _underline_ and BOLD attributes as well as continuing
|
||||
support of inverse as before. Becuase of these additions the font
|
||||
programs need to be updated (I added the code in fontdumper and
|
||||
changed the kernel_font.c.distrib to get you started.) The only
|
||||
thing that gets added is kernel_font_(baseline|boldsmear) attributes.
|
||||
|
||||
All known ite scrolling bugs and repeating bugs are fixed in this version.
|
||||
(actually there is one, but I need to get this out.)
|
||||
|
||||
The new ``/dev/view??'' are the character devices that replace the
|
||||
old ``/dev/grf''. These new psuedo-devices represent a single monitor
|
||||
screen. They go through the new grf interface in a portable way.
|
||||
All programs will interface graphics on Amiga-BSD through these devices.
|
||||
(ite does)
|
||||
|
||||
I will shortly (a day or two) be releasing some example code on how
|
||||
to program with the view?? devices. For now let me give you an
|
||||
example on how to map the bitmap data into your process with the
|
||||
view device.
|
||||
|
||||
bitplane_data = mmap (0, size, PROT_READ|PROT_WRITE, MAP_FILE, fdesc, 0);
|
||||
|
||||
``size'' is the number of bytes of bitmap data to map. ``fdesc'' is the
|
||||
file descriptor returned from open().
|
||||
|
||||
There are some major bugs with mmap()'ing the 709 grf device. The largest
|
||||
being the allowing of processes to quickly vm_fault the kernel. (one access).
|
||||
These are gone now.
|
||||
|
||||
Support for the custom hardware is now in the kernel, things such as a
|
||||
``/dev/audio'' will probably be written. Its easy now. Any way, the ite
|
||||
bell now goes through this interface.
|
||||
|
||||
Some missing stuff: mouse pointer. sorry sprites are not retargetable*
|
||||
X windows is however and when that is done you will get your pointer
|
||||
back (exactly what was it doing there anyway?)
|
||||
|
||||
A screen blanker. This is a very easy one I hope to have installed
|
||||
into the system in a upcoming patch (maybe 20 lines of code needed)
|
||||
Again I need to get this out now so it was skipped.
|
||||
|
||||
I hope everyone enjoys the new code features. Now i can try and get
|
||||
emacs working...
|
||||
|
||||
Chris...
|
||||
|
||||
(this was written after a 20 hour stint to try and finalize stuff please
|
||||
forgive mispellings and improper grammar. thanks)
|
||||
--
|
||||
(* spites could be but I didn't make them.)
|
|
@ -0,0 +1,54 @@
|
|||
12/6/93 7:12am.
|
||||
|
||||
Ok here are the latest patches to the CC console and graphics subsystem.
|
||||
|
||||
- iteconfig: is a configuration program that can dynamically change
|
||||
your console's settings. It has been placed under GNU
|
||||
Copyleft so the source is included. You will have to whip
|
||||
a Makefile together to build it---I use the bsd system,
|
||||
and mine just wouldn't make (no pun intended) sense to include.
|
||||
|
||||
- cc-fixes.diff: these are the diffs necsessary to use the iteconfig program
|
||||
and you should probably apply them to your 713 kernel sources.
|
||||
I expect Markus will include them in the next release.
|
||||
|
||||
|
||||
Enjoy.
|
||||
|
||||
: Whats fixed
|
||||
|
||||
overscan: it works but is a little korny sometimes sorry. The only
|
||||
bug I found so far is with an width of 642 it just doesn't center correctly.
|
||||
I also am not happy that my overscan abilities do not match that of C='s.
|
||||
I will perhaps look into there method at some later time. If your curious
|
||||
C= is offseting the bitmap pointers by -2 bytes and doing funky things with
|
||||
the ddfstart under 2.0+ so that they can get a tighter fit. You'll probably
|
||||
notice that I have to move the screen left at certain widths (644+,674+,708+)
|
||||
This is becuase datafetch must be a multiple of 4 and must also not cross the
|
||||
$d8 boundry, what C= is doing is offseting the bitmap pointers by -2 and
|
||||
delaying display so they can get widths of multiples of 2 (word). I suppose
|
||||
I have just figured out how to do it while typeing this README...so next time
|
||||
we should have this ability.
|
||||
|
||||
colors: not that anyone noticed but the /dev/view device's colormap functions
|
||||
were disabled by Markus. They are now implemented in a cleaner fashion so
|
||||
they can be used. iteconfig uses them to allow you to change the screen
|
||||
colors.
|
||||
|
||||
2024: 1024x800 sorry this mode still appears to be dead. I haven't had the time
|
||||
to look into it. It is enabled however and a quasi-functioning 1024x800x2 (NOTE
|
||||
only depths of 2) can be made to display through iteconfig if your kernel allows.
|
||||
|
||||
AGA: someone send me a newer computer :^)
|
||||
|
||||
ECS: ECS PAL is now working so that people with NTSC machinces can use it.
|
||||
|
||||
X: Why is it that as the author of the Custom chips code I haven't received one
|
||||
letter from these people? I wonder if they relize that using the view device
|
||||
as it was designed will allow people to have a console open and X at the same
|
||||
time... HEY X PEOPLE. there is no need to use the /dev/console for X try
|
||||
/dev/view01. (Actually I did receive one from Philip asking for my source
|
||||
which I gave. no questions asked. no replies received.)
|
||||
|
||||
Again Enjoy,
|
||||
Chris.
|
|
@ -0,0 +1,96 @@
|
|||
From leland@wacky.acet.org Mon Nov 22 17:48:45 1993
|
||||
Received: from mwunix.mitre.org by chsun.eunet.ch (8.6.4/1.34)
|
||||
id RAA09132; Mon, 22 Nov 1993 17:48:41 +0100
|
||||
Received: from wacky.acet.org.acet.org ([192.188.104.18]) by mwunix.mitre.org (5.65c/SMI-2.2)
|
||||
id AA13343; Mon, 22 Nov 1993 11:46:42 -0500
|
||||
Received: by wacky.acet.org.acet.org (4.1/SMI-4.1)
|
||||
id AA06945; Sun, 21 Nov 93 16:30:44 EST
|
||||
Date: Sun, 21 Nov 93 16:30:44 EST
|
||||
From: leland@wacky.acet.org (Robert Leland - PSI)
|
||||
Message-Id: <9311212130.AA06945@wacky.acet.org.acet.org>
|
||||
To: mw@chsun
|
||||
Subject: SCSI tape driver.
|
||||
Cc: leland@wacky.acet.org
|
||||
Status: OR
|
||||
|
||||
I would like to change the way scsi tape /dev/rst maps the minor device.
|
||||
This will allow for the selection of more than just one density of tape.
|
||||
|
||||
Also though my Archive Viper 2525 drive can Read QIC-24 Tapes generated by
|
||||
a sun tape drive, it has to do this by traversing the tape several times
|
||||
until it figures it is a QIC-24, I would rather not wear out my tapes!
|
||||
This change would allow all type drive types to specify 3 additional densities, other than
|
||||
the default.
|
||||
----------------------------- The Bottom Line(first)------------------------------
|
||||
People currently using
|
||||
/dev/rst0, rts1 .... rst15
|
||||
would remain uneffected, regardless of tape drive type.
|
||||
|
||||
People using the Exabyte type tape drives including Python that normally use
|
||||
/dev/rst16 , /dev/rst32
|
||||
would use instead:
|
||||
/dev/rst32, /dev/rst64
|
||||
(See below for more details)
|
||||
-------------------------------------------------------------------------------------
|
||||
Current
|
||||
* Specific to Exabyte:
|
||||
* minor bit 4 [b1bbbb] (aka /dev/rst16) selects short filemarks
|
||||
* Specific to 8mm Drives.
|
||||
* minor bit 5 [1bbbbb] (aka /dev/rst32) selects fix block mode, 1k blocks.
|
||||
*
|
||||
|
||||
Minor Device: --------------------------------+
|
||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|
||||
+---+---+---+---+---+---+---+---+
|
||||
^ ^ ^ ^ ^ ^ ^ ^
|
||||
| | | | | | |___|_____ Unit Number
|
||||
| | | | | |_____________ NoRewind
|
||||
| | | | |_________________ HiDensity
|
||||
| | | |_____________________ Short FileMarks
|
||||
|_________________________ Fix block mode 1K
|
||||
|
||||
- - - - - - - - - - - - - - - - - - - - - - -
|
||||
Proposed
|
||||
* Specific to Exabyte:
|
||||
* minor bit 5 [bb1bbbbb] (aka /dev/rst32) selects short filemarks
|
||||
* Specific to 8mm Drives.
|
||||
* minor bit 6 [bb1bbbbb] (aka /dev/rst64) selects fix block mode, 1k blocks.
|
||||
|
||||
Minor Device: --------------------------------+
|
||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|
||||
+---+---+---+---+---+---+---+---+
|
||||
^ ^ ^ ^ ^ ^ ^ ^
|
||||
| | | | | | |___|_____ Unit Number
|
||||
| | | | | |_____________ NoRewind
|
||||
| | | |___|_________________ HiDensity
|
||||
| |_________________________ Short FileMarks
|
||||
|_____________________________ Fix block mode 1K
|
||||
|
||||
|
||||
Advantages: More similar to sun mapping, Keeps bits together.
|
||||
Disadvantages: Possiblely some initial confusion.
|
||||
- - - - - - - - - - - - - - - - - - - - - - -
|
||||
Alternate Proposed
|
||||
I would rather keep the density bits together but we could...
|
||||
Split the bits used for density Use bits 3 and 6:
|
||||
|
||||
Minor Device: --------------------------------+
|
||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|
||||
+---+---+---+---+---+---+---+---+
|
||||
^ ^ ^ ^ ^ ^ ^ ^
|
||||
| | | | | | |___|_____ Unit Number
|
||||
| | | | | |_____________ NoRewind
|
||||
| | | | |___________________________________ HiDensity
|
||||
| | | |_____________________ Short FileMarks |
|
||||
| |_________________________ Fix block mode 1K |
|
||||
|_________________________________________________|
|
||||
|
||||
This would mean that other users would remain uneffected.
|
||||
-----------------------------------------------------------------------------------------
|
||||
This change will also benefit other tape drives, so that specific densities can be specified.
|
||||
Could really use three bits for density, however It's nice to have a spare bit for the future.
|
||||
|
||||
|
||||
-Rob
|
||||
|
||||
|
Loading…
Reference in New Issue