geoLink 1.00 (GEOS IRC client) released
Glenn Holmer
redrumloa
> http://lyonlabs.org/commodore/geoLink/geoLink.html
Cool, I was hoping IRC support would be added.Will this run in 128
mode Geos? I assume maybe 40 column 128 mode? 80 column 128 mode would
be sweet, as would Wheels / MP3 support.
Glenn Holmer
It is not supported on a 128, although you are welcome to try. It was
written for the '64.
As for Wheels or MP3, there is a version check that will fail if you
are using a version of GEOS less than 2.0, but if a higher version
number is found, it will proceed with a warning (may or may not work).
Groepaz
> http://lyonlabs.org/commodore/geoLink/geoLink.html
just tried it, congrats on that one.... the first geos app ever that spawned
my interest =)
pro:
- worked just fine with no hazzle whatsoever using dhcp
- no petscii/ascii fuckups like the contiki client had :)
con:
- the screen updates appear to be very slow, on a busy channel it can hardly
keep up even :/ it would be interesting to add a speed optimized "soft 80"
routine to it, how hard (or even possible?) would that be?
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Bad officials are the ones elected by good citizens who do not vote.
<George Jean Nathan>
Glenn Holmer
> just tried it, congrats on that one.... the first geos app ever that spawned
> my interest =)
It's a miracle!
> - the screen updates appear to be very slow, on a busy channel it can hardly
> keep up even :/ it would be interesting to add a speed optimized "soft 80"
> routine to it, how hard (or even possible?) would that be?
The text drawing is being done by GEOS itself (PutString) using an
embedded font, and will sometimes change to boldface (e.g. actions) or
italic (PMs). So the font style is one concern; the other is the
amount of memory it would take to implement a soft 80 (compared to
using the GEOS APIs). Note also that the scrolling is being done by
moving screen memory rather than by reprinting the characters. We've
all seen what 80 columns looks like on a '64... :( My hope was that
the 9 x 5 character cells (when plaintext) would be a happy medium.
Jonno Downes
> http://lyonlabs.org/commodore/geoLink/geoLink.html
Nifty!
I'm well impressed you managed to parse the IRC protocol in 6502 asm -
I couldn't see how to make sense of it all without using regexes.
BTW can you give Per a credit for ip65? - it's his code more than
mine.
Cheers
Jonno
Glenn Holmer
> BTW can you give Per a credit for ip65? - it's his code more than
> mine.
I'll add him to the info box in the next release.
Dmackey828
<glenn....@gmail.com> wrote:
>http://lyonlabs.org/commodore/geoLink/geoLink.html
Thats Sweet, Works great, Nice Job Glenn.
Really do appreciate your work on this project. Well done.
mrtin...@gmail.com
> http://lyonlabs.org/commodore/geoLink/geoLink.html
I like this very much. A TCP/IP stack in GEOS - WOW!
Currently the TCP/IP stack and the applications are in the same VLIR
application file.
If I want to use the TCP/IP stack in my software, I imagine this
solution:
- TCP/IP is configured buy running geoLink application.
- My application loads VLIR records from geoLink application that
implements TCP/IP.
- My application calls public rutines in TCP/IP stack.
Is this the correct approach?
/mrtinb
Glenn Holmer
wrote:
geoLink depends on a slightly modified version of ip65 built to load
from $2e00-$5fff. A separate program ("geoLinkEmbed" on the source
code disk) then writes that binary to VLIR record 9 of geoLink so it
can use its own overlay code to load it (the same technique is used
for the monospace font). Actually calling into ip65 is non-trivial,
since a) you have to be careful to bank in I/O space when talking to
the network card and b) callbacks are registered against ip65. Also,
you need to poll the card regularly (geoLink does it every 250ms using
a GEOS process). There's more information in the slides from the World
of Commodore presentation (available on my site).
Having said all that, I can provide a copy of the binary if there's
interest (or you can extract it from VLIR record 9 of geoLink), but
your best bet is to print out the source code and study it. I can help
with questions, and try to stay present in #geos on NewNet.
Groepaz
> The text drawing is being done by GEOS itself (PutString)
i figured that much :)
> using an
> embedded font, and will sometimes change to boldface (e.g. actions) or
> italic (PMs). So the font style is one concern;
that could be solved by using inverse and colors easily though (which is
also more readable than eg italic characters, imho)
> the other is the
> amount of memory it would take to implement a soft 80 (compared to
> using the GEOS APIs).
it would take a fair bit of memory obviously... well, depending on how fast
you want it to be :)
that said, arent there 4x8 fixed size charsets for geos? that might already
speed up the rendering a fair bit.
> Note also that the scrolling is being done by
> moving screen memory rather than by reprinting the characters.
really? then the copy routine must be exceptionally crap =P atleast that one
should be replaced by a somewhat more unrolled one then :)
> We've
> all seen what 80 columns looks like on a '64... :( My hope was that
> the 9 x 5 character cells (when plaintext) would be a happy medium.
personally i find proportional fonts for terminals very irritating,
especially on irc it just doesnt "look right". and i dont think soft80 looks
all that terrible either (that said, alternativly even simple 40 columns
textmode would be an improvement for me, its even easier to read, and a LOT
faster).
anyway, nice work :) if i didnt have 100 other things on my list already,
i'd be very tempted to take the source and make a standalone app out of it
:)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
My aim is to produce games that have graphics and audio that will rape your
eyeballs and take your ears from behind with a strap-on
<Jeff Minter>
Glenn Holmer
> > Note also that the scrolling is being done by
> > moving screen memory rather than by reprinting the characters.
>
> really? then the copy routine must be exceptionally crap =P atleast that one
> should be replaced by a somewhat more unrolled one then :)
How nice of you to say so! Actually, now that I look at it, I see that
at some point I changed it to scroll both the foreground and
background screens so that pulling down a menu wouldn't foul the
screen (GEOS calls RecoverRectangle to roll up a menu). So if I could
find a way to call ImprintRectangle before a menu is called (with just
the size that a menu might cover), I could make the scroll twice as
fast. In fact, if I could hook DoDlgBox, I could turn off double-
buffering for the printing as well (dialog boxes also recover from the
background screen).
If you're interested, the scroll routine is on page 3 of the
geoLinkText source file. I suppose the call to GetScanLine could be
optimized out as well.
> anyway, nice work :) if i didnt have 100 other things on my list already,
> i'd be very tempted to take the source and make a standalone app out of it
> :)
Have a lot of fun :)
Jonno Downes
I was inspired to hack a geoWrite filter into peekbot so now I can
browse your source code at
http://peekbot.jamtronix.com/dispatch.fcgi/catalog_image/http%3A%2F%2Flyonlabs.org%2Fcommodore%2FgeoLink%2FgeoLink-20100414.d64
cheers
Jonno
Maciej Witkowiak
> screen (GEOS calls RecoverRectangle to roll up a menu). So if I could
> find a way to call ImprintRectangle before a menu is called (with just
> the size that a menu might cover), I could make the scroll twice as
Just an idea. You could hook into mouseVector, check mouseData if button
was pressed, if mouse is in top level menu area and if menuNumber is 0
(only top level menu is active). If so - imprint the screen.
In any case continue through original vector.
ytm
--
Najlepsza sygnatura to brak sygnatury.
http://bossstation.dnsalias.org/
Maciej Witkowiak
>> screen (GEOS calls RecoverRectangle to roll up a menu). So if I could
>> find a way to call ImprintRectangle before a menu is called (with just
>> the size that a menu might cover), I could make the scroll twice as
>
> Just an idea. You could hook into mouseVector, check mouseData if button
> was pressed, if mouse is in top level menu area and if menuNumber is 0
> (only top level menu is active). If so - imprint the screen.
> In any case continue through original vector.
It can be done even easier. You just need to change type of your top level
submenus to dynamic. The handling routine would just call imprint and set
in r0 the address of proper submenu.
Glenn Holmer
wrote:
> It can be done even easier. You just need to change type of your top level
> submenus to dynamic. The handling routine would just call imprint and set
> in r0 the address of proper submenu.
Yes, already testing that when you posted :)
Glenn Holmer
> On Apr 15, 5:34 am, Glenn Holmer <glenn.hol...@gmail.com> wrote:
>
> I was inspired to hack a geoWrite filter into peekbot so now I can
Thanks, that's very cool. I've added a link on the web page.
Jonno Downes
available" - from looking through the hex dump of 'IP65-GEOS', I can
see the http & gopher client code has been included but I assume is
not being used. - it should be possible to reclaim a fair bit of both
code and variable space by removing that code, which (from the
browsing through geoLink.inc) would be a matter of deleting the
implemention of function $31 (K_DLOAD) from geos_dispatcher.s
Regards
Jonno