[comp.sys.amiga.misc] Virtual memory for Amiga!

peterk@cbmger.UUCP (Peter Kittel GERMANY) (03/25/91)

Cited from an ad about harddisk controllers in the German magazine
"Kickstart" (April issue, backpage):
In the course of a severe software revision, EVOLUTION sets another
milestone of power. By using the MMU, as present on most 68020 and
all 68030 cards, you may use as much harddisk storage as you want
as FAST RAM. The extremely high data transfer rate of EVOLUTION
(beyond 2 MB/s) and most current page exchange algorithms (similar
to UNIX) open new possibilities of use.
Company: Macro System, Witten, Germany, tel. 0049-2302-27073

Now this is April's issue, but this is a commercial ad. I didn't
talk with them, but this sounds hot. I also don't know whether they
developed this themselves or only distribute it. It may even be an
imported product?

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

GUTEST8@cc1.kuleuven.ac.be (Ives Aerts) (03/27/91)

I don't think it's an April joke. Amiga Magazin allso had a small
article about it. I don't know the details of it but it said
something about being able to use virtual memory if you have their
harddisk controller and an MMU.
------------------------------------------------------------------------
      Ives Aerts           |          IBM definition SY-34378
GUTEST8@BLEKUL11.BITNET    |   A signature consists of sequences of
gutest8@cc1.kuleuven.ac.be | non-blank characters separated by blanks.
------------------------------------------------------------------------

stefanb@kaa.informatik.rwth-aachen.de (Stefan Becker) (03/27/91)

peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>as FAST RAM. The extremely high data transfer rate of EVOLUTION
>(beyond 2 MB/s) and most current page exchange algorithms (similar
>to UNIX) open new possibilities of use.

Virtual RAM? Paging? That does remind me of the 4th grade project of 
Mr. Valentin Pop. (Sorry can't remember your name :-) from C=. 

What was his experience? 98% of the Amiga programs didn't run, because
they expect REAL memory.

Facit: You gain NOTHING. Nice marketing idea, though :-)

	Stefan

BTW: Peter, do you really expect a WORKING Virtual RAM system from a german
     firm like MacroSystems? They usually employ 64'er hardware freaks and
     SEKA programmers.

--
Mail  : Stefan Becker, Holsteinstrasse 9, D-5100 Aachen  ///    Only
Phone : +49-241-505705   FIDO: 2:242/7.6    Germany     ///  Amiga makes
Domain: stefanb@informatik.rwth-aachen.de           \\\///  it possible..
Bang  : ..mcvax!unido!rwthinf!stefanb                \XX/  -->A3000/25<--

kris@tpki.toppoint.de (Kristian Koehntopp) (03/28/91)

peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
[ ... Availability of VM for Amiga ... ]
>Now this is April's issue, but this is a commercial ad. I didn't
>talk with them, but this sounds hot. I also don't know whether they
>developed this themselves or only distribute it. It may even be an
>imported product?

This is no april's joke at all, but instead a program smaller than 10 KB
plus two 250 byte utility programs. I have no idea, wether these are
depending on the evolution hardware.

I have been able to test the Evolution HDD Controller on an Amiga 2500 with
2 MB Fast Memory and Quantum 50 MB SCSI HDD. I was using the entire disk as
VM and tested several applications with this amount of memory.

Most memory-clocks fail, since they used signed shorts for displaying
kilobytes of memory and having an entire 50 MB HDD as VM gives you negative
numbers on these displays. Myclock had to be slightly patched and recompiled
for proper operation.

Installation was easy and straightforward. I chose the entire disk for VM
and the entire 2 MB as buffer pool for the VM. There is no use in having
pure, no-VM fast memory, as long as you don't have any realtime
applications. These better go in real RAM and be not paged out, to achieve
good and somewhat determined response times.

DPaint III worked good with this immense amount of mem, although allocating
memory for a large animated brush lasted nearly one minute. I suppose this
is because DPaint III also cleares this memory.

SnapShot Studio plus, Version 5, ran fine and was faster at allocating
memory for a 50 MB RAM animation. Of course the overall playback speed was
nearly the same as for a disk animation, but when it came to browsing
forward and backward through a small set of frames, response was real fast.

Several other applications also worked fine except for some minor problems
with short integers for free memory displays. These problems will not show
up, if you choose a sane amount of VM, instead going for manta-style amounts
("Ey, my A2500 now displays 500 MB of free ram at boot and I already have 3
resident copies of CED running then.").

Yours,
	Kristian

PS: Commo should really include this in the next KS release. Since the
    program is that small, it should not very difficult to handle.

Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689
"Im uebrigen ist 'Z-NETZ-Sysops quaelen' auf Dauer weder lustig noch
 befriedigend." - sysop@infinet.zer.sub.org

rivero@dev8.mdcbbs.com (03/29/91)

In article <stefanb.670080198@kaa>, stefanb@kaa.informatik.rwth-aachen.de (Stefan Becker) writes:
> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>>as FAST RAM. The extremely high data transfer rate of EVOLUTION
>>(beyond 2 MB/s) and most current page exchange algorithms (similar
>>to UNIX) open new possibilities of use.
> 
> Virtual RAM? Paging? That does remind me of the 4th grade project of 
> Mr. Valentin Pop. (Sorry can't remember your name :-) from C=. 
> 
> What was his experience? 98% of the Amiga programs didn't run, because
> they expect REAL memory.
> 
> Facit: You gain NOTHING. Nice marketing idea, though :-)
> 
True virtual memory must be imbedded in the OS to be effective. According
to rumor, the "hooks" for a VM system are in AmigaDOS 2.0, just as they
are in the as-yet-unreleased Version & MACII OS. However, implimenting
a disk based blocking system for software which uses stack based data (such
as a scanline renderer) are quite easy to impliment on the Amiga with
current hardware/software.

Michael

sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) (03/30/91)

stefanb@kaa.informatik.rwth-aachen.de (Stefan Becker) writes:

> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
> >as FAST RAM. The extremely high data transfer rate of EVOLUTION
> >(beyond 2 MB/s) and most current page exchange algorithms (similar
> >to UNIX) open new possibilities of use.
> 
> Virtual RAM? Paging? That does remind me of the 4th grade project of 
> Mr. Valentin Pop. (Sorry can't remember your name :-) from C=. 
> 
> What was his experience? 98% of the Amiga programs didn't run, because
> they expect REAL memory.
> 
> Facit: You gain NOTHING. Nice marketing idea, though :-)

Why shouldn't virtual RAM work on the Amiga? It works on the PC
and Macintosh....

Is there any real reason, or is it just that no one got around
to working out the bugs...

--
   Sleeping Beagle (aka Thomas Farmer)  sbeagle@kennels.actrix.gen.nz
   The Kennels                          Ph. +64-4-796306 (voice)
   25 Awarua St, Ngaio, Wellington, New Zealand.
               "You ain't nothin' but a Hound Dog."

gilgalad@caen.engin.umich.edu (Ralph Seguin) (04/01/91)

In article <wDskZ1w164w@kennels.actrix.gen.nz> sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) writes:
>stefanb@kaa.informatik.rwth-aachen.de (Stefan Becker) writes:
>
>> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>> >as FAST RAM. The extremely high data transfer rate of EVOLUTION
>> >(beyond 2 MB/s) and most current page exchange algorithms (similar
>> >to UNIX) open new possibilities of use.
>> 
>> Virtual RAM? Paging? That does remind me of the 4th grade project of 
>> Mr. Valentin Pop. (Sorry can't remember your name :-) from C=. 

>> What was his experience? 98% of the Amiga programs didn't run, because
>> they expect REAL memory.

What are you talking about?  You are accessing real memory, it's just mapped
into a virtual address space.  All address translations are handled by the MMU.

>> Facit: You gain NOTHING. Nice marketing idea, though :-)

What?  There is a hell of a lot to be gained with virtual memory.  Ever
hear of a debugging environment where the system doesn't lock itself up when
a process does?  Segmentation fault... :)


>Why shouldn't virtual RAM work on the Amiga? It works on the PC
>and Macintosh....

Hmmm... you mean with some sort of virtual memory software of course :)
What's the point of having virtual memory under DOS anyways :) ?



Ralph Seguin			gilgalad@caen.engin.umich.edu
536 South Forest Apt. #915	gilgalad@zip.eecs.umich.edu
Ann Arbor, MI 48104		(313) 662-4805

jdickson@jato.jpl.nasa.gov (Jeff Dickson) (04/02/91)

>Why shouldn't virtual RAM work on the Amiga? It works on the PC
>and Macintosh....
>
>Is there any real reason, or is it just that no one got around
>to working out the bugs...
>
>--
>   Sleeping Beagle (aka Thomas Farmer)  sbeagle@kennels.actrix.gen.nz
>   The Kennels                          Ph. +64-4-796306 (voice)
>   25 Awarua St, Ngaio, Wellington, New Zealand.
>               "You ain't nothin' but a Hound Dog."

	Virtual memory is not possible on any Amiga that does not have an
MMU. Without one, there is no way to "catch" references to memory that is
swapped out.

			-jeff

peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/02/91)

In article <1991Apr1.222906.12714@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes:
>	Virtual memory is not possible on any Amiga that does not have an
>MMU. Without one, there is no way to "catch" references to memory that is
>swapped out.

Yes. And the said software from EVOLUTION says that it *needs* a MMU.
So this does run on *the* Amiga, but not on *any* Amiga.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

walrus@wam.umd.edu (Udo K Schuermann) (04/03/91)

In article <1032@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
> Yes. And the said software from EVOLUTION says that it *needs* a MMU.
> So this does run on *the* Amiga, but not on *any* Amiga.

Well, I've got an MMU, and I want virtual memory!
My questions:
	a) when is EVOLUTION available?
	b) how much will it cost?
	c) will it live with my GVP SCSI controller?
	d) will it operate under 2.0 when it becomes available for the 2000?

Thanks for any info!

 ._.  Udo Schuermann		And now for something completely different:
 ( )  walrus@wam.umd.edu	An Iraqi dictator without his underpants.

peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/03/91)

In article <1991Apr3.053350.20366@wam.umd.edu> walrus@wam.umd.edu (Udo K Schuermann) writes:
>In article <1032@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>> Yes. And the said software from EVOLUTION says that it *needs* a MMU.

I should add something I heard: This only works, if the MMU
is currently totally free, unused. If it is already in use (like in
today's A3000), then the software can't provide VM.

>Well, I've got an MMU, and I want virtual memory!
>My questions:
>	a) when is EVOLUTION available?
*** seems now
>	b) how much will it cost?
*** controller without hd: 448,- DM; up to 5588,- DM with a 660 MB drive
    (today 1 US$ ca. equals 1,70 DM)
>	c) will it live with my GVP SCSI controller?
*** it is an own controller, I fear you won't get the software separately
>	d) will it operate under 2.0 when it becomes available for the 2000?
*** they say so

contact: MacroSystem, Billerbeckstr. 39a, 5810 Witten, Germany
         Tel. 0049 - 2302 - 27073, Fax ... - 27072
(also offering Medusa, the ST emulator and much other hw stuff)

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

rivero@dev8.mdcbbs.com (04/03/91)

In article <1032@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
> In article <1991Apr1.222906.12714@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes:
>>	Virtual memory is not possible on any Amiga that does not have an
>>MMU. Without one, there is no way to "catch" references to memory that is
>>swapped out.
> 
> Yes. And the said software from EVOLUTION says that it *needs* a MMU.
> So this does run on *the* Amiga, but not on *any* Amiga.
> 
> -- 
> Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
> Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

Even with an MMU, the way Amigados structures the free lists in its memory
manager produces accumulating problems with a virtual memory manager, either
in software or hardware. That the memory tends to fragment rapidly has always
been one of the Amigas problems.

Michael

P.S. Flamers! I LOVE the Amiga. I Have 3 of them at home. Every time I make a
critical comment about the Amiga I get a ton of bad mouth E-Mail I do
not feel I deserve. Even a loving parent should be able to admit his kid has
pimples!

rbabel@babylon.rmt.sub.org (Ralph Babel) (04/04/91)

In article <3033@tpki.toppoint.de>, kris@tpki.toppoint.de
(Kristian Koehntopp) writes:

> I have no idea, wether these are depending on the
> evolution hardware.

They depend on driver-private entry points in the Evolution
software (disk I/O without OS).

> Several other applications also worked fine [...]

Try it under some really heavy system load. Or what about
SCSIF_AUTOSENSE to virtual memory? Why not backup the SCSI
harddrive (the one used for paging) to a SCSI tape drive
using a backup program allocating buffers in virtual memory?
Then, while backing up the system, eject the tape cartridge.

Ralph

rbabel@babylon.rmt.sub.org (Ralph Babel) (04/04/91)

In article <1991Apr3.053350.20366@wam.umd.edu>,
walrus@wam.umd.edu (Udo K Schuermann) writes:

> c) will it live with my GVP SCSI controller?

Amiga-OS 1.3 does not really support DMA _and_ MMU at the
same time. Ever tried to save a SetCPU KICKROM image? :-)

Ralph

kris@tpki.toppoint.de (Kristian Koehntopp) (04/05/91)

walrus@wam.umd.edu (Udo K Schuermann) writes:
>Well, I've got an MMU, and I want virtual memory!
>My questions:
>	a) when is EVOLUTION available?
>	b) how much will it cost?
>	c) will it live with my GVP SCSI controller?
>	d) will it operate under 2.0 when it becomes available for the 2000?


I have been mailed by so many people, so I am going to post complete
information on this device here.

The Evolution HDD Controller comes with a workbench disk including the
following additional programs:

Directory "EvolutionInstall 2.1:" on Wednesday 03-Apr-91
MedusaSCSI                  2260 ----rwed 29-Jul-90 21:11:54
	-> Device for the "Medusa" Atari Emulator
SCSIStop                    1300 ----rwed 29-Jan-91 02:12:37
	-> Stops all HD motors
SCSIStop.info               1208 ----rwed 26-Feb-91 02:04:08
SCSIInstall                10040 ----rwed 07-Feb-78 01:53:04
	-> prep & format
SCSIInstall.info            1118 ----rwed 26-Feb-91 02:04:03
SCSIBootSel                 4120 ----rwed 07-Feb-78 01:53:19
	-> Select Boot HD and Partition
SCSIBootSel.info            1118 ----rwed 26-Feb-91 02:03:57
VMem                         Dir ----rwed 19-Mar-91 12:31:16
	-> Directory with VM programs
VMem.info                    712 ----rw-d 19-Mar-91 12:27:53
20 files - 14 directories - 103 blocks used

Directory "EvolutionInstall 2.1:devs" on Wednesday 03-Apr-91
evolution.amhd              2220 ----rwed 26-Feb-91 02:16:07
	-> Device driver for AMAX II
8 files - 3 directories - 113 blocks used

Directory "EvolutionInstall 2.1:VMem" on Wednesday 03-Apr-91
PreferVirtualMem             256 ----rwed 26-Feb-91 02:07:37
	-> Set priority of VM to one higher than Fast Memory
PreferVirtualMem.info       1898 ----rwed 26-Feb-91 02:07:47
PreferNormalMem              256 ----rwed 26-Feb-91 02:07:54
	-> Set priority of VM to one lower than Chip Memory
PreferNormalMem.info        1898 ----rwed 26-Feb-91 02:08:32
VRam                        8272 ----rwed 26-Feb-91 02:07:24
	-> Vram Tool, MMU required
VRam.info                   2210 ----rw-d 19-Mar-91 12:28:24
7 files - 40 blocks used

TOTAL: 200 files - 24 directories - 1741 blocks used


The Evolution HD Controller can be obtained from

 Macrosystems
 Billerbeckstrasse 39a
 D - 5810 Witten
 Germany

 Tel.: +49 2302 27073
 Fax.: +49 2302 27072

 Mo-Fr:  9.00 AM to 12.30 PM
        14.00 PM to 18.00 PM

	This is Central European Time (GMT +0100) and CET DST (GMT +0200)

I do not work for Macrosystems nor do I sell their products.

PLEASE DO NOT MAIL ME, IF YOU WANT TO HAVE IT.

Maximum performance on an A2500 (68020) as measured by DiskPerf (Fish 187):

- Imprimis Wren Runner 7: 2,24 MB/s
- Quantum Prodrive 210S : more than 1.00 MB/s

The Evolution HDD Controller is a Card Controller, the disk is mounted
directly onto the card. The construction seems somewhat mechanically
instable. The controller supports Burstmode transmission into memory,
whatever this means, it surely is fast.

All partitions can be automounted. Any partition can be boot partition.
Kickstart 1.2, 1.3 and 2.x are supported. Documentation is in german
language. I have no idea, whether english docs can be obtained.

Prices are (netto without tax):

Filecard (solo)                 392.- DM /  230.- $
Filecard +  52MB Quantum LPS    910.- DM /  535.- $
Filecard + 105MB Quantum LPS   1490.- DM /  876.- $
Filecard + 170MB Quantum       2095.- DM / 1232.- $
Controller +
 ext. Wren Runner 7 (660 MB)   4901.- DM / 2883.- $
Medusa Atari Emulator with Tos  349.- DM /  205.- $

Add post & package. Don't forget your tax and custom. US $ price is
calculated and may vary heavily, according to US politics :-)

Again: I am not connected to Macrosystems. I do not sell their products.
Any, yes, an MMU is required. Without an MMU this is just another fast SCSI
controller. I have no idea, whether their VRam-Tool works with any other
controller.

PLEASE SNAIL-MAIL OR PHONE THEM, NOT ME.

Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689
"Das Editier, das Editier, das lebt jetzt leider nicht mehr hier."
	-- aus "Un-Zen oder die Kunst des schlechten Kalauers".

jesup@cbmvax.commodore.com (Randell Jesup) (04/05/91)

In article <1991Apr3.114837.1@dev8.mdcbbs.com> rivero@dev8.mdcbbs.com writes:
>Even with an MMU, the way Amigados structures the free lists in its memory
>manager produces accumulating problems with a virtual memory manager, either
>in software or hardware. That the memory tends to fragment rapidly has always
>been one of the Amigas problems.

	The tricky part is programs that a) access memory under Forbid or
worse yet disable (they may avoid this by only working with their own
controller, and not using interrupts (or requiring their use) in the driver);
b) programs that put critical code in VM (interrupt handlers, for example).

	The "proper" method requires programs specify that they want VM and
are willing to abide by the rules for safe access.  All this was hashed out
quite a while ago in c.s.a.tech.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Thus spake the Master Ninjei: "To program a million-line operating system
is easy, to change a man's temperament is more difficult."
(From "The Zen of Programming")  ;-)