lharris@gpu.utcs.toronto.edu (Leonard Harris) (07/13/88)
Does anyone have any info on patching magic sac to the 128K roms. I have the roms (legal ones) and I'm getting really frustrated that a lot if my mac software won't run on the sac. It can't be that difficult to do. ( and no, data pacific will NOT be coming out with patches to do this - I heard they signed a deal with apple agreeing not to make it 128K compatible. ) Technically there should be no problem. Thanks .leonard
koreth@ucscb.UCSC.EDU (Froot-Loops Addict) (07/13/88)
In article <1988Jul12.201345.24692@gpu.utcs.toronto.edu> lharris@gpu.utcs.toronto.edu (Leonard Harris) writes: >Does anyone have any info on patching magic sac to the 128K roms. [deleted] >Technically there should be no problem. I believe there is a technical problem, actually. Isn't the cartridge's address bus only 16 bits wide? If so, that places a 64K limit on the size of cartridge software, unless some fancy footwork (a la OSS's SuperCartridges on the 8-bit) is done to increase the effective space. And said footwork isn't trivial, as far as I know. Of course, I'm not a hardware person, so this could be totally bogus. -Steven Grimm (posting from a different machine than usual because he's lazy) koreth@ssyx.ucsc.edu ...!ucbvax!ucscc!ssyx!koreth +New! Improved! Now 200% Artificial-+-+----------Steven Grimm-------------+ |# # @@@ **** &&&&& $$$$$ % %| | ARPA: koreth@ssyx.ucsc.edu | |# # @ @ * * & $ % %+-+ UUCP: ...!ucbvax!ucscc!ssyx!koreth| |### @ @ **** &&&& $ %%%%%| |___________________________________| |# # @ @ * * & $ % %+-+"You can lead a fish to water, but | |# # @@@ * ** &&&&& $ % %| |you have to run fast or he'll die."| +-----with NutraSour(TM)! No natural colors or preservatives!------------+
stowe@silver.bacs.indiana.edu (holly) (07/13/88)
Data Pacific will not be coming out with a 128K version of Magic Sac, but Dave Small (the original author) is no longer with DP, and he is working on a 128K version. I don't have any release date information as of now, though.
greg@bilbo (Greg Wageman) (07/14/88)
In article <4132@saturn.ucsc.edu> koreth@ucscb.UCSC.EDU (Froot-Loops Addict) writes: >In article <1988Jul12.201345.24692@gpu.utcs.toronto.edu> lharris@gpu.utcs.toronto.edu (Leonard Harris) writes: >>Does anyone have any info on patching magic sac to the 128K roms. >[deleted] >>Technically there should be no problem. > >I believe there is a technical problem, actually. Isn't the cartridge's >address bus only 16 bits wide? If so, that places a 64K limit on the size >of cartridge software, unless some fancy footwork (a la OSS's SuperCartridges >on the 8-bit) is done to increase the effective space. And said footwork >isn't trivial, as far as I know. Of course, I'm not a hardware person, so >this could be totally bogus. True, the address bus is only 16 bits wide (15, actually, with Upper Data Strobe and Lower Data Strobe providing the High/Low byte info, as well as doubling as the Data Strobe). However, there are two additional lines called "ROM Select 3" and "ROM Select 4" which become active when the addresses 0xFB000-0xFBFFFF and 0xFA0000-0xFAFFFF, respectively, are read. This gives access to 64K bytes x 2 = 128K bytes, just enough for the ROMS, but no room for the clock as in the 64K byte Magic Sac. Greg Wageman ARPA: greg%sentry@spar.slb.com Schlumberger Technologies BIX: gwage 1601 Technology Drive CIS: 74016,352 San Jose, CA 95110 GEnie: GWAGEMAN (408) 437-5198 UUCP: ...!decwrl!spar!sentry!greg ------------------ The opinions expressed herein are solely the responsibility of the author.
ltf@killer.UUCP (Lance Franklin) (07/14/88)
In article <318@snjsn1.SJ.ATE.SLB.COM> greg%sentry@spar.slb.com (Greg Wageman) writes: >True, the address bus is only 16 bits wide (15, actually, with Upper >Data Strobe and Lower Data Strobe providing the High/Low byte info, as >well as doubling as the Data Strobe). However, there are two >additional lines called "ROM Select 3" and "ROM Select 4" which become >active when the addresses 0xFB000-0xFBFFFF and 0xFA0000-0xFAFFFF, >respectively, are read. This gives access to 64K bytes x 2 = 128K >bytes, just enough for the ROMS, but no room for the clock as in the >64K byte Magic Sac. The clock should not be a problem...Dallas Semiconductor makes a nice little clock that sits under a ROM socket (or a separate 16 pin package for use with systems not using JEDEC 28-pin packages) that sits kinda "phantom" on the address bus and awakens when a specific sequence of addresses comes across the address bus, then passes the time serially across a data line during subsequent reads. So, unless the clock on the Magic Sac is required to be functionally identical to the one on the Mac, a clock is certainly possible, at a fairly low cost. Incidently, an additional chip is available from the same source that, using a similar setup, can bankswitch up to 16 banks of memory...so a single cartridge could access up to 16 banks of 128k, or 2 megs. Finally, a third chip uses the same addressing scheme to implement a simple serial port (very simple...software clocked, in fact, but probably sufficient to drive a printer)...of course, the bankswitch could probably switch in/out some memory-mapped i/o, like a Zylog SIO chip to drive an AppleTalk port. At any rate, if you get a chance, take a look in the Dallas Semiconductor data book...they have the most unusual chips in the industry. The company I work for uses their KeyRing Electronic Key for its AutoCAD-related product (only for the European/Far Eastern Versions though). It's probably the least objectionable form of copy-protection available on the market these days. Lance -- +------------------+ +------------------------------------------------------+ | Lance T Franklin | | Now accepting suggestions for clever, humourous or | | ltf@killer | | incredibly insightful .signature quote. Send Now! | +------------------+ +------------------------------------------------------+
dlm@druhi.ATT.COM (Dan Moore) (07/14/88)
in article <1988Jul12.201345.24692@gpu.utcs.toronto.edu>, lharris@gpu.utcs.toronto.edu (Leonard Harris) says: > Does anyone have any info on patching magic sac to the 128K roms. > I have the roms (legal ones) and I'm getting really frustrated that > a lot if my mac software won't run on the sac. It can't be that > difficult to do. ( and no, data pacific will NOT be coming out > with patches to do this - I heard they signed a deal with apple agreeing > not to make it 128K compatible. ) Technically there should be no problem. > Thanks > .leonard There is no way to modify the current Magic Sac (version 5.9 or 5.91) to make it work with the 128K ROMs. The 128K ROMs are _VERY_ different from the 64K ROMs, different things have to be done in order to make them work in the ST. Your correct about Data Pacific, they are not going to be releasing a 128K ROM version of the Magic Sac. There is no agreement with Apple not to do so though. In fact there are no agreements with Apple on anything other than the name, "Mac" is a trademark of Apple, therefore the name couldn't be "Mac Sac". Dave Small has left Data Pacific so there aren't going to be many new updates from them. The only new version Data Pacific will be releasing is 6.1. It has major improvments to the disk I/O performance. In one test a file copy which took 2 minutes using 5.91 required only 7 seconds using 6.1. Dave is currently working on improved versions of the software he developed. These improved versions will be marketed by him not by Data Pacific and will do everything you want them to do. (Great vague statement about the new features, unfortunately Dave is out of town so I can't clear anything more specific with him.) ------------------------------------------------------------------------------ Dan Moore ex-Data Pacific programmer, AT&T Denver technical support, hardware ihnp4!druhi!dlm tester and general go-fer. ------------------------------------------------------------------------------
tim@brspyr1.BRS.Com (Tim Northrup) (07/15/88)
From an article by stowe@silver.bacs.indiana.edu (holly): > > Data Pacific will not be coming out with a 128K version of Magic Sac, > but Dave Small (the original author) is no longer with DP, and he is > working on a 128K version. I don't have any release date information > as of now, though. For those interested that have ID's on GEnie, in the dataPacific Roundtable ("dp"), there is ongoing discussion on the 128k ROM version (current code name is "Spectre 128", I believe). There is also talk of getting sound to work on the Sac, which would be nice! -- Tim Northrup +------------------------------------------+ +---------------------------------+ GEnie: T.Northrup | UUCP: uunet!steinmetz!brspyr1!tim | Air Warrior: "Duke" | ARPA: tim@brspyr1.BRS.Com +------------------------------------------+
hase@netmbx.UUCP (Hartmut Semken) (07/17/88)
In article <4132@saturn.ucsc.edu> koreth@ucscb.UCSC.EDU (Froot-Loops Addict) writes: >In article <1988Jul12.201345.24692@gpu.utcs.toronto.edu> lharris@gpu.utcs.toronto.edu (Leonard Harris) writes: >>Does anyone have any info on patching magic sac to the 128K roms. >[deleted] >>Technically there should be no problem. > >I believe there is a technical problem, actually. Isn't the cartridge's >address bus only 16 bits wide? The cartridge port gives you 128 KBytes of adress space, this is not the problem. The problem is, the ROM software cannot run at the adress of the cartridge port. Magic Sac and Aladin (the german MAC-Emulator) load the ROM image into RAM, relocate and patch it (in case of Aladin) to acces the ST hardware rather than the MAC ports, floppy etc, and then run Mac software. Copying the ROMs into RAM ist what Apple Germany calls "illeagal duplication of copyrighted works"; that's why the Aladin must not be sold anymore to avoid legal action from Apple. besides: I like it very much. It seems more stable than the Sac; too good? :-) hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP High on a rocky promontory sat an Electric Monk on a bored horse. (D. Adams)