From: groepaz (groepaz_at_gmx.net)
Date: 2001-11-05 20:39:19
Hello MagerValp, M> 8N2 is often overlooked -- sometimes it makes it possible to use a M> higher baudrate. 115200 8N2 might be stable where 115200 8N1 isn't, M> and it's 80% faster than 57600 8N1. oh well.... read uart specs... the second stop-bit is practically nothing more than an additional delay after each sent byte (the reciever doesnt care about the second stopbit) (not starting a religious war here anyway ;=)) also...well... its not like the transfer would be unreliable even at 115k here ;=P atm its the pc that limits the speed, not the c64 *G* (just stupid ppl use crystals on serial ports that result in the divisor beeing 1 at 115k already.... bah) M> Well, that works nicely, we're not multitasking or anything :) well, it works nicely for me even in a turbo-c or djgpp compiled programm running in a dosbox of win9x ;=) (then again, i am not claiming windooze would be multitasking hehehehe) M> I'll release this under the GPL. I'd send it to you straight away, but M> I haven't implemented SAVE yet so I can't transfer the TASS source :) ok, send when it's done then hehe ,=P M> Feel free to use whatever you want. I'm writing the server in Perl, M> but the protocol is simple and could easily be implemented in the M> language of your choice. Right now it's limited to a single command. M> C64 sends <NAME\r\n and the PC answers with ? if it for some reason M> can't send NAME, otherwise it sends a ! followed by the length of the M> file. Then it just sends the raw PRG binary. If the C64 tries to load M> $ the server lists the current dir and makes a basic listing out of M> it, just like a real drive. If NAME is a directory the server CDs M> there and sends a listing (just like $). Saving will be implemented with >>NAME\r\n (duh :) followed by the length, wait for ? or !, then M> raw data. Oh, it supports @0: too. M> This is good enough for load and save, but open and more advanced M> drive emulation needs some sort of packet protocol and a much larger M> driver. I probably won't bother. well.... what i/we (the retroreplay devers) were actually planning is letting the cartridge route all file-accesses done through standard kernal calls (and a certain device adress) to the fileserver, so i guess we would need more advanced handling than just loading/saving like you implemented (actually what you have done is already implemented in a different way, controlled from the remote host that is) however like i said my host program is supposed to support as many possible solutions on the c64 side as possible, so it'll be still very interisting to have a look at what you have done. (btw if you want the true debugging experience, implement 2 simple commands accessable from the host side which are "read block of memory" and "write block of memory" ... and to be truely hooked "set pc" "get pc" "set breakpoint" "clear breakpoint" "get breakpoints" "halt" "go" .... uhmz no well, let me first release the debugger before bugging ppl to support it hehehe ,=P) M> I don't mind testing for you. You'd only have to change a few low M> level routines: hehe although that stuff is interisting, it may be more intelligent if i replace your routines by mine, test it, and then send to you (you change back to your swithlink stuff ofcoz) :o) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:43 CET