This has been a fascinating process.
First, the 8-bit mode of the CS8900a chip that the RR-NET uses is a bit weird, as it still uses 16-bit registers, and so you have to write to the two halves of the registers in turn, among various oddities.
Once I figured out the semantics I managed to get packet receiving working relatively quickly. Packet transmission proved a little more frustrating, until I eventually removed the buggy code and wrote it again from scratch. This is often the case with software that it is faster to re-write something than it is to fully understand and fix it.
I wrote a little BASIC test program that just uses POKE to send an ethernet frame, and it works quite nicely.
However, I haven't had a fully positive response from any of the C64 network-enabled programs I could fine.
The Breadbox64 twitter client requires a supertweet account, and Twitter have disconnected supertweet, so no joy there.
udpslave runs, sees packets, and tries to send replies, but seems to mess up the checksum fields. I don't know whether this represents a bug in my RR-NET emulation, the C65GS more generally, or something else.
The Contiki webserver runs, but fails to actually service any request, even though it does respond to ARP, reply to PING (sometimes at least), and can see and parse HTTP requests given to it. It looks like there is something fishy going on with packet reception. I might need to improve buffer handling in my ethernet controller to stop packets getting stomped on while you are still reading them out. You can see what it does here:
The Contiki webserver and IRC client don't want to accept keyboard input on the C65GS for reasons I don't understand.
Most of the other ethernet-enabled software for the C64 requires either GEOS or a Final Replay or similar cartridge, neither of which are an option right now.
So I am at the frustrating point where it mostly works, and I can see very tantalising signs, but can't actually do anything useful with it.
The one program I have yet to test, but intend to, is the RR-NET version of 64NET/2. 64NET/2 is software that I wrote almost 20 years ago to interface C64s to PCs, and which was extended by some volunteers to support the RR-NET in place of a user port cable. The RR-NET version consists of a patched kernel, which will be easy enough to load on the C65GS, I just need to make a little program that can load a custom kernel and then restart the machine.
Geos shouldn't be that demanding for the VIC and SID. I guess your main problem is that, due to its fast loader & copy protection, it is quite demanding for a 1541 emulator. But what if you used a real 1541?
ReplyDeleteHello Daniël,
ReplyDeleteActually, GEOS isn't quite so hard, because it is possible to replace the default fast 1541 driver (or better, 1581 driver) with something else. There is a port of GEOS to the old parallel cable 64NET v1 for example, that could be used as a very handy starting point. It might even be that I make a kind of exception system for the C65GS, so that accesses to the user port trigger a hyper-visor exception and the 64NET server then effectively lives inside the C65GS itself. In that way, the 64NET version of GEOS wouldn't need any modification at all.
But back to allowing a real 1541, I do plan this, however the timing may (or may not) be accurate enough to support some of the fancier fast loaders. This will depend a bit on how I do the 6510 emulation. I oscillate between having a separate 6510+VIC-II core for c64 compatibility mode, versus adding a 6510 personality to the 45GS10, and putting some work into making the VIC-IV a little more VIC-II compatible, e.g., supporting VSP and some other of the more common effects. But it will likely be a while before I have to make the final decision.
Paul.
Well.... as you are building a C65 system, you should be carefull to to fall into the C128 trap: The C128 was 100% compatible, but because there was no new functionality in C64 mode, nobody was able to enhance his software for C128 while keeping it compatible with the hugely popular C64. And therefore buying a C128 was not atrractive enough, further reducing the market for native C128 software.
ReplyDeleteWhile commcerical succes might not be your goal here, I do think it makes sense to stay close to the C65 philiosofy. So build an enhanced machine rather than perfect emulation, perfect emulation has been done before after all. A separate VIC-II core might give perfect compatibility has the same risk of offering no enhancements. IMO it should be compromise between compatibility and new features.
Some support fort fast loaders will be necessary though. The 1541 is so slow that the C64 experience is greatly reduced without them.
You are quite right, and this is the approach I am taking, to make it reasonably compatible, but without sacrificing the ability to add interesting new features. In fact, it is the philosophy page from the C65 specifications book that is my guide in this.
DeleteAt the moment all enhanced features are available from C64 mode, as they are on a C65. This might change a little if I implement my plan for a hypervisor, as it would be possible to control which features (and which parts of RAM) are available to a given session, partly for segregation, but also partly for compatibility assistance. For example, it might be necessary to hide 4510 extended opcodes from some programs or other things like REU that might upset some software.
Paul.