Patrick@ark.cs.vu.nl (Patrick van Kleef) (12/24/86)
*** MUNCH MUNCH MUNCH *** Just an idea: The most frequent error that occurs using the Mac Emulator, is a bus error. This happens when programs start writing at locations they're not allowed to on the Atari ST. Usually it means the software wasn't 'perfect', not in accordance with the Apple Programming Guidelines. People tell me there is a way of preventing bus errors on the ST. This type of error is generated by one line of the Glue chip, the so called BERR line. Now what if we disconnected that line? In theory bus errors would be impossible. Would it affect 'normal programs'? Will more Macintosh programs run? Is there anyone who can figure this out? Dave Small writes, the most frequent error is the bus error that occurs when Mac programs write at location 0, Ram at the Mac, Rom at the ST. This action has -as far as I know- no effect on the working of a program on the Mac. But on the ST, a bus error occurs and the program fails to run. Would a switch, that disconnects the BERR line on the Glue have the same effect as on the Mac. Namely that programs run without further failure? I think it would increase the amount of good working Mac software a lot. As I'm too much of a kludge concerning hardware (and software too, for that matter), I'd like the opinion of some experts. Moshe, do you have any idea?
joeb@marque.UUCP (Bronikowski) (12/27/86)
In article <870@ark.cs.vu.nl> Patrick@ark.cs.vu.nl (Patrick van Kleef) writes: > >People tell me there is a way of preventing bus errors on the ST. This >type of error is generated by one line of the Glue chip, the so called >BERR line. > >Now what if we disconnected that line? In theory bus errors would be >impossible. Would it affect 'normal programs'? Will more Macintosh programs >run? Is there anyone who can figure this out? I know nothing about the internal architecture of the ST or Mac, but from my experience with 68000's I can tell you this much: The Bus Error signal (BERR) is generated when no device on the bus responds to the address strobe with a data-tranfer acknowledge signal (DTACK). It is usually generated by some sort of timer circuit that watches the DTACK line; the system designer sets the timer to a little longer than the maximum acknowledge time of all the devices in his system (perhaps 1 - 2 micro seconds maximum, for some slow I/O devices). Thus if you disable the BERR signal by pulling the pin from wherever it is generated, the micro will essentially wait FOREVER for that memory access to finish! Any programs which cause bus errors would now hang the system. A better way to go might be writing your own exception handler and storing its address in the bus error exception vector (hopefully the ST's vectors are in RAM and not ROM!). It probably would be impossible to make the programs run correctly, but at least you could handle the errors more gracefully. Joe Bronikowski
jafischer@watrose.UUCP (01/14/87)
In article <37@marque.UUCP> joeb@marque.UUCP (Joe Bronikowski) writes: >In article <870@ark.cs.vu.nl> Patrick@ark.cs.vu.nl (Patrick van Kleef) writes: >> >>People tell me there is a way of preventing bus errors on the ST. This >>type of error is generated by one line of the Glue chip, the so called >>BERR line. >> >>Now what if we disconnected that line? In theory bus errors would be >>impossible. Would it affect 'normal programs'? Will more Macintosh programs >>run? Is there anyone who can figure this out? The Mac has RAM in locations 0-8 that is unused by the OS (after booting), and some Mac programs, you would think, must actually USE this RAM. The ST has ROM in that area (or is it just ROM in location 0?), so eliminating the BERR would do no good. The program would still not work. It would be like eliminating the sensation of pain. You wouldn't feel that you have just sawed off your right leg, but it would still be gone. The above is based largely on hearsay and stuff from Magic Sac README files, so I may be partly wrong. Am I? -Jonathan Fischer
ravi@mcnc.UUCP (01/30/87)
[] I remember reading in the original posting regarding the PD Mac emulator from Europe that it used parts of Dave Small's Magic Sac. Wouldn't that be illegal? I think he has a clause in the sale agreement that specifically prohibits disassembly of his code, etc. Even if someone manages to get the Mac ROM's on disk (?), would using the emulator itself be kosher? If anyone knows more about this, please comment (Peter?) -ravi
paulm@ccicpg.UUCP (tmp Paul Moreau usenet acct) (11/28/89)
I sorry for posting this here but my reply to the 'sender' just bounced. I am VERY interrested in the MAC Emulator. I've never used a 'MAC' but I am very interrested in trying one. Buying Spectre 128 is just too much for something I'm not sure of. If you need someone to re-post the code let me know, I can do that. Thanx in advance! ---- .===========================================================. | ### ####### ### | N O R T H | /==============\ | | ### ### ### | A M E R I C A |< An STC Company >| | ### ####### ####### | (was CCI) | \==============/ | |-----------------------------------------------------------| | UUCP: ...ccicpg!dl2!paulm | Paul L. Moreau | | or ...ccicpg!dl1!paulm | Diagnostics Software Eng. | | or ...ccicpg!paulm | Irvine, California | `==========================================================='
kc_yeo@sngsf1.SINet.SLB.COM (KC Yeo*Sedco Forex S'pore*Tel-65-345-9944*Fax-65-344-2655) (03/25/90)
I have heard of Mac emulator on the Atari16 but do not know how it works, the price, software compatibility, problems and etc. Will appreciate those experienced users out there for any information on this product. Thank you. Arthur KC_YEO@SNGSF1.SINET.SLB.COM
SO-JAM@finou.oulu.fi (JACOB MATTHAN) (01/25/91)
One of my colleagues will be visiting USA shortly and wants to
buy a MAC emulator. Can someone give me the name and address of
a reliable dealer in or around ALBANY. I am not a regular reader
reader of this group so please e-mail me.
Thanks in advance.
JACOB MATTHAN