Posts by M3wP

    I am working on a MIDI based synth driver for the M65 right now! :)

    Once it is a bit more functional and robust, I will look at getting a MIDI port expansion cart (probably the Datel one, though..) for Paul to test and then for me to implement MIDI input and processing from it.

    Hmm... You have me thinking now about how I could redesign the system to use UDP instead.

    This is specifically a test to see if TCP/IP will work well enough, though. I will definitely keep what you have said in mind for the future. There really is a lot of overhead for the poor ol' C64 doing TCP/IP...


    Argh... I seem to have lost that version of the program. I was being very lax about keeping things organised at the time.

    I'll see what I can do about reshuffling my schedule to get the Mega65 project stuff happening in the next few weeks.

    I really should have sorted this out a long time ago. Sorry, sorry!


    Yes, I agree there are many issues and this is why I'm starting with something "simple" although "real world" and seeing how it goes.

    I don't want to implement my own ACK/NAK, keep alives and so on. That's what TCP is for! Hehe :) The packets really have to be in the correct order too and this isn't guaranteed with UDP. Its really a test to see what's possible. I do agree that you should probably try to use UDP where possible, though.

    I have noticed fragmentation and message "condensation" (multiple messages in one packet) in my "PC" (Windows/Android) client and server and have done my best to handle that. I have markers (a length byte) in the messages to help determine if a whole message or more is being received.

    I don't know what to do about "side channel" and ICMP. I'm hoping this is handled in the driver and its just ignored. I think the C64 client could easily be swamped by a malicious server though.

    I think I should get away with it all, in the end. I'm not going to try to implement the server on the C64. I think that is really out of scope.


    I must just pop in a post here and make an apology for the configuration program "problem" that Paul had...

    I have tried to give him an update without the "Apply Now" feature (three times) but there was a hectic amount of work going on for both of us at the time and it seems to have been lost.

    I actually still think that the feature would be useful for when changing video settings and allowing a check to ensure that they are working but this confirmation check isn't currently present. Without it, the feature is kind of redundant.

    Anyway, we should sort it out! *lol* :P


    Awesome that you have an ip65 driver in the works already. I will definitely want to get that from you in the not too distant future and will very likely need some help with it.

    As for UDP... I think its fine if you don't need to know for sure that the client "is there" all the time and if you're doing continuous state updates that needn't be acknowledged all of the time but for my Yahtzee! client, I really do need to know for sure that the client is still connected. Also, there is only a state update when one of the users does something and it has to be acknowledged and further, these updates have to occur in the correct order (mostly). TCP is the best for it.

    Yes... There is a huge overhead in processing, code and data. I think that there is about 4KB (at least) of code and another 4KB of data required by ip65 to get TCP/IP working. I can't remember how much effective raster time it uses/needs but I think its a lot. It hurts a lot for my client because I have a fairly complex interface controls system (to make it nice for the user) which also "chews" much memory. It does allow me to update things more easily while I'm polling the TCP/IP driver though. I'm up to about 24KB in total usage and I have only a skeleton, most of the interface and the start of some processing functions but not much specific message handling although I can make the connection to the server and do its "handshaking". I will be able to complete the client, I'm certain but I am a bit dismayed. I am concerned about getting in a sound and music driver both for how much memory it needs and for the processing time though. It would be a shame to go without but we'll have to see.

    Since you mentioned it, there is a possibility I should have made it a Contiki based program but I haven't been bothered trying to get it to work with ca65 in the build chain. I really don't like C and C++ and I honestly don't want to be bothered with learning how to get cc65 working with code I want to write in assembly. I guess I could be a little lazy but I did want the entirety of the code to be in assembly. I don't mind effectively writing my own controls library. I have much bigger plans in mind and it needs to be as efficient as possible... This "practice run" has been really insightful.

    If you want to check out the client, I have it uploaded on GitHub at the M3wP Yahtzee! GitHub repository.

    I usually have a server running and can give you the address in private if you would like to try but the game isn't playable on the C64 yet. If some nice person has Delphi 10.1 (or is it 10.2? I forget) they they can compile a Linux version of the client and server for us... I haven't been able to justify the expense of upgrading (I am considering it for the next 6 monthly budget ^^) but I needed to use FMX to make a nice Android compatible client. Still, whats there is there and you can see my source code, too.

    Whew! This post has gotten long. I won't do a TLDR section, I hate them :P


    Yes, this information will be very useful!

    We will need to implement a driver in the ip65 library. Unfortunately, I'm not the greatest network layer programmer so I will have to put the Mega65 compatibility on hold for the moment. This could be something I look at in the near future, after I finish the client but my Nexys4 board is out of action right now. I have to set it all up again with the new software and core. It all takes time and its such a limited resource. I'm assuming that the networking will function on the Nexys4 as well as the actual machines?

    As for the networking in Xemu only working on Linux, perhaps you could look at how VICE does it for Windows and use that? I forget how it works exactly but you get some kind of bridge drivers and then connect to those from the software. I think its a little nasty but it does work.

    Ahh yes after a quick look, Winpcap is what you use but its been superseded by something else now. I forget. It wasn't hard to find when I got it working, though.


    Thanks for the interest!

    I've been poking around in my source archives and I have found the tools but it has been a year and a half since I've looked at them and they have become rather complex...

    I'm just trying to get my head around how they work now and how/what to upload. It may take a few days because I want to include some documentation as well. I have the added problem of not having a working Mega65 at the moment, too. I can't get that up and running for some time because I won't have the time so the stuff may be untested but I will have demos that did work and apparently still do on the machines recently built (they are including some of the demos with them).

    I'll post back when I have more information.



    I'm currently developing a networked (client/server) version of Yahtzee! and a client for the C64. This is just a test for me and I'm hoping to develop other networked games, too.

    Presently, I can only support the RR-Net and ETH64 devices.

    There was some talk once, long ago, about emulating the RR-Net (?) in C64 mode on the Mega65. I'm wondering if this is still the case? I was initially against the idea but I've changed my position and think this would probably be a good idea.

    I'm really hoping that my games can run on the Mega65. For technical details, I'm using the ip65 library with ca65 to build the programs.


    I have some tools I developed for converting images into a format that is usable on the Mega65. I haven't published them as yet since there was a snag in the relocation functionality that I was trying to incorporate. They are otherwise quite usable and I made use of them in a number of demos I did last year.

    I can upload them if you like. The "driver/loader" would provide some insight into how to create large, 256 colour images on the Mega65.

    There is also a demo showing how to use 16 colour sprites... I could provide this as well if required.


    I don't know if this helps but I wrote my own tools to generate source code instead of binaries for GoatTracker tunes to compile with ca65. I could provide them if they would be of interest?

    Having the source code would allow some versatility. More over, the tools use a driver that you provide so you could even potentially optimise it for the 4510.

    I'm not sure that they support dual SIDs as they stand but it would be extremely simple to do this if not the case.