retrohackers.org
http://retrohackers.org/

Talking to the RR-Net
http://retrohackers.org/viewtopic.php?f=5&t=144		 Page 1 of 1
Author:  Bones [ Sat Jul 15, 2006 12:32 pm ]
Post subject:  Talking to the RR-Net
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 ?
Author:  Bones [ Tue Jul 25, 2006 5:07 pm ]
Post subject: 
No Ideas ?
Author:  hannenz [ Tue Jul 25, 2006 11:46 pm ]
Post subject: 
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 ;)
Author:  Kratznagel [ Wed Jul 26, 2006 12:46 am ]
Post subject: 
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
Author:  Devia [ Wed Jul 26, 2006 7:29 am ]
Post subject: 
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).
Author:  RaveGuru [ Wed Jul 26, 2006 9:15 pm ]
Post subject: 
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.
Author:  Devia [ Thu Jul 27, 2006 10:36 am ]
Post subject: 
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 :)
Author:  Bones [ Fri Jul 28, 2006 9:40 am ]
Post subject: 
Ah!
I see .. I was misunderstanding how to address the 16 bit memory addresses ..
thanks
Page 1 of 1 All times are UTC [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/