Hi,

First of all thanks for testing - and the positive feedback .


Regarding the C128 version:

- It works on VICE in C128 mode. Therefore most likely it's not generally broken.
- It uses the very same CS8900A driver binary used by the C64 version.

So my guess is that the info I got saying that RR-Net works just same as with the C64 is not 100% accurate. However I have not options to track that down. Maybe a "simpler" TFE-style hardware works ?!? Somebody would need to take care of investigating...

Result: The C128 port will not become part of the official Contiki for now.


Regarding http://www.c64web.com:

@zap: Great to see Contiki 2.1 in action - and thanks for the credits .

However I thought that you consider an alternative disk storage system like MMC64/Dreamload as obligatory. Do you already have a satisfying solution? What are you currently using? What have you tested but didn't work? Future plans?


Regarding MMC64:

@RaveGuru: Thanks for the info. Is your code available on the net? If not, could you make it available to me?


Best, Oliver

Both Contiki 1.2 and 2.1 work fine on my 128D in 64 mode with RetroReplay/RRNet hardware combo.

However, the native 128 version of Contiki 2.1 does not. Shane, did you notice that this native 128 version requires the 80 column mode display?

Getting Contiki v2.1 up and my website back online now done i will start to test Contiki v2.1 on other drive,s.

I am so happy just to be able to use more html code at the moment as contiki v1.2 allowed only minimal amount of html code due to the larger memory use i " guess ".

I am now using more than double the amount of code on the webpage and its fine .

Also its been 18hrs and the c64 has not locked so code must be stable.

No more COMPILING a big plus as the code is now outside the program file
wow this is great news and should allow other c64 user,s to easily place a Commodore 64 on the web.

I am on my way to work on return will try it on other media.

Have Fun and Thanks again.

_________________
Have Fun!!

It loads but just sits there.
I will play about with it a bit more later maybe a different ethernet card without clock port like the RetroReply/MMC card will work.

You got it to work in c64 mode mine will not.

I have another c128 coming i will try it on that one fingers crossed.

_________________
Have Fun!!

Oliver do you have a Website ?.

_________________
Have Fun!!

Is there a precompiled binary available for download?

_________________
Call me Golan; my parents did.

Yes, in the Uploads section

Hi Oliver,

Is there any chance you could compile a 40 column version running at 1Mhz. 80 column mode shouldn't be a problem but the 2MHz mode might be. I suspect that the Retro-Replay is using pin E of the C64/128 expansion port (phase 2 system clock) for timing purposes. Running it at 2Mhz may cause issues with the Retro-replay and it's clock-port implementation. This may be why the RR-Net isn't working with Contiki 2.1 in native 128 mode. Just an idea.

Regards
Fotios

Another thing i like about Contiki v2.1 over v1.2 is it displays where the user is coming from.

ie

138.48.33.xxx: index.html
Referer: http://retrohackers.org/forum/

Its a simple thing but i like it.

Contiki v2.1 is working on a CMD-FD2000.

I asked Oliver to select his prize as the winner of the Contiki Challenge with the release of Contiki v2.1 as it meets all aspects of the Challenge .

Thanks also to

hollowman who gave it a good go i learned alot from this fellow who sent many emails to me about compiling, dreamload etc .

RaveGuru for allowing it.

I like to think the challenge got contiki v2.1 completed ahead of time looking at the forum you might think that not alot was happening but
many email's were sent to me with programs to try and results sent back i looked forward to the emails as the Contiki Challenge seesawed backwards and forwards towards completion.

Have Fun Shane.

_________________
Have Fun!!

@zap: Thanks for a cool challange. I hope to see more of this on the forum in the future

@oliver: IIRC that Vice implementation of RR/RR-Net doesn't require you to activate the clockport. Could it just be the clockport setup that's incorrect? All I do (provided that you attach RR-Net to RR and RR to the C64) is...

...to activate the clockport and that's about it for the initialization. The mmc64 setup involves a few more steps. After this I do the cs8900a_init(), uip_init(), etc.

I had the Contiki 2.1 webserver send a 40kB jpg without any issue - beside the floppy disk performance maybe .

Actually it is supposed to successfully send files as large as the underlying DOS supports.

Best, Oliver

I'd like to thank everybody in this thread pointing me to the clockport issue und helping me to understand - at least enough to get the driver working !

Yes, the VICE implementation of RR-Net is really just an emulation of RR-Net and not an emulation of RR+RR-Net. The NIC selection just adjusts the I/O port mapping. Otherwise I would have notice much earlier that I was missing something.

Now some words on the actual implementation (and the missing MMC64 support): I'm afraid that this seems quite arrogant/ignorant - especially as I'm just starting to begin to understand thing - but nevertheless:

The goal for my Contiki 2.1 port to cc65 targets is really to stay as generic and "clean" as possible. I hope that the extremly quick availability of the C128 port kind of proves that benefit.

I put quite some effort I implementing the Ethernet support in a generic way as well:

1. Separate the common stuff (like ARP handling) from the actual device driver (which isn't common for Contiki) and load the actual device drivers based on user configuration at runtime using the cc65 module loader.

2. Let the device drivers modify themselves to the user configurable I/O port mapping. This allows to support all "known" NICs both in the CBM and Apple world with just two driver binaries. The Apple2 benefits from this especially as it has 7 slots a NIC can be plugged in in every slot has a specific "own" port mapping range.

That self modification generally works this way: The NIC register addresses are declared as offsets to the base address. For the CS8900A in example:

rxtxreg := $0000
txcmd := $0004
...

Then the highbyte of address given in the configuration file is used to just overwrite all register address highbyte occurances and the lowbyte is ORed with all register address lowbyte occurances.

That works for every C64/Apple2 NIC but the RR-Net. Fortunately there was an elegant solution for that: Just replace the OR with an XOR. With a configuration address of $DE08 it does the same address bit-3 toggle done in the RR-Net hardware. So far so good - no "if RR-Net then ... else ..." type of code .

But then came the RR clockport initialization: Checking out the CS8900A data sheet I noticed that in 8-bit non-interrupt mode any read/write access to the ISQ (Interrupt Service Queue) is supposed to have no effect at all. So I declared the register in the usual way:

isq := $0008

And added the follwoing code:

; Activate C64 RR clockport in order to operate RR-Net
; - RR config register overlays CS8900A ISQ register
; - No need to distinguish as ISQ access doesn't hurt
fixup01:lda isq+1
ora #$01 ; Set clockport bit
fixup02:sta isq+1

You see - the code is unnecessary with all other NICs but still no "if then else" .

From my perspective I've stretched my generic approach to the maximal extent. And - although I have very limited knowledge on this - I feel that there's rather something "wrong" with the MMC64 if it isn't able to "emulate" the behaviour of RR more closely when it comes to replace RR as RR-Net "mother".

Once more thanks for the great friendliness and support in this community. There's one other binary I plan to create out of the existing Contiki applications. Maybe in time for a XMAS present ... But then I really hope that someone else will take advantage of Contiki 2.1 to built something !

Best, Oliver

See 'Uploads' .

I presume this is for testing purposes only as I don't see the point in a native C128 program taking no advantage at all of any C128 feature...

Is there any chance that your upcoming NIC works with 2MHz? Talking about that: Do you already have an idea on the price?

Best, Oliver

2 MHz should not be a problem, as the C128 brings the CPU down to 1 MHz during I/O write cycles.

Thanks Oliver.

Yes, it's for testing purposes only. I'll give it a shot when I'm back at home tomorrow as I'm out of town at the moment. However, MagerValp pointed out that the C128 uses 1MHz for IO operations so it may not make any difference.

If all goes to plan, my NIC solution will not use a clockport. I should be able to announce pricing some time next week.... I hope.