@olsen

Frist point, fair enough, you know far more about this than I do.

On the second:

Quote:

First thing, IPv6 is still not ready for prime time, unless you are deploying it in the intranet of a large corporation, a university campus, or, say revamping the entire network infrastructure of a chinese province. There are interoperability issues which are still hard to resolve, and only a lot of work and time spent on the effort will make them go away. In other words, don't hold your breath. IPv6 will come around one day, but it won't be tomorrow. And when it comes around, it will not instantly displace devices which are restricted to IPv4, since there are so many of them around, which will take another couple of years to be replaced. Don't jump to the conclusion that because the public IPv4 address space has run out, the sky will fall in what must be minutes, if not seconds. We already have a workaround for scarce IPv4 address spaces: it's called "network address translation", which has been around for decades. And there will be IPv6 to IPv4 NAT mechanisms in place when the time comes.

I agree that for internal networks IPv6 isn't needed. Definitely not for home users, and not even for large corporations. My main concern is when websites are forced to only have IPv6 addresses because there aren't any IPv4 available (and this is likely to start happening by the end of next year). To cope with this, we need to be able to lookup and resolve IPv6 addresses and connect to them. No amount of NATing will resolve this as you can't tell the computer to connect to an IPv6 address if it can't look it up, and you can't fake an IPv4 address and let the router handle it because, well, how does it know what to connect to? Maybe with some crazy magic DNS server in the router which hands out random private IPv4 addresses when a host returns only an IPv6, and translates them itself, it could work, but I've not seen that proposed anywhere.

Besides which, we really ought to have this stuff before it becomes necessary, rather than waiting until users start complaining that blahblahblah isn't working, and then start on the several years' worth of work to add IPv6 support. We've already seen this in a minor way with not having CSS support in web browsers - now multiply that by "this isn't working at all". It'll be a slower change, sure, but it does need to be looked at before it becomes a problem.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@wawa

Short answer we need a common api whit Windows/Linux/MacOS, so that programs can easily be ported over and because we need to be able to do the same things on AmigaOS as Internet changes.

We do not need to base the work on a existing TCP/IP stacks or just grab some code somewhere that does not fit in to the Amiga design, but writing one can take time, I have started on something but its extremely hard to debug and come up whit model that fits whit the OSI model.

http://www.kaixintea.net/osi-7-layer/

There are also numbers of protocols that need to work in harmony that sometimes interact.

UDP/IPv4, UDP/IPv6, TCP/IPv4, TCP/IPv6, SPX/IPX, Bootp/dhcp, arp, ndp, vpn, npnp and many more that’s not so common.

The roadshow has number of problems:

1. it has be active before applications runs.
2. there is no easy way activate and deactivate network devices.
3. Network protocols can’t be added easily
4. It’s hard to monitor traffic and hock in to it, it used to be easy but it’s not anymore.
5. It’s not easy to bebug or monitor, and there to resource tracking of bandwidth that I know of.
6. its outdated, you can’t do simple things as look up the nx record.

Last edited by NutsAboutAmiga on 15-Feb-2012 at 02:09 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 12:40 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 12:40 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 12:38 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

i dont know how important spotify on os4 is. personally i was not even aware about it before. when i think on aros or 68k, im mostly interested in, its priority is moderate. which means, the application, if ported, should be rather, where it is possible, adopted to the os than the other way around. generally the thinking behind should be what is easier and demands less ressources.
please treat it just like an outsider remark.

Last edited by wawa on 15-Feb-2012 at 12:45 PM.

@Chris_Y

Quote:

Chris_Y wrote: @olsen Frist point, fair enough, you know far more about this than I do. On the second: Quote: First thing, IPv6 is still not ready for prime time, unless you are deploying it in the intranet of a large corporation, a university campus, or, say revamping the entire network infrastructure of a chinese province. There are interoperability issues which are still hard to resolve, and only a lot of work and time spent on the effort will make them go away. In other words, don't hold your breath. IPv6 will come around one day, but it won't be tomorrow. And when it comes around, it will not instantly displace devices which are restricted to IPv4, since there are so many of them around, which will take another couple of years to be replaced. Don't jump to the conclusion that because the public IPv4 address space has run out, the sky will fall in what must be minutes, if not seconds. We already have a workaround for scarce IPv4 address spaces: it's called "network address translation", which has been around for decades. And there will be IPv6 to IPv4 NAT mechanisms in place when the time comes. I agree that for internal networks IPv6 isn't needed. Definitely not for home users, and not even for large corporations. My main concern is when websites are forced to only have IPv6 addresses because there aren't any IPv4 available (and this is likely to start happening by the end of next year). To cope with this, we need to be able to lookup and resolve IPv6 addresses and connect to them.

Technically, this is how it ought to be. Practically, it won't be necessary for a long, long time. See below...

Quote:

No amount of NATing will resolve this as you can't tell the computer to connect to an IPv6 address if it can't look it up, and you can't fake an IPv4 address and let the router handle it because, well, how does it know what to connect to?

This is not an unsolved issue. Consider this: how many smart phones which support or require IPv4 are currenly in use in any telephony network? Now do the math: how many IPv4 addresses would be required to assign each device a unique IPv4 address, issues such as dynamic IP address allocation through sort of a DHCP solution notwithstanding?

The practical solution is to assign each smart phone a private IPv4 address from, say, the 10.* prefix net. Whenever the phone accesses an internet resource, it goes through a router, which ultimatively allows the access to be performed by tunneling it through the company's publicly-visible IPv4 network, using a combination of proxies and NAT. And all of this scales well, it even works if the number of phones currently active should exceed the number of IPv4 addresses which the company owns.

The same principle works for IPv6 to IPv4 connectivity, too. We'll have proxies and NAT between our devices, the ISP and the greater internet. This has its upsides, but it has its downsides, too, of course. Do you really want your ISP to be able to look at your traffic, maybe even manipulate your DNS lookups (oops, they already do the latter)?

In any case, this approach will obviate the need to forcibly render IPv4-only devices obsolete. It will also ease the transition to "native" IPv6, in case interoperability issues prevent your gear from correctly talking the IPv6 your ISP expects: you "downgrade" to IPv4 and use the proxy/NAT.

Quote:

Maybe with some crazy magic DNS server in the router which hands out random private IPv4 addresses when a host returns only an IPv6, and translates them itself, it could work, but I've not seen that proposed anywhere.

See above: this stuff is straightforward, and it has been used successfully for more than a decade.

Quote:

Besides which, we really ought to have this stuff before it becomes necessary, rather than waiting until users start complaining that blahblahblah isn't working, and then start on the several years' worth of work to add IPv6 support. We've already seen this in a minor way with not having CSS support in web browsers - now multiply that by "this isn't working at all". It'll be a slower change, sure, but it does need to be looked at before it becomes a problem.

Software is comparatively easy to migrate, unless your computing platform itself puts up greater obstacles. You can replace that web browser with a more standards compliant version. Well, usually you can.

It's a different matter for the network backbone infrastructure and the IP layer that sits somewhere on top of it. As I mentioned before, IPv6 support is still not quite as interoperable as it ought to be. The good thing about this is that the migration from IPv4 will have to be gradual, and maybe, just maybe, a baseline IPv4 support layer will never go away.

On the other hand, pulling a fully functional, robust IPv6 TCP/IP stack for the Amiga out of your or my hat is the kind of magic trick that takes practice and preferably a paying audience. For now I can't quite see how any of these two should come together.

@olsen

Ok, everything sounds impossible and negative, so how will you solve it?

_________________
AmigaOS on Google+
AmigaOS on Facebook

@NutsAboutAmiga

Quote:

Short answer we need a common api whit Windows/Linux/MacOS, so that programs can easily be ported over

Er.. we have that already. We use the standard BSD Sockets API, same as Linux, BSD and Windows (winsocks are based on the same API AFAIK). We just don't have some of the newer bits. As olsen says, that doesn't mean you can't do things, it just makes it more difficult.

Anyone who has tried to use the BSD Sockets API knows that it is far harder work than it needs to be.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@olsen

I'm still not convinced about the v4-v6 interoperability, but I will bow to your superior knowledge

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @wawa Short answer we need a common api whit Windows/Linux/MacOS, so that programs can easily be ported over and because we need to be able to do the same things on AmigaOS as Internet changes. We do not need to base the work on a existing TCP/IP stacks or just grab some code somewhere that does not fit in to the Amiga design, but writing one can take time, I have started on something but its extremely hard to debug and come up whit model that fits whit the OSI model. http://www.kaixintea.net/osi-7-layer/ There are also numbers of protocols that need to work in harmony that sometimes interact.

Sorry, guv, this isn't how things are done.

For starters, the ISO/OSI layer hierarchy is, sadly, more of theoretical relevance than it is of practical importance. The reason is that the TCP/IP stack managed to eat the ISO network standards for lunch, and then some. What so far mostly escaped from the ever hungry TCP/IP technology was the telephony domain, whose protocols are highly domain-specific and generally have little functional overlap with how the TCP/IP stack goes about its business. The TCP/IP stack does not have seven distinct layers. While its makeup is similar to the ISO/OSI layer hierarchy, its architecture lumps the responsibilities of certain layers together. For some protocols that are part of the TCP/IP stack it's also hard to say clearly which ISO/OSI layer they would belong into.

Also, there's a reason why practically nobody starts from scratch, implementing network protocol stacks, these days. These things are complex beasts. You don't go about knocking one off unless you have solid specifications, a test plan and the resources to follow it through. If you really think us motley collection of Amiga software developers could play in that league, then I'd have to say it's flattering view of the situation.

Quote:

UDP/IPv4, UDP/IPv6, TCP/IPv4, TCP/IPv6, SPX/IPX, Bootp/dhcp, arp, ndp, vpn, npnp and many more that’s not so common.

Um, I think you might want to look at that list again. Not all of these belong into the same category, for a start.

Quote:

The roadshow has number of problems: 1. it has be active before applications runs. 2. there is no easy way activate and deactivate network devices. 3. Network protocols can’t be added easily 4. It’s hard to monitor traffic and hock in to it, it used to be easy but it’s not anymore. 5. It’s not easy to bebug or monitor, and there to resource tracking of bandwidth that I know of. 6. its outdated, you can’t do simple things as look up the nx record.

I can state with great confidence that out of these six items you quoted, none of them actually is in fact an issue. I also suspect that your first-hand knowledge of the matter at hand might need a bit of bolstering.

@wawa

Spotify might not be of importance to many Amigans, however what it represents should.

Mainstream software that is available on many other platforms is being ported to Amiga (shows Amiga is worthy hardware).

Other companies could follow suit trying to expand their user base by developing for Amiga.

I know it doesn't mean that Adobe will pick up their Creative Suite and port to Amiga however some of the smaller companies could see it as viable option.

_________________
1 AmigaOne G4XE (OS4 Pre-Release Update4)
Minimig
Sam440ep + OS4.1FE
Sam460cr + OS4.1FE

@joeled

Quote:

joeled wrote: @olsen Ok, everything sounds impossible and negative, so how will you solve it?

I didn't say it was impossible. It's just difficult, in the absence of important resources, like money or software developers.

The Amiga "market" is a niche market at best, supported by enthusiasts. Funding is hard to come by.

Constraints such as these imply that we need to pick our battles and not get overly enthusiastic.

Trying to knock out another TCP/IP stack is hard these days. Porting software from other platforms is not getting easier. If the goal is to make Spotify work on the Amiga, the underlying constraints will shape how, if at all, the goal could be reached. But it starts with looking at the goal, and not by looking at the stars. We should not overreach ourselves.

Sorry to overgeneralize here, but to solve the problem at hand requires a little more information than I have access to. All I can say is that to crack this problem is to look at what we can do, which is actually quite a lot, technologically, and not so much at what our fondest wishes would make come true if unlimited time and resources were available.

Last edited by olsen on 15-Feb-2012 at 04:53 PM.

@1Mouse

definitely it is an interesting experiment. i wonder what comes out of that.

@wawa

Quote:

wawa wrote: i dont know how important spotify on os4 is.

It is important because it represents a realistic goal that could be reached using the means available to us, and beyond. By beyond I mean that we stand to learn from making it happen what exactly it is our existing platform technology cannot yet handle well.

As such, a project like this can help to guide the development of the platform, maybe even allowing us to identify aspects which need specific improvements in order to become attractive to other developers. Developers who are now at best still on the fence whether or not the Amiga is a serious target platform.

@Kicko

Quote:

Kicko wrote: @Mikey_C You forgot mic support for tunenet

The chances of BEAN returning to the Amiga scene and adding mic support in tunenet is about as likely as I am dating Jessica Alba whilst having 100 Million in the bank and inventing a time machine.

_________________
No cause is lost if there is but one fool left to fight for it.

@Mikey_C

Oi, keep away from my girl friend, she is already going through my millions like nobodies business.

_________________
Amiga 1000, 3000D Toaster, Checkmate A1500 Plus
http://www.checkmate1500plus.com/

@olsen

The comment you committed was intended to wawa not you take it whit grand of salt.

Quote:

For starters, the ISO/OSI layer hierarchy is, sadly, more of theoretical relevance than it is of practical importance. The reason is that the TCP/IP stack managed to eat the ISO network standards for lunch, and then some. What so far mostly escaped from the ever hungry TCP/IP technology was the telephony domain, whose protocols are highly domain-specific and generally have little functional overlap with how the TCP/IP stack goes about its business. The TCP/IP stack does not have seven distinct layers

I have noticed thats its difficult to keep things apart, TCP for example links in to transport (handshaking) and session layer (connections).

The presentation layer is the BSDSocket API, at lest that’s how I define it, thins might look different in roadshow.

Link layer can only do simple things as Multicasts, Mac broadcasts, or forward packages based on there destination Mac address.

Quote:

Um, I think you might want to look at that list again. Not all of these belong into the same category, for a start.

I was not trying to list things by category or where belongs in the osi model, just pointing out there are many protocols and every thing has implemented correctly and browsing RFC pages whit 1000's of lines takes time.

and every page takes about specifications and how to correctly implement something.

Quote:

I can state with great confidence that out of these six items you quoted, none of them actually is in fact an issue. I also suspect that your first-hand knowledge of the matter at hand might need a bit of bolstering.

First-hand knowledge whit out NDA? The problem is the SDK has little or no information on inner workings of roadshow. Asking for NDA does not help when no one care to write NDA, Ben is just keeping me waiting on some thing is not going to happen thanks.

1. It's horrible annoying that “RUN” is not in front of AddInterface in startup-sequence way can't it be by default.

3. as you pointed out your self quote “For starters, the ISO/OSI layer hierarchy is, sadly, more of theoretical relevance than it is of practical importance. The reason is that the TCP/IP stack managed to eat the ISO network standards for lunch“

4. and 5. things that worked before on sanaii does not anymore so its true from where I stand, we don't have tools like wireshark for AmigaOS, we can't see a packages goes trow or what is returned, sanautils does not work anymore, can't get basilisk network work whit Roadshow sanaii.

6. is also true, DNS lookup stuff is dated.

Last edited by NutsAboutAmiga on 15-Feb-2012 at 08:03 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 07:49 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 07:42 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 07:40 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 07:31 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 07:25 PM.
Last edited by NutsAboutAmiga on 15-Feb-2012 at 07:23 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Mikey_C

Quote:

The chances of BEAN returning to the Amiga scene and adding mic support in tunenet is about as likely as I am dating Jessica Alba whilst having 100 Million in the bank and inventing a time machine.

Let me see...


...yeah, building time machine may be little bit tricky

_________________
Sam440ep-flex 800MHz 1GB RAM R9250 128MB SB Live!

@clusteruk

Bah! - GIT!

Oh well, that makes it even less likely!!!

_________________
No cause is lost if there is but one fool left to fight for it.

@Skuggan



Excellent initiative! Thanks for taking this on. Here's hoping this project is a catalyst for others like it. I'll donate to this bounty.

:edit: Ah.. I see now that I'm too late to donate. Next time then.


@Skuggan,

Whatever blueprint you come up with for the OS and tools install should be noted so that more dev boxes can be shipped out in that image. I mean hopefully, we'll all get more opportunities like this to donate to a Sam460 bounty and send out a few more boxes to important projects like spotify.

The djnick, and spotify bounty's illustrate that the community is ready to fund important projects like this. And a big project like Spotify (were it to bear fruit) might encourage other important players in the industry to follow suit.

Last edited by jingof on 16-Feb-2012 at 07:53 AM.

_________________
Vic-20, C-64, C-128
Amiga 1000, 3000
AmigaOne X1000

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @olsen The comment you committed was intended to wawa not you take it whit grand of salt.

Quote:

Quote: For starters, the ISO/OSI layer hierarchy is, sadly, more of theoretical relevance than it is of practical importance. The reason is that the TCP/IP stack managed to eat the ISO network standards for lunch, and then some. What so far mostly escaped from the ever hungry TCP/IP technology was the telephony domain, whose protocols are highly domain-specific and generally have little functional overlap with how the TCP/IP stack goes about its business. The TCP/IP stack does not have seven distinct layers I have noticed thats its difficult to keep things apart, TCP for example links in to transport (handshaking) and session layer (connections). The presentation layer is the BSDSocket API, at lest that’s how I define it, thins might look different in roadshow.

It does not exactly match. If I remember correctly, the presentation layer is, in ISO/OSI terms, more concerned with how the data transported is transformed into something useful for the application layer. For example, the e-mail message format described in rfc822 would be just what the presentation layer is about : structured data.

In the socket API, the I/O operations are all about unstructured data. The TCP and UDP transports make no assumptions about the structure of the data transported (except for length, as far as UDP is concerned).

And so the lines between layers 5-7 become even more blurred in TCP/IP...

Quote:

Link layer can only do simple things as Multicasts, Mac broadcasts, or forward packages based on there destination Mac address. Quote: Um, I think you might want to look at that list again. Not all of these belong into the same category, for a start. I was not trying to list things by category or where belongs in the osi model, just pointing out there are many protocols and every thing has implemented correctly and browsing RFC pages whit 1000's of lines takes time. and every page takes about specifications and how to correctly implement something.

ACK

Quote:

Quote: I can state with great confidence that out of these six items you quoted, none of them actually is in fact an issue. I also suspect that your first-hand knowledge of the matter at hand might need a bit of bolstering. First-hand knowledge whit out NDA? The problem is the SDK has little or no information on inner workings of roadshow.

Well, documentation could always be better, and there could be more sample code, etc.

I'm afraid that the Roadshow SDK, which by the way is free, and you don't have to sign an NDA with anybody to get more information on how Roadshow works (I'm the go-to guy here), got short shrift in the early OS4 SDKs. The whole package should have included header files, autodocs, sample code and full source code for all shell commands which ship with Roadshow.

Quote:

Asking for NDA does not help when no one care to write NDA, Ben is just keeping me waiting on some thing is not going to happen thanks.

I repeat, Roadshow is my responsibility, and mine alone. You do not need to sign an NDA with Hyperion to learn more about Roadshow and how it works. It's sufficient to ask me.

Quote:

1. It's horrible annoying that “RUN” is not in front of AddInterface in startup-sequence way can't it be by default.

That was a design decision on my part when I came up with the shell commands which replace the ifconfig, route (and the dhcp client daemon) normally required to bring up the network.

The idea was to have the network operational by the time the Workbench opens. This is something that never worked quite right with "Miami", which is why I designed the AddNetInterface command and the APIs in Roadshow's bsdsocket.library to work like they do.

In the end, the plan didn't work that well after all. I had overlooked latency issues (some dhcp servers take several seconds to come around), and if something went wrong during Startup-Sequence execution, you would not see the AddNetInterface error message, etc. This would make diagnostics very difficult.

Adding "Run" in front of the AddNetInterface command does not resolve these issues. It just makes your system boot faster.

I still haven't found the right approach to starting the network that would satisfy most of the requirements I since learned were important, though

Source code for AddNetInterface is available, by the way, as is documentation for the Roadshow bsdsocket.library API which AddNetInterface uses

Quote:

3. as you pointed out your self quote “For starters, the ISO/OSI layer hierarchy is, sadly, more of theoretical relevance than it is of practical importance. The reason is that the TCP/IP stack managed to eat the ISO network standards for lunch“

Which protocols, specifically, do you believe need to be attached to a TCP/IP stack?

The 4.4BSD-Lite2 kernel code which Roadshow is built upon still contains the ISO networking hooks, as do all BSDs that stem from it (NetBSD, OpenBSD, FreeBSD, PC-BSD, DragonFly BSD). To the best of my knowledge, the code is there, it just has practically no application.

The fact is, TCP/IP stacks, such as the BSD-derived ones, today at best sit on top of exotic transport layers, but everything on top of that is based upon IP, and no other networking protocol families.

Quote:

4. and 5. things that worked before on sanaii does not anymore so its true from where I stand, we don't have tools like wireshark for AmigaOS, we can't see a packages goes trow or what is returned, sanautils does not work anymore, can't get basilisk network work whit Roadshow sanaii.

That's where the Roadshow documentation would have helped. I specifically added hooks for traffic monitoring and control to the library API. Beyond that, there's full bpf read/write support, and Roadshow ships with a tcpdump port. Hence, Wireshark (if you can get the UI toolkit ported, etc.) is possible. Raw network write access through the bpf API is possible, too.

As for SANA-II, shared network access is possible. Roadshow does not monopolize the network device drivers it uses unless you specifically tell it to. Since there is no distinct higher level protocol for sharing SANA-II network drivers, you can expect that some applications will not play nice, though. "Envoy" is one of these, which is liable to stealing ARP packets, even if these packets were not intended for it.

Quote:

6. is also true, DNS lookup stuff is dated.

But that's not the point you were making. In order to pull information such as MX records or specific TXT records out of DNS query responses, you need API functionality which was never even part of the bsdsocket.library API as defined by AmiTCP of old. Yes, that specific API is dated (but not obsolete), but it never covered the entire DNS stub resolver library functionality in the first place.

I don't see this as a problem, because if you really need such API functionality, it is possible to adapt the DNS stub resolver library and link your code against it. It's not as if the DNS API in bsdsocket.library would use private APIs or suchlike. It all boils down to the use of public BSD socket API functions.

@olsen

Quote:

Quote: What exactly does spotify need from the TCP/IP stack that the AmiTCP API cannot provide, and cannot be worked around as far as it sounds? I haven't got the foggiest right now. So far it appears that the Spotify code feels comfortable to perform DNS lookups through an API which does not exist within the AmiTCP domain. AmiTCP contains the bare necessities to perform DNS lookups through an early version of the libresolv code, which is baked into it. It's a much older DNS lookup API than Spotify apparently expects. Problem here is that you cannot retrofit this API. You might be able to emulate it. You might be able to use conditional compilation to have the client code call the old clunky API instead of the shinier version we don't have. You might be able to simply drop in a more recent version of the libresolv code than what exists as part of the AmiTCP API. There are a lot of options, some nicer, some not so nice.

Two important points in this post:

Quote:

1. I haven't got the foggiest right now.

Fair enough. But until we have a clear answer on #1, I think discussion about the large effort necessary to update to a modern TCP/IP stack could be premature. If duck tape and gum can be made to work for now, then lets boot strap toward the ideal solution later.

Quote:

2. You might be able to emulate it.

Speaking of duck tape and gum, as a work around, it would seem the missing or out of date DNS lookup APIs could be stubbed and proxied to known remote hosts within the Spotify P2P network having the expected versions of those APIs. I.e. if the nodes in the P2P network are exchanging media stream fragments, why couldn't selected, known nodes in that same P2P exchange DNS lookup details as well? (Of course, all this assumes course granularity in how the calls are sequenced by the calling code.) Yes, it could be far less efficient and potentially incur more round trips, but it may be good enough to make a start.

:edit - darn typos! If not for backspace, I'd be writing gibberish they'd commit me for.

Last edited by jingof on 16-Feb-2012 at 08:54 AM.
Last edited by jingof on 16-Feb-2012 at 08:40 AM.
Last edited by jingof on 16-Feb-2012 at 08:36 AM.
Last edited by jingof on 16-Feb-2012 at 08:35 AM.
Last edited by jingof on 16-Feb-2012 at 08:33 AM.

_________________
Vic-20, C-64, C-128
Amiga 1000, 3000
AmigaOne X1000