So I was kindda bored and started reading the CS8900A docu again.. and then decided to play around a bit.

OK, so RR-Net is hardwired for 8-bit mode. There is absolutely no way of switching it into 16-bit mode without HW modification (the /SBHE pin is connected to VCC). Yet, the RR-Net exposes the PacketPage Data Port 1 and the Receive/Transmit Data Port 1. These two ports allow for 32-bit transfers if combined with their Port 0 counter parts, according to the datasheet. This doesn't work however, and I suspect that this feature is ONLY available in 16-bit mode, but none of the cs8900a related datasheets say anything about this. It does however appear that the Port 1 regs work exactly like the Port 0 regs as long as you don't mix and match, so to speak.

Question(s): Why does the 8-bit Application Note (AN181) list the Port 1 regs as if they were interresting? - and why were they implemented on the RR-Net? - Did I miss something here?

The 8-bit Application Note (AN181) also states that the packet page pointer auto increment feature CANNOT be used in 8-bit mode. This seems to work perfectly though. - Just thought I'd let you know

What i was actually poking around the CS8900A for, was to see if I could find some reserved memory locations that would work as RAM, since it has relatively large amounts of reserved memory space.. I found 2 bytes at $015e
Anybody else tried this?

I suspect that one might be able to send a packet to one self and then read this back. This could work as a sort of slow serial bank switching ..maybe I'll try that next time I get bored

Ok.. so I just got bored again

Apparently nobody seems to be able or willing to try to give some sort of answers to any of the questions asked above.. so I'll rant on for a while..

I tried putting the cs8900a in loopback mode, then send a packet and see if I could read that packet back again. - and well, no surprise.. of course I could ..it's one of the chip's "marketed" features.. would also have been the first NOT to feature an internal loopback feature that I have seen.
Anyways, what I was actually trying to figure out was if it was able to buffer more than one packet in loopback mode, but no. Only one packet of 1514 bytes + CRC.. Additional packets I send just gets ignored until I read the receive buffer or issue a Skip_1. For some reason I can't seem to get it working by not generating CRC on send and then reading in the CRC upon receive. That would have given me 1518 usable bytes, but for now 1514 will have to do

And what is it good for then? Not a clue hehe.. but I guess somewhere out there in the future of some fancy MMC64 and/or RR application, one might be able to utilize these 1514 bytes for some wicked stuff.. or not.. but at least now you know you have the possibility

I guess we are just as puzzled as you are mate



I'm guessing the entire point with the loopback mode is to check if the CRC is correct.



I guess it's meant to check the functionality of the chip. Can't believe it's being an important feature these days. Either it works or it doesn't. It's a pretty neat way of gaining an extra kb of swap space though. Well done! Source code please!

Hehe.. well, sources are a mess as usual, but I think I'll try to clean it up a bit and reduce it to a minimum.. It's a standard send/recieve though, only difference it to the config, rx and tx regs. I'll see what I can do to explain it in code later on.


Yeah, well.. I think I figured why it won't work. In loopback mode the output and input buffers are directly connected. I guess this means that the CRC I'm telling the chip to read into the input buffer off the wire, never gets read since it didn't come from the wire but is already in the buffer. This would mean that the length of the packet is off by 4 and probably confuses the chip's receive buffer handler thingie. This could be easily tested by simply doing an external loopback. If that works, it would indicate that an internal loopback of 1518 user controlable bytes is not possible.

Oh, and I do know what the loopback is for What I meant was: What the hell are these 1514 serially swappable bytes good for in relation to c64 application

Hmm.. I must have misread something in the datasheet.. anyways, I now have routines that can swap from 8 to 1518 bytes in/out of RR-Net in internal loopback mode. 8 bytes is the absolute minimum the chip will accept and 1518 is the absolute maximum.
A source for a small test program will follow once I return from my weekend-activities

Nice!
Graham should update the TFR ROM to display 97.5K RAM SYSTEM