GDMike Posted August 8 Share Posted August 8 Yeah, apperson. Bit chewing helps us. Lol rocking your boat as usual Quote Link to comment Share on other sites More sharing options...
apersson850 Posted August 9 Share Posted August 9 23 hours ago, hhos said: apersson850, where else would it go? On a card in the box, or equivalent. That's what we are referring to here. The CPU will execute interrupts generated by hardware on a card as well and then execute the ISR stored on the card. That's how my clock card puts the current time on the p-system's screen, for example. Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted August 9 Share Posted August 9 If you have an horizon with Rambo you can load a user DSR in it which can contain an interrupt code as well if you wish. But also there a bug with rs232 DSR in that it thinks no other devices can generate an hardware interrupt, but that only can be a problem if you using a terminal program that sets up the rs232 to use interrupts. Quote Link to comment Share on other sites More sharing options...
Jeff White Posted August 9 Share Posted August 9 IIRC, there is a bug in the console ROM with regards to handling peripheral card interrupts as well as an ISR bug in TI RS232 cards — possibly other makes — that mishandles interrupts even when it is not set to use interrupts. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted August 9 Share Posted August 9 Concerning the suboptimal implementation of the ISR, see Thierry's analysis: http://www.unige.ch/medecine/nouspikel/ti99/rs232c.htm#RomISR Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted August 9 Share Posted August 9 On 7/24/2024 at 12:53 AM, Vorticon said: Any way to see some general example code on how to set up an ISR? The RTC on the IDE card can generate interrupts but I don't know how to service them. I understand interrupt vectors and such but have never seen actual code on this. It isn’t clear to me if you are trying to build code to service an interrupt or better understand how the interrupt routine finds which card generated an interrupt (and how the card’s dsr services it) or some other aspect. One good resource to poke at is the interface standard design guide. The link is also in post 1 of the development resource thread. https://oratronik.de/atariage/interface-standard-design-guide-complete_ti99.pdf Quote Link to comment Share on other sites More sharing options...
apersson850 Posted August 10 Share Posted August 10 (edited) As far as I understood @Vorticon he wants to know how to design a DSR for a card so that it can service interrupt calls generated from that card itself. In order to understand how my function with the clock on the p-system's screen can work. Simplest thing would be to show my source code, but I seem to have misplaced it. A diskette died on me and I think I screwed up the backup. Edited August 10 by apersson850 3 Quote Link to comment Share on other sites More sharing options...
hhos Posted August 13 Share Posted August 13 On 8/10/2024 at 2:58 AM, apersson850 said: Simplest thing would be to show my source code, but I seem to have misplaced it. A diskette died on me and I think I screwed up the backup. Perhaps you could get the binary off the clock's ROM and upload it to this forum? I would be willing to help recreate the source. There's sure to be others who could help as well, I think.🙂 I've been looking for a good example of an ISR and can't find a good one so far. The RS232 board, with its bugs, is the closest I've found so far.🤮 Has anyone ever attempted to replace that ROM with a bugless version? Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted August 13 Share Posted August 13 30 minutes ago, hhos said: 🙂 The RS232 board, with its bugs, is the closest I've found so far.🤮 Has anyone ever attempted to replace that ROM with a bugless version? There was versions of the RS232 that were fixed that was released by Dijit for their AVPC card as it uses the interrupt as well for the VDP. 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted August 14 Share Posted August 14 (edited) My clock has RAM, but that doesn't matter. I do have the assembled object code that I load to the clock card as well as the loader program. It's just the source that's the problem. Edited August 14 by apersson850 Quote Link to comment Share on other sites More sharing options...
+dhe Posted October 26 Share Posted October 26 I mentioned this book in today's zoom meeting. I think even for a TIer it's money well spent, as the ColecoVision and TI - share a VDP and Sound Chip. The book has excellent information on programming both. (You just have to over look the z80 assembly 😃 ) https://www.amazon.com/Programming-Games-ColecoVision-Adam-Assembler-ebook/dp/B08B5WNV3K 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 26 Share Posted October 26 Good book overall. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted Sunday at 03:34 PM Share Posted Sunday at 03:34 PM How does one AND 2 registers together? There is only an ANDI provided... 1 Quote Link to comment Share on other sites More sharing options...
Artoj Posted Sunday at 03:52 PM Share Posted Sunday at 03:52 PM (edited) 18 minutes ago, Vorticon said: How does one AND 2 registers together? There is only an ANDI provided... As usual TI have a way of expressing these things in a different way. SOC = OR SZC = AND thus SZC R1,R2 does exactly as AND R1,R2 in Z80 Edited Sunday at 03:52 PM by Artoj 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted Sunday at 04:33 PM Share Posted Sunday at 04:33 PM (edited) 49 minutes ago, Artoj said: SZC = AND thus SZC R1,R2 does exactly as AND R1,R2 in Z80 That is not quite right. SZC effectively ANDs R2 with the ones’ complement of R1, i.e., INV R1 SZC R1,R2 is required to actually AND R1 and R2. ...lee Edited Sunday at 04:42 PM by Lee Stewart clarification 5 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted Sunday at 04:43 PM Share Posted Sunday at 04:43 PM Thanks gents. One wonders why no AND was implemented... 1 Quote Link to comment Share on other sites More sharing options...
Stuart Posted Sunday at 05:59 PM Share Posted Sunday at 05:59 PM 1 hour ago, Lee Stewart said: That is not quite right. SZC effectively ANDs R2 with the ones’ complement of R1, i.e., INV R1 SZC R1,R2 is required to actually AND R1 and R2. ...lee Or the joy of self-modifying code if it is in RAM ... something like MOV R2,@SAVR2 ANDI R1,0 SAVR2 EQU $-2 6 Quote Link to comment Share on other sites More sharing options...
Tursi Posted Sunday at 07:02 PM Share Posted Sunday at 07:02 PM 2 hours ago, Vorticon said: Thanks gents. One wonders why no AND was implemented... They probably thought that SOC/SZC was a more flexible approach. Every so often I have this brief fleeting insight that it makes sense, then I go back to normal. 3 5 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted Sunday at 11:02 PM Share Posted Sunday at 11:02 PM Does the XOR instruction not accept a register as the first operand? Quote Link to comment Share on other sites More sharing options...
Artoj Posted Monday at 12:30 AM Share Posted Monday at 12:30 AM 7 hours ago, Lee Stewart said: That is not quite right. SZC effectively ANDs R2 with the ones’ complement of R1, i.e., INV R1 SZC R1,R2 is required to actually AND R1 and R2. ...lee Thanks Lee, I was thinking an inversion might be somewhere, as I cannot for the life of me find my Minimem module among my current PCB rubble LOL. I remember using SZC and SOC in so many lines of code 35 years ago, especially when dealing with graphics subroutines. Regards Arto. 2 Quote Link to comment Share on other sites More sharing options...
hhos Posted Monday at 02:04 PM Share Posted Monday at 02:04 PM 14 hours ago, Vorticon said: Does the XOR instruction not accept a register as the first operand? XOR is a type III instruction, so the source(1st operand) can be any register. The 2nd operand, the destination, must be any of the registers. In addition to the registers the source can be any General Address Source(GAS). Why do you ask? Is your assembler rejecting a register designation? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted Monday at 02:14 PM Share Posted Monday at 02:14 PM 7 minutes ago, hhos said: XOR is a type III instruction, so the source(1st operand) can be any register. The 2nd operand, the destination, must be any of the registers. In addition to the registers the source can be any General Address Source(GAS). Why do you ask? Is your assembler rejecting a register designation? It is rejecting indirect addressing of the second operand. For example XOR *R1,*R2 will give an error, but XOR *R1,R2 will not. Quote Link to comment Share on other sites More sharing options...
hhos Posted Monday at 02:38 PM Share Posted Monday at 02:38 PM That would be correct. As I pointed out, XOR is a type III instruction, and the destination therefore must be a register. Only type I instructions allow both operands to be GAS/GAD. They used up 75% of the possible opcodes to give this capability to 12 instructions: A,AB,C,CB,MOV,MOVB,S,SB,SOC,SOCB,SZC,SZCB. 3 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.