From mjhostet@slayer.MIT.EDU Sat Oct 17 14:09 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Sat, 17 Oct 92 14:09:45 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Sat, 17 Oct 92 14:08:25 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Sat, 17 Oct 92 14:08:13 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Sat, 17 Oct 92 14:08:58 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ23GPSCKG8WWR65@yvax.byu.edu>; Sat, 17 Oct 1992 14:07:29 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA03141; Sat, 17 Oct 92 16:07:22 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 17 Oct 1992 16:07:22 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: stupid NXStream question To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210172007.AA03141@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO I'm messing around with adding Prodos support and I have a stupid NXStream question to ask y'all. I'm opening the disk file with NXMapFile(), as NeXT recommends for random access to file stored on disk. If I modify this stream (as when the Apple // attempts to modify its disk), the memory stream gets modified but the original file does not. NXFlush and NXCloseMemory did not seem to flush the changes back to the original file. As a result, right now I'm using NXSaveToFile() to save the whole image back to disk if even one byte was modified. Is this the right way to do it? It seems wasteful to write a huge file back to disk (eg, a 20 MB hard drive image) if they only change one byte. Is the NXStream clever about writing back pages that have changed, or should I use open() and NXOpenFile() to get a real, "write-through" stream? I could of course also use FILE *'s, but I was hoping to do this the NeXTy way. Thanks for your time... -Mat From mjhostet@slayer.MIT.EDU Mon Oct 19 10:33 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 01:17:23 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Mon, 19 Oct 92 01:16:01 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Mon, 19 Oct 92 01:15:50 mdt Received: from byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 01:17:19 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ453945E88WWSYN@yvax.byu.edu>; Mon, 19 Oct 1992 01:15:28 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA02850; Mon, 19 Oct 92 03:15:21 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 19 Oct 1992 03:15:21 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Mockingboard To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210190715.AA02850@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO Someone here really really wants to write a Mockingboard card for the emulator. I once owned a Mockingboard manual but I can't find it. Would anyone who knows anything about this board (the rev. without the speech synthesizer I suppose) and how easy it might be to emulate on a NeXT please send me some general info? cc the message to patl@athena.mit.edu. Thanks! -Mat From mjhostet@slayer.MIT.EDU Mon Oct 19 10:33 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 01:13:26 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Mon, 19 Oct 92 01:12:03 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Mon, 19 Oct 92 01:11:53 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 01:13:22 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ44YOJ4V48WWVOI@yvax.byu.edu>; Mon, 19 Oct 1992 01:11:46 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA02830; Mon, 19 Oct 92 03:11:42 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 19 Oct 1992 03:11:42 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Re: nulib + unpacked disks To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210190711.AA02830@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO Brian Willoughby writes: >Hey, is the Apple emulator usable yet? Last I heard it was still >very preliminary. What is the story currently? I have not released a new version yet, but my development version has/will have some neat new things: 1) DOS 3.3 support 2) ProDOS support [someone send me a prodos disk so I can test this!] 3) Fast 16 bit color support for hi-res 4) Various bug fixes 5) A Serial Card is in the works...may not make the release 6) A .pkg for easy installation 7) Some PD games disks (defender and berzap, I'd welcome more) It is still missing many important things, like an Inspector for the dynamically loadable peripheral cards (which would let you switch disks at runtime, for example), LoRes, Preferences, improved sound, and lots of UI stuff. Since I may not have much time this term, my hope was to add in sufficient (or is that insufficient? :-) disk support (and a virtual serial card) so that others could easily use their own favorite disks and thus have some incentive to work on the emulator. But, to make a long story short, the new version is perfectly sufficient to play games, and that's what counts! :-) -Mat From sounds!brianw@nwnexus.wa.com Mon Oct 19 10:33 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 00:54:28 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Mon, 19 Oct 92 00:53:06 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Mon, 19 Oct 92 00:52:55 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 00:54:24 -0600 Received: from nwnexus.wa.com by yvax.byu.edu (PMDF #2655 ) id <01GQ44B6KJ4G8WWT5N@yvax.byu.edu>; Mon, 19 Oct 1992 00:52:51 MDT Received: from sounds.UUCP by nwnexus.wa.com with UUCP id AA16803 (5.65c/IDA-1.4.4 for byu.edu!na2sig); Sun, 18 Oct 1992 23:39:17 -0700 Received: by sounds. (NX5.67c/NX3.0S) id AA14362; Sun, 18 Oct 92 23:20:46 -0700 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 18 Oct 1992 23:20:46 -0700 From: Brian Willoughby Subject: Re: nulib + unpacked disks To: NeXT Apple 2 Message-Id: <9210190620.AA14362@sounds.> Content-Transfer-Encoding: 7BIT Status: RO Yeah, what he said! Scott is right, the sector ordering you're seeing is the same one I had to memorize to use a sector editor on ProDOS disks. Hey, is the Apple emulator usable yet? Last I heard it was still very preliminary. What is the story currently? --- Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Consulting and Signal Processing Software NeXTmail welcome - NO EMAIL SOLICITATION without prior permission Begin forwarded message: | Mathew J. Hostetter wrote: | >I've been hacking in Prodos and DOS 3.3 support. I grabbed some | >shk'd DOS 3.3 disks off the net and unpacked them with NuLib. It | >gave me the expected 140K file. It seems to be in a strange format, | >though; the tracks are all in order, but the logical sectors appear | >to be in this order within each track: | > | >0 14 13 12 11 10 9 8 7 6 5 4 3 2 1 15 | > | >If I have the emulator adjust for this strangeness it works (I was | >able to play Berzap and Defender right off the net!) Does it really | >leave the disk in this order, or is something wrong? | | That's the order in which ProDOS combines sectors into blocks. NuLib | packs disks in block order, not track/sector order. ProDOS apps know | nothing (or are supposed to know nothing) about the physical format of | a device. | | Scott Alfter From mjhostet@slayer.MIT.EDU Mon Oct 19 10:33 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 00:02:38 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Mon, 19 Oct 92 00:01:16 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Mon, 19 Oct 92 00:01:03 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 00:02:29 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ42HRVH9C8WWVIP@yvax.byu.edu>; Mon, 19 Oct 1992 00:00:53 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA02751; Mon, 19 Oct 92 02:00:27 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 19 Oct 1992 02:00:27 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Re: nulib + unpacked disks To: Scott Alfter Cc: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210190600.AA02751@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO Scott Alfter wrote: >That's the order in which ProDOS combines sectors into blocks. NuLib >packs disks in block order, not track/sector order. ProDOS apps know >nothing (or are supposed to know nothing) about the physical format of >a device. You were absolutely right, Scott! I should have known, since Rich Skrenta's emulator has a program to convert from prodos ordering to dos ordering. I wrote a simple utility to convert this format to a DOS 3.3 "a2disk" (which involves prepending a small header and reordering the sectors) and I'll distribute it with the emulator. Would anyone prefer that we standardize the format for DOS 3.3 as prodos ordering (right now it is in order of logical sectors.) We could amend the disk format so that if the emulator sees a file exactly 140K long (without a header) it looks at the some known byte pattern in the first 256 bytes to figure out if it is prodos or DOS 3.3. Right now if it sees no header it assumes the file is a prodos disk image (block 0 followed by block 1, etc). The advantage of this scheme is that you could just un-shk a disk image, tack a ".a2disk" suffix on the end, and it would work, whether it was prodos or dos 3.3! -Mat From sknkwrks@sonny-boy.cs.unlv.edu Mon Oct 19 10:33 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Sun, 18 Oct 92 23:12:37 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Sun, 18 Oct 92 23:11:16 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Sun, 18 Oct 92 23:11:05 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Sun, 18 Oct 92 23:12:29 -0600 Received: from JIMI.CS.UNLV.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ40QV1NDC8WX0S1@yvax.byu.edu>; Sun, 18 Oct 1992 23:10:56 MDT Received: from sonny-boy.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa28864; 18 Oct 92 21:56 PDT Date: 18 Oct 1992 21:56:54 -0700 From: Scott Alfter Subject: Re: nulib + unpacked disks In-Reply-To: Your message of "18 Oct 92 23:08:38 EDT." <9210190308.AA02497@slayer.MIT.EDU> To: na2sig@byu.edu Cc: mjhostet@athena.mit.edu Message-Id: <01GQ40QV426Q8WX0S1@yvax.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO Mathew J. Hostetter wrote: >I've been hacking in Prodos and DOS 3.3 support. I grabbed some >shk'd DOS 3.3 disks off the net and unpacked them with NuLib. It >gave me the expected 140K file. It seems to be in a strange format, >though; the tracks are all in order, but the logical sectors appear >to be in this order within each track: > >0 14 13 12 11 10 9 8 7 6 5 4 3 2 1 15 > >If I have the emulator adjust for this strangeness it works (I was >able to play Berzap and Defender right off the net!) Does it really >leave the disk in this order, or is something wrong? That's the order in which ProDOS combines sectors into blocks. NuLib packs disks in block order, not track/sector order. ProDOS apps know nothing (or are supposed to know nothing) about the physical format of a device. _/_ Scott Alfter Internet: sknkwrks@cs.unlv.edu / v \ Call the Skunk Works BBS today! (IIe ( (702) 894-9619 300-14400 V.32bis Apple II/IBM/Star Trek/Aerospace \_^_/ Ask me about SoftDAC--digital audio for your IIe/IIc! Apple II Forever! From mjhostet@slayer.MIT.EDU Mon Oct 19 10:33 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Sun, 18 Oct 92 21:10:57 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Sun, 18 Oct 92 21:09:36 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Sun, 18 Oct 92 21:09:25 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Sun, 18 Oct 92 21:10:17 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ3WHE3B3K8WX09C@yvax.byu.edu>; Sun, 18 Oct 1992 21:08:46 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA02497; Sun, 18 Oct 92 23:08:38 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 18 Oct 1992 23:08:38 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: nulib + unpacked disks To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210190308.AA02497@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO I've been hacking in Prodos and DOS 3.3 support. I grabbed some .shk'd DOS 3.3 disks off the net and unpacked them with NuLib. It gave me the expected 140K file. It seems to be in a strange format, though; the tracks are all in order, but the logical sectors appear to be in this order within each track: 0 14 13 12 11 10 9 8 7 6 5 4 3 2 1 15 If I have the emulator adjust for this strangeness it works (I was able to play Berzap and Defender right off the net!) Does it really leave the disk in this order, or is something wrong? Also, would anyone mind NeXTmailing me some .SHK'd disks I can experiment with? Thanks, y'all... -Mat From yackd@wyoming.et.byu.edu Mon Oct 19 15:06 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 15:06:30 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Mon, 19 Oct 92 15:05:05 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Mon, 19 Oct 92 15:04:47 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 15:06:18 -0600 Received: from wyoming.et.byu.edu by yvax.byu.edu (PMDF #2655 ) id <01GQ4Y2C5V1S8WX5ZB@yvax.byu.edu>; Mon, 19 Oct 1992 15:04:40 MDT Received: by wyoming.et.byu.edu; Mon, 19 Oct 92 15:05:45 -0600 Date: 19 Oct 1992 15:05:45 -0600 From: yackd@wyoming.et.byu.edu (Don Yacktman) Subject: Re: Mockingboard To: na2sig@byu.edu Cc: patl@athena.mit.edu Message-Id: <9210192105.AA08063@wyoming.et.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO I'v got an old programmer's manual; I think it even has the info on the speech chip. It does list all the registers, waveforms, etc., and I assume that's what you want. It's small enough I could xerox and mail it to any interested parties... Later, -Don Yacktman yackd@alaska.et.byu.edu From mjhostet@slayer.MIT.EDU Mon Oct 19 21:44 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 21:44:18 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Mon, 19 Oct 92 21:42:52 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Mon, 19 Oct 92 21:42:35 mdt Received: from byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 21:42:35 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ5BVQ8HU88WX63Q@yvax.byu.edu>; Mon, 19 Oct 1992 21:41:00 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA03556; Mon, 19 Oct 92 23:40:56 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 19 Oct 1992 23:40:56 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Color mapping opinions wanted To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210200340.AA03556@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO You all probably know how screwed up Apple hi-res graphics are. The challenge for me is making it look as good as possible on the NeXT (even if that means making it look slightly different from a real Apple //). I would like some input on which display behavior you prefer. First let me describe how I'm drawing color. Let X be on pixels, o be off pixels, C be some color (or shade of gray on a grayscale machine) and W be white: oooXooo -> oooWooo In this situation, I assume that they really wanted a white dot so I draw it white. This makes thin white lines and text drawn on the hires screen look really good. ooXXooo -> ooWWooo Pretty standard...two pixels together are white. ooXoXoo -> oCCCCCo Here the algorithm "notices" a pattern and assumes that a color was desired, so it "smears" a color between and around the two (or more) pixels. ooXoXXX -> oCCCWWW This case is unclear, so I make the lone pixel become color and smear out. It makes the lookup tables smaller to do this... The first one is what I'm really concerned about. I'm thinking about making it look like: oooXooo -> oooCooo (note how the color does NOT spread out) I personally think it looks better on a grayscale machine to make it white, but now that I've been messing with color perhaps making it the "real" color on a color system would be the Right Thing to do. I don't have a color monitor for the Laser 128 here so I've had difficulty comparing two screens side by side. Any comments, anyone? This is your emulator, too... :-) -Mat From sounds!brianw@nwnexus.wa.com Tue Oct 20 00:54 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 00:54:57 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 00:53:31 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 00:53:13 mdt Received: from byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 00:54:52 -0600 Received: from nwnexus.wa.com by yvax.byu.edu (PMDF #2655 ) id <01GQ5IM3RC6O8WWF46@yvax.byu.edu>; Tue, 20 Oct 1992 00:53:19 MDT Received: from sounds.UUCP by nwnexus.wa.com with UUCP id AA09862 (5.65c/IDA-1.4.4 for byu.edu!na2sig); Mon, 19 Oct 1992 23:39:08 -0700 Received: by sounds. (NX5.67c/NX3.0S) id AA18943; Mon, 19 Oct 92 22:45:26 -0700 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 19 Oct 1992 22:45:26 -0700 From: Brian Willoughby Subject: Re: Color mapping opinions wanted To: NeXT Apple 2 Message-Id: <9210200545.AA18943@sounds.> Content-Transfer-Encoding: 7BIT Status: RO Mathew and all, Concerning the choices on how to display Apple ][ color, what about having a Preferences setting which takes effect immediately? You could allow for Monochrome display (B&W, Amber, Green, Color Well, etc.), Color display (by simple mapping), or even your Intelligent display. The reason that I suggest this is because I am concerned about speed. The smart Color mapping sounds like an impressive undertaking, but it might be slower. With a Preference, each person could decide what is best for the program they are trying to run on the emulator. You could even try some fancy algorithms in the Intelligent display map with the fallback for Monochrome. This would also support the rare Apple programs which used the 560x192 mono mode (you know, each 7-bit pixel group that was displayed could be shifted by a half pixel for a total of 560 pixels in the X dimension) - the Color modes would not support those programs very well. I was thinking that you could use a function pointer that is set by the Preference. Function pointer dereferencing is much faster than a conditional, and makes it simple to swap the Color Mapping routine on the fly. You might need a special routine to re-display the current Apple screen with the new mapping when someone changes the setting, or you could go for a spacy effect and just leave the old bits there. Sounds like you have a fun project going. Begin forwarded message: | From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) | | You all probably know how screwed up Apple hi-res graphics are. The | challenge for me is making it look as good as possible on the NeXT | (even if that means making it look slightly different from a real | Apple //). I would like some input on which display behavior you | prefer. I'll describe what I would like to see for three modes: Mono, Color, & Smart. | First let me describe how I'm drawing color. Let X be on pixels, o be | off pixels, C be some color (or shade of gray on a grayscale machine) | and W be white: | | oooXooo -> oooWooo | In this situation, I assume that they really wanted a | white dot so I draw it white. This makes thin white lines | and text drawn on the hires screen look really good. Mono & Smart modes would show white, Color would follow the rules for Apple color. | ooXXooo -> ooWWooo | Pretty standard...two pixels together are white. All three modes would show white, but the following: oXXoooo -> oCCoooo would show the funky edge colors that the Apple is famous for (only in "dumb" Color mode) | ooXoXoo -> oCCCCCo | Here the algorithm "notices" a pattern and assumes that a | color was desired, so it "smears" a color between and | around the two (or more) pixels. Mono would show two distinct pixels, possibly shifted a half-pixel is the high bit is on. Color and Smart mode may or may not differ with this input, you can play around in Smart mode to see what looks best, but plain Color mode you be concerned with top speed for video games (ha!, like we're going to be playing loads of action-packed Apple [p Games on our multi-thousand dollar, 15 MIPS machines :-) who knows? | ooXoXXX -> oCCCWWW | This case is unclear, so I make the lone pixel become color | and smear out. It makes the lookup tables smaller to do | this... You could probably get by with a single, 256-byte lookup table. Folks who still have their Apple handy with a color monitor or TV can help tweak the table (how about user loadable tables?, nothing fancy should be needed since the source code is around - just keep the table in a separate source file). | The first one is what I'm really concerned about. I'm thinking about | making it look like: | | oooXooo -> oooCooo (note how the color does NOT spread out) You can experiment with this by writing several mapping functions and swapping in each function under Preference control. | I personally think it looks better on a grayscale machine to make it | white, but now that I've been messing with color perhaps making it the | "real" color on a color system would be the Right Thing to do. Hey, if you like my idea, you can leave the "tweaking" of the color systems to other folks. | I don't have a color monitor for the Laser 128 here so I've had | difficulty comparing two screens side by side. Any comments, | anyone? This is your emulator, too... :-) Ditto; does anyone else have any comments? --- Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Consulting and Signal Processing Software NeXTmail welcome - NO EMAIL SOLICITATION without prior permission From yackd@maine.et.byu.edu Tue Oct 20 09:39 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 09:39:23 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 09:37:56 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 09:37:38 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 09:39:10 -0600 Received: from maine.et.byu.edu by yvax.byu.edu (PMDF #2655 ) id <01GQ60X3IUGW8WWHVQ@yvax.byu.edu>; Tue, 20 Oct 1992 09:37:32 MDT Received: by maine.et.byu.edu; Tue, 20 Oct 92 09:41:07 -0600 Date: 20 Oct 1992 09:41:07 -0600 From: yackd@maine.et.byu.edu (Don Yacktman) Subject: Re: Color mapping opinions wanted To: na2sig@byu.edu Message-Id: <9210201541.AA24455@maine.et.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO As to the question on single pixel color mapping: > oooXooo -> oooWooo on my //e, this case comes out in color...and on every 14th pixel, it's the double hires single pixel color, which means that a pixel that is normally orange comes out brown, and a blue pixel becomes a dark blue, but only if the high bit is on (green/violet don't have this odd behavior). It was this way on ][+, original //e, and enhanced //e. However, going with white here _does_ make lines and text much easier to read, so I think perhaps the best way to do this is to support BOTH, and let the user pick (via Preferences, or a menu item) which version is active. I know this is a bit more complex, but on the other hand, it gives the best of both worlds, and it seems to me that there are times when one is more appropriate than the other. Does that make sense? Whatever.... Later, -don From mjhostet@slayer.MIT.EDU Tue Oct 20 10:06 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 10:06:06 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 10:04:39 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 10:04:21 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 10:06:01 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ61UDDEPC8WXB7O@yvax.byu.edu>; Tue, 20 Oct 1992 10:04:23 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA04164; Tue, 20 Oct 92 12:04:18 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 20 Oct 1992 12:04:18 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Re: Color mapping opinions wanted To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210201604.AA04164@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO Brian Willoughby writes: >Concerning the choices on how to display Apple ][ color, what about >having a Preferences setting which takes effect immediately? You >could allow for Monochrome display (B&W, Amber, Green, Color Well, >etc.), Color display (by simple mapping), or even your Intelligent >display. Don Yacktman writes: >However, going with white here _does_ make lines and text much easier to >read, so I think perhaps the best way to do this is to support BOTH, and >let the user pick (via Preferences, or a menu item) which version is >active. I know this is a bit more complex, but on the other hand, it >gives the best of both worlds, and it seems to me that there are times >when one is more appropriate than the other. Brian and Don are right, a Preferences option is always the best answer...now, if I only HAD a preferences menu... :-) Don't worry, it's coming; Chris Osborn and I are talking about finally merging our two emulators into one super-emulator. To respond to Brian's suggestions, most of the complicated color display behavior changes you might want are as easy as changing a lookup table. Since the conversion routines are almost entirely lookup-table based you can use extremely complicated color mappings with no loss in performance. The only real question is how much context each pixel needs, as this affects the size of the lookup tables. However, in the quest for performance I wrote optimized special-case routines for monochrome (where there is obviously 0 context needed per pixel.) That particular routine must be much faster than the color one, but I haven't noticed any speedup. I can only infer that more CPU time is spent identifying what has changed, remembering what has changed, and blitting to the NeXT screen than is spent converting, at least for screens that don't change radically every frame. Anyway, since those routines are already written I'll use those routines for efficient amber, green, white, etc. Should you be able to associate color mapping preferences with individual disks somehow? How would you do it? The specs in the disk file format allow for arbitrarily large headers...or is this the Wrong way to go about it? -Mat From mjhostet@slayer.MIT.EDU Tue Oct 20 17:09 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 17:09:52 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 17:08:24 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 17:08:02 mdt Received: from byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 17:09:46 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ6GNN3GPC8WXJCD@yvax.byu.edu>; Tue, 20 Oct 1992 17:08:03 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA04690; Tue, 20 Oct 92 19:07:58 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 20 Oct 1992 19:07:58 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Re: Color mapping opinions wanted To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210202307.AA04690@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO Matt Ackeret writes: >first off.. bad idea.. If you're doing an emulator, do it RIGHT! >That is, emulate all of the funkiness.. Including how when two pixels of >(some certain colors, I don't know which) are near each other, they go >1/2 pixel closer to each other.. I agree that "absurdly accurate mode" should be an option. However, I suspect most programmers were pissed off at the Apple // graphics behavior and had to approximate what they wanted to display. We can give the user what the programmer _really_ wanted in many cases if we're clever. If someone sends me the "correct" graphics mapping algorithm I'll look into implementing it. Since I'm scaling horizontally by a factor of 2 we have half-pixels to play with. -Mat From mjhostet@slayer.MIT.EDU Tue Oct 20 17:12 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 17:12:56 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 17:11:28 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 17:11:06 mdt Received: from byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 17:12:53 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ6GRK0MRK8WXHLM@yvax.byu.edu>; Tue, 20 Oct 1992 17:11:14 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA04702; Tue, 20 Oct 92 19:11:08 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 20 Oct 1992 19:11:08 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: another graphics question To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210202311.AA04702@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO The Rescue Raiders title screen seems to have some pixel patterns that looks like: XXoXX Under my current algorithm this maps to: WWoWW But judging by the rest of the title screen it looks like they may have meant it to look like: WWCWW What does a real Apple //e look like with this pattern? I don't have access to a color monitor. -Mat From mjhostet@slayer.MIT.EDU Tue Oct 20 18:44 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 18:44:55 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 18:43:26 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 18:43:05 mdt Received: from byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 18:44:51 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ6JYL171C8WXKOY@yvax.byu.edu>; Tue, 20 Oct 1992 18:43:10 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA04872; Tue, 20 Oct 92 20:38:12 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 20 Oct 1992 20:38:12 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Inspector API To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210210038.AA04872@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO OK, I need to generate an Inspector API for the dynamically loadable PeripheralCard objects and I wanted some input. I've never written an inspector before, but it looks pretty easy. I looked at BackSpace, and here's what I'm thinking now. PeripheralCard (the superclass of all cards we'll write) should just be a subclass of object. It will support: - inspector:sender; /* Returns a View containing controls for the Inspector */ - inspectorInstalled; /* Called when the inspector is fully installed. */ - inspectorWillBeRemoved; /* Notifies the object that the inspector is about the be replaced. */ Of course, the card can leave out inspectorInstalled and inspectorWillBeRemoved, and if inspector:sender returns nil then there is no inspector... -Mat From yackd@maine.et.byu.edu Tue Oct 20 21:47 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 21:47:25 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 21:45:55 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 21:45:34 mdt Received: from byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 21:46:01 -0600 Received: from maine.et.byu.edu by yvax.byu.edu (PMDF #2655 ) id <01GQ6QB6T2NK8WXJKQ@yvax.byu.edu>; Tue, 20 Oct 1992 21:44:20 MDT Received: by maine.et.byu.edu; Tue, 20 Oct 92 21:47:57 -0600 Date: 20 Oct 1992 21:47:57 -0600 From: yackd@maine.et.byu.edu (Don Yacktman) Subject: Re: another graphics question To: na2sig@byu.edu Message-Id: <9210210347.AA21499@maine.et.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO > The Rescue Raiders title screen seems to have some pixel patterns > that looks like: > XXoXX > But judging by the rest of the title screen it looks like they may > have meant it to look like: > WWCWW Right. This is the correct behavior, not WWoWW. Whenever there's an off pixel bordered by an on pixel to either side, it's a color and not black. Later, -don From mjhostet@slayer.MIT.EDU Tue Oct 20 23:13 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 23:13:25 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 23:11:55 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 23:11:34 mdt Received: from byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 23:13:21 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ6TCH2X1S8WXL72@yvax.byu.edu>; Tue, 20 Oct 1992 23:11:40 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA05713; Wed, 21 Oct 92 01:11:36 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 21 Oct 1992 01:11:36 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: clock card To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210210511.AA05713@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO Does anyone have any info on how a clock card works, exactly? I've go the docs in the Prodos 8 Tech Ref Man, and they tell me how to give Prodos everything but the year, but I don't know the weirdnesses associated with installing periodic interrupts, etc. -Mat From mjhostet@slayer.MIT.EDU Wed Oct 21 00:00 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 00:00:47 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Tue, 20 Oct 92 23:59:17 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Tue, 20 Oct 92 23:58:55 mdt Received: from byu.edu by alaska.et.byu.edu; Tue, 20 Oct 92 23:59:28 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ6UYKY6V48WXJ7O@yvax.byu.edu>; Tue, 20 Oct 1992 23:57:44 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA05934; Wed, 21 Oct 92 01:57:40 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 21 Oct 1992 01:57:40 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: One more graphics question To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210210557.AA05934@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO Thanks for all the hires responses I've gotten! One more question to solve a pressing problem I have. Should ooXoXoo map to oCCCCCo or ooCCCoo? I'm doing the former right now but it turns out the latter is a hell of a lot easier (-> smaller + faster). The only problem with the latter is that a screen tiled like oXoXoXoXoX ... etc. won't "spread" to color the leftmost pixel on the NeXT screen. Is it OK anyway? I have a hunch that the Apple // hardware does something similar... -Mat From sounds!brianw@nwnexus.wa.com Wed Oct 21 01:59 MDT 1992 Received: from nwnexus.wa.com by maine.et.byu.edu; Wed, 21 Oct 92 01:59:23 -0600 Return-Path: Received: from sounds.UUCP by nwnexus.wa.com with UUCP id AA03295 (5.65c/IDA-1.4.4); Wed, 21 Oct 1992 00:51:43 -0700 Received: by sounds. (NX5.67c/NX3.0S) id AA03518; Wed, 21 Oct 92 00:36:15 -0700 Date: Wed, 21 Oct 92 00:36:15 -0700 From: Brian Willoughby Message-Id: <9210210736.AA03518@sounds.> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: mjhostet@athena.MIT.EDU Subject: Re: One more graphics question Cc: yackd@maine.et.byu.edu (Don Yacktman) Next-Attachment: .tar.344.Re__One_more_graphic_.attach, 5540, 1/1, 7656, 0 Status: RO begin 666 .tar.344.Re__One_more_graphic_.attach M'YV0:=R0*8/'A1PZ9@`H7,BPH<.'$"-*G$BQ(HB+-FC0``'@(H@8&CEZO`A# MY,B+-V;,N'&QAHP;,63`H!&CQ@R/-6#.Z%BQI\^?0(,*'4JTJ-&C2),J7;IT M#Y>#9F!P">-F3AJG9MZXH4-'#!LN4<'.N9-FSAP02,JPL5.&3IHQ87:`C0&6 M3IDQ:$!,R=-&S!LV._HHX-(FC)PS;&+"&%SXL!S%"IR.^?OFH%>Y&+`L'$#=@P;,.BREA%C1@W8,FS8P`%[ MADP9Q5/:@$WCI536-'#`>,W:=>VP8J2FD5J'C1NM9<3*H`%VC-0Q44%P4=`D M#!TT9>ZP6+\>2ADY:,+`.3OG39LRX(&@UAQE@`"7&R#8Q08;(.3Q1AT@A.%7 M'72`<$=^%>H'1QF&G47'&R"(42`99<'!1AAY:`:"5@G"EX8<(`0!AXD%MJ%5 M&A_*P4*(%(*0!`CYL14A@FD,%$:(81!(QHH(MI$'""BPD48;.&J6`@AK?'<' M&YJ=4>`;9H!`A14&OCA&'3C*D8<+]"DP!&4PC@E"62"P\<8;:P1T!@A9P7@D M'/D1V(*-9'3GGHHSN%`##DT@H8>%8;#59QLN7"3;I26AQM5]53'98H$RTAAA M9G.ZT0*@21:(0I^?@@!''7+`\0:!*X;Y'ITDSG&F66EH=2552^8F;`RNNF>7 M')T:5F`,T@UF!K&P.%O2BA2V`.:I@991J9CP`9G&&6BT(`:.(,R!1AIFT.$A M?+2.JVZ(3^;'AAD[LIK#8G.!$"U8TP(+@G/.0BOM1:@2.,>V5'1;<($$OOM> M@6B,MJ._#T?(EAQA>%EKJ^"=Y:\>]\U:;EOK%AB0757AN.9%2+Q8QEF3V2F' MQZ2&L2"0-H=Y\F=6T?$D"C7`4`*3+Z>PHQ@]ROSRD$N2\:!79;1P;F8P4Q5B M@3+4,'1E(-R@=:DH][QRC#?'<,)97-O,(`QG@T!U=^\&!,)WD$I:61L[JE'' M'!D:J!7?5%5(Q!`@V&&SQ.6"N'<=:C])=\Q4"S[U:=]'A/8(BAM'&Z6\4#2_RQ+J[8W\^6BC[DL.S'>[>HSMRQ:X[M)L1 MAV#DE3",80W;0L(;KG>QB8&@)!=Z2UZRLJ`)>NPC?D/@U5!@XB`^.0PCDF_87$,RU2DZ+:UR=,L8? M_\3G>'++C`/=PKP_5DQUS%N:W"HVNM(Q:#)4JJ09O#>_BH6*2U`RY8Q02:?@ MN8U#"WJ2E]QP'_=P;PVS@@^,G$"%*0PA!5Y4P!,05+$W/`Q&^1'(CI)P@OGI MC6]ND]\+]P2F,.VG#'5P6H((0@=QW6D-0QK+?0YVD2P\"`14`M?Y+*06!DFI MBL0$T85TMZ$WB$I9Y=)B)>FD(65MQ5,/>Q$Z;Y2C.4R,#>]Y$+@2]Q^W_.%ADGOTU)^B.,4)"<0P:VH3%%PP!83ILD#X M[`_NJ.(?FZ5A:;5[PQC2<*@ED>4]WJ(:"#JC'Q^2TT=AQNS21F+>IPUH"U-&YU0A.^'I+%):`TPY1Q9#5DRKAX(2 M2%PP`ZSN*(,_I--8*V:'(@&H3'(X4YJ>M,ENG;)`7=C"G#R61,;%TFUU<(,; MN.<>'BKU!#<+WEL8YDCHW:>BYV+>64!'S&Z=:Z'/HU/#_F@N="G1521EPUG$ M\*0CRBUD)M9"G30IL%T!P1"R(-=0&"% MPY7!O=X!3WGH@AYB)0"_Y3E/>IQ6!ZBU8*OWY4)WOD/+_7*AOR!(P'\5_!4S MF.?!Z>%=9=:#7P87"`;#$E8"0!P#V>3&Q"4&<0((;."I+0T*L!(5"GZ0@O6$ M^%()2/&)28SB&"1`!"!@0ODJ=(3I0HG&Z]&AB'_`XR;O^,<@>`+&,GGD&BL@ MQ3I,P`]TS&440[D)Q+L=?+VK*B0K0,)H3L!(O+">-$MX))IUJVESU@*RD`&H M<(CM>GYDW)L*";GG@NAHCT<$%F5ADH5!T!V2]$HSW(=\E33B9-P@WLE&NELB M``F>8PMD$5&6?@5&I8MA!J=@KG2E+;W(%,0H0CX7:#)PR`/W.K<5ET5(2HQF M$<;Z(B71UBD-:FU167ZPGA88>SU"()_5KA`].]4!7+1-P!3`1(=%DXH(+_L6 M@HK`O("4X3X[$L(4BE`$$#AA"%.H`K*5[88K`&':D25#2Z\0!!>`4MH/LNZ; MJ@(WREIW"MHV'12\ASE>57+:Z;)V>!3@A#)@@0J%B1X[V0#*,B2@!>9^`@B* MT(0@)($)>GD"$Y(PA"10(0A42,(3G`"]A/9H::5-R"[#&>36 M)VL/9$D/G4/&RL!>UQ'A4#KX%[&>D,2/Y"`',KA@#'20$QW0H"0MF`F(UV,$ M4B:]#6H08Q7I`(0YG"A%N6&+[XAZ:63P>B`0-LZN$`S=5B/%#*WQQ90 MX?'H#/NL[$)V]\"G=&IGN]O5[2:MH*R;5)CR'!PMAQ9P>S++.T/2;R`$D[`!BJK5"`O\`(X0U$*1S]+(U-M M$5I[8A54NDBV#\@:%TH"(HBB, MXB@R-"G;HF3%XH`*6%IN>$^D$A#8DBI0PBH5\RJQ,BMEP!3JN([LV([N^([P M&(_R.(_T6(_V>(_XF(_ZN(_\V(_^^(\`"9"W4R!M"`+#*$3`HUW#0R)-]T9' MPB5AD'L7%"(&U&PCQ$'6@SW:PSVC]#U/R#GC,X",QDGJ4TGLDT3O#Q3.$4!4441>44E`E'<6"X!]TG^P9&DU"JBB`*J)"JMI%V2]%BS5$N4M">X9"X!R$N^ M!$QM,DP<A">".4[;8DX0DD[F4Y43 MYTYE@3)_-%;UY(T,HT][PD\SXD\5\HD"92.D6!D&=6LNMU!XZ%":I%%G,5$5 M!2(7U4,%U)\<96E[0A`@]20L,E)4&"+Y1@8H96HL18(U0RIX."0U)24X918Z MQ5-4N8+'5WA&Q85)=4Y,M3''%U4X,E5=8U4V@%4Q&4U<52K;1'-A):`Z>8QH M!6QKE2!MA9G%12X()E;1H5[1JA^AIFZ35FG^5R"91@/_JA:=!HJ5="2R"C$N0VHR(Z&HMBWIUVHC M!&NR=FD%4CFV9E.YAB#/V6N>^6O!9K#$I@#&U@+KQE,(PFP=]&QH$&T(5VWX MA&V=M''=1DO@!E_C5F[GEFX_2Q7N!F\",6_U=F]8NR3[9CL(Y6]+`G"D(W`$ M]S+@MR='JW#K@8401UX,6AWF:QWEYX'F@!W9B1WI`(+NHU[JORWK[ M]GJ>)WNT9WN4YHQZLGN]1P5^&7S#ES8W4S''1S7*MY;-1WC&A#+2%V6_.WC$ MJWC9%T^)LQ8PY2K?QSTHR*=GF(K!E+(\>27\K`B/V-W]O8(:2 MVG\NVT3_`2/DLZU:PB,Z20<)B#8]XH0M^(`?!!\WHY44:#E) Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Wed, 21 Oct 92 09:33:22 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Wed, 21 Oct 92 09:33:00 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 09:34:32 -0600 Received: from JIMI.CS.UNLV.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ7F1IM8UO8WXOHE@yvax.byu.edu>; Wed, 21 Oct 1992 09:32:50 MDT Received: from sonny-boy.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa15644; 21 Oct 92 8:28 PDT Date: 21 Oct 1992 08:28:22 -0700 From: Scott Alfter Subject: Re: One more graphics question To: na2sig@byu.edu Message-Id: <01GQ7F1LWEBQ8WXOHE@yvax.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO In message <9210210557.AA05934@slayer.MIT.EDU>, mjhostet@athena.MIT.EDU wrote: >Should ooXoXoo map to oCCCCCo or ooCCCoo? I'm doing the former right >now but it turns out the latter is a hell of a lot easier (-> smaller >+ faster). The latter is also the way a real Apple II works. :-) If you're concerned about a pattern not going all the way to the edge of the window, you might want to provide some black space around the active image area. It'd be like a real monitor, which doesn't give you an edge-to-edge display. _/_ Scott Alfter Internet: sknkwrks@cs.unlv.edu / v \ Call the Skunk Works BBS today! Ask me about SoftDAC--digital (IIe ( (702) 894-9619 300-14400 V.32bis audio for your Apple IIe/IIc! \_^_/ If Bill Clinton is the answer, it must've been a damn stupid question!! From sknkwrks@sonny-boy.cs.unlv.edu Wed Oct 21 09:34 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 09:34:58 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Wed, 21 Oct 92 09:33:26 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Wed, 21 Oct 92 09:33:04 mdt Received: from byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 09:34:37 -0600 Received: from JIMI.CS.UNLV.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ7F1IM8UO8WXOHE@yvax.byu.edu>; Wed, 21 Oct 1992 09:32:46 MDT Received: from sonny-boy.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa15595; 21 Oct 92 8:24 PDT Date: 21 Oct 1992 08:24:07 -0700 From: Scott Alfter Subject: Re: clock card To: na2sig@byu.edu Message-Id: <01GQ7F1IOXAQ8WXOHE@yvax.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO In message <9210210511.AA05713@slayer.MIT.EDU>, mjhostet@athena.MIT.EDU wrote: >Does anyone have any info on how a clock card works, exactly? I've >go the docs in the Prodos 8 Tech Ref Man, and they tell me how to >give Prodos everything but the year, but I don't know the weirdnesses >associated with installing periodic interrupts, etc. The clock isn't supposed to provide the year--it provides the date, month, and day-of-the-week (as well as the time, of course). The year is calculated based on the information provided; that's why people's Apple IIs went back to 1986 at the start of this year. (Apple should've had a new version of ProDOS 8 out by then that would've worked properly.) I have an AE Timemaster HO...its manual describes the behavior of the Thunderclock, which is what ProDOS expects to work with. I'll have to remember to dig up the manual for it and post the specs. _/_ Scott Alfter Internet: sknkwrks@cs.unlv.edu / v \ Call the Skunk Works BBS today! Ask me about SoftDAC--digital (IIe ( (702) 894-9619 300-14400 V.32bis audio for your Apple IIe/IIc! \_^_/ If Bill Clinton is the answer, it must've been a damn stupid question!! From yackd@alaska.et.byu.edu Wed Oct 21 09:37 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 09:37:43 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Wed, 21 Oct 92 09:36:11 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Wed, 21 Oct 92 09:35:49 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 09:37:39 -0600 Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF #2655 ) id <01GQ7F5H83IO8WXH6M@yvax.byu.edu>; Wed, 21 Oct 1992 09:35:57 MDT Received: by alaska.et.byu.edu; Wed, 21 Oct 92 09:37:28 -0600 Date: 21 Oct 1992 09:37:28 -0600 From: yackd@alaska.et.byu.edu (Don Yacktman) Subject: Re: One more graphics question To: na2sig@byu.edu Message-Id: <9210211537.AA00692@alaska.et.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO Brian's explanation of this is pretty good... > ?1100110011001 Medium Blue (?) > ^ > notice the half-width pixel > I believe that this is what Don Yactman was referring to > concerning the "14th pixel " being a double hires color. Exactly. This is what's going on. Notice that orange has this effect, too, but on a different byte boundary: > ?0011001100110 Orange (?) if extended, would be ?001100110011001100110011001 which has the problem here: ^ So, I think, actually the pattern ends up repeating every 28 pixels for a given color, but that there is an anomaly (orange/brown or blue/dk.blue) every 14 pixels. Note also that this only happens when the dot is not bordered on both sides by the color. For example, a solitary pixel will display this problem, but if it's the end of a horizontal line, it doesn't. (However, since the color _is_ darker, it is possible that the line is just masking the the color via bleeding on the screen, etc. However, if there is color on both sides, then the "1/2 pixel" becomes a full "0110" pixel, and this effect definitely disappears.) Another thing to note is that our model will probably end up being more "perfect" than most Apple ][ screens ever were...I always found TVs to bleed and smear the colors pretty bad. (As Brian said, the "NTSC" the ][ puts out is more than the TV can handle...and so you see low pass filtering effects on most TVs that end up making the pixel boundaries smear a bit.) If we want a "perfect" emulation, by the way, you have to follow these hires dot coloring rules on the text screen when in a split graphics/text mode, too. Why? Because in only text mode, the ][ cuts off the color burst signal, but whenever in a graphics mode, the ][ turns it on and the text get just as colorized as the hires screen, making it more difficult to read. Thus, in a mixed text/graphics mode, you ought to treat the text as if it were graphics. Nasty huh? This is one quirk that ought to be on a Preferences panel, though, because I'd sure like to be able to turn it off! For completeness, it probably ought to be in the emulator, but I'd rather run the emulator with readable text! :) It's ironic that most of the complexity we're talking about here is caused by the ultra simple method used to implement the ]['s grpahics hardware! :-) Later, -don From yackd@alaska.et.byu.edu Wed Oct 21 09:41 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 09:41:32 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Wed, 21 Oct 92 09:40:00 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Wed, 21 Oct 92 09:39:38 mdt Received: from byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 09:41:28 -0600 Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF #2655 ) id <01GQ7FA7TGG08WXH1K@yvax.byu.edu>; Wed, 21 Oct 1992 09:39:46 MDT Received: by alaska.et.byu.edu; Wed, 21 Oct 92 09:41:19 -0600 Date: 21 Oct 1992 09:41:19 -0600 From: yackd@alaska.et.byu.edu (Don Yacktman) Subject: Re: One more graphics question To: na2sig@byu.edu Message-Id: <9210211541.AA01655@alaska.et.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO ? > If you're concerned about a pattern not going all the way to the edge > of the window, you might want to provide some black space around the > active image area. It'd be like a real monitor, which doesn't give [4~> you an edge-to-edge display. I like this idea. In fact, to make it look like a real monitor, you could grab the bezel tiffs out of the 3.0 version of boink out, stretch them with Icon (or something better than IconBuilder) and use them to border the virtual monitor. That would look really cool...and quite NeXTish, too. Later, -don From sknkwrks@sonny-boy.cs.unlv.edu Wed Oct 21 12:31 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 12:31:41 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Wed, 21 Oct 92 12:30:09 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Wed, 21 Oct 92 12:29:45 mdt Received: from byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 12:31:30 -0600 Received: from JIMI.CS.UNLV.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ7L80RN2O8WXQBY@yvax.byu.edu>; Wed, 21 Oct 1992 12:29:48 MDT Received: from sonny-boy.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa22170; 21 Oct 92 11:20 PDT Date: 21 Oct 1992 11:20:25 -0700 From: Scott Alfter Subject: Re: One more graphics question To: na2sig@byu.edu Message-Id: <01GQ7L80U1VM8WXQBY@yvax.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO In message <9210211537.AA00692@alaska.et.byu.edu>, Don Yacktman wrote: >If we want a "perfect" emulation, by the way, you have to follow these >hires dot coloring rules on the text screen when in a split graphics/text >mode, too. Why? Because in only text mode, the ][ cuts off the color >burst signal, but whenever in a graphics mode, the ][ turns it on and >the text get just as colorized as the hires screen, making it more >difficult to read. Thus, in a mixed text/graphics mode, you ought to >treat the text as if it were graphics. Nasty huh? This is one quirk >that ought to be on a Preferences panel, though, because I'd sure like >to be able to turn it off! For completeness, it probably ought to be >in the emulator, but I'd rather run the emulator with readable text! :) The IIGS always displays readable text--in whatever color is selected in the Control Panel. If you put an RGB card in a IIe, text remains readable. It's only with a composite monitor or TV that text on a mixed screen becomes colorized. _/_ Scott Alfter Internet: sknkwrks@cs.unlv.edu / v \ Call the Skunk Works BBS today! Ask me about SoftDAC--digital (IIe ( (702) 894-9619 300-14400 V.32bis audio for your Apple IIe/IIc! \_^_/ If Bill Clinton is the answer, it must've been a damn stupid question!! From mjhostet@slayer.MIT.EDU Wed Oct 21 14:04 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 14:04:34 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Wed, 21 Oct 92 14:03:01 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Wed, 21 Oct 92 14:02:39 mdt Received: from byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 14:04:29 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ7OH4WY008WXN9H@yvax.byu.edu>; Wed, 21 Oct 1992 14:02:41 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA06334; Wed, 21 Oct 92 16:02:35 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 21 Oct 1992 16:02:35 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Re: clock card To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210212002.AA06334@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO >The clock isn't supposed to provide the year--it provides the date, >month, and day-of-the-week (as well as the time, of course). The year >is calculated based on the information provided; that's why people's >Apple IIs went back to 1986 at the start of this year. (Apple >should've had a new version of ProDOS 8 out by then that would've >worked properly.) With my card installed, AppleWorks gets everything right but thinks the year is 1987. The ProDOS 8 Technical Reference Manual says: "The year is looked up in a table in the clock driver". I checked what addresses in $Cn00 the system was looking at when AppleWorks booted, and it first checked $Cn05, then the signature bytes, then looked at every byte from $CnFF to $Cn00, in that order. >I have an AE Timemaster HO...its manual describes the behavior of the >Thunderclock, which is what ProDOS expects to work with. I'll have to >remember to dig up the manual for it and post the specs. That would be great! -Mat From yackd@alaska.et.byu.edu Wed Oct 21 18:21 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 18:21:11 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Wed, 21 Oct 92 18:19:38 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Wed, 21 Oct 92 18:19:16 mdt Received: from byu.edu by alaska.et.byu.edu; Wed, 21 Oct 92 18:21:01 -0600 Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF #2655 ) id <01GQ7XF91UEO8WXS8J@yvax.byu.edu>; Wed, 21 Oct 1992 18:19:14 MDT Received: by alaska.et.byu.edu; Wed, 21 Oct 92 18:20:46 -0600 Date: 21 Oct 1992 18:20:46 -0600 From: yackd@alaska.et.byu.edu (Don Yacktman) Subject: Re: One more graphics question To: na2sig@byu.edu, sknkwrks@sonny-boy.cs.unlv.edu Message-Id: <9210220020.AA03228@alaska.et.byu.edu> Content-Transfer-Encoding: 7BIT Status: RO > The IIGS always displays readable text--in whatever color is selected > in the Control Panel. If you put an RGB card in a IIe, text remains > readable. It's only with a composite monitor or TV that text on a > mixed screen becomes colorized. True enough...but nobody I knew could afford an RGB card...we all used TVs, and so I still say the "colorized" text is a valid thing to consider, awful though it is. :) At any rate, this graphics trivia stuff is certainly interesting at least in that it shows how much better things are now... Later, -don From mjhostet@slayer.MIT.EDU Thu Oct 22 11:49 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Thu, 22 Oct 92 11:49:35 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Thu, 22 Oct 92 11:47:58 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Thu, 22 Oct 92 11:47:35 mdt Received: from byu.edu by alaska.et.byu.edu; Thu, 22 Oct 92 11:49:01 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ8Y1GSCKW8WXLLG@yvax.byu.edu>; Thu, 22 Oct 1992 11:47:09 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA07602; Thu, 22 Oct 92 13:47:04 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 22 Oct 1992 13:47:04 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Inspector behavior suggestions? To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210221747.AA07602@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: RO I'm working on the inspector for the peripheral cards now, and I was wondering what it should look like. I want to be able to drag peripheral cards into different slots and highlight any of the cards in any of the slots to bring up the inspector for that card (sort of like the shelf in the File Viewer). I tried making a Matrix of ButtonCells with one card per cell, but I thought that looked pretty lousy. What we really want is something that actually looks like a bus, maybe with the various slots numbered appropriately. The card TIFF I have is a side view of a card, so we might want the bus arranged vertically on the right edge of the window so you can really plug cards in to the bus. Below each card can be the name that card chooses for itself. Does this sound good or do y'all have any better ideas? I'd like suggestions and maybe a few appropriate TIFFS for this... -Mat From fozztexx%marauder.uucp@groucho.sonoma.edu Sun Nov 8 15:53 MST 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Sun, 8 Nov 92 15:53:38 -0700 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Sun, 8 Nov 92 15:53:03 -0700 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Sun, 8 Nov 92 15:51:33 mst Received: from byu.edu by alaska.et.byu.edu; Sun, 8 Nov 92 15:53:16 -0700 Received: from mvax.Sonoma.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQWXJLSLTC8X15HZ@yvax.byu.edu>; Sun, 8 Nov 1992 15:52:33 MST Received: by mvax.Sonoma.EDU (5.57/Ultrix2.4-C) id AA03917; Sun, 8 Nov 92 14:52:57 -0800 Received: by groucho.sonoma.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA20919; Sun, 8 Nov 92 14:50:29 GMT-0800 Received: by nvcc (NX5.67c/NeXT-2.0) id AA02026; Sun, 8 Nov 92 14:36:48 -0800 Received: by marauder. (NX5.67c/NX3.0M) id AA00890; Sun, 8 Nov 92 13:41:09 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 08 Nov 1992 13:41:09 -0800 From: Chris Osborn Subject: Icons and Windows To: na2sig@byu.edu Message-Id: <9211082141.AA00890@marauder.> Content-Transfer-Encoding: 7BIT Status: RO For some reason I can't get windows to archive or unarchive themselves. Is there some trick to this? For now, when you save the config, it won't save the window config, because I'm just doing a loadNibSection, instead of unarchiving a stored window. I need an icon for .a2config files. I can't make them double clickable until I do. --- Chris Osborn Napa Valley College fozztexx%nvcc.uucp@groucho.sonoma.edu <- Preferred fozztexx@groucho.sonoma.edu NeXTMail ok at both From mjhostet@slayer.MIT.EDU Tue Nov 24 21:44:27 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA17998; Tue, 24 Nov 92 21:44:26 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA00523 (5.65c/IDA-1.4.4 for ); Tue, 24 Nov 1992 19:53:50 -0800 Received: from byu.edu by alaska.et.byu.edu; Tue, 24 Nov 92 18:35:42 -0700 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GRJFWFC5Y88WW08D@yvax.byu.edu>; Tue, 24 Nov 1992 18:35:43 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA06516; Tue, 24 Nov 92 20:35:37 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 24 Nov 1992 20:35:37 -0500 From: "Mathew J. Hostetter" Subject: Re: Newbie na2sig questions To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9211250135.AA06516@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Speaking as the author of what you were probably playing around with, everything is really rough around the edges. Fortunately, Chris Osborn has taken my code and is (hopefully) grafting on all sorts of nice features from his emulator (Diamond) and also cleaning up the installation process. What's your status, Chris? -Mat From nvcc!fozztexx@groucho.sonoma.edu Thu Dec 3 15:40:39 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA10649; Thu, 3 Dec 92 15:40:38 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA27266 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 14:21:43 -0800 Received: from yvax2.byu.edu by alaska.et.byu.edu; Thu, 3 Dec 92 15:14:17 -0700 Received: from mvax.Sonoma.EDU by yvax.byu.edu (PMDF #2655 ) id <01GRVTH0UTQ88WWF0Z@yvax.byu.edu>; Thu, 3 Dec 1992 15:13:40 MST Received: by mvax.Sonoma.EDU (5.57/Ultrix2.4-C) id AA05655; Thu, 3 Dec 92 14:14:04 -0800 Received: by groucho.sonoma.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA10771; Thu, 3 Dec 92 14:12:34 GMT-0800 Received: by nvcc (NX5.67c/NeXT-2.0) id AA16297; Thu, 3 Dec 92 14:11:39 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 03 Dec 1992 14:11:39 -0800 From: fozztexx%nvcc.uucp@groucho.sonoma.edu (Chris Osborn) Subject: Interface for selecting cards for slots To: na2sig@byu.edu Message-Id: <9212032211.AA16297@ nvcc > Content-Transfer-Encoding: 7BIT I need a good way to be able to select and modify cards in slots. Mathew J. Hostetter suggests having multiple a well for every slot, to allow the user to drop cards into slots. That sounds good to me, however, the way I have things set up right now, all the installed cards have an icon in a scrolling matrix, similar to the Preferences.app. The problem is what to do about having multiple of the same card installed into one computer. Right now, you would get two of the same icon in the matrix, with no indication of which one goes in which slot. I was thinking that maybe double clicking the card in the well could allow you to bring up the inspector for that card, just below it. I'm not sure I like that idea. Anyone have some good suggestions? --- Chris Osborn, Network Administrator Napa Valley College fozztexx%nvcc.uucp@groucho.sonoma.edu <- Preferred fozztexx@groucho.sonoma.edu NeXTMail ok at both From john@arissoft.com Thu Dec 3 21:44:41 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA13807; Thu, 3 Dec 92 21:44:39 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA04576 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 20:15:20 -0800 Received: from byu.edu by alaska.et.byu.edu; Thu, 3 Dec 92 21:09:09 -0700 Received: from deepthought.cs.utexas.edu by yvax.byu.edu (PMDF #2655 ) id <01GRW5TPENJ48WVYXO@yvax.byu.edu>; Thu, 3 Dec 1992 21:07:29 MST Received: from im4u.cs.utexas.edu by deepthought.cs.utexas.edu (5.64/1.2/relay) with SMTP id AA20239; Thu, 3 Dec 92 20:08:35 -0600 Received: from avsoft by im4u.cs.utexas.edu (5.64/1.8.1/uucp) with UUCP id AA28916; Thu, 3 Dec 92 20:07:52 -0600 Received: from ballantyne by arissoft.com (NX5.67c/NeXT-2.0g) id AA00839; Thu, 3 Dec 92 19:57:43 -0600 Received: by ballantyne. (NX5.67c/NX3.0X) id AA00830; Thu, 3 Dec 92 19:57:53 -0600 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 03 Dec 1992 19:57:53 -0600 From: John Dawson Subject: Re: Interface for selecting cards for slots To: na2sig@byu.edu Message-Id: <9212040157.AA00839@arissoft.com> Content-Transfer-Encoding: 7BIT > Mathew J. Hostetter suggests having multiple a well for every > slot, to allow the user to drop cards into slots. That sounds > good to me, however, the way I have things set up right now, all > the installed cards have an icon in a scrolling matrix, similar > to the Preferences.app. > > The problem is what to do about having multiple of the same card > installed into one computer. Right now, you would get two of the > same icon in the matrix, with no indication of which one goes in > which slot. Hmm. I think Mat's UI design is a better plan here -- how much work would it be to do it instead? You've got to specify which slot each card goes in anyway; it would be more intuitive to have seven wells, with zero or one cards in each well. Consider the consequences of a Preferences-like scrolling matrix: you must set a slot number for each slot *ANYWAY* (at least, I hope so!); if you do it numerically, by letting the user have a slider or type in a slot number or something, you have to worry about slot number collisions, and besides, there's no good way to view all the slots at once to get a visual feel for what's where. If you support such a panaramic view of the slots, you may as well make them slot wells and let the user drop cards into them. Incidentally, is there any possibility for peripheral cards getting any screen real estate apart from when you pop up an inspector for them? Mostly, I could live without this, but it would be *VERY* handy to have disk drive wells, so you could drag a disk icon from the Workspace Manager into a drive well and have that disk be inserted. Other cards might benefit; for example, a small volume dial might be nifty if somebody finishes a Mockingboard card (though a normal inspector would be adequate for this, since you wouldn't really be playing with it that often). It would be nice to have such wells be easily accessible; I think a Shelf setup, like in recent versions of Stuart, would be good for this. It might be possible to kill two birds with one stone and have a row of seven slot wells on the shelf of each emulator window, thus getting slots easily visible and accessible too. I can appreciate the current minimalist UI aesthetic -- but without some easily accessible disk drive wells at the very least, the UI is non-functional. ..jkd ..jkd From mjhostet@slayer.MIT.EDU Thu Dec 3 21:44:46 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA13840; Thu, 3 Dec 92 21:44:45 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA05448 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 21:07:54 -0800 Received: from byu.edu by alaska.et.byu.edu; Thu, 3 Dec 92 22:01:47 -0700 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GRW7P97GF48WVZII@yvax.byu.edu>; Thu, 3 Dec 1992 22:01:10 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA06562; Fri, 4 Dec 92 00:01:04 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 04 Dec 1992 00:01:04 -0500 From: "Mathew J. Hostetter" Subject: Re: Interface for selecting cards for slots To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9212040501.AA06562@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT >Incidentally, is there any possibility for peripheral cards getting >any screen real estate apart from when you pop up an inspector for >them? Perhaps it should be possible for PeripheralCards to be notified when something (which is not another card) is dragged onto their "slot" icon? That way you wouldn't have to actually bring up the inspector for that particular card when all you want to do is feed it a file. This still requires having the 7 slots visible somewhere, though, and you've got to be careful when they have multiple emulators open. Long ago I used to have space reserved above the Apple //e screen in the same window for peripheral card slots, but I think I like the minimalist approach better. After all, how often do you switch cards or manipulate them in general? I would prefer a simple command-key sequence to bring up the peripheral card inspector to an approach that permanently reserves screen space for the cards. Maybe if "cmd-6" brought up the inspector for the card in slot 6, and so on? -Mat From nvcc!fozztexx@groucho.sonoma.edu Fri Dec 4 13:39:49 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA20665; Fri, 4 Dec 92 13:39:48 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA24437 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 11:43:41 -0800 Received: from yvax2.byu.edu by alaska.et.byu.edu; Fri, 4 Dec 92 12:37:32 -0700 Received: from mvax.Sonoma.EDU by yvax.byu.edu (PMDF #2655 ) id <01GRX2AV28CW8ZDYQK@yvax.byu.edu>; Fri, 4 Dec 1992 12:36:47 MST Received: by mvax.Sonoma.EDU (5.57/Ultrix2.4-C) id AA08976; Fri, 4 Dec 92 11:37:14 -0800 Received: by groucho.sonoma.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA11821; Fri, 4 Dec 92 11:35:41 GMT-0800 Received: by nvcc (NX5.67c/NeXT-2.0) id AA17434; Fri, 4 Dec 92 11:35:20 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 04 Dec 1992 11:35:20 -0800 From: fozztexx%nvcc.uucp@groucho.sonoma.edu (Chris Osborn) Subject: Re: Interface for selecting cards for slots To: na2sig@byu.edu Message-Id: <9212041935.AA17434@ nvcc > Content-Transfer-Encoding: 7BIT > >Incidentally, is there any possibility for peripheral cards getting > >any screen real estate apart from when you pop up an inspector for > >them? > Perhaps it should be possible for PeripheralCards to be notified > when something (which is not another card) is dragged onto their > "slot" icon? That way you wouldn't have to actually bring up > the inspector for that particular card when all you want to do > is feed it a file. This still requires having the 7 slots > visible somewhere, though, and you've got to be careful when > they have multiple emulators open. That still sounds like a good idea. I was also planning to support simply dragging files onto the emulator window. Of course, this would require asking each card whether they know how to access the file or not, so cards in higher slots would get first chance at any file inserted this way. Even dropping a file onto the icon in the well wouldn't be perfect. A disk drive card wouldn't know if you wanted the disk inserted into drive 1 or drive 2. > Long ago I used to have space reserved above the Apple //e > screen in the same window for peripheral card slots, but I think > I like the minimalist approach better. After all, how often do > you switch cards or manipulate them in general? I would prefer > a simple command-key sequence to bring up the peripheral card > inspector to an approach that permanently reserves screen space > for the cards. Maybe if "cmd-6" brought up the inspector for > the card in slot 6, and so on? Yes, I suppose that would work. Would be pretty easy to do as well. --- Chris Osborn, Network Administrator Napa Valley College fozztexx%nvcc.uucp@groucho.sonoma.edu <- Preferred fozztexx@groucho.sonoma.edu NeXTMail ok at both From nvcc!fozztexx@groucho.sonoma.edu Fri Dec 4 13:39:51 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA20676; Fri, 4 Dec 92 13:39:50 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA24446 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 11:43:56 -0800 Received: from yvax2.byu.edu by alaska.et.byu.edu; Fri, 4 Dec 92 12:37:34 -0700 Received: from mvax.Sonoma.EDU by yvax.byu.edu (PMDF #2655 ) id <01GRX2AWFSPC8ZDXQZ@yvax.byu.edu>; Fri, 4 Dec 1992 12:36:49 MST Received: by mvax.Sonoma.EDU (5.57/Ultrix2.4-C) id AA08974; Fri, 4 Dec 92 11:37:11 -0800 Received: by groucho.sonoma.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA11814; Fri, 4 Dec 92 11:35:39 GMT-0800 Received: by nvcc (NX5.67c/NeXT-2.0) id AA17431; Fri, 4 Dec 92 11:35:18 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 04 Dec 1992 11:35:18 -0800 From: fozztexx%nvcc.uucp@groucho.sonoma.edu (Chris Osborn) Subject: Re: Interface for selecting cards for slots To: na2sig@byu.edu Message-Id: <9212041935.AA17431@ nvcc > Content-Transfer-Encoding: 7BIT > > Mathew J. Hostetter suggests having multiple a well for every > > slot, to allow the user to drop cards into slots. That sounds > > good to me, however, the way I have things set up right now, all > > the installed cards have an icon in a scrolling matrix, similar > > to the Preferences.app. > > > > The problem is what to do about having multiple of the same card > > installed into one computer. Right now, you would get two of the > > same icon in the matrix, with no indication of which one goes in > > which slot. > Hmm. I think Mat's UI design is a better plan here -- how much > work would it be to do it instead? You've got to specify which > slot each card goes in anyway; it would be more intuitive to > have seven wells, with zero or one cards in each well. Well, I was sorta actually wanting both. Not only do I have the cards have an icon in the scrolling view, but other controls that are built-in also have icons, like the keyboard and display. I was thinking of just adding another built-in inspector to allow the selection of cards with wells. When a card is added or removed from the well, its icon would then also be added or removed from the list. The confusion would then come from having several of the same card loaded. You wouldn't know which icon went to which slot. Perhaps simply putting "Slot X" below the icon in the button would suffice? --- Chris Osborn, Network Administrator Napa Valley College fozztexx%nvcc.uucp@groucho.sonoma.edu <- Preferred fozztexx@groucho.sonoma.edu NeXTMail ok at both From sounds!brianw Fri Dec 4 15:39:23 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA21418; Fri, 4 Dec 92 15:39:22 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA29892 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 15:29:04 -0800 Received: from byu.edu by alaska.et.byu.edu; Fri, 4 Dec 92 16:20:33 -0700 Received: from nwnexus.wa.com by yvax.byu.edu (PMDF #2655 ) id <01GRXA3D3M2O8ZE1RA@yvax.byu.edu>; Fri, 4 Dec 1992 16:19:54 MST Received: from sounds.UUCP by nwnexus.wa.com with UUCP id AA29323 (5.65c/IDA-1.4.4 for byu.edu!na2sig); Fri, 4 Dec 1992 15:02:32 -0800 Received: by sounds. (NX5.67c/NX3.0S) id AA20728; Fri, 4 Dec 92 14:30:03 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 04 Dec 1992 14:30:03 -0800 From: Brian Willoughby Subject: Re: Interface for selecting cards for slots To: na2sig@byu.edu Reply-To: sounds!brianw Message-Id: <9212042230.AA20728@sounds.> Content-Transfer-Encoding: 7BIT Perhaps I am not aware of the history behind the designs being worked on, but I have a few suggestions. Why does everything have to be in one main window? Couldn't there be a window devoted to card slots that could be opened by a menu option and then closed when no longer needed? The slot window could have a ScrollView with sizing attributes sets so that the user could stretch the window out to its full width to see all 7 (8) slots without scrolling. Or, folks who need the window open but don't want to waste screen real estate could drag the window smaller and the Scroller would appear to allow scrolling between slots. Keyboard and display attributes, since they are not usually handled in the same way as swapping cards, could appear in their own configuration window, perhaps with total emulation RAM settings (e.g. Language Card, Apple Expanded Memory Card, etc.) as well. * I'm also wondering if the "setup" parts of the emulator need to be so graphic. Perhaps editing of the keyboard and display options could be in a simple Preferences panel without icon wells or any other fancy graphics (this is just food for thought, I don't want to stop anyone from having fun with a snazzy interface). My personal opinion is that icon wells are very handy for operations which happen quite often, like ten times per session, or thousands of times over the life of the program. Wouldn't it suffice to have a simpler interface for populating card slots since it seems like folks would not be doing this very often? * P.S. Apple ][ trivia time: Did anyone ever figure out that the SMT Expanded Memory Card driver ROM was a direct copy of the Apple Expanded Memory Card, except that the order of the subroutines was changed? SMT even "copied" the documented "bug" which Apple describes in their Technical Notes, even though it had no beneficial side-effect. Most likely, they didn't even code review the subroutines they were copying. The really funny part is the hidden message in the ROM data which would have appeared in the $C000-$C0FF area, except that this part of the ROM was never accessible. The Apple Expanded Memory Card had a ROM which was conditionally mapped in from $C100-$CFFE, the area from $C100-$C7FF was obviously only mapped in for the slot that the Card was installed in. At what would be $C000, the following message appeared on the Apple product: "This wonderful, wonderful romis brought to you by Richard Williamsand should only be used forthe benefit of mankind." (116 bytes) I can't say which came first, the chicken or the egg (i.e. the Apple or the SMT), but the contrasting message which appears in the SMT ROM is almost a dead give-away: "(C) 1986 SYSTEMS MANUFACTURING TECHNOLOGY, INC. 1145 LINDA VISTA DRIVE SAN MARCOS, CALIFORNIA 92069 744-3590 " (109 bytes) However, since Apple's message is longer, I wonder if they ripped off the SMT? Apple's subroutines were better placed, though, so I suspect that the organization of the SMT ROM was just to be "different" than Apple, not to be "optimal". Anyone remember when the SMT and Apple Expanded Memory Cards were announced/made available? --- Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Consulting and Signal Processing Software NeXTmail welcome - NO EMAIL SOLICITATION without prior permission From orbit!pnet51!stgeorge@kksys.mn.org Fri Dec 4 17:40:14 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA23150; Fri, 4 Dec 92 17:40:13 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA02407 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 17:10:20 -0800 Received: from byu.edu by alaska.et.byu.edu; Fri, 4 Dec 92 17:49:39 -0700 Received: from uum1.mn.org by yvax.byu.edu (PMDF #2655 ) id <01GRXD6YJXDS8ZE2R5@yvax.byu.edu>; Fri, 4 Dec 1992 17:48:59 MST Received: from kksys.mn.org by uum1.mn.org with bsmtp (Smail3.1.28.1 #3) id m0mxnMT-0001XhC; Fri, 4 Dec 92 18:27 CST Received: from orbit by kksys.kksys.mn.org with uucp (Smail3.1.27.1 #1) id m0mxmjl-0000CPC; Fri, 4 Dec 92 17:47 CST Received: by orbit.orb.mn.org (smail2.5) id AA00422; 4 Dec 92 12:05:01 CST (Fri) Date: 04 Dec 1992 12:01:03 -0600 (CST) From: stgeorge@pnet51.orb.mn.org (Steve George) Subject: unsubscribe To: na2sig@byu.edu Message-Id: Content-Transfer-Encoding: 7BIT unsubscribe stgeorge@pnet51.orb.mn.org From alex@data.acs.calpoly.edu Mon Dec 7 11:42:07 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA04559; Mon, 7 Dec 92 11:42:06 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA20880 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 11:40:33 -0800 Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 7 Dec 92 12:37:58 -0700 Received: from data.acs.calpoly.edu by yvax.byu.edu (PMDF #2655 ) id <01GS196B2C1S8ZEJ3P@yvax.byu.edu>; Mon, 7 Dec 1992 12:37:06 MST Received: by data.acs.calpoly.edu (NX5.67c/NX3.0M) id AA00495; Mon, 7 Dec 92 11:37:02 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 07 Dec 1992 11:37:02 -0800 From: Alex Raftis Subject: Re: Interface for selecting cards for slots To: na2sig@byu.edu Message-Id: <9212071937.AA00495@data.acs.calpoly.edu> Content-Transfer-Encoding: 7BIT Begin forwarded message: > > >Incidentally, is there any possibility for peripheral cards getting > >any screen real estate apart from when you pop up an inspector for > >them? > > Long ago I used to have space reserved above the Apple //e screen in > the same window for peripheral card slots, but I think I like the > minimalist approach better. After all, how often do you switch cards > or manipulate them in general? I would prefer a simple command-key > sequence to bring up the peripheral card inspector to an approach > that permanently reserves screen space for the cards. Maybe if > "cmd-6" brought up the inspector for the card in slot 6, and so on? > How about something like WordPerfect or some other applications I've seen have done. Basically, along the bottom of the window you put a button that when clicked extends the size of the window. Once extended, clicking it again would shrink the window again. WordPerfect uses this as part of it's inspector panels for less used options that a user wouldn't normally need to see. Alex --- ______________________________________________________ Internet: alex@data.acs.calpoly.edu (NeXT mail) alex@cosmos.acs.calpoly.edu From swiet@server.cs.jhu.edu Tue Dec 8 07:41:06 1992 Return-Path: Received: by sounds. (NX5.67c/NX3.0S) id AA06433; Tue, 8 Dec 92 07:41:05 -0800 Received: from alaska.et.byu.edu by nwnexus.wa.com with SMTP id AA15689 (5.65c/IDA-1.4.4 for ); Tue, 8 Dec 1992 07:07:43 -0800 Received: from byu.edu by alaska.et.byu.edu; Tue, 8 Dec 92 08:00:07 -0700 Received: from server.cs.jhu.edu by yvax.byu.edu (PMDF #2655 ) id <01GS2DR4C1JK8ZEP11@yvax.byu.edu>; Tue, 8 Dec 1992 07:59:13 MST Received: by server.cs.jhu.edu; Tue, 8 Dec 92 09:59:08 -0500 Date: 08 Dec 1992 09:59:04 -0500 (EST) From: swiet@server.cs.jhu.edu Subject: hello Sender: swiet@server.cs.jhu.edu To: na2sig@byu.edu Message-Id: <01GS2DR4GLIA8ZEP11@yvax.byu.edu> Content-Transfer-Encoding: 7BIT Anyone notice the new newsgroup: alt.emulators.ibmpc.apple2? Anyone gonna post? :) From sounds!brianw@nwnexus.wa.com Wed Dec 9 14:48 MST 1992 Received: from nwnexus.wa.com by newyork.et.byu.edu; Wed, 9 Dec 92 14:48:39 -0700 Return-Path: Received: from sounds.UUCP by nwnexus.wa.com with UUCP id AA19906 (5.65c/IDA-1.4.4 for newyork.et.byu.edu!yackd); Wed, 9 Dec 1992 13:44:31 -0800 Received: by sounds. (NX5.67c/NX3.0S) id AA27733; Wed, 9 Dec 92 11:46:28 -0800 Date: Wed, 9 Dec 92 11:46:28 -0800 From: Brian Willoughby Message-Id: <9212091946.AA27733@sounds.> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: yackd@newyork.et.byu.edu (Don Yacktman) Subject: Re: Interface for selecting cards for slots Reply-To: sounds!brianw@nwnexus.wa.com Status: RO Don, This bounced when I sent it to the Apple ][ list, but since it seems that you were the only one to miss out, I'm remailing it to you individually rather than send the list a duplicate. Is anything wrong with alaska? --- Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Consulting and Signal Processing Software NeXTmail welcome - NO EMAIL SOLICITATION without prior permission Begin forwarded message: Date: 04 Dec 1992 14:30:03 -0800 From: nwnexus!alaska.et.byu.edu!MAILER-DAEMON (Mail Delivery Subsystem) To: Subject: Returned mail: Deferred: read timeout: Connection timed out during MAIL with alaska.et.byu.edu ----- Transcript of session follows ----- While connected to everest.ee.byu.edu [128.187.21.13] (tcp): >>> RCPT To: <<< 451 read timeout: Connection timed out during MAIL with alaska.et.byu.edu yackd@wombat.ee.byu.edu... Deferred: read timeout: Connection timed out during MAIL with alaska.et.byu.edu >>> QUIT <<< 421 everest.ee.byu.edu.ee.byu.edu Lost input channel from alaska.et.byu.edu >>> QUIT 451 Unexpected close while awaiting SMTP reply from everest.ee.byu.edu Unexpected close while awaiting SMTP reply from everest.ee.byu.edu ----- Unsent message follows ----- Received: from byu.edu by alaska.et.byu.edu; Fri, 4 Dec 92 16:20:33 -0700 Return-Path: Received: from nwnexus.wa.com by yvax.byu.edu (PMDF #2655 ) id <01GRXA3D3M2O8ZE1RA@yvax.byu.edu>; Fri, 4 Dec 1992 16:19:54 MST Received: from sounds.UUCP by nwnexus.wa.com with UUCP id AA29323 (5.65c/IDA-1.4.4 for byu.edu!na2sig); Fri, 4 Dec 1992 15:02:32 -0800 Received: by sounds. (NX5.67c/NX3.0S) id AA20728; Fri, 4 Dec 92 14:30:03 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 04 Dec 1992 14:30:03 -0800 From: Brian Willoughby Subject: Re: Interface for selecting cards for slots To: na2sig@byu.edu Reply-To: sounds!brianw@nwnexus.wa.com Message-Id: <9212042230.AA20728@sounds.> Content-Transfer-Encoding: 7BIT Perhaps I am not aware of the history behind the designs being worked on, but I have a few suggestions. Why does everything have to be in one main window? Couldn't there be a window devoted to card slots that could be opened by a menu option and then closed when no longer needed? The slot window could have a ScrollView with sizing attributes sets so that the user could stretch the window out to its full width to see all 7 (8) slots without scrolling. Or, folks who need the window open but don't want to waste screen real estate could drag the window smaller and the Scroller would appear to allow scrolling between slots. Keyboard and display attributes, since they are not usually handled in the same way as swapping cards, could appear in their own configuration window, perhaps with total emulation RAM settings (e.g. Language Card, Apple Expanded Memory Card, etc.) as well. * I'm also wondering if the "setup" parts of the emulator need to be so graphic. Perhaps editing of the keyboard and display options could be in a simple Preferences panel without icon wells or any other fancy graphics (this is just food for thought, I don't want to stop anyone from having fun with a snazzy interface). My personal opinion is that icon wells are very handy for operations which happen quite often, like ten times per session, or thousands of times over the life of the program. Wouldn't it suffice to have a simpler interface for populating card slots since it seems like folks would not be doing this very often? * P.S. Apple ][ trivia time: Did anyone ever figure out that the SMT Expanded Memory Card driver ROM was a direct copy of the Apple Expanded Memory Card, except that the order of the subroutines was changed? SMT even "copied" the documented "bug" which Apple describes in their Technical Notes, even though it had no beneficial side-effect. Most likely, they didn't even code review the subroutines they were copying. The really funny part is the hidden message in the ROM data which would have appeared in the $C000-$C0FF area, except that this part of the ROM was never accessible. The Apple Expanded Memory Card had a ROM which was conditionally mapped in from $C100-$CFFE, the area from $C100-$C7FF was obviously only mapped in for the slot that the Card was installed in. At what would be $C000, the following message appeared on the Apple product: "This wonderful, wonderful romis brought to you by Richard Williamsand should only be used forthe benefit of mankind." (116 bytes) I can't say which came first, the chicken or the egg (i.e. the Apple or the SMT), but the contrasting message which appears in the SMT ROM is almost a dead give-away: "(C) 1986 SYSTEMS MANUFACTURING TECHNOLOGY, INC. 1145 LINDA VISTA DRIVE SAN MARCOS, CALIFORNIA 92069 744-3590 " (109 bytes) However, since Apple's message is longer, I wonder if they ripped off the SMT? Apple's subroutines were better placed, though, so I suspect that the organization of the SMT ROM was just to be "different" than Apple, not to be "optimal". Anyone remember when the SMT and Apple Expanded Memory Cards were announced/made available? --- Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Consulting and Signal Processing Software NeXTmail welcome - NO EMAIL SOLICITATION without prior permission From sounds!brianw@nwnexus.wa.com Thu Jan 7 05:40 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Thu, 7 Jan 93 05:39:54 -0700 Return-Path: Received: from nwnexus.wa.com by yvax.byu.edu (PMDF V4.2-4 #2655) id <01GT85MJ9BLS8WXJQQ@yvax.byu.edu>; Thu, 7 Jan 1993 05:39:45 MST Received: from sounds.UUCP by nwnexus.wa.com with UUCP id AA16492 (5.65c/IDA-1.4.4 for byu.edu!na2sig); Thu, 7 Jan 1993 04:31:23 -0800 Received: by sounds. (NX5.67c/NX3.0S) id AA27536; Thu, 7 Jan 93 04:33:25 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Thu, 07 Jan 1993 04:33:25 -0800 From: Brian Willoughby Subject: Anything new? problems with current binary. To: na2sig@byu.edu (NeXT/Apple2 Special Interest Group) Reply-To: sounds!brianw@nwnexus.wa.com Message-Id: <9301071233.AA27536@sounds.> Content-Transfer-Encoding: 7BIT Status: R Have there been any improvements to the zaniWok project since Sep 2nd? I cannot seem to get it to run. I installed the Apple2.font - so I don't see that Alert anymore. I created ROM_IMAGE with cat APPLESOFT.ROM AUTOSTART.ROM > ROM_IMAGE and placed it in /LocalLibrary/Apple2 - so I no longer get the Alert about ROM_IMAGE. I put DISK.PROM in /LocalLibrary/Apple2/PeripheralCards/DiskCard.a2card along with DiskCard - so I don't get an Alert about DISK.PROM (which never gave me a clue about where to put the file). So now I don't get any Alerts, but I don't get a working emulator either. I was able to get a2* running, and even loaded a Basic program that my uncle wrote. I used the same APPLESOFT.ROM and AUTOSTART.ROM, so this verifies that they are probably accurate. I have a working serial cable between my NeXT and Apple //e operating at 2400 baud (I have the old com card that only runs at one or two speeds). I can log onto my NeXT using the Apple as a terminal (40-column only, I still haven't rewritten my assembly language based Term program to cooperate with the 80-column screen), and I can also use "cu" to get into my Apple from Terminal.app on the NeXT. I used the latter method to create DISK.PROM. I transferred the Basic program by listing it to the screen which was captured by "cu" and then pasting the file into a2* (after removing extraneous carriage returns - I should have POKE'd my Apple first). P.S. Does anyone know of a source for the VT-100 specification? --- Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Consulting: Software Design and Development NeXTmail welcome From fozztexx%nvcc.uucp@groucho.sonoma.edu Fri Jan 8 16:33 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Fri, 8 Jan 93 16:32:36 -0700 Return-Path: Received: from mvax.Sonoma.EDU by yvax.byu.edu (PMDF V4.2-4 #2655) id <01GTA6PZFMM88WXOD4@yvax.byu.edu>; Fri, 8 Jan 1993 16:32:20 MST Received: by mvax.Sonoma.EDU (5.57/Ultrix2.4-C) id AA21036; Fri, 8 Jan 93 15:32:45 -0800 Received: by groucho.sonoma.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03276; Fri, 8 Jan 93 15:29:17 GMT-0800 Received: by nvcc (NX5.67c/NeXT-2.0) id AA05257; Fri, 8 Jan 93 15:22:26 -0800 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Fri, 08 Jan 1993 15:22:26 -0800 From: fozztexx%nvcc.uucp@groucho.sonoma.edu (Chris Osborn) Subject: Re: Anything new? problems with current binary. To: sounds!brianw@nwnexus.wa.com Cc: na2sig@byu.edu (NeXT/Apple2 Special Interest Group) Message-Id: <9301082322.AA05257@ nvcc > Content-Transfer-Encoding: 7BIT Status: R > Have there been any improvements to the zaniWok project since > Sep 2nd? > I cannot seem to get it to run. I installed the Apple2.font - > so I don't see that Alert anymore. I created ROM_IMAGE with > cat APPLESOFT.ROM AUTOSTART.ROM > ROM_IMAGE and placed it in > /LocalLibrary/Apple2 - so I no longer get the Alert about > ROM_IMAGE. I put DISK.PROM in > /LocalLibrary/Apple2/PeripheralCards/DiskCard.a2card along with > DiskCard - so I don't get an Alert about DISK.PROM (which never > gave me a clue about where to put the file). I really wouldn't expect it to work with Apple //+ roms. You'll need to get some //e roms. The //e roms are a lot larger and load in a different place than the //+ roms do. --- Chris Osborn, Network Administrator Napa Valley College fozztexx%nvcc.uucp@groucho.sonoma.edu <- Preferred fozztexx@groucho.sonoma.edu NeXTMail ok at both From mjhostet@slayer.MIT.EDU Mon Jan 11 23:50 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Mon, 11 Jan 93 23:50:02 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-4 #2655) id <01GTESVKP9OW8WWN0P@yvax.byu.edu>; Mon, 11 Jan 1993 23:49:58 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA02795; Tue, 12 Jan 93 01:49:48 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Tue, 12 Jan 1993 01:49:48 -0500 From: "Mat J. Hostetter" Subject: Re: Anything new? problems with current binary. To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301120649.AA02795@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R Is the zaniWok version on the archives way outdated? Chris, why don't you upload your most current version (with the patch I sent?) It's got to be better than the current stuff there, even if it is a bit flaky. We also need to write up some decent INSTALL instructions. -Mat From mjhostet@slayer.MIT.EDU Mon Jan 11 23:57 MST 1993 Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 11 Jan 93 23:57:39 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-4 #2655) id <01GTET5H9VQO8WWSWH@yvax.byu.edu>; Mon, 11 Jan 1993 23:57:56 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA02807; Tue, 12 Jan 93 01:57:14 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Tue, 12 Jan 1993 01:57:14 -0500 From: "Mat J. Hostetter" Subject: Re: Font problems, Paste problems, and is gcc really necessary To: sounds!brianw@nwnexus.wa.com Cc: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301120657.AA02807@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R Most of these problems are fixed in more current versions (which we haven't uploaded). > The font looks terrible, it seems too large and the scrolling >is all wrong. Could this be due to the fact that I have the font in >~/Library/Fonts instead of /LocalLibrary/Fonts? It's definitely not finding the font. Does the font show up in Stuart? > a2* accepts Pasted text very well. However, the new emulator >does not seem to accept Pasted text. The version you have doesn't do keyboard buffering. I believe Chris Osborn has integrated that feature into zaniWok. > And hey! Where is the color? I have a NeXTdimension: I >suppose that you NeXTstation Color owners are getting color Apple ][ >emulation!?!? The newest stuff is geared towards 12 bit color stations; however, it works on a NeXTdimension (it's just slower). > I am wondering if these problems would be solved if I were to >compile my own emulator. Were the zaniWok binaries created from the >same source as can now be found on the archives? Or are the sources newer? Probably not, we'll upload new sources. >Also, is gcc absolutely required to compile zaniWok? If so, then why? It's not absolutely required; I provide .s (assembly) files for the C code that uses gcc extensions. You probably won't need to edit these files. I use gcc because it supports some extensions to the C language that are damn useful. >Does the core of the emulator use some kind of compile on the fly >technique? If so, could someone distribute the object file for the >core code which requires gcc so that I can compile the other sources >and link them all together? Is this possible - can you link gcc and >cc objects? Yes, I compile stuff on the fly into an efficient interpreted language. "execute.s" is provided in the source distribution so you won't have to compile execute.c (which requires gcc and 100 MB of swap space). You can link gcc and cc objects (cc is really gcc version 1.93 on the NeXT, I require gcc 2.3.3 to build a few of the zaniWok source files). I'll try to get on getting out current sources; I was just out of town and other people have been hacking on it so I haven't bothered. I'm glad people are psyched to start messing with it; I think it's starting to get stable enough that mortals can use it/hack with it. No known 6502/RAM bugs left... :-) -Mat From mjhostet@slayer.MIT.EDU Wed Jan 13 15:23 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Wed, 13 Jan 93 15:22:42 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-4 #2655) id <01GTH3QI0PGG8WWBDJ@yvax.byu.edu>; Wed, 13 Jan 1993 15:22:49 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA04151; Wed, 13 Jan 93 17:22:42 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Wed, 13 Jan 1993 17:22:42 -0500 From: "Mat J. Hostetter" Subject: New zaniWok 0.3 sources available on ftp.byu.edu To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301132222.AA04151@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R OK, I uploaded the sources for zaniWok 0.3 to ftp.byu:/apple2/submissions/zaniWok0.3.src.tar.Z Consider this a complete replacement for all previous versions of zaniWok. These sources are pretty much as I received them from Chris Osborn (who in turn was extending my stuff), so I can't claim to be entirely familiar with his changes. The INSTALL instructions may be somewhat out of date. Those of you who have access to ROMs: please try to build and install this version, send me feedback, and I'll probably make a 0.4 that solves whatever installation problems you find. You shouldn't need gcc to compile this, just NeXTSTEP 3.0. I'll also make a .pkg once people seem to be able to get the emulator running. I'm not sure what people were using before, but this version adds color, the ability to switch disks at runtime and numerous bug fixes. I wish I could work on this more but I'm scrambling to meet a contract deadline by the end of the month. Good luck! -Mat From nika!ken@uunet.UU.NET Wed Jan 13 15:59 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Wed, 13 Jan 93 15:59:26 -0700 Return-Path: Received: from relay2.UU.NET by yvax.byu.edu (PMDF V4.2-4 #2655) id <01GTH50TYDUO8WWEHJ@yvax.byu.edu>; Wed, 13 Jan 1993 15:59:21 MST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19455; Wed, 13 Jan 93 17:59:22 -0500 Received: from nika.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 175826.17341; Wed, 13 Jan 1993 17:58:26 EST Received: by nika (NX5.67c/NX3.0M) id AA03782; Wed, 13 Jan 93 17:33:52 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Wed, 13 Jan 1993 17:33:52 -0500 From: Ken Pelletier Subject: Apple II emulator on NeXTSTEP To: na2sig@byu.edu Reply-To: nika!nika.com!ken@uunet.UU.NET Message-Id: <9301132233.AA03782@nika> Content-Transfer-Encoding: 7BIT Status: R What can you tell me about a PD Apple emulator for NeXTSTEP that you are rumored to be developing? Thanks! --- Ken Pelletier (ken@nika.com) NiKA Software, Inc. Arlingon, Ma NeXT Mail welcome! From mjhostet@slayer.MIT.EDU Fri Jan 15 14:28 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Fri, 15 Jan 93 14:27:48 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTJUEZ6USG8WX02N@yvax.byu.edu>; Fri, 15 Jan 1993 14:27:48 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA07681; Fri, 15 Jan 93 16:27:40 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Fri, 15 Jan 1993 16:27:40 -0500 From: "Mat J. Hostetter" Subject: Whoops, forgot a useful utility program in zaniWok0.3/utilities - now at ftp.byu.edu To: na2sig@byu.edu Cc: swiet@server.cs.jhu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301152127.AA07681@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R In this early release of zaniWok, if a program attempts to access the drive hardware directly on a DOS 3.3 or ProDOS disk, the emulator will abort; such accesses are only allowed for "raw" (nibbleized) disks. This problem tends to crop up on disks that have "fast" DOS loaders, like BOLO and Hard Hat Mack seem to have. Someday I (or someone else) will modify zaniWok to support raw access of non-RAW disks by nibbleizing the data and feeding it through the drive latch as it is requested. This isn't really all that hard. However, until that day arrives, I wrote a utility program which will convert DOS 3.3 .a2disks to RAW .a2disks. This will let the disks be accessed directly via the drive hardware; the drawbacks are that disk performance will slow down and the disk image becomes larger. I've uploaded dos33toraw.c to ftp.byu.edu:/apple2/submissions: -rw-r--r-- 1 ftp other 5226 Jan 15 14:11 dos33toraw.c Please try applying this to your DOS 3.3 disks that don't work before sending me bug reports. Enjoy! -Mat P.S. If anyone out there is a real DOS 3.3 hacker, I'd appreciate it if they took a look at this program. I applied it to BOLO and BOLO boots REALLY slowly, so I'm wondering if I'm screwing up the sector ordering or something. It could also be a zaniWok problem; the Disk ][ hardware emulation doesn't yet spin the disk when the drive motor is on but the drive is not being accessed, which a fast loader might be counting on. From mjhostet@slayer.MIT.EDU Fri Jan 15 18:07 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Fri, 15 Jan 93 18:07:41 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTK23NXQHS8WX4F1@yvax.byu.edu>; Fri, 15 Jan 1993 18:07:45 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA08174; Fri, 15 Jan 93 20:07:37 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Fri, 15 Jan 1993 20:07:37 -0500 From: "Mat J. Hostetter" Subject: Transferring disks - how to To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301160107.AA08174@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R There has been some interest in how to transfer disks to the NeXT. Here are my thoughts on the matter, and feel free to correct me or otherwise add your 2 cents. The basic plan is that you archive the disk up with ShrinkIt, transfer the .shk file to your NeXT via your favorite communications software, and unpack it with a PD program called nulib (available via anonymous ftp to wuarchive.wustl.edu:/systems/apple2/Unix). This will create a file that represents the disk image. If the disk was a ProDOS disk, just add a ".a2disk" suffix to the filename and you are ready to go. If it was a "real" DOS 3.3 disk, you need to process it with the file "remap", whose source code is available in the utilities directory of the zaniWok source distribution. If programs on the disk access the drive hardware directly, you will want to run remap and then run dos33toraw on it (available @ ftp.byu.edu:/apple2/submissions and will be in the utilities dir of the next release of zaniWok). Would someone mind writing up step-by-step directions to include in the next release of zaniWok? We need a new version of the INSTALL file, too. -Mat From mjhostet@slayer.MIT.EDU Fri Jan 15 18:14 MST 1993 Received: from yvax2.byu.edu by alaska.et.byu.edu; Fri, 15 Jan 93 18:14:30 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTK2C6S3A88WX4QB@yvax.byu.edu>; Fri, 15 Jan 1993 18:14:37 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA08188; Fri, 15 Jan 93 20:14:31 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Fri, 15 Jan 1993 20:14:31 -0500 From: "Mat J. Hostetter" Subject: zaniWok user interface To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301160114.AA08188@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R Please don't flame about the zaniWok UI too much; Chris Osborn is in the middle of writing it but we decided to make a somewhat premature release anyway so that people would have something more recent to play with. However, now that people have something to play with perhaps we will be able to get a better feel for what the UI should feel like and we can have a raging debate on na2sig once again! :-) Here's my suggestion: I like the idea of "configuration files", sort of like how Executor works, which is what I think Chris is also using. I would also like to see a "default" configuration file that would be used when you double clicked on a disk; this would leave the configuration mostly alone but insert the double-clicked upon disk in the first drive it found before booting up the machine. We still need an app icon! -Mat From mjhostet@slayer.MIT.EDU Fri Jan 15 22:00 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Fri, 15 Jan 93 22:00:44 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTKA8MQEU88WX4WR@yvax.byu.edu>; Fri, 15 Jan 1993 22:00:48 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA08877; Sat, 16 Jan 93 00:00:43 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Sat, 16 Jan 1993 00:00:43 -0500 From: "Mat J. Hostetter" Subject: Icon To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301160500.AA08877@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R If you want a laugh, here's what an artist friend of mine threw together back when zaniWok was called naziWok. Just hoping to inspire any artists out there... :-) -Mat begin 644 naziwok.icon.tiff M34T`*@```DCN[O[N_N[N[N[N[NZ[N@"X`[J[NKNZN[KN[#\`\.[N[N[N[NZ[ MN````#N[N[N[N[O@`*H*JB[N[N[N[NZSPJHJJCJZNKJZNKK`&*H*JB[N[N[N M[NZ*J*J*J#N[N[N[N[OAF0H`J"#N[N[N[NX`@@",``,[NKNZN[H9"8JAF,,N M[N[N[NX*0H*`H,`+N[N[N[O@()@8DP@.[N[N[NZX"B0J(RHZNKJZNKKNP(F! MF!@N[N[N[NZ[N`*JJJ"[O[N[N[ON[AF8F8+NX`+N[NZ[NH*DJ@J[@``ZN[KN M[N"8`"[N`NP.[NZ[N["H*CN````+N[ON[NX`J@``````[NZZNKJPJH`[^_L` M"KKN[N[LJ@+654;L`.Z[N[N[)ATVJJJK\`ON[N[N"`!41&FIG@"[NKNZ,``` M`5$:4X#N[N[N#$``!$0$0!"[N[N[@!)@``````SN[N[N[(1!D`!`0+"ZNKJZ MN!%0!FJ@%?/N[N[N[@2#R:H!6<.[N[N[NPD4`F#S5X/N[N[N[L!&6JX-GA"[ MNKNZN[!4```%4%3N[N[N[NP`___A`!6[N[N[N[L&```(`X#N[N[N[L``A:H` M+NZZNKJZN`%4```*NKKN[N[NP%55555"[NZ[N[NP!550%%50N[ON[N[L`50" M`!54+NZ[NKNXP`"[NH%5.+KN[N[L`"[N[NP5``"[NX`P`+N[N[L`%0#N[@P# M`N[N[N[N!0"ZN@`,"KJZNKJZL`#N[L``#N[N[N[N[BZ[N[N[N[N[N[N[N[L` M#`$```,````!`#````$!``,````!`#````$"``,````!``(```$#``,````! M``$```$&``,````!``$```$1``0````!````"`$5``,````!``$```$7``0` M```!```"0`$:``4````!```"W@$;``4````!```"Y@$<``,````!``(```$H >``,````!``(`````````"OR````G$``*_(```"<0 ` end From vince@whatnxt.cuc.ab.ca Sat Jan 16 13:17 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Sat, 16 Jan 93 13:16:06 -0700 Return-Path: vince@whatnxt.cuc.ab.ca Received: from fsa.cpsc.ucalgary.ca by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTL67E7PPC8WWLU2@yvax.byu.edu>; Sat, 16 Jan 1993 13:16:05 MST Received: from news.cpsc.ucalgary.ca by fsa.cpsc.ucalgary.ca (4.1/CSd1.2) id AA22511; Sat, 16 Jan 93 13:09:05 MST Received: from whatnxt.cuc.ab.ca by dlgsys.cuc.ab.ca (4.1/Cuc2.2) id AA27143; Sat, 16 Jan 93 12:58:41 MST Received: by whatnxt.cuc.ab.ca id AA01275 (5.65c#3#/IDA-1.4.4 for na2sig@byu.edu); Sat, 16 Jan 1993 12:54:40 -0700 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Sat, 16 Jan 1993 12:54:40 -0700 From: Vince DeMarco Subject: Emulator To: na2sig@byu.edu Message-Id: <199301161954.AA01275@whatnxt.cuc.ab.ca> Content-Transfer-Encoding: 7BIT Status: R I just got Aztec running under the emulator, does anyone remember the keys used to control the game. What is the command to take a thing that you find. Also, the mouse seems to emulate the apple joystick, this works fine, is there anything to emulate button 0 and 1 on the apple joystick???? vince --- vince@whatnxt.cuc.ab.ca (NeXT Mail accepted) demarco@cpsc.ucalgary.ca Nobody speaks the truth when there's something they must have. ELIZABETH BOWEN 1899-1973 From mjhostet@slayer.MIT.EDU Sat Jan 16 13:25 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Sat, 16 Jan 93 13:24:42 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTL6I0NSQO8WX3X2@yvax.byu.edu>; Sat, 16 Jan 1993 13:24:38 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA09847; Sat, 16 Jan 93 15:24:31 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Sat, 16 Jan 1993 15:24:31 -0500 From: "Mat J. Hostetter" Subject: Re: Emulator To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301162024.AA09847@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R Vince DeMarco writes: >I just got Aztec running under the emulator Cool! Is it fast enough? >Also, the mouse seems to emulate the apple joystick, this works fine, is there anything to emulate button 0 and 1 on the apple >joystick???? The mouse buttons used to work (that's how I played Rescue Raiders). Left button for #0, right button for #1. I think you have to set "Menu Button Enabled" in Preferences.app under the mouse section for the right button to work. Chris Osborn also added open and closed apple support, which probably let you do the same thing from the keyboard. It's possible his changes rendered the mouse buttons inoperable, but I doubt it. Also, a general note about the mouse joystick: the active box for the mouse is actually inset into the zaniWok window somewhat, so you can pin the joystick to the extremes without leaving the emulator window. -Mat From swiet@server.cs.jhu.edu Sat Jan 16 13:40 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Sat, 16 Jan 93 13:39:16 -0700 Return-Path: Received: from server.cs.jhu.edu by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTL707LLV48WX7BI@yvax.byu.edu>; Sat, 16 Jan 1993 13:39:17 MST Received: by server.cs.jhu.edu; Sat, 16 Jan 93 15:39:05 -0500 Date: Sat, 16 Jan 1993 15:39:03 -0500 (EST) From: swiet@server.cs.jhu.edu Subject: Joystick buttons Sender: swiet@server.cs.jhu.edu To: na2sig@byu.edu Message-Id: <01GTL707QFGY8WX7BI@yvax.byu.edu> Content-Transfer-Encoding: 7BIT Full-Name: Alexander Swietlicki Status: R The Command and Alternate keys work (emulating the open and closed apple, which are they same as the buttons). Check the keyboard settings... From mjhostet@slayer.MIT.EDU Sat Jan 16 13:53 MST 1993 Received: from yvax2.byu.edu by alaska.et.byu.edu; Sat, 16 Jan 93 13:51:54 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTL7FVZFSW8WX7DF@yvax.byu.edu>; Sat, 16 Jan 1993 13:51:56 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA09886; Sat, 16 Jan 93 15:51:51 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Sat, 16 Jan 1993 15:51:51 -0500 From: "Mat J. Hostetter" Subject: mouse buttons won't work To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9301162051.AA09886@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R Vince was right. I poked around and it looks like Chris took out my code to let the mouse buttons act as joystick buttons. Why? Anyway, for now you'll have to do as swiet suggested and use the keyboard. -Mat From fozztexx%nvcc.uucp@groucho.sonoma.edu Sat Jan 16 14:13 MST 1993 Received: from yvax2.byu.edu by alaska.et.byu.edu; Sat, 16 Jan 93 14:11:54 -0700 Return-Path: Received: from mvax.Sonoma.EDU by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTL85NY5HC8WX2D3@yvax.byu.edu>; Sat, 16 Jan 1993 14:11:56 MST Received: by mvax.Sonoma.EDU (5.57/Ultrix2.4-C) id AA20560; Sat, 16 Jan 93 13:12:24 -0800 Received: by groucho.sonoma.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA09417; Sat, 16 Jan 93 13:08:37 GMT-0800 Received: by nvcc (NX5.67c/NeXT-2.0) id AA01241; Sat, 16 Jan 93 13:08:14 -0800 Date: Sat, 16 Jan 1993 13:08:14 -0800 From: fozztexx%nvcc.uucp@groucho.sonoma.edu (Chris Osborn) Subject: Re: mouse buttons won't work To: na2sig@byu.edu Message-Id: <9301162108.AA01241@ nvcc > Content-Transfer-Encoding: 7BIT Status: R I took out the mouse buttons temporarily to make the keyboard work. I'll put them back in eventually, I just didn't feel like hassling with two input buttons at the time. Also, keyboard buffering doesn't work. There was a patch to do it, did you ever install it Mat? If you did, then maybe I could get the cut and paste working. Chris From vince@whatnxt.cuc.ab.ca Sat Jan 16 21:32 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Sat, 16 Jan 93 21:32:07 -0700 Return-Path: vince@whatnxt.cuc.ab.ca Received: from fsa.cpsc.ucalgary.ca by yvax.byu.edu (PMDF V4.2-5 #2655) id <01GTLNIBU9Z48WXB9P@yvax.byu.edu>; Sat, 16 Jan 1993 21:32:08 MST Received: from news.cpsc.ucalgary.ca by fsa.cpsc.ucalgary.ca (4.1/CSd1.2) id AA02352; Sat, 16 Jan 93 21:24:59 MST Received: from whatnxt.cuc.ab.ca by dlgsys.cuc.ab.ca (4.1/Cuc2.2) id AA28448; Sat, 16 Jan 93 21:13:56 MST Received: by whatnxt.cuc.ab.ca id AA00985 (5.65c#3#/IDA-1.4.4 for na2sig@byu.edu); Sat, 16 Jan 1993 21:11:50 -0700 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Sat, 16 Jan 1993 21:11:50 -0700 From: Vince DeMarco Subject: test drive To: na2sig@byu.edu Message-Id: <199301170411.AA00985@whatnxt.cuc.ab.ca> Content-Transfer-Encoding: 7BIT Status: R Has anyone gotten test drive working, I get it going up until it shows you all of the cars you can test drive, then the program crashes (the emulator not test drive) any suggestions???? BTW just incase anyone is wondering Aztec works great under the emulator, just like old times. vince --- vince@whatnxt.cuc.ab.ca (NeXT Mail accepted) demarco@cpsc.ucalgary.ca Nobody speaks the truth when there's something they must have. ELIZABETH BOWEN 1899-1973 From mjhostet@slayer.MIT.EDU Sun Jan 31 19:03 MST 1993 Received: from byu.edu by alaska.et.byu.edu; Sun, 31 Jan 93 19:02:48 -0700 Return-Path: Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF V4.2-6 #2655) id <01GU6GO2L09S8X1HQB@yvax.byu.edu>; Sun, 31 Jan 1993 19:02:29 MST Received: by slayer.MIT.EDU (NX5.67c/NX3.0M) id AA03953; Sun, 31 Jan 93 21:02:22 -0500 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: Sun, 31 Jan 1993 21:02:22 -0500 From: "Mat J. Hostetter" Subject: Chris Osborn will be supporting zaniWok for a while To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9302010202.AA03953@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R I'll be mostly off the net for the next 6 months, so Chris Osborn has graciously agreed to take over supporting zaniWok. Send bug reports, suggestions, AN APPLICATION ICON [hint], and whatever else to him: fozztexx%nvcc.uucp@groucho.sonoma.edu Hopefully my email address will be functional again in a week or two, but my net access will be constrained. Would people mind posting lists of what programs work and what don't to this group? I'm really curious and I suspect others may be as well. -Mat -- /--------------------------------------------------------------------- ----\ | Mat Hostetter mjhostet@athena.mit.edu (NeXTMail OK) | | **** MIT NeXT Campus Consultant **** | | "The only part of the conduct of anyone for which he is amenable to | | society is that which concerns others. In the part which merely | | concerns himself, his independence is, of right, absolute. Over | | himself, over his own body and mind, the individual is sovereign." | | - John Stuart Mill, _On Liberty_ | \--------------------------------------------------------------------- ----/ From mjhostet@slayer.MIT.EDU Mon Oct 19 10:33 MDT 1992 Received: from newt.ee.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 01:13:26 -0600 Return-Path: Received: from wombat.ee.byu.edu by newt.ee.byu.edu; Mon, 19 Oct 92 01:12:03 -0600 Received: from alaska.et.byu.edu by wombat.ee.byu.edu; Mon, 19 Oct 92 01:11:53 mdt Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 19 Oct 92 01:13:22 -0600 Received: from slayer.MIT.EDU by yvax.byu.edu (PMDF #2655 ) id <01GQ44YOJ4V48WWVOI@yvax.byu.edu>; Mon, 19 Oct 1992 01:11:46 MDT Received: by slayer.MIT.EDU (NX5.67c/NeXT-2.0) id AA02830; Mon, 19 Oct 92 03:11:42 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) Date: 19 Oct 1992 03:11:42 -0400 From: mjhostet@slayer.MIT.EDU (Mathew J. Hostetter) Subject: Re: nulib + unpacked disks To: na2sig@byu.edu Reply-To: mjhostet@athena.MIT.EDU Message-Id: <9210190711.AA02830@slayer.MIT.EDU> Content-Transfer-Encoding: 7BIT Status: R Brian Willoughby writes: >Hey, is the Apple emulator usable yet? Last I heard it was still >very preliminary. What is the story currently? I have not released a new version yet, but my development version has/will have some neat new things: 1) DOS 3.3 support 2) ProDOS support [someone send me a prodos disk so I can test this!] 3) Fast 16 bit color support for hi-res 4) Various bug fixes 5) A Serial Card is in the works...may not make the release 6) A .pkg for easy installation 7) Some PD games disks (defender and berzap, I'd welcome more) It is still missing many important things, like an Inspector for the dynamically loadable peripheral cards (which would let you switch disks at runtime, for example), LoRes, Preferences, improved sound, and lots of UI stuff. Since I may not have much time this term, my hope was to add in sufficient (or is that insufficient? :-) disk support (and a virtual serial card) so that others could easily use their own favorite disks and thus have some incentive to work on the emulator. But, to make a long story short, the new version is perfectly sufficient to play games, and that's what counts! :-) -Mat