I assume Glenn's finished his ECCC talk now, so...

Kipper BASIC is a BASIC extender that adds some keywords for writing simple TCP apps
There are also keywords for TFTP upload and download, PING and NETCAT (both ASCII and PETSCII).

BASIC ON BAILS is a BASIC extender for writing web apps
You configure the IP stack (either hardcoded values or via DHCP) and then listen on a port. You then specify what line number should be executed when different URLs are requested.

This stuff is still evolving, so please don't use it in any life support systems!

Glenn's ECCC presentation is at http://lyonlabs.org/commodore/kb-bob/index.html

enjoy!

I was at Glenn's presentation and it was fantastic. Well done! I've got so many ideas on things I could do with this I don't even know where to start.

I'm pleased to report it works very well on my IDE64 with RR-Net. You lose access to the IDEDOS commands, of course, but you can still access the IDE64 drives with the normal BASIC routines (LOAD, etc.). Interestingly, the F-keys still work, would be amusing to remap them to KipperBASIC commands...

Some silly suggestions for future improvement:

-Can setting the second argument to PING to 0 cause it to ping forever (until RUN/STOP pressed)

-Can PING be a function? i.e. it would be awesome to do A=PING"BLAH",10 and have A set to the number of echoes received.

Cheers, this is a cool toy for sure.

Too much fun:



i.e. http://192.168.7.113/POKE?A=53281&V=2

I think I can do that



Not really. Partly because I haven't worked out how to implement functions that return values (although I know it's all in the reference material I am using, namely Trans BASIC and "What's Inside the C64"), mostly though because a single keyword can't be both a command and a function. I.e. if I made it return a value, you would always have to call it in a context that required a value (e..g A=PING.. or ?PING, but never just PING)

What I could do though is create another magic variable, say PC% which does what you suggest

I will consider both of these for the next release (whenever that may be)



Glad you're having fun

This is AWESOME... thank you!

Not only is this a BASIC extender, it adds several network commands to the Commodore 64 operating system (which is BASIC 2.0). It's almost like having a suite of network command line tools that we usually take for granted in DOS, linux, etc.

I **love** Kipper Basic. I've already started tooling around with it and wanted to give some feedback.

1) There doesn't appear to be a command to terminate connection from the server side. This makes it kinda hard to write a real application.

2) NETCAT needs to show the cursor.

3) Running DHCP a second time should not cause a new lease to be obtained. There should be a RENEWLEASE command, or at least require an optional parameter on the DHCP to force a renewal on the lease. This is a pretty big deal because if you want your autoexec.bas program to be responsible for calling DHCP then every time you run it subsequently you get a new IP address. This is a royal pain when you are testing applications.

4) Please create a C128 version. You're going to find that the C128 is a far better platform for programming a large net application than the C64.

Glad you're having fun with this!

1) the command you want is TCPCLOSE which was (unintentionally) undocumented
2) good feedback - will consider this for next release (can't promise when)
3) I'll have to review the RFCs again - I think all I need to do to get what you want is include the current IP address in every DHCP request - on the initial request this will be the hardwired default of 19.168.1.64 but I will have to check what happens when a DHCP server gets a request for a 'renewal' of an IP address in a range it doesn't service (best case - it will respond with an IP address from a range it does service; worst case - it doesn't respond at all)
4) and I think you would find that a Linux or Win32 machine is an even better platform for large net programming than a C128 The interest for me is working within the constraints. Having said that, the idea of adding TCP extensions to CP/M does have appeal (but doubt I'll get time to implement until I retire in about 2032). In any case, the source is available at http://netboot65.svn.sourceforge.net/vi ... ent/basic/ for anyone who wants to attempt a port

I haven't tried this, but can you fix this with a POKE204,0 before running the command?

I've figured out a way I could do this: Clear the screen so that the result is always in the same place, then do a PING, and PEEK screen memory to see if the result was a '.' or '!'. It's wonderfully hacky, but hey it's BASIC...!

It works... with side effects. The cursor leaves remnants on the screen if the cursor was in the "on" state when there is fast movement of the cursor to another location on the screen. It makes the screen very messy.

It would be good of there was a timeout for TCPLISTEN. This would allow a program to execute code periodically during periods of inactivity. For example, I want to program a game that performs some maintenance once per minute while nobody is playing. If TCPLISTEN had a timeout argument, that would give my game an opportunity to perform that work once per minute. As it is now, I'd have to hook into the IRQ with ML and perform my maintenance on BASIC variables using ML, which honestly I don't have the skill, nor desire, to do.

It would also be good if there was simply an asynchronous listener instead of a blocking listener. Whenever a connection attempt was made it would call back to the specified line number, such as how Basic on Bails works. This would allow a program to intelligently handle multiple requests and present a message such as "Busy, call back later". Maybe something like this:

TCPASYNCLISTEN 6400, 1000, 2000

This would listen on port 6400. If a connection is made, and there are no other connections, it would call the routine at line 1000. If a connection is made, and there is already an active connection, then it would call the routine at line 2000.

I hope this makes sense and I really hope it gets implemented. It would make programming a BBS or game much simpler.

Maybe the whole model should move to event driven with callbacks, as per BoB. Rather than a timeout for TCPLISTEN, would you rather instead have something like :

10 ONTIMER 60,1000 : REM call line 1000 every 60 seconds
20 BINDTCP 6464,2000,3000,4000: REM listen on tcp port 6464 - this call would never return, rather 2000 is called after a connection is made, 3000 is called whenever new data arrives, 4000 is called when a session is dropped.

There would also be a BINDUDP option, which (since UDP is sessionless) would only take a port number and a line to call whenever a packet arrives.

Some questions:
1) If I did this, should I retain the procedural model (TCPLISTEN/POLL) or replace it ?
2) Would this be better done as an extension of BoB rather than Kipper BASIC?
3) Should I add an "ONKEY" event as well (when a key is pressed on the local machine)?
4) Any other significant events?

Unfortunately, I don't see being able to add the ability to specify a line number to call for a 2nd (or subsequent) simultaneous connection in the near future - I took a bunch of shortcuts when I added TCP to ip65 (which BoB & KB are built on) that mean adding support for multiple sessions (even if they are only help open long enough to say "CALL BACK LATER") will be hard work.

I like your asynchronous model you've expressed here. Maybe the current version of KB is an evolutionary dead-end from a programming perspective and a new version that's asynchronous in nature could take over. I don't need the weight of BoB. As a matter of fact, I was shocked to do a fre(0) and discover only 14k available to me. I need a runtime that doesn't have the TFTP stuff, just asynchronous TCP networking.

PS. We may be shooting a shotgun at a gnat here. What would have some HUGE value would be to write a wrapper around ip65 for usage with C programs written for cc65. We could then write some truly awesome software in that environment. Right now the learning curve for getting into ip65 is so steep that it scared me off. Having someone already familiar with it do the wrapper would make it accessible to us "application programmers" who aren't as worried about the nuts and bolts.

I actually started playing with ip65 precisly because it *wasnt* C, which made it more interesting for me. If you want to write some "real" apps, then you might be better off with contiki and/or uIP, which have cc65 / c64 ports (in fact I believe the c64 was the original platform for them). http://www.sics.se/contiki

In terms of memory usage - I didn't really imagine that either KB or BoB would be used for more than dabbling by people enjoying the novelty of doing network coding in CBM BASIC, but there's 2 things that I could do to reduce that (but can't make any guesses as to when).

1) I've been experimenting (as part of a ip65 port of V-1541) with using the RAM under BASIC, which would let me reclaim 8KB.
2) A card with an inbuilt TCP/IP stack (e.g. the wiznet board per six's recent "3000 words" thread) would free up a heap of memory, since it would need both less code and less buffers.

Putting those 2 together, I reckon it would be possible to have a fairly complete event driven BASIC (combining the asynch tcp/udp described above plus httpd from BoB) that still had the usual 38911 bytes free for a BASIC program (although it would use the 4KB at $C000.$CFFF which is not used by BASIC but sometimes used by M/L stubs)