On Tue, 26 Sep 2000, Adriano Camargo Rodrigues da Cunha wrote:
UZIX processes have priority. You can use a daemon process as a
JUMP driver (as TCP/IP do). The only problem that can arise is that it
will slow down the link (assuming JUMP is a sincronous protocol - an
asincronous
In linux, interrupt handlers and their children are not processes and thus
don't have a priority. If they claim the processor, they'll get it. So
just ajusting the polling frequency should do. I don't know how uzix does
this.
UZIX processes have priority. You can use a daemon
I don't know much about IP either, but Adriano Camargo Rodrigues da Cunha
knows (and implemented it in UZIX) and Laurens Holst is now learning (and
implementing) it. Guys, please enlighten us.
Pfff... It's really very simple. An IP packet consists of a header
IP packets are a
UZIX is multi-threaded. JoyNet send could be a thread and JoyNet receive
another thread.
It's not a good way to do it, Maarten.
On "heavy systems", like a PC, it's a good solution.
But on MSX, that has limited memory and clockspeed, it's not.
You're wasting twice the
On Fri, 8 Sep 2000, Laurens Holst wrote:
Yes, a timeout is needed for such situations. But as long as the other
side is connected (and running an os with JUMP drivers), everything should
be ok and no locks are possible.
You should _never_ assume that... One flawd bit on the ack line
On Tue, 5 Sep 2000, Maarten ter Huurne wrote:
Small numbers of cycles are not possible. But usually, the number of
cycles needed is about 50 or 100.
JoyNet singal propagation doesn't need waits that long. On 3.5MHz I got
speeds of about 3.5 kilobyte per second, that is 3500*8=28000 bits
I only replied to what I didn't agree with or what I had something to say
about. Other things I cut out.
On Wed, 6 Sep 2000, Maarten ter Huurne wrote:
The protocol can be fixed: adding CRC and a timeout is sufficient. But I
think a more elegant solution is possible, where you wouldn't need a
On Fri, 08 Sep 2000, you wrote:
The protocol can be fixed: adding CRC and a timeout is sufficient. But I
think a more elegant solution is possible, where you wouldn't need a CRC.
What do you mean with that? Some error-correction algoritm in the protocol
(equivalent to a CRC)? Or UDP-like
On Fri, 08 Sep 2000, you wrote:
JoyNet singal propagation doesn't need waits that long. On 3.5MHz I got
speeds of about 3.5 kilobyte per second, that is 3500*8=28000 bits per
second, which is 125 clocks for a total 1-bit cycle (data + ack). Given
the fact that there are quite a few
On Fri, 8 Sep 2000, Maarten ter Huurne wrote:
Error detection other than CRC. Under the assumption that there are only
1-bit errors, the protocol itself can detect errors. I'm not sure this
assumption is correct, but gathering statistical evidence (hours of testing)
should tell us more
On Fri, 8 Sep 2000, Maarten ter Huurne wrote:
For Linux, the best solution would be to write a serial driver for
JoyNet. Then pppd can be used to connect to UZIX and you can use the
existing PPP network device.
Not at all. Linux knows the `network driver' as a special object. I
Not at all. Linux knows the `network driver' as a special object. I
should
just write a network driver, so the parallel port is treated as a
network
device. Then you can just use the connection as if it is an ethernet
card
, which means there is no need for a point to point link. It also
Yes, a timeout is needed for such situations. But as long as the other
side is connected (and running an os with JUMP drivers), everything should
be ok and no locks are possible.
You should _never_ assume that... One flawd bit on the ack line and... The
receiver thinks he sent an ack and
And if the 2-computer case is very important, you can always make a single
cable connecting 2 nodes. But it won't work for larger networks and it
isn't
really JoyNet, just partly compatible. I think Laurens even has the
schematic
for the 2-computer cable on his JoyNet page.
Yes, it's there.
I do have ideas on how to implement a bidirectional
peer-to-peer link using JoyNet (=2 computers only).
Let's hear it! Supporting more than 2 nodes is a matter of routing, and it
can be solved in a higher layer.
Not with JoyNet. With more than 2 computers, the databits arrive at a
On Tue, 05 Sep 2000, you wrote:
Small numbers of cycles are not possible. But usually, the number of
cycles needed is about 50 or 100.
JoyNet singal propagation doesn't need waits that long. On 3.5MHz I got
speeds of about 3.5 kilobyte per second, that is 3500*8=28000 bits per
second, which
For Linux, the best solution would be to write a serial driver for JoyNet.
Then pppd can be used to connect to UZIX and you can use the existing PPP
network device.
You can also make a user-mode solution, that sends stdin over JoyNet and
sends JoyNet input to stdout. That program can then
On Tue, 05 Sep 2000, you wrote:
I hope you realize that implementing JoyNet in any system which also
executes other tasks is a highly delicate matter??? It requires a lot of
fine-tuning, and within a single application that's easy, but with multiple
apps running...
It's not hard at all if
On Sat, 2 Sep 2000, Maarten ter Huurne wrote:
How can a node (single computer in the network) determine whether its
neighbours use JUMP or not? Especially, how can it do so without causing
problems with other protocols?
It can't. It is impossible to determine.
I don't think it's
There is another problem in the time before a transfer is started. The
sender
must wait for the receiver to be ready. If it waits while interrupts are
disabled, interrupts can be disabled for quite a while (maximum: timeout
value). If it waits while interrupts are enabled, the waiting can
On Mon, 04 Sep 2000, you wrote:
That's true. But does it really matter? A unidirectional network seems a
lot simpler to me.
It is simpler to code, but slower and harder to get (you really NEED 2
cables for two computers).
A ring scales just as well as a line:
#nodes#cables:ring
On Mon, 04 Sep 2000, you wrote:
Interrupts must be disabled during waiting and the timeout value must be
smaller than 1/60th of a second.
Music (games/apps) and Modem (apps) won't be happy with that.
The good news is, that using a non-timed protocol interrupts can be allowed.
It must be
UZIX can be useful to test JUMP, because it has every layer of the network
already implemented. JoyNet + JUMP can replace RS232 and we'll have a running
system.
Maarten is right. Implementing JUMP so it's able to send and
receive a byte through the network is enough for UZIX.
On Fri, 18 Aug 2000, Maarten ter Huurne wrote:
On Fri, 18 Aug 2000, you wrote:
3. When JUMP should be used
The term "JUMP" is not introduced...
JUMP = Joynet Univeral Message Protocol?
Hmm did I forget that? sorry. It should be Joynet Unified Machine
Protocol. I used this term to
On Fri, 01 Sep 2000, you wrote:
If a coder wants to make a program (probably a game) that should run on
multiple computers, she may use any protocol she desires. If she has a
way of knowing what the other side of the connection does, for example
because it also runs her software, she
Timing has some serious disadvantages:
- it depends on how strong the joystick port drives the signals
(probably not equal for all MSX types)
- it depends on cable length
(actually capacity, but length is probably the most important factor)
- it means the interrupt must be disabled when
On Fri, 18 Aug 2000, you wrote:
3. When JUMP should be used
The term "JUMP" is not introduced...
JUMP = Joynet Univeral Message Protocol?
If a coder wants to make a program (probably a game) that should run on
multiple computers, she may use any protocol she desires. If she has a way
of
I think we had this discussion before, but 32 bit CRC is overkill for small
chunks of data. For example, MSX floppy uses 16 bit CRC for sectors (512
bytes long).
A quick and interesting checksum algorithm is the one used for
TCP/IP (one's complement of the sum of the one's
28 matches
Mail list logo
