It is currently Thu Jan 22, 2026 10:48 am

All times are UTC [ DST ]




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Talking to the RR-Net
PostPosted: Sat Jul 15, 2006 12:32 pm 
Offline
User avatar

Joined: Fri Jan 13, 2006 12:27 pm
Posts: 30
Hi ..
I finally got around to writing a bit of code and I have a question .

I am using XLANG for the language and trying to work my way thourough The docs in Scarebears ethernet experiments

here is the code:

Code:
;----------------------------------------------------------
;              Experimentation with rr-net
;----------------------------------------------------------

; --- Basic Header ---

*         do  0
         org $0801        ;set assemble address

         da               $080b;link
         da  2006         ;line number
         dfb $9e          ;sys
         txt '2061'
         dfb 00,00,00
*         fin

; --- Variables ---

UByte CS_PacketPage_a@$de02
UByte CS_PacketPage_b@$de03
UByte CS_PacketData0_a@$de04
UByte CS_PacketData0_b@$de05
UByte CS_PacketData1_a@$de06
UByte CS_PacketData1_b@$de07
UByte CS_RxTxPort0@$de08
UByte CS_RxTxPort1@$de0a
UByte CS_TxCmd@$de0c
UByte CS_TxLength@$de0e
Byte Temp_var

; --- Get id of rr-net card ---

poke CS_PacketPage_a,0


Println CS_PacketData0_a
Println CS_PacketData0_b


Poke CS_PacketPage_b,0

Println CS_PacketData1_a
Println CS_PacketData1_b


WaitChar


; --- Includes ---

Put 'PutCore.I.s'



this produces an output of :

    0
    3
    14
    99

which in binary =
0000 0000 - 0
0000 0011 - 03
0000 1110 - 14
0110 0011 - 99

According to the docs this is correct (I think), but I originally tried this :

Code:
poke CS_PacketPage_a,0
Poke CS_PacketPage_b,0

Println CS_PacketData0_a
Println CS_PacketData0_b
Println CS_PacketData1_a
Println CS_PacketData1_b


which only produced :
    14
    99
    14
    99


Can anyone tell me why this is ?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jul 25, 2006 5:07 pm 
Offline
User avatar

Joined: Fri Jan 13, 2006 12:27 pm
Posts: 30
No Ideas ?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jul 25, 2006 11:46 pm 
Offline

Joined: Thu Jan 12, 2006 8:04 am
Posts: 116
Location: Germany / 88471
no idea, sorry - all i can say is that i stopped using xlang since it often seems to behave so unpredictable, just as in your case, but i didn't look any closer into this... maybe you try with assembler or cc65??!

EDIT: i tried it with cc65 and it occurs exactly the same. but i don't know why. ???

Code:
#include <stdio.h>

unsigned char *CS_PacketPage_a = (unsigned char*) 0xde02;
unsigned char *CS_PacketPage_b = (unsigned char*) 0xde03;
unsigned char *CS_PacketData0_a = (unsigned char*) 0xde04;
unsigned char *CS_PacketData0_b = (unsigned char*) 0xde05;
unsigned char *CS_PacketData1_a = (unsigned char*) 0xde06;
unsigned char *CS_PacketData1_b = (unsigned char*) 0xde07;

int main(){
   *CS_PacketPage_a = 0x00;
   *CS_PacketPage_b = 0x00;
   printf("\n%d %d ",*CS_PacketData0_a,*CS_PacketData0_b);

   printf("%d %d",*CS_PacketData1_a,*CS_PacketData1_b);
}


gives 14 19 14 19
while when moving the "POKE" between the printf's it gives 0 3 14 99... just as you said...
so xlang is not to blame ;)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jul 26, 2006 12:46 am 
Offline

Joined: Wed May 31, 2006 12:21 am
Posts: 34
Hi!

I don't know much about RR-Net programming, but I just tried out a bit.
And I found out that the right way to get data form RR-Net is like this (taken from Baccy's led flasher program):

Code:
;--------------------------------------
; look for crystal magic and version number
; the product id is located at packet page 0 - 3 and contains
;   $0e $63 $00 VV
; where VV is the revision code of the chip
;   Rev B : $05
;   Rev C : $06
;   Rev D : $07
; (i have no idea what happened to Rev A)

cs_detect:
   lda #0         ;check for the first 2 magic bytes
   jsr cs_readPage
   cpx #<$630e
   bne notfound
   cpy #>$630e
   bne notfound

   lda #1         ;check for the second magic bytes
   jsr cs_readPage
   cpx #0
   bne notfound
   tya         ;they also contain the version nr of the chip
   ldx #2
detectVersion:
   cmp revcode,x
   beq found
   dex
   bpl detectVersion
notfound:
   sec
   rts

found:
   clc
   rts

revcode:
   .DB $07,$08,$09

;--------------------------------------
; read the packet page register (a*2) to x(lo) and y(hi)

cs_readPage:
   asl
   sta CS_PacketPage
   lda #0
   rol
   sta CS_PacketPage+1
   ldx CS_PacketData0
   ldy CS_PacketData0+1
   rts

;--------------------------------------


You dont't need to access CS_PacketData1 because it obviously contains the same data like CS_PacketData0 after writing something to CS_PacketPage.

Instead you have to access the two registers $0000 and $0002 (adressed in 16 bit (low/high) via CS_PacketPage) in a row to suck the two 16-bit-values out of CS_PacketData0 which determine the revision number.

In SLANG it should look like this:
Code:
poke CS_PacketPage_a,0
Poke CS_PacketPage_b,0
Println CS_PacketData0_a
Println CS_PacketData0_b

poke CS_PacketPage_a,2
Poke CS_PacketPage_b,0
Println CS_PacketData0_a
Println CS_PacketData0_b


I tried this thing out myself with ACME and got $0e 63 00 09, exactly the value for revision D. :)

CU
Kratznagel


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jul 26, 2006 7:29 am 
Offline
User avatar

Joined: Thu Jan 12, 2006 12:52 am
Posts: 203
Location: Denmark
Hmm.. it's been too long ago since I did any RR-Net code, but I remember the CS8900 datasheet being pretty specific about how to read/write data from/to it. I also remember there were some caveats, so maybe you should re-read the datasheet and pay close attention to the order in which the different 16bit registers need to be read/written (i remember something fishy in that region).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jul 26, 2006 9:15 pm 
Offline
Site Admin

Joined: Wed Jan 11, 2006 11:22 am
Posts: 874
Yep! Especially important is the Crystal AN-181 application note on using the CS8900 in 8-bit mode. It's available for download in the RR-net section.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jul 27, 2006 10:36 am 
Offline
User avatar

Joined: Thu Jan 12, 2006 12:52 am
Posts: 203
Location: Denmark
So I dug through some of my rr-net code and I this is how I defined my NIC read/write macros:

Code:
NIC_PPPtrL      = $de02
NIC_PPPtrH      = $de03
NIC_PPData0L      = $de04
NIC_PPData0H      = $de05

.macro NICPut addr,data
   lda   #<(addr)
   sta   NIC_PPPtrL
   lda   #>(addr)
   sta   NIC_PPPtrH
   lda   #<(data)
   sta   NIC_PPData0L
   lda   #>(data)
   sta   NIC_PPData0H
.endmacro


.macro NICGet addr,dest
   lda   #<(addr)
   sta   NIC_PPPtrL
   lda   #>(addr)
   sta   NIC_PPPtrH
   ldy   NIC_PPData0L
   ldx   NIC_PPData0H
.ifnblank dest
   sty   dest
   stx   dest+1
.endif
.endmacro




So, lo, hi, lo, hi ;-)
Anyways, just read Kratznagels post again and saw that the answer is actually in there.. maybe I should pay more attention when reading ;-)

@Bones: When defining macros like the ones above and creating proper include files with proper definitions in them, coding stuff like this actually becomes a LOT easier to do in assembly than any other language.

oh, and ca65 is imho the best available x-assembler :)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jul 28, 2006 9:40 am 
Offline
User avatar

Joined: Fri Jan 13, 2006 12:27 pm
Posts: 30
Ah!
I see .. I was misunderstanding how to address the 16 bit memory addresses ..
thanks


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 13 guests


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
Powered by phpBB® Forum Software © phpBB Group