It is currently Mon Oct 20, 2014 4:48 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Wed Jul 23, 2008 11:08 am 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
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.


Top
 
PostPosted: Wed Jul 23, 2008 1:29 pm 
Offline
User avatar
 Profile

Joined: Wed Jan 09, 2008 7:30 am
Posts: 406
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.


Top
 
PostPosted: Wed Jul 23, 2008 3:25 pm 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
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.


Top
 
PostPosted: Wed Jul 23, 2008 3:30 pm 
Offline
User avatar
 Profile

Joined: Wed Jan 09, 2008 7:30 am
Posts: 406
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.


Top
 
PostPosted: Wed Jul 23, 2008 4:46 pm 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
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.


Top
 
PostPosted: Wed Jul 23, 2008 8:18 pm 
Offline
User avatar
 Profile

Joined: Wed Jan 09, 2008 7:30 am
Posts: 406
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.


Top
 
PostPosted: Thu Jul 24, 2008 12:53 am 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
Thanks Steve.

Kind regards,

Francis.


Top
 
PostPosted: Thu Jul 24, 2008 2:20 pm 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
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.


Top
 
PostPosted: Thu Jul 24, 2008 3:09 pm 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
I've just removed lines 120-160 from the above listing and this also seems to work. :?

Kind regards,

Francis.


Top
 
PostPosted: Thu Jul 24, 2008 3:26 pm 
Offline
User avatar
 Profile

Joined: Mon Jan 07, 2008 6:46 pm
Posts: 380
Location: Málaga, Spain
Yeah, you can just use the value returned directly in X :)


Top
 
PostPosted: Thu Jul 24, 2008 6:18 pm 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
Thanks Rich!

Kind regards,

Francis.


Top
 
PostPosted: Fri Jul 25, 2008 4:48 pm 
Offline
User avatar
 WWW  Profile

Joined: Wed Jan 09, 2008 10:23 am
Posts: 359
Location: Glasgow, Scotland
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.


Top
 
PostPosted: Tue Aug 25, 2009 4:07 pm 
Offline
 Profile

Joined: Sat Aug 22, 2009 7:45 pm
Posts: 34
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.


Top
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron