Integrate recent changes done to the amiga branch. Includes support

for the '40.
This commit is contained in:
mw 1994-01-26 21:00:13 +00:00
parent 036641804e
commit faf29d9800
5 changed files with 279 additions and 1 deletions

View File

@ -1,5 +1,5 @@
# from: @(#)Makefile 7.3 (Berkeley) 6/9/91 # 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] \ COMM= ../net/*.[ch] ../netimp/*.[ch] ../netinet/*.[ch] ../netns/*.[ch] \
../netiso/*.[ch] ../netccitt/*.[ch] \ ../netiso/*.[ch] ../netccitt/*.[ch] \

View File

@ -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

View File

@ -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.)

View File

@ -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.

96
sys/arch/amiga/README.st Normal file
View File

@ -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