SMB.MDC@OFFICE-1.ARPA.UUCP (07/16/86)
Is there a way to replace the MFP interrupt service routines with a user written version? I've been looking for a table which contains the address of the ISRs, but haven't been able to locate it. Is the BIOS in a different location in the 1040ST? I have the ST internals book and the BIOS listing doesn't seem to be correct for my computer.
dyer@atari.UUcp (Landon Dyer) (07/17/86)
In article <MDC-SMB-9K5PJ@OFFICE-1>, SMB.MDC@OFFICE-1.ARPA writes: > Is there a way to replace the MFP interrupt service routines with a user > written version? I've been looking for a table which contains the address of > the ISRs, but haven't been able to locate it. 68901 interrupts are based at 0x100: Vector Function 0x100 (disabled) Centronics BUSY 0x104 (disabled) RS232 Carrier Detect 0x108 (disabled) RS232 Clear-To-Send 0x10c (disabled) 68901 timer D (RS232 baud rate) 0x110 (disabled) GPU operation done 0x114 200hz System clock (timer C) 0x118 Keyboard/MIDI (wire-ORed interrupts from both 6850s) 0x11c (disabled) Floppy/hard disk controller 0x120 (disabled) Horizontal blanking counter (timer B) 0x124 RS232 transmit error 0x128 RS232 transmit buffer emtpy 0x12c RS232 receive error 0x130 RS232 receive buffer full 0x134 (disabled) 68901 timer A 0x138 (disabled) RS232 ring indicator 0x13c (disabled) Polled monitor type > Is the BIOS in a different location in the 1040ST? I have the ST > internals book and the BIOS listing doesn't seem to be correct for my > computer. The ROMs for the 520ST and the 1040ST are identical. The BIOS listing you have is from the first RAM-loaded release of the system, not from the later ROMs. The listing is useful in that it gives examples (e.g. how to twiddle the ST's hardware), but DON'T expect the addresses or code in the ROM to match your listing. -Landon -- -Landon Dyer, Atari Corp. {lll-lcc,lll-crg!vecpyr}!atari!dyer /-----------------------------------------------\ | The views represented here do not necessarily | "If Business is War, then | reflect those of Atari Corp., or even my own. | I'm a Prisoner of Business!" \-----------------------------------------------/
rb@cci632.UUCP (Rex Ballard) (07/25/86)
In article <389@atari.UUcp> dyer@atari.UUcp (Landon Dyer) writes: >In article <MDC-SMB-9K5PJ@OFFICE-1>, SMB.MDC@OFFICE-1.ARPA writes: >> Is there a way to replace the MFP interrupt service routines with a user >> written version? I've been looking for a table which contains the address of >> the ISRs, but haven't been able to locate it. > >68901 interrupts are based at 0x100: > >> Is the BIOS in a different location in the 1040ST? I have the ST >> internals book and the BIOS listing doesn't seem to be correct for my >> computer. > >The ROMs for the 520ST and the 1040ST are identical. The BIOS listing >you have is from the first RAM-loaded release of the system, not from >the later ROMs. The listing is useful in that it gives examples (e.g. >how to twiddle the ST's hardware), but DON'T expect the addresses or >code in the ROM to match your listing. >-Landon Dyer, Atari Corp. {lll-lcc,lll-crg!vecpyr}!atari!dyer Thank you for giving the information. Just out of curiousity, did you fix the perverse usage of the high address bits so that a 68010 or 68020 could be used in place of the 68000? You forgot to caution against jumping into the ROM for any reason. This shouldn't be necessary for the ST since almost all of the "useful routines" are available as "system calls" or exceptions. Let's hope we can avoid the "hacker tactics" used on the Atari 800, Apple II, and IBM-PC. Otherwise Atari can't come up with better versions and bug fixes. Landon, maybe you could give some "ground rules" about "hostile applications" that "take over" vectors for private use. Definately not reccomended if Atari plans to go to multi-tasking in a future ROM release.
gnu@hoptoad.uucp (John Gilmore) (08/04/86)
In article <259@cci632.UUCP>, rb@cci632.UUCP (Rex Ballard) writes: > ...did you > fix the perverse usage of the high address bits so that a 68010 or 68020 > could be used in place of the 68000? This is a red herring. First, a 68010 has the same address space as a 68000. Second, a 68020 just feeds those bits out on pins; if you have less than 16 megs of stuff to address, you're free to ignore the pins. Third, if what they are doing is putting the vector number in the high byte of the interrupt vector address, this is no problem. They will have to rewrite the interrupt vector code in a minor way for the 68010/20 anyway; in fact, their trick lets them use the same assumptions (e.g. that multiple interrupt vectors can point to the same routine, but the routine can tell which interrupt actually happened) in the 68000 as well as in the later models. I wish I'd thought of it! It's not hard to write code that figures out which CPU it's on and copes with the stack frame differences. I wrote that code when I first got a sample 68010. The system can, at boot time, cause a software trap and look at the size of the resulting stack frame (6 bytes on 68000, 8 on 68010/20). That test can set a flag that anybody who cares can check. The test for 68020 is even easier; user programs can do it. Use an instruction that does scaled indexing. The scaling bits are ignored on 68000/68010 and used on 68020. (I used "moveq #4,d0" followed by "jmp pc@(4,d0*2)", which either jumps to pc+8 or pc+12. You can adjust the constant to suit.) For example, you could stick a 2-instruction test on the front of a multiply routine that, if run on a 68020, would jump to a 32-bit multiply instruction but on the older models would do it the hard way. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!