kamath@reed.UUCP (Sean Kamath) (06/18/88)
[oops. My previous article should have said I've bought well over *$1000* from the store, not $100.] In article <IWh4gyy00V4DwHg0ZD@andrew.cmu.edu> jm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness") writes: > > >However, Prodos has routines that can handle extended memory. Appleworks is a >brilliant example of how a large program can use Prodos routines to fit itself >within the tiny 64K space the 65c02 allows. What is done is the program is >segmented and Prodos handles the memory switching. Check out Appleworks running >under a 512K Ramworks (eight 64K banks) with AE's enhancements that put all of >Appleworks into a RAM, still manages to enlarge the desktop (the Appleworks >desktop is handled by Prodos routines (I think) and kept in extended memory) >and also provides a print buffer; a feature unique to RAMWorks. No other >Ramcard can feature a print buffer. I do not think GSRam or slot 1-7 cards are >capable of it. Obviously, I do not know how this feature can work, and Applied >Engineering isn't telling. Woa, tha boy, I say woa thar! A) Prodos does *nothing* for Ramcards save as a small /RAM volumn. It has no auxmem bitmap, it provides no routines for handling aux mem, either data transfers or code transfer, short of usage as a RAMdisk. Companies like AE and Checkmate write a device driver for their cards. B) Appleworks is indeed segmented, but it is pulled off *disk*. It just so happens that this disk is a RAMdisk, in your case. There is not special code, really. However, you think wrong when you say Appleworks' desktop is handled by ProDOS. Actually, the desktop (as opposed to the program segments) are handled strictly by Appleworks. AppleWorks worries about the switches and transfers. If ProDOS handled it, then we should be able to have desktops as large as disk . . . THink about it. C) People wrote printerbuffers before AE existed. (I think. I'm not sure *how* long they've been around, but it's been a long time.) In no way is it unique to Ramworks cards. Anything (*any* card) with memory can be used as a buffer/spooler. Check out Diversi-DOS, if you can find a copy. If you want, you can install a buffer in the language card, for use from *BASIC*, if you want. D) If you're so hot to know how a printer buffer works, and fear AE will never let out their horrible secret, here, I'll tell you. You call the routine to hook the printer card up to CSW ($36,$37). In Basic.System or DOS 3.3, that's PR#1 (assuming you are using slot one). When you call that link, it's up to whatever layers of stuff you have to go through (in Basic.systems case, you have to go though it's parser, if it's a BASIC command, it then goes to the BASIC parser, other wise it goes to ProDOS.) to say "hay, he wants to hook up a printer!" (Actually, you can set up a buffer to a modem, if you want. . .It's slot dependant (or device-independant)), and instead of just calling $C100, it calls $C100, get's the hook that $C100 will put at CSW, ans restore it's own hooks there, while safely tucking the printer hooks somewhere safe. DOS and Basic.system do just this, *every* time you turn on the printer with a PR#1. In anycase, to make a buffer, when a character is sent that isn' supposed to go to ProDOs, DOS, or BASIC (i.e. to the printer), it get's send to the buffer management software, which periodically sends as much as it can to the printer whenever it get's the chance. If you want, I'll send you an example. Sean Kamath >I hope this gives you an idea as to what you can and cannot do with extended >memory. If I had my way, I would have a //e with 512K extended to hold a huge >desktop/print buffer and then have an additional 512K in a slot 1-7 card to act >as a RAM disk. But that takes money and another slot... > > >Capt. Albatross >jm7e+@andrew.cmu.edu > >============ >disclaimer: These opinions are mine and will remain so until more intelligent >or insightful or informed people are kind enough to show me the error of my >ways. >Remember: A mind is a terrible thing to baste. -- UUCP: {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath CSNET: reed!kamath@Tektronix.CSNET || BITNET: reed!kamath@PSUVAX1.BITNET ARPA: reed!kamath@PSUVAX1.CS.PSU.EDU US Snail: 3934 SE Boise, Portland, OR 97202-3126 (I hate 4 line .sigs!)
jm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness") (06/20/88)
Ooooh am I chagrined! "But it looked so smoooothe Mr. Chips!" ummmm, okay, but how if >A) Prodos does *nothing* for Ramcards save as a small /RAM volumn. It has >no auxmem bitmap, it provides no routines for handling aux mem, either data >transfers or code transfer, short of usage as a RAMdisk. How does Prodos accomplish a standard 64K Ramdisk in 128K machines? It's always there, and comes in handy, too. How does it work w/o aux mem handling? (The basic point of my post was that the best use of aux mem and Ramworks-like cards, short of double hires, was as a Ramdisk...) >Anything (*any* card) with memory can be used as a buffer/spooler. Just out of curiosity, why, then, aren't more cards being used as one? It's amazing when Appleworks tells me "loading file into print buffer" and then goes on the let me do other things. No other card offers that... > it get's send to the buffer management software, which periodically sends as much as it can to the > printer whenever it get's the chance. If you want, I'll send you an example. Sounds a little like multitasking. Yes, I'd like an example. Send me E-Mail. Capt. Albatross "I have been made less of an ignorant whatever..." jm7e@drycas (Bitnet) jm7e@drycas.club.cc.cmu.edu (Arpa) ============ disclaimer: These opinions are mine and will remain so until more intelligent or insightful or informed people are kind enough to show me the error of my ways. Remember: A mind is a terrible thing to baste.