It is currently Thu Dec 14, 2017 8:50 pm

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Mon Jun 12, 2006 8:43 pm 
Offline

Joined: Sat Jan 14, 2006 5:08 pm
Posts: 26
bitbreaker wrote:
I have added network support to 64net/2. 64net/2 was first meant to be a fileserver for c64, serving via multiple solutions, like parallel cable or silversurfer. Now with the rr-net also transfer via network is possible and achieves transfer-rates up to 39kb/s. The protocoll is UDP based, and all the changes necessary fit into a special patched kernal.
Yet the current version is running well with linux, and should as well with BSD, OSX and also Widnows should be no problem (though not tested with recent changes).
Loading and saving is super fast. The new network drive is mapped to @9 and appears like a normal floppy. .d64 images can be mounted easily, as well as dirs can be changed teh same way. Also it supports the usual disk commands, as well as M-W and M-R commands. Just no true 6502 emulation is avaliable, thus M-E won't work, as well as of ocurse fastloaders won't work. But as it is a kind of trend to remove such things again and make things thus more compatible again with recent solutions like ide64 and such, this should not be much of a problem.
Also works fine with nasty things like TAS, Amica Paint, Funpaint, ....
Nitro is adding multiclient support at the moment. That means one 64net/2-Server can then server a whole squadron of c64s, each c64 with his own or a shared home directory.
The recent sourcecode can be obtained from at the sourceforge cvs.
http://sourceforge.net/projects/c64net
A current version of the Kernal patch can be obtained by me (still optimizing even more), so just send a mail to bitbreaker@metalvotze.de.


Sounds very cool ..
Does this mean we would have to somehow replace the c64 kernal ?

will the network commands be built into the kernal ?

Does this mean there will be a 'firmware network API' for the c64 based on your modified UDP protocol ?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Jun 12, 2006 9:00 pm 
Offline

Joined: Mon Jun 12, 2006 7:30 pm
Posts: 10
Yes, the Kernal of the C64 needs to be replaced so far for full functionality. All the patched kernal does is redirecting the serin/seroutcalls if they are directed to device #9.
If ATN is high a sent byte is a command, and thus a command packet is sent via UDP to the PC, else data packets are sent. In addition each package is acknowledged to get a synchronous transfer. That is most of the trick, not much more modifications needed. ARP is handled statically, so all the c64 needs to do is sending a mostly preformated UDP header + data. Same for frame reception, but including a check of the originating MAC and packet type.
Sure, this way there are also routines avaliable like sendheader, recvheader, calcchecksum, ... but i would not consider it an API, as it is optimised for speed and size to fit in the kernal, and work without additional buffer, RAM or zeropage-use, to be as compatible as possible.
Many of the routines (most of all for initialisation) could in fact move into the RR-Rom somewhen (contacted Count0 already for that) the rest are changed serin/serout routines. For more speed i of course also modified the loading and saving routines (bigger data packets). But this stuff could also move into the RR-Rom. It is a proov of concept, and it works, fast and so far realiable (i am using it successfully and did later patches already with the 64net attached, for saving and loading my patches and optimizations)
so what you can do is like:
Code:
@9
00, OK, 00, 00

$:*
1 "FILES           " 64NET
17   ".."               DIR
33   "PATCH"            PRG
689  "TEST.D64"         DIR
65535 BLOCKS FREE.

/PATCH

SEARCHING FOR PATCH
LOADING $4000 $6000
READY


Now you can just load the programm patch for example or do a @cd:.. or @cd:test.d64 to change dir or mount the .d64

If you are interested in the current patch in general, i can put the TAS-sourcecode online.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jun 13, 2006 12:20 am 
Offline

Joined: Thu Jan 12, 2006 9:04 am
Posts: 116
Location: Germany / 88471
yes, please, please, please...! upload it!
that sounds veeeery interesting!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jun 13, 2006 12:58 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 860
Brilliant stuff!! How about subnet addressing? Would it for instance be possible to squeeze in a subnet/gateway checking and forwarding routine? I.e: make it possible to access the internet.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jun 13, 2006 8:09 am 
Offline

Joined: Mon Jun 12, 2006 7:30 pm
Posts: 10
Routing might be possible, but is not implemented so far as it was yet not my focus and also is limited by left space in the Kernal. ARP is doen statically, means, no arp requests are sent or handled by the c64, as i would need to hold an arp cache, where to store it? Sure, there is the RR-RAM. I tried that for buffering my packets, but that is more or less a pain in the ass and all but not fast (regarding expectations, hehe).
I'll upload as well the actual source and a kernal-image (a bit older, but working as perfect, just slightly slower)


Top
 Profile  
Reply with quote  
 Post subject: Re:
PostPosted: Sun Jul 27, 2008 1:00 am 
Offline

Joined: Tue Jul 15, 2008 3:03 am
Posts: 11
RaveGuru wrote:
I've only looked briefly into the Telnet IAC codes, but it should be fairly simple to implement some basic functionality there, so yes I'll add it to my TODO list, although BBS related features will come first.


Ahh is that what it is? Telnet IAC commands (Protocol?) ... I was looking to do this but in reverse. If you use a DOS telnet client to connect to my BBS for example, when I type from the Telnet window, I get double characters echoed back, but if I use the same client and telnet to an Amiga C-Net BBS it seems to compensate for this.

Note, terminal programs work just fine. Its the DOS telnet app that I use and have problems with, even with SecureCRT... I was hoping I could find out how C-Net Amiga compensates and implement it into C-Net 128. It must be a code of some sort? I had no idea about IAC, hopefully this will shed some light on it??

I've tried various switches and stuff when launchnig telnet, but nothing seems to stop the half-duplex type of thing... Any knowledge on this? Thanks!

_________________
Eddie!
Telnet to my C= BBS: bbs.innercirclebbs.com
Port 23 = Centipede, Port 64000 = C-Net 128


Top
 Profile  
Reply with quote  
 Post subject: Re: RR-net projects?
PostPosted: Sun Jul 27, 2008 2:59 am 
Offline

Joined: Tue Jul 15, 2008 3:03 am
Posts: 11
I found the answer! I think.

Quoted text:
Suppress Go Ahead
The original Telnet implementation defaulted to half duplex operation. This means that data traffic could only go in one direction at a time and specific action is required to indicate the end of traffic in one direction and that traffic may now start in the other direction. [This similar to the use of "roger" and "over" by amateur and CB radio operators.] The specific action is the inclusion of a GA character in the data stream.

Modern links normally allow bi-directional operation and the "suppress go ahead" option is enabled.

Echo
The echo option is enabled, usually by the server, to indicate that the server echos every character it receives. A combination of "suppress go ahead" and "echo" is called character-at-a-time mode meaning that each character is separately transmitted and echoed.

There is an understanding known as kludge-line mode, which means that if either "suppress go ahead" or "echo" is enabled but not both, then Telnet operates in line-at-a-time mode meaning that complete lines are assembled at each end and transmitted in one "go".
End quote.

Microsoft had a good article on it:
http://support.microsoft.com/kb/231866

Now Im finding out how to construct an IAC command. I love the internet, but sometimes things (the articles, white papers) get too technical for me.

There's a section in that article that says to construct an IAC command you have to the highest bit to 1 or something, getting too complicated, or too technical. Then, further on down it shows some examples and don't know if I can take the 'pseudo code' (?) literally. Guess I will have to test it out and see. For example, "IAC,SB,1" will supress the 'go ahead' thing and get the Telnet client out of half duplex mode. (I'm ass-u-ming) (me)

UPDATE:
After talking with Brain (he might want to add something here like use CHR$(255)CHR$(250)CHR$(1)CHR$(1) - did I get that right - it doesn't work for me. [ I used CHR$(255)+"SB,1" and it worked!], he pointed out the IAC command is CHR$(255).

So I made:
a$=chr$(13)+chr$(255)+"SB,1" and poked a$ to the RS232 buffer, and badabing!! Local echo disabled. However, this is just a hack. To do this properly, it really should be done in the TCP<>Serial program, Brain points out that his TCPSer takes care of this, which is awesome. Leaving only BBS Server. The complicated part is building the correct conversation between the host and telnet app in BBS Server. Which brings up another problem, I can't just blindly send a CHR$(255)+"SB,1".. can I? Maybe I can...
END UPDATE

This is cool, I did something similar when I looked into auto detecting an ANSI, RIPScript, and SuperRes client... I'll tell you how it works :) I looked at the code in Centipede BBS that had this working, studied it and looked it up: This URL really helped:
http://www.termsys.demon.co.uk/vtansi.htm

You string all the detect codes together in one spurt then look at the RS232 buffer for a response from the client, if any. Petscii Terms do not respond to such things! So, the trick is to find what codes to send. For ANSI you construct a Device Status query string which is simply ESC[5n ... The client responds with ESC[0n ... Meaning OK, meaning ANSI!

CHR$(27) is the ESC character, BTW.

There is a similar code that is sent the RipScrip terms respond to (now obsolete, pretty much, but still good to know), that code is ESC[! If a RipScript client sees this, it responds "RIPScript version x.xx" or something.

For SuperRES, again, obsolete, but good to know... I could not get this working, but Eric did. This is because it involes the \ key which is an MCI trigger in C-Net... He wound up Poking the ASC values to the RS232 port/buffer/whatever. SuperRes detect is untested. And I am unsure if this is correct.

In Centipede, Adam wrote it:
chr$(13){LINEFEED}{RVS}{SHIFT}p{RVSOFF}@\{TAB}

The CHR$(13) and Linefeed just makes a fresh new line to send it on...
{RVS}{SHIFT}p{RVSOFF} is a reversed text mode shifted 'p' for a capital 'P' in reverse text mode. Not sure what CHR$ that is.
@\ is part of the code...
{TAB} is the CTRL-i character.

But in C-Net it is:
uhh, not in there! hehe Crap, it got left out.

Anyway, you string it all together like so:

a$=chr$(13)+"{LINEFEED}{RVS}{SHIFT}p{RVSOFF}@\{TAB}"+chr$(27)+"[!"+chr$(27)+"[5"+chr$(110)
goto simple sub routine to poke a$ one char at a time to the RS232 buffer, ASC(a$)

Next step is to create a loop to read the RS232 buffer and exit in 2 seconds or if the buffer contains the first unique chracter in a result code, read in CHR$() (the ASCII code). When the buffer contains:

48 = ANSI Detected (chr$(48) is 0) This is the '0' (zero) in the response code ( ESC[0n ) the client's terminal sends from the device status query
82 = RIPScript Detected. (chr$(82) is 'R' in the response code ("RIPScript Version...")
9 = SuperRes (chr$(9) is the TAB character, which is what a SuperRes terminal responds with).

That's pretty much it, clear the buffer before and after this routine too. I'd like to finish this off with turning off the "Go Ahead" mode in a standard telnet client and get this out to all the Sysops out there in BBS land.

you can then set a variable that indicates the terminal type, and use it through out the program to display different files.... Like, if ANSI term, variable set to 1. On a menu read command, add a check: if variable=1 then filename$=filename$+"A". Check if file exists, if not, go back to original filename... This way, the filename+A ("sys.menu 1A" for example) would contain an menu built with ANSI codes. And so on... Problem with this is, you need to find a routine that the BBS uses (IF it has one, C-Net does not currently, but it will) to read a file in the RAW, ie no translation from Petscii to ASCII.

Ok, digging deeper, there's also a problem if the BBS has MCI commands that display variables and such, since this is a RAW file read, it wont go through the MCI piece in the ML. Thus, you can not have a Status screen graphic and then fill that in with the User's name, access level or whatever else you may want. I made a simple fix for this but it is SUPER slow, even with a SCPU. :) Simple SEQ reader that GET#2,a$... if a$ = < MCI command code > Which is \ in C-Net and Centipede's case), then add to b$ and GET#2,a$ two more times, appending b$, building the three character MCI command, then send that through the regular BBS ML output routine and continue reading the file. Freaking A if it works!! Proof of concept code is:

61000 close2:open2,8,2,"testfile.ans,s,r"
61005 get#2,a$:if st then close 2: goto 1300:rem exits to main menu.
61010 if a$="\" then b$=a$ :forx=1to2 :get#2,a$: b$ = b$ + a$: next: a$=b$: syso: b$="": goto 61005
61015 poke rs232buffer,asc(a$)
61020 goto 61005

I did a lot of this from memory, so I hope it is correct. I will edit if need be.

Good God, where did all this come from? Sorry to go on, hope it helps things in the world. :)

Anyway, if anyone can help me out with the technical jargan on creating an IAC command, it'd be great. But, it may just be 255,250,1,1 and the 7 bit mumbo jumbo is really the telnet client itself in a lowlevel form.... Now that I typed this up I can get back to testing.

This is good, I been meaning to type all this up. Hope it is ok I did it here.

Thanks,

_________________
Eddie!
Telnet to my C= BBS: bbs.innercirclebbs.com
Port 23 = Centipede, Port 64000 = C-Net 128


Last edited by Eddiie on Thu Jul 31, 2008 8:40 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: RR-net projects?
PostPosted: Mon Jul 28, 2008 10:29 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 860
Wow Eddiie, that's quite a nice bunch of information right there. Almost enough for an article :D Very interesting reading indeed!


Top
 Profile  
Reply with quote  
 Post subject: Re: RR-net projects?
PostPosted: Tue Jul 29, 2008 12:19 am 
Offline

Joined: Tue Jul 15, 2008 3:03 am
Posts: 11
Hey Guru,

That being said, would you please add SuperRes support to the next version of GuruTerm? I have some D64 images of the old term program and docs on how it works. Basically, it sends Doodle pics from the BBS to client. With the speed of telnet I think it would be great. Centipede already supports this (although untested by me), C-Net 128 will too. If there's new development on any other 64 BBS and they read my message, they might add support for it too! I'm going to look into adding some pics to my Centipede BBS.

Here's some files, compliments of Rick Youngman

Attachment:
SuperRes.zip [44.91 KiB]
Downloaded 386 times

_________________
Eddie!
Telnet to my C= BBS: bbs.innercirclebbs.com
Port 23 = Centipede, Port 64000 = C-Net 128


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group