I've just removed lines 120-160 from the above listing and this also seems to work.
Kind regards,
Francis.
| www.retrosoftware.co.uk http://www.retrosoftware.co.uk/forum/ |
|
| 6502 co-processor compatibility http://www.retrosoftware.co.uk/forum/viewtopic.php?f=73&t=140 |
Page 1 of 1 |
| Author: | FrancisL [ Wed Jul 23, 2008 11:08 am ] |
| Post subject: | 6502 co-processor compatibility |
Hi guys, I'm writing a program that I would like to be compatible with the 6502 co-processor. What is the best way (i.e. fastest) way to output stuff directly to the screen? Here is an example snippet of what I am trying to do: Code: 10 MODE 2 20 DIM mc% 100 30 FOR opt%=0 TO 2 STEP 2 40 P%=mc% 50[ OPT opt% 60.loop LDA #&30 70.scrnaddr STA &3000 80 INC scrnaddr+1 90 BNE checkend 100 INC scrnaddr+2 110.checkend 120 LDA scrnaddr+2 130 CMP #&80 140 BNE loop 150 RTS 160] 170 NEXT 180 CALL start Kind regards, Francis. |
|
| Author: | SteveO [ Wed Jul 23, 2008 1:29 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
Do you mean you want your code to reside in the co-pro memory ? If in the co-pro memory then the above code won't work as the screen memory isn't in the co-pros memory, that's one reason why you've got lots of memory to play with on the co-pro side. To write to screen memory via the co-pro requires sending the bytes across the Tube interface. Which would slow things down a lot. If your running in the beebs side then your above code would be ok. If your running a graphic intensive program (i.e. a game) then getting the balance right between the two processors could be tricky. Open Question : Did any other games apart from Elite make use of the co-pros faster processor ? I'd have thought a Chess game or anything where it's mostly computational work would have benefited, but sprite base games would not have fared so well. |
|
| Author: | FrancisL [ Wed Jul 23, 2008 3:25 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
Hi Steve, I was just really wanting to be able to write to the screen memory regardless of whether the co-processor was active or not. Maybe I'm just better forgetting about the co-processor compatibility. Kind regards, Francis. |
|
| Author: | SteveO [ Wed Jul 23, 2008 3:30 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
I think the trend used to be to check for it, and if active inform user to switch it off before allowing the game to load. Otherwise it's a whole different machine if active. |
|
| Author: | FrancisL [ Wed Jul 23, 2008 4:46 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
I'm not at home just now so I can't consult my books for an answer, but how would you check if the co-processor is active? In reference to your open question, did UIM make use of the co-processor? I can't remember, but it would be the only other likely candidate that I can think of. Kind regards, Francis. |
|
| Author: | SteveO [ Wed Jul 23, 2008 8:18 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
Lifted straight from the advanced user guide; Quote: OSBYTE &EA (234)
Read flag indicating Tube presence. <NEW VALUE>=(<OLD VALUE> AND Y) EOR X The old value is returned in X. The contents of the next location are returned in Y. This location contains 0 if a Tube system is not present and &FF if Tube chips and software are installed. No other values are meaningful or valid. |
|
| Author: | FrancisL [ Thu Jul 24, 2008 12:53 am ] |
| Post subject: | Re: 6502 co-processor compatibility |
Thanks Steve. Kind regards, Francis. |
|
| Author: | FrancisL [ Thu Jul 24, 2008 2:20 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
I've written the following code for the TUBE detection: Code: 10 DIM mc% 100 20 osasci=&FFE3 30 osbyte=&FFF4 40 FOR opt%=0 TO 3 STEP 3 50 P%=mc% 60[ OPT opt% 70 LDA #&EA 80 LDX #&00 90 LDY #&FF 100 JSR osbyte 110 TXA 120 STY &70 130 AND &70 140 STX &70 150 EOR &70 160 LDA &70 170 CMP #&00 180 BEQ routine 190 LDY #&00 200.loop LDA message,Y 210 JSR osasci 220 INY 230 CMP #&0D 240 BNE loop 250 RTS 260.message EQUS "TUBE detected!" 270 EQUB 13 280.routine \ rest of program 290 RTS 300] 310 NEXT 320 CALL mc% It works, but I can't help but feel that it could be done better. I'm not sure about the <NEW VALUE>=(<OLD VALUE> AND Y) EOR X part. Is this necessary or can I just take the value in the X register only? Kind regards, Francis. |
|
| Author: | FrancisL [ Thu Jul 24, 2008 3:09 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
I've just removed lines 120-160 from the above listing and this also seems to work. Kind regards, Francis. |
|
| Author: | RichTW [ Thu Jul 24, 2008 3:26 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
Yeah, you can just use the value returned directly in X 
|
|
| Author: | FrancisL [ Thu Jul 24, 2008 6:18 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
Thanks Rich! Kind regards, Francis. |
|
| Author: | FrancisL [ Fri Jul 25, 2008 4:48 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
For anyone that is interested here is the improved version of the TUBE detection code based on Rich's comments: Code: 10 DIM mc% 100 20 osasci=&FFE3 30 osbyte=&FFF4 40 FOR opt%=0 TO 3 STEP 3 50 P%=mc% 60[ OPT opt% 70 LDA #&EA 80 LDX #&00 90 LDY #&FF 100 JSR osbyte 110 CPX #&00 120 BEQ routine 130 LDY #&00 140.loop LDA message,Y 150 JSR osasci 160 INY 170 CMP #&0D 180 BNE loop 190 RTS 200.message EQUS "TUBE detected!" 210 EQUB 13 220.routine \ rest of program here 230 RTS 240] 250 NEXT 260 CALL mc% Kind regards, Francis. |
|
| Author: | jgharston [ Tue Aug 25, 2009 4:07 pm ] |
| Post subject: | Re: 6502 co-processor compatibility |
If you want to be executing in the I/O processor then your load and execution addresses have to be in the I/O processor. |
|
| Page 1 of 1 | All times are UTC [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|