rminnich@udel.EDU (Ron Minnich) (09/14/87)
The sources to a very preliminary version (-1) of dvi2iff are
in pub/dvi2iff.tar.Z on louie.udel.edu. It only does one page,
cause at the moment it just calls PutPict; if you broke up
PutPict then you could do many pages. The iff code from EA is real nice,
and the dv.c code is pretty clear. ALl the iff code on the iff disk is
there. This program has compiled and run on a Sun-3; there is no
sun-specific stuff in it. I have stopped working on it pending
a decision to just buy AmigaTeX, which is a real impressive
piece of work. Anyway you wizards out there can probably
bang this piece of junk into shape. Unfortunately it has to run
on the Amiga; i was crazy to try dvi2iff on the sun and ftp it
down, as one full page is a couple k of (compressed) bitmap. too big.
Questions to me and i will try to help.
ON a related note, i have been thinking about TCP/ip on amiga.
My idea is to take ed pucketts pipe device and hack it so that
it is wired into TCP/IP. Then TCP/IP looks like a device; we could
call it net:. Why do this? Well, consider this mapping:
First, call the modified pipe device net:
Open -> open a tcp/ip socket. You call it "tcp.port" (e.g. tcp.25)
or just "ip". Returns a handle to a unique tcp or ip port
Close -> close the socket
Dir -> when applied to net:, just shows you all the open sockets.
Delete -> close the connection from outside the tcp/ip code
or the program using the socket, e.g. you could
from the CLI do a DIR net:, then delete stuff
you are trying to kill.
and so on.
Note that we can also allow taps on connections; useful for debugging.
Now we can migrate telnet, ftp, and so on out of the karn code
into seperate processes. We can also now run rcp, rsh, and so on.
Each tcp/ip user will be in its own window. Looks like a win to me;
it is not possible on a PC or Mac because, as usual, no multi-tasking.
In fact the karn code does a sort of multi-tasking on its own
because of this lack.
Anyway, i started to do this, and my shitso Lattice v3.03 gets
a CXERR 28 on iproute.c. Damn. Guess i have to wait for 4.0 and
then update. Any of you wizards wanna hit this, go to it. It is
actually not too hard.
ron
--
Ron Minnich louie@trantor.umd.edu (Louis A. Mamakos) (09/15/87)
In article <503@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: > ON a related note, i have been thinking about TCP/ip on amiga. >My idea is to take ed pucketts pipe device and hack it so that >it is wired into TCP/IP. Then TCP/IP looks like a device; we could >call it net:. Why do this? Well, consider this mapping: >First, call the modified pipe device net: >Open -> open a tcp/ip socket. You call it "tcp.port" (e.g. tcp.25) > or just "ip". Returns a handle to a unique tcp or ip port >Close -> close the socket >Dir -> when applied to net:, just shows you all the open sockets. >Delete -> close the connection from outside the tcp/ip code > or the program using the socket, e.g. you could > from the CLI do a DIR net:, then delete stuff > you are trying to kill. >and so on. > >Note that we can also allow taps on connections; useful for debugging. >Now we can migrate telnet, ftp, and so on out of the karn code >into seperate processes. We can also now run rcp, rsh, and so on. >Each tcp/ip user will be in its own window. Looks like a win to me; >it is not possible on a PC or Mac because, as usual, no multi-tasking. >In fact the karn code does a sort of multi-tasking on its own >because of this lack. I've started a similar effort. In fact, my port of the Phil Karn TCP/IP code to the amiga was just an intrim step to a real implementation of an Amiga device driver. I dropped amigatcp.tar on TRANTOR.UMD.EDU for a few folks to play with; I'm surprized its taken off so much. You should fetch the complete package (for the PC), from LOUIE.UDEL.EDU. It comes complete with documentation and everything! Note that Phil has produced new versions that have made my port obsolete by now. Maybe when C Ltd returns my hard disk (#$%^#@$..) I can get some work done. My idea was to make an EXEC device driver, "internet.device". In fact, you will see a stub of code in the existing version that actually does this. I'm not sure at this point if imbedding it in the file system is a good idea; I done know if the semantics of the network connection can be maintained. How dow you indicate CLOSE on your side of a TCP connection, yet continue to read from the other side? And make this work with existing applications that use fhe file system? Hmmm... The code I ported was compiled with Manx C; I've given up on Lattice a long time ago. The vapor 4.0 might be better, but it is a little soon to count on it saving the day. I understand that the next major version of Manx C also has function prototypes (see interview in latest Amazing Computing with Goodnow). Anybody know about any SCSI ethernet controllers? Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
ricks@well.UUCP (09/18/87)
In article <1929@umd5.umd.edu>, louie@trantor.umd.edu (Louis A. Mamakos) writes: > >First, call the modified pipe device net: > >Open -> open a tcp/ip socket. You call it "tcp.port" (e.g. tcp.25) > > or just "ip". Returns a handle to a unique tcp or ip port > >Close -> close the socket > >Dir -> when applied to net:, just shows you all the open sockets. > >Delete -> close the connection from outside the tcp/ip code > > or the program using the socket, e.g. you could > > from the CLI do a DIR net:, then delete stuff > > you are trying to kill. Yes, Ameristar does this. Only item not handled NOW is dir. We call it inet:, and you get to IP, TCP, UDP, etc by incanting inet:tcp/addr/port, inet:udp/addr/port, etc. > I've started a similar effort. In fact, my port of the Phil Karn TCP/IP > code to the amiga was just an intrim step to a real implementation of > an Amiga device driver. I dropped amigatcp.tar on TRANTOR.UMD.EDU for a few The problem with device driver/library implementations of Phils code is that the code was designed to be single threaded commutating loop. To play as a device library requires either toggling a semaphore on entry to any network routine (minimal changes to code), or identifying and then placing monitors around critical sections in the code (mucho changes to code). > > Anybody know about any SCSI ethernet controllers? > Gheesh, I'm beginning to think there is a 60 dB Ameristar notch filter at UDel :-). Yes, there is a SCSI <-> Ethernet box - made by Kinetics. The cost to Universities is $1125 ($1250 for commercial folks) for the thin Ethernet version (thick Ethernet costs ~$125 less). As I've said before, though, the cheapest way onto Ethernet copper for the Amiga is the Ameristar A2000 board: $699. It plays on thin Ethernet without setting you back extra bucks, and as always, I have a driver (that I wrote for a port of KA9Q's code to the Amiga done before Lou's time) that you can have for free.. Rick Spanbauer PS. I do development for Ameristar, so consider this posting biased..
rminnich@udel.EDU (Ron Minnich) (09/18/87)
ack. There is some confusion, and i can see why.
For the record:
rminnich@udel.edu is me, ron minnich
louie@trantor.umd.edu is louis mammakos (spelling, louie? )
who did the real nice work on porting karn's
code to the amiga.
louie.udel.edu is the machine on which we keep louie@umd.trantor.edu's
code.
We did not name the machine after him, though
maybe we should have.
In article <3969@well.UUCP> ricks@well.UUCP (Rick Spanbauer) writes:
>
> The problem with device driver/library implementations of Phils
> code is that the code was designed to be single threaded commutating
> loop. To play as a device library requires either toggling a
> semaphore on entry to any network routine (minimal changes to
> code), or identifying and then placing monitors around critical
> sections in the code (mucho changes to code).
.
.
>Gheesh, I'm beginning to think there is a 60 dB Ameristar notch filter
>at UDel :-).
>...
Na, no filter here! In fact i just dumped another plug for this
board out on the net, and am pushing it on friends at upenn.
I think we are having name confusion ...
On to other things.
Here was my thinking on the net: device. First off,
when you write to the device, the driver looks to see if the session
is active. If not, it makes the session active via the same
mechanism you currently use via ^] and then a session command.
That i think will take care of writes to the device. I have not looked
close enough to see how to handle tcpinput. The code is so nice
i just figured there had to be a way to do this. If only i could
get enough time.
In an ideal world i would just buy the Ameristar board,
but it is more than i can afford right now. :-(
ron
--
ron (rminnichme reow totpeter@sugar.UUCP (Peter da Silva) (09/20/87)
In the referenced article, louie@trantor describes an internet.device he's working on, and comments that putting it into the file system might not be such a good idea. I feel that all devices that can even remotely have some use be installed into the file system. I want to be able to "type DATE:" and also "copy * DATE:". I want to be able to "dmp rdf1:" (this one might want to be a read-only device, or a seperately loadable one). Even if the file system device isn't as powerful as the raw one, it's useful. CON: isn't as powerful as doing direct console.device calls, but it's still a useful tool. How many programs use it (raise your hands). If I ever get the time to figure out how to do device drivers in Aztec, or someone posts a sample driver for 3.40a, just watch out. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?
stu@splut.UUCP (Stewart Cobb) (09/20/87)
There's been some discussion about adding TCP/IP, and other stuff, to
the Amiga file system. I'd like to add an enthusiastic YES!
Philosophy: One of the great things about UNIX is its simplicity. In
the original UNIX, _everything_ was treated as a file, and there was one
hieracherial directory structure, where all files had a home. Later
Unixes, designed by "others," have added features such as sockets. It's
not clear to me that a socket is a better picture of a TCP stream than
a file with a few special ioctl()'s. Putting a variety of devices into
the filesystem may sound bizzare, but it actually provides a clean
implementation from the user's point of view. I would definitely
support this as the way to go on the Amiga.
And while we're at it, can we get rid of device names and go to a
single filesystem? I have always hated this minor-but-annoying
difference between Amiga and UNIX.
Practice: A lot of Official Commodore People read this net. Perhaps
one of them can give me an answer (Official or not) to this question:
Why hasn't Commodore released the source to the operating system?
Think about it. They can't be afraid of pirates: everyone who has an
Amiga gets a copy of the OS, gratis. Are they afraid someone would hack
it up into a better OS? That would only sell them _more_ Amigas. They
shouldn't be concerned about having multiple, perhaps buggy, new OS's
floating around, because everyone who has one of those also has the
original to fall back to. If one of these new ones emerges as a new
"standard", so what?
The very worst case I can think of for Commodore is that 1.2 is
replaced in everyday use by something else. In that case, people buy
their new Amiga's, reformat the 1.2 disks, and continue on. And who
cares? That wouldn't cost Commmodore a dime -- they are in business to
sell hardware, not software.
Can someone point out the flaw in my reasoning? Or, perhaps, the
flaw in theirs?
software away.
--
| Stewart Cobb (Hacking GNC for STS) ... sun!housun!nuchat!splut!stu
| N5JXE @ KA5KTH or WB5BBW ... seismo!soma!uhnix1 /
| << Insert the usual disclaimer >> ... hoptoad!academ /
| Sattinger's Law: It works better if you plug it in.fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (09/22/87)
in article <156@splut.UUCP>, stu@splut.UUCP (Stewart Cobb) says: > > Why hasn't Commodore released the source to the operating system? > Commodore doesn't have the soure. At least, that's what they said earlier. MetaComco has the source. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
keithd@cadovax.UUCP (Keith Doyle) (09/22/87)
In article <156@splut.UUCP> stu@splut.UUCP (Stewart Cobb) writes: > Why hasn't Commodore released the source to the operating system? Probably because they don't own it. And it's Metacomco's bread and butter. C= is still paying royalties to them I believe. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
jdow@gryphon.CTS.COM (Joanne Dow) (09/22/87)
In article <156@splut.UUCP> stu@splut.UUCP (Stewart Cobb) writes: > >Practice: A lot of Official Commodore People read this net. Perhaps >one of them can give me an answer (Official or not) to this question: > > Why hasn't Commodore released the source to the operating system? > > Think about it. They can't be afraid of pirates: everyone who has an >Amiga gets a copy of the OS, gratis. Are they afraid someone would hack >it up into a better OS? Speaking as one who would herself adore having a set of the OS sources I still support C='s holding them close to their vests. Look at what happened in the C-64 world with everybody and his uncle hacking directly into OS internals. Can you imagine the chaos that would result when 1.3 comes out if this were commonplace on the Amiga? If you STILL want public sources I propose putting your name on it and letting you personally take the heat when all the programs that used "hidden internal" entry points died with improved versions. This way folks HAVE to use approved entrys. This leaves C= the necessary slack to optimize internal code, alter internal code, and add improvements in left over space as long as they keep the advertised interface to spec. (If they can get it there to begin with.) If you want to improve the OS so much by hacking why not do what I and others, notably Charlie Heath and crew doing the ARP library and BCPL program replacements, have done. We rebuild what displeases us and link it in via proper library linkages. That is at least quite legal and proper. Just don't hack inside, please. I can't imagine a machine like the Amiga surviving with developers hying off after which ever hacker's version of the OS pleases them at the moment. At least now all programs run off the same OS (unless they're one of the nasty hacks on 1.1...) and can often (not often enough) work properly TOGETHER. I suppose I've flamed enough. I'll just say again that I have repeatedly asked Andy for copies ofthis or that piece of source and been peeved when i can't get it. Still, I find that in my more lucid moments I have to support the non- release decision. -- <@_@> BIX:jdow INTERNET:jdow@gryphon.CTS.COM UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was better you left it in the bush with the other one.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/23/87)
>> >> Why hasn't Commodore released the source to the operating system? >> > Commodore doesn't have the soure. At least, that's what they said >earlier. MetaComco has the source. Try to be accurate. The only thing commodore might possibly NOT have the source to are parts of DOS, which was done by MetaComco. Everything else was done by Amiga/Commodore-Amiga/Commdore. -Matt
carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) (09/23/87)
In article <178@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >in article <156@splut.UUCP>, stu@splut.UUCP (Stewart Cobb) says: >> >> Why hasn't Commodore released the source to the operating system? >> > Commodore doesn't have the soure. At least, that's what they said >earlier. MetaComco has the source. > >--Fabbian Dufoe Wrong. We have all of the source. We just don't OWN all of it. We don't own the narrator/translator source. We may not own some or all of the dos.library source. But we do have it all. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< UUCP ...{allegra,ihnp4,rutgers}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=ASTC 4nstheref rne mou mou Me
rminnich@udel.EDU (Ron Minnich) (09/24/87)
In article <775@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >If I ever get the time to figure out how to do device drivers in Aztec, or >someone posts a sample driver for 3.40a, just watch out. >-- >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter >-- 'U` Have you hugged your wolf today? Well, i think ed pucketts' p: driver is a good example. It supports all the operations i suggested in my original posting. Take a look at it ... pretty nice code. -- ron (rminnich@udel.edu)
bryce@hoser.berkeley.edu.UUCP (09/24/87)
In article <1759@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <156@splut.UUCP> stu@splut.UUCP (Stewart Cobb) writes: >> Why hasn't Commodore released the source to the operating system? > >Probably because they don't own it. And it's Metacomco's bread and >butter. C= is still paying royalties to them I believe. Please! Metacomco came in at the last moment and contributed the file system, "AmigaDOS". It's that icky, BCPL kludge that causes so much overhead. Exec, Intuition, Graphics, Layers, Math and all that stuff was developed at Amiga (or Commodore or Commodore-Amiga). DOS and (I think) translator are all that was farmed out. "AmigaDOS" is one of those tricky terms. People hear "PC-DOS" for the PC, so the Amiga must have AmigaDOS. Oh, you say, AmigaDOS was written by Metacomco? When I say "DOS" I mean just the file system; what handles the disks, directories and files. I don't think Metacomco's contribution went much beyond that. A little more semi-speculation: I think DOS was added in Rev 28 of the OS. 30 was the first one to be released to the public, as V1.0. 31 was V1.1, 32 was the PAL release, 33 is V1.2. (I never met an Amiga until V1.1) Amiga apparently had a file system that was actually designed to sit on top of the rest of the Amiga. I don't know the details of that other than it never came to life. They used something I have never seen, the "Kludge file system", until Metacomco was pulled in to port a DOS over in just a few weeks of panic. (Sources: BYTE and AmiProject) From a programmer's perspective it is very clear that Metacomco's file system and the rest of the Amiga are of clearly distinct design. Commodore-Amiga is still working on the Operating System. Recent changes have been made for better multi-tasking 68881 and 68882 math co-processor support. The huge-screen overscan bug was found and fixed. (Source: Dale Luck announcing at a FAUG meeting. No release dates mentioned.) |\ /| . Ack! (NAK, ENQ, SYN) {o O} . (") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce U How can you go back if you have not yet gone forth?
glee@cognos.uucp (Godfrey Lee) (09/24/87)
In article <156@splut.UUCP> stu@splut.UUCP (Stewart Cobb) writes: > And while we're at it, can we get rid of device names and go to a >single filesystem? CAUTION CAUTION CAUTION Single file system works fine when the drives are permanently mounted, floppy systems mean that you have a large number of file systems (disks) that are mounted and dis-mounted regularly. Can you imagine having to issue a unmount command, eject disk, then issue a mount command every time you change floppies? Of course, it is impossible to access two floppies at once with a single floppy system, like diskcopy. The Xenix system requires you to mount and unmount floppies, making it virtually impossible to run without a hard disk. Other systems that run on PCs run with device names, such as QNX, AmigaDOS, etc, etc, precisely for the above reasons!!! -- Godfrey Lee P.O. Box 9707 Cognos Incorporated 3755 Riverside Dr. VOICE: (613) 738-1440 FAX: (613) 738-0002 Ottawa, Ontario UUCP: decvax!utzoo!dciem!nrcaer!cognos!glee CANADA K1G 3Z4
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (09/25/87)
in article <8709222157.AA26354@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: >>> Why hasn't Commodore released the source to the operating system? >> Commodore doesn't have the soure. At least, that's what they said >>earlier. MetaComco has the source. > Try to be accurate. The only thing commodore might possibly NOT have > the source to are parts of DOS, which was done by MetaComco. Everything else > was done by Amiga/Commodore-Amiga/Commdore. You're right. I just assumed "operating system" referred to AmigaDOS, not Intuition. At any rate, my point was that someone from Commodore answered the question some time back saying they didn't have the source to the software which was written by MetaComco. From the discussions I've read about problems with the Amiga's system software, it's the MetaComco stuff that most needs fixing. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <519@louie.udel.EDU>, rminnich@udel.EDU (Ron Minnich) writes: > In article <775@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >If I ever get the time to figure out how to do device drivers in Aztec, or > >someone posts a sample driver for 3.40a, just watch out. > Well, i think ed pucketts' p: driver is a good example. It supports > all the operations i suggested in my original posting. Take a look > at it ... pretty nice code. Is it in Aztec? I've got it... it looked like Lattice to me. The Aztec and Lattice startup code isn't a real close match, and I don't want to get into that stuff... Maybe I better look again. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
andy@cbmvax.UUCP (Andy Finkel) (09/27/87)
In article <181@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >in article <8709222157.AA26354@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: >>>> Why hasn't Commodore released the source to the operating system? >>> Commodore doesn't have the soure. At least, that's what they said >>>earlier. MetaComco has the source. >> Try to be accurate. The only thing commodore might possibly NOT have >> the source to are parts of DOS, which was done by MetaComco. Everything else >> was done by Amiga/Commodore-Amiga/Commdore. > You're right. I just assumed "operating system" referred to AmigaDOS, >not Intuition. At any rate, my point was that someone from Commodore >answered the question some time back saying they didn't have the source to >the software which was written by MetaComco. From the discussions I've >read about problems with the Amiga's system software, it's the MetaComco >stuff that most needs fixing. We got all the sources. We've always had all the sources. What someone may have said in the distant past was that he/she didn't have the sources. I think the gathered net folks have pretty much summarized the reasons for and against distributing the source. Control issues, lawyer issues, money issues, possible port to other machine issues, etc. Maybe we should have an AT&T 'big bucks for a source license' type program. That way we could afford the AT&T number of lawyers to defend it. ("Let me get this straight...its *both* copyright *and* trade secret ???) Anyway, in our own peculiar fashion, we are addressing many of the OS issues. >--Fabbian Dufoe -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.