Clean up deleted files.
This commit is contained in:
mycroft
parent
108e1a3d55
commit
c9cd559100
|
|
@ -1,25 +0,0 @@
|
|||
The HP300 version uses a kernel which is loaded into the range 0xfffxxx... but
|
||||
is linked for range 0x000.. This causes the problem that with switching the
|
||||
MMU to the mapped kernel, the PC becomes invalid. The HP version solves the
|
||||
problem by mapping 1:1 the last page of physical memory into virtual memory.
|
||||
|
||||
On the Amiga, there *is* memory at PA 0x0, so we might as well use it, causes
|
||||
much less grief and weirdness in locore.s. However, since memory down there
|
||||
is CHIPMEM, inherently slower than FASTMEM, and badly needed for framebuffer
|
||||
storage space, we'll copy the kernel over to the first bank of FASTRAM, and
|
||||
when enabling the MMU, the kernel will execute in FASTRAM, although the PC
|
||||
stays the same.
|
||||
|
||||
This strategy has the big advantage (compared to the solution in Amiga MACH)
|
||||
that we can link the kernel absolutely to VA 0, for all memory models, since
|
||||
we'll never execute the kernel in the FASTMEM space while the MMU is turned
|
||||
off.
|
||||
|
||||
This strategy also means, that we don't have to relocate any addresses while
|
||||
bootstrapping the mmu!!
|
||||
|
||||
Initialization of the MMU happens in amiga_init.c. This file is quite a mess,
|
||||
I have generated it trying to understand what's happening in the hp300 locore.s
|
||||
file. I think, it should be able to handle MMU initialization much cleaner
|
||||
now that we don't have to think about relocation until the MMU is enabled.
|
||||
If you need your daily bit of horror, take a look at amiga_init.c...
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
There are probably dozens of bugs, keep in mind this is the first release :-)
|
||||
|
||||
Those I'm aware of:
|
||||
- the console has some scrolling bug. This shows in the ircII client, where
|
||||
incoming message lines just `scroll' in the last displayed line, instead
|
||||
of scrolling the entire display.
|
||||
- the dma code is currently broken. I'd really like to get this going again,
|
||||
it's scribbling over innocent memory at the moment, and I think there might
|
||||
be some bugs in the A3000 Service Manual describing some registers, we'll
|
||||
see...
|
||||
- nfsd and mountd crash regularly when going to multiuser mode...
|
||||
- the console seems to have some problems displaying text when parity is
|
||||
enabled. This shows in a distorted login-prompt (multiuser mode).
|
||||
- the vt200 emulator is really far from perfect, and needs a lot more work
|
||||
to be honestly called a vt200 (or vt320 even) emulator.
|
||||
- 8bit characters are all displayed as ^@. Problems could lie in wrong tty
|
||||
settings or the ite driver.
|
||||
- although autoconfig information is passed into the kernel and the hardware
|
||||
table is generated, no I/O-space is currently allocated in kernel VM for
|
||||
boards. This will probably be one of the first things to fix or nobody is
|
||||
able to access their boards under BSD ...
|
||||
- sun-style disklabels are not yet supported.
|
||||
- disklabels can't be written back to disk. You'll have to configure your
|
||||
drives under amigados (with hdtoolbox), and just format the partitions
|
||||
under BSD. I think this is a tolerable limitation.
|
||||
- the clock runs much too fast. I have an idea the kernel might think in
|
||||
60Hz units, when the clock really runs at 100Hz, I'll look into this.
|
||||
- there's currently no provision for reading the realtime-clock, so time
|
||||
is always set using the last modification date of the mounted root
|
||||
filesystem.
|
||||
- severe crash after dumping to disk...
|
||||
|
||||
to be continued...
|
||||
|
|
@ -1,121 +0,0 @@
|
|||
How to install BSD on your Amiga:
|
||||
--------------------------------
|
||||
|
||||
*Please* (re)read the README.amiga file, and make sure your system is
|
||||
supported by the current kernel.
|
||||
|
||||
Since BSD doesn't yet have a floppy driver, and you'll need a root fs
|
||||
to start using commands (chicken and egg problem..) to make your own
|
||||
fs, installation of the root fs is a bit hacky...
|
||||
|
||||
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|
||||
> We copy a binary image (8M) of the root fs directly to the place on <
|
||||
> your harddisk. This is an extremely dangerous thing to do, since if <
|
||||
> you get the offsets wrong, you'll destroy data on other partitions of <
|
||||
> the drive! <
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you don't feel like risking the life of innocent data on your disk,
|
||||
better stop installing now, and wait until installation gets safer in
|
||||
the future!!!
|
||||
|
||||
|
||||
Ok.. if you're reading on, start up hdtoolbox, and create some partitions
|
||||
for use by BSD. You'll have to at least create two partitions:
|
||||
|
||||
o a root partition:
|
||||
Must have FileSystem: Custom File System
|
||||
Identifier: 0x42534452 (`BSDR')
|
||||
Reserved begin: 0
|
||||
end: 0
|
||||
Use custom boot code: NO (ie. no checkmark)
|
||||
FS block size: 512
|
||||
You don't have to check Automount, the partition could only
|
||||
confuse AmigaDOS.
|
||||
|
||||
o a swap partition:
|
||||
Must have FileSystem: Custom File System
|
||||
Identifier: 0x42534453 (`BSDS')
|
||||
Reserved begin: 0
|
||||
end: 0
|
||||
Use custom boot code: NO (ie. no checkmark)
|
||||
FS block size: 512
|
||||
You don't have to check Automount, the partition could only
|
||||
confuse AmigaDOS.
|
||||
|
||||
|
||||
You might also add a /usr partition, for example on BSDD:
|
||||
Must have FileSystem: Custom File System
|
||||
Identifier: 0x42534444 (`BSDD')
|
||||
Reserved begin: 0
|
||||
end: 0
|
||||
Use custom boot code: NO (ie. no checkmark)
|
||||
FS block size: 512
|
||||
You don't have to check Automount, the partition might only
|
||||
confuse AmigaDOS.
|
||||
|
||||
|
||||
Other settings (like MaxTransfer and Mask) are ignored.
|
||||
|
||||
Now, you'll have to find out about the exact block start address and length
|
||||
in blocks of the BSDR fs (BSD will find out about the data of the other
|
||||
partitions once it's started up). Go into "Change Drive Type" menu, and
|
||||
write down the "Blocks per Cylinder" value it shows you for this drive. Then
|
||||
go into the "Partition Drive" menu, select your BSDR partition, enable
|
||||
"Advanced Options", and write down the "Start Cyl" and "End Cyl" values.
|
||||
|
||||
Doing "Blocks per Cylinder" * "Start Cyl" gives you the block start number
|
||||
of the BSDR partition, doing "Blocks per Cylinder" * ("End Cyl" - "Start Cyl")
|
||||
results in the length of the partition in blocks. You'll need these values
|
||||
to install the root fs onto the drive, so please write them down, and PLEASE
|
||||
make sure you calculated them right, since if not, you'll scribble anywhere
|
||||
on the drive, and that just might be.. (insert worst imaginations..).
|
||||
|
||||
**************************************************************************
|
||||
The rootfs has a length of ~8M, 16448 blocks. Your root fs must have at
|
||||
least (!) the same amount of blocks. You don't have to make it exactly
|
||||
16448 blocks though, a task that could even be impossible if the number of
|
||||
blocks per cylinder on your drive is not a divisor of 16448.
|
||||
**************************************************************************
|
||||
|
||||
Now you're almost ready to do the installation. Unzip the distributed rootfs.gz
|
||||
file (you'll need 8M of free space on your amigados partition for this!), and
|
||||
then do:
|
||||
|
||||
filetodev {START_NUMBER} 16448 rootfs scsi.device {UNIT} 1000
|
||||
|
||||
with:
|
||||
{START_NUMBER}: above calculated block start number
|
||||
{UNIT}: the scsi unit you're installing on, 0-6
|
||||
|
||||
|
||||
The filetodev program is included in the bffs11.lzh archive, and was written
|
||||
by Chris Hooper (cdh@mtu.edu).
|
||||
|
||||
|
||||
|
||||
How to start BSD
|
||||
----------------
|
||||
|
||||
You start BSD with a loader program from AmigaDOS. This loader is called
|
||||
`loadbsd', and it takes as parameter the kernel file, normally vmunix.
|
||||
|
||||
So,
|
||||
|
||||
loadbsd vmunix
|
||||
|
||||
will (try to...) boot BSD. The kernel as distributed prefers to boot from
|
||||
SCSI unit 6. It will probably boot from other units as well (can't test
|
||||
this at the moment, since I don't want to repartition my other drives). If
|
||||
you run into problems (ie. BSD says it can't mount the root filesystem),
|
||||
you'll have to recompile the kernel. Please see the RECOMPILE file for
|
||||
how to do this.
|
||||
|
||||
|
||||
What about /usr ?
|
||||
-----------------
|
||||
For the first distribution of the kernel, I decided not to distribute
|
||||
binaries for the /usr filesystem. Simply, because /usr is huge compared
|
||||
to root, and a.out headers are likely to change in the future, rendering
|
||||
a distributed /usr filesystem almost useless.
|
||||
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
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
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
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.)
|
||||
Loading…
Reference in New Issue