[MSX] MAP Update - JoyNet
Hi all, I did a MAP update today; I moved the JoyNet documentation from the old archived http://datax.grauw.nl/ location to the MAP, at http://map.tni.nl/resources/joynet/ . In the process I also cleaned up and merged documents, and fixed stuff that was broken, and even attempted to add some formal language :). A lot of stuff with regard to JoyNet disappeared. Oh, the transience of the web. Fortunately I was able to retrieve some stuff from the Web Archive and my local files. There’s still some things missing though: - Maarten ter Huurne’s JoyNet test program (I do have the source), http://map.tni.nl/resources/joynet/#tester - Maarten ter Huurne’s Tetris clone beta http://map.tni.nl/resources/joynet/#tetrisclone - Ricardo Bittencourt’s JoyWave WAV play thing, http://map.tni.nl/resources/joynet/#joywave - A bunch of missing F-16 Fighting Falcon (1984) scans from the MSX Core Club site (originally), http://map.tni.nl/resources/joynet/#f16 - Connect disk 2 archive (I do have disk 1), http://map.tni.nl/resources/joynet/#connect - Snafu, the final version (the one from Jaù ’99). I only had the first version, http://map.tni.nl/resources/joynet/#snafu If anyone could help me retrieve those, that would be nice. So anyway, if you have links to JoyNet, please update them. I believe I saw one on the Ultimate FAQ :). Also I made a few updates to my own website at http://www.grauw.nl/, mainly regarding moving stuff from my old archived website to my current one. ~Grauw -- Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~ Laurens Holst, student, university of Utrecht, the Netherlands. Website: www.grauw.nl. Backbase employee; www.backbase.com. ___ MSX mailing list (msx@stack.nl) Info page: http://lists.stack.nl/mailman/listinfo/msx
[MSX] reviving JoyNet
Hi Folks, Not long ago I got some new MSX stuff and while sorting things from one of my cable-bags, I found my old JoyNet cable again. Realising that there were hardly any games/apps made, I thought it was probably due to the fact there was never really written a good protocol for it. So last night I started figuring things out again and came up with a pretty decent _theoretical_ protocol. Since I'm not really an MSX programmer, this is where you guys come in :) First of all I still have a couple of questions. I remember that the joystick ports status gets 'changed' when interrupts are enabled. Is this 1 status the ports change to, or does it change randomly/continuously? If it's a stable status, which bits get set and which bits unset? Finally, is there interest in opening a discussion on this mailinglist, or should I find someone to help me implement this in private? Greets, Patsie ___ MSX mailing list (msx@stack.nl) Info page: http://lists.stack.nl/mailman/listinfo/msx
RE: [MSX] reviving JoyNet
Hey Pats :) Couldn't you just write this in MSX-C? Should be right up there with ANSI-C, right? Just some other ports stuff, by the way when are we gonna sort the MSX's ? Cheers mate! RE -Original Message- RE From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] RE On Behalf Of [EMAIL PROTECTED] RE Sent: Friday, May 20, 2005 9:43 AM RE To: msx@stack.nl RE Subject: [MSX] reviving JoyNet RE RE RE Hi Folks, RE RE Not long ago I got some new MSX stuff and while sorting RE things from one of my cable-bags, I found my old JoyNet RE cable again. Realising that there were hardly any RE games/apps made, I thought it was probably due to the fact RE there was never really written a good protocol for it. So RE last night I started figuring things out again and came up RE with a pretty decent _theoretical_ protocol. Since I'm not RE really an MSX programmer, this is where you guys come in :) RE RE First of all I still have a couple of questions. RE I remember that the joystick ports status gets 'changed' RE when interrupts are enabled. Is this 1 status the ports RE change to, or does it change randomly/continuously? If RE it's a stable status, which bits get set and which bits unset? RE RE Finally, is there interest in opening a discussion on this RE mailinglist, or should I find someone to help me implement RE this in private? RE RE Greets, RE RE Patsie RE RE ___ RE MSX mailing list (msx@stack.nl) RE Info page: http://lists.stack.nl/mailman/listinfo/msx RE This message is confidential and is intended solely for the named addressee. It may contain information that is privileged and exempt from disclosure under applicable law. If you are not the intended recipient, please notify us immediately, and destroy any copies and delete it from your computer system. Any unauthorised dissemination, distribution or copying thereof is prohibited and may be unlawful. We cannot guarantee the genuineness or completeness of the information sent by or through email, nor for any timely receipt thereof. Furthermore, GlobalCollect does not give any guarantee in relation to the accuracy of any information sent by or through this email message. GlobalCollect is in any event under no circumstances liable for any damages of whatever nature, which are the direct or indirect result of any actions and/or decisions which are or may be based on the information sent by or through this email message. ___ MSX mailing list (msx@stack.nl) Info page: http://lists.stack.nl/mailman/listinfo/msx
Re: [MSX] reviving JoyNet
FYI, the JoyNet documentation is still online at: http://datax.grauw.nl/joynet/joynet.html At some point Ill move the information to the MSX Assembly Page - I just havent gotten around to it yet. ~Grauw -- Ushiko-san! Kimi wa doushite, Ushiko-san!! ___ MSX mailing list (msx@stack.nl) Info page: http://lists.stack.nl/mailman/listinfo/msx
Re: (Joynet protocol)
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 protocol will not work, because UZIX JUMP driver will lose
bits).
I understand. It is actually a good thing to give the driver a priority,
because then the user can decide if she wants to slow down the network to
get better performance or not.
So Grauw (you were writing a paper on an asynchronous protocol, right?),
please hurry up and post it, so we can soon realise it.
The best thing (even for TCP/IP) would be putting the driver
inside the kernel (but it can't be done now, due to low memory).
It is good to be compatible with e.g. 64kB, but you could use the system
as in linux, where the user can compile her own kernel with or without
support for all kind of things, so she can choose to have a powerfull
kernel or a small one.
I personally like the idea of a microkernel very much though, because it
can be bugfree eventually. The idea is to have the kernel doing the
resource managing (memory, cpu time) and leave the device managing (vdp,
psg, etc) to the drivers. The drivers should then not have all
permissions, as they do in the linux kernel, but also be limited, so the
kernel doesn't hang if a driver does.
Drivers should be run-time includable and removable (like insmod and
rmmod, but in a more transparent way). I don't know if you feel like
including those ideas into UZIX. I just think it is a good idea, because
it gives the possibility to put drivers like tcp/ip in the kernel, without
wasting the space/opening possible security holes for the users that don't
use them.
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44 x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 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 protocol will not work, because UZIX JUMP driver will lose bits). The best thing (even for TCP/IP) would be putting the driver inside the kernel (but it can't be done now, due to low memory). Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * Te ky o my kybord ha litl dfect. * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 header plus data. Header is, at least, 20 bytes. Data is 0 or more bytes. TCP packets are a header plus data. TCP header is, at least, 20 bytes. Data is 0 or more bytes. So, a TCP/IP packet is, at least, 40 bytes (no data, only the IP and TCP headers). UZIX TCP/IP Stack doesn't use any TCP/IP options, because they are quite useless for TCP/IP clients (except the Maximum Transmission Unit option, that is 4 bytes). A datalink protocol should be able to handle packets with a minimum of 40 bytes for TCP/IP. The maximum size is important too (since sending packets of 50 bytes, for example, just allow transmission of, in the best case, 10 bytes of data). 256 bytes is a good choice, and is not a so big value. Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * The faith remove montains, substituting them by abisms. - CDA * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 memory and charging twice the CPU. Use the same process (I wouldn't call it a 'thread', since the concept is different) to send and receive data. That's how the TCP/IP is implemented. Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * -8- Don't cut here or you'll destroy your monitor! -8- * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 and... The
receiver thinks he sent an ack and waits for the next data, the sender
didn't receive an ack so he doesn't send the next packet... wham. Lock.
If I set the joystick port to 1, it cannot go to 0 and stay there, or can
it? even if it can, you should just refresh the signal every now and then
and you can still design a protocol with no dead-lock posibility.
bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44 x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 per
second, which is 125 clocks for a total 1-bit cycle (data + ack). Given the
fact that there are quite a few instructions executed for every bit, there is
hardly any waiting at all.
In that case I am truely convinced that the unidirectional solution is
also the quickest (given the joynet hardware).
Adriano wrote that he would like someone to write some code to use joynet
in uzix. I would like to do it, when the protocol is finished. If anyone
else wants to do it (or doesn't want me to do it :P ), let me know, since
I could use my time on other things as well.
I could do it, but I have too many projects already, so if you are willing
to, I prefer that you do it.
It looks like I am the best person to do it anyway. I have experience in
writing drivers for linux and designing operating systems and computers.
It should be pretty easy (with my knowledge, that is).
I would also like to write a network driver for linux, so you can connect
it to a router as well and connect the internet and all that.
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 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 means
that UZIX will need to use 4 byte host addresses (actually interface
addresses), at least in the JUMP driver.
You can also make a user-mode solution, that sends stdin over JoyNet and
sends JoyNet input to stdout. That program can then be connected to pppd
using pipes. It's less flexible than a kernel driver, but it's also easier to
write
Not at all. Just hacking the plip driver is done in a few minutes.
and won't crash your system if it's buggy.
That is true. Well, let's just hope I'm a good programmer :P
It can be a good intermediate step towards a kernel driver.
It can be, but I prefer to write a kernel driver directly.
Hmm, ok. So the parent must be named in every document. By the way I
don't keep my old versions of it and I don't expect others to. There is
no archive of them, which makes it a bit useless, since you cannot see
the tree anyway.
There is the mailinglist archive on msxnet.org...
But I don't post the document to the mailinglist every time I change it.
It's doesn't matter what kind of version system you use personally. The
proposed versioning system is only intended for published documents. So it
should refer to the last *published* parent document.
All documents I make are directly published on my homepage
(www.cpedu.rug.nl/shevek/JUMP.txt). I do not keep an archive of that. But
the evolution tree doesn't really matter anyway, IMO. The reason to give
version numbers to the documents is to make them distinguishable, so you
know you are talking about the same thing.
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44 x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 CRC.
What do you mean with that? Some error-correction algoritm in the protocol
(equivalent to a CRC)? Or UDP-like transfer, which leaves the
error-checking to the receiving party?
A timeout is always needed, because when the cable is disconnected the
protocol should be able to handle that.
True, but the protocol should not be able to enter a dead lock, as long as
both computers system memory is not corrupt.
Anyway, it could be a gradual system: if you haven't had a transfer in
a long time, lower the poll frequency.
That is a very good idea, but care must be taken not to make the
calculating of the time before the next poll is done make the system too
inefficient. Also, a minimum frequency should of course be kept, so you
don't have to wait an hour for a reaction after a week not using the
network.
and your system is completely 'locked' while receiving...
If you use a non-timed protocol, you can leave interrupts enabled. To improve
performance of the JoyNet transfer, you can lift the thread priority a bit
above average.
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.
Do you mean a scheduler? UZIX has one, PC operating systems have one.
Not all PC operating systems do. *-DOS doesn't.
Note that a running thread is not necessarily active, because there can be
many running threads and CPU time will be shared between them. However, if
the user is waiting for a JoyNet transfer, there will probably be no
foreground process (the user is waiting) and background processes should be
set at a lower priority than the JoyNet transfer, so in result the JoyNet
transfer will get the majority of the CPU time.
No, they should not. If one process wants the joynet data, and another
wants data from memory, there is no reason to priviledge the networking
process. On normal linux systems, most of the processes (all except the
ones that don't require any input for a while, like compilers) sleep most
of the time waiting for data to be ready (from disk, from network, from
the user via a keyboard, etc.). I think it will be a little different in
uzix, because most hardware needs to be polled, but I think that still it
is good to give joynet normal priority. If the system is slow, the network
is slow...
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44 x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 transfer, which leaves the error-checking to the receiving party? 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 about that. A timeout is always needed, because when the cable is disconnected the protocol should be able to handle that. True, but the protocol should not be able to enter a dead lock, as long as both computers system memory is not corrupt. The protocol will deadlock if the cable is disconnected. There is no way to avoid that. But a timeout will handle those situations and abort the hanging transfer. A timeout must be viewed as a kind of exception (in Java/C++ terminology), it is not part of the regular protocol. and your system is completely 'locked' while receiving... If you use a non-timed protocol, you can leave interrupts enabled. To improve performance of the JoyNet transfer, you can lift the thread priority a bit above average. 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. Hmmm... Maybe JUMP in Linux should be implemented in user mode after all? Claiming the processor for what could be a long time is not a good idea. Or maybe Linux is fast enough to use one interrupt for every single bit transfer? Anyway, I still want to be able to play MP3s while a JoyNet transfer is in progress. Do you mean a scheduler? UZIX has one, PC operating systems have one. Not all PC operating systems do. *-DOS doesn't. OK; all multitasking OSes have one. Note that a running thread is not necessarily active, because there can be many running threads and CPU time will be shared between them. However, if the user is waiting for a JoyNet transfer, there will probably be no foreground process (the user is waiting) and background processes should be set at a lower priority than the JoyNet transfer, so in result the JoyNet transfer will get the majority of the CPU time. No, they should not. If one process wants the joynet data, and another wants data from memory, there is no reason to priviledge the networking process. On normal linux systems, most of the processes (all except the ones that don't require any input for a while, like compilers) sleep most of the time waiting for data to be ready (from disk, from network, from the user via a keyboard, etc.). I think it will be a little different in uzix, because most hardware needs to be polled, but I think that still it is good to give joynet normal priority. If the system is slow, the network is slow... JUMP also acts as a router, forwarding packets that are intended for another node. Should other computers in the network suffer if one of them is under heavy load? Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 instructions executed for every bit, there is hardly any waiting at all. In that case I am truely convinced that the unidirectional solution is also the quickest (given the joynet hardware). There is one thing that takes a lot of time in the non-timed protocol: because the ack should be read for every bit written (reverse read and write if you're receiving instead of sending), you constantly have to switch between PSG register 14 and 15. In a timed protocol you only have to read ack once in a while. I think a timed protocol can be quicker, but it's just too complex to get it working correctly on all possible configurations. 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 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 means that UZIX will need to use 4 byte host addresses (actually interface addresses), at least in the JUMP driver. One advantage of PPP is that there are very little modifications necessary in UZIX. Another advantage is that host configuration can be done using PAP. If JUMP is treated as ethernet, UZIX has to be configured manually or we would have to write a DHCP client for it. You can also make a user-mode solution, that sends stdin over JoyNet and sends JoyNet input to stdout. That program can then be connected to pppd using pipes. It's less flexible than a kernel driver, but it's also easier to write Not at all. Just hacking the plip driver is done in a few minutes. Are you experienced or optimistic? ;) Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 about that.
That is a good idea. Anyway, I don't think the error detection mechanism
is really important for the protocol. It can, e.g. be implemented at a
high level like TCP/IP. Then fast and unreliable packets can also be sent
(some people seem to want that... maybe they don't want it over joynet,
because `fast' is slow anyway?)
A timeout is always needed, because when the cable is disconnected the
protocol should be able to handle that.
True, but the protocol should not be able to enter a dead lock, as long as
both computers system memory is not corrupt.
The protocol will deadlock if the cable is disconnected. There is no way to
avoid that. But a timeout will handle those situations and abort the hanging
transfer. A timeout must be viewed as a kind of exception (in Java/C++
terminology), it is not part of the regular protocol.
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.
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.
Hmmm...
Maybe JUMP in Linux should be implemented in user mode after all? Claiming
the processor for what could be a long time is not a good idea. Or maybe
Linux is fast enough to use one interrupt for every single bit transfer?
Anyway, I still want to be able to play MP3s while a JoyNet transfer is in
progress.
No problem. The implementation should consist of polling every once in a
while and flipping bits if the receiver says it's ready. It doesn't keep
the processor occupied very much.
JUMP also acts as a router, forwarding packets that are intended for another
node. Should other computers in the network suffer if one of them is under
heavy load?
I think this is up to the owner of the computer. This means it should be
ajustable in the driver. This shouldn't be a problem to implement.
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44 x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 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 means
that UZIX will need to use 4 byte host addresses (actually interface
addresses), at least in the JUMP driver.
One advantage of PPP is that there are very little modifications necessary in
UZIX. Another advantage is that host configuration can be done using PAP. If
JUMP is treated as ethernet, UZIX has to be configured manually or we would
have to write a DHCP client for it.
I do not have experience with that. But I don't think doing it manually is
much work. On my linux box it is just one ifconfig statement. Do you think
it would be more difficult on a MSX?
You can also make a user-mode solution, that sends stdin over JoyNet and
sends JoyNet input to stdout. That program can then be connected to pppd
using pipes. It's less flexible than a kernel driver, but it's also
easier to write
Not at all. Just hacking the plip driver is done in a few minutes.
Are you experienced or optimistic? ;)
Both :P
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44 x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 means that UZIX will need to use 4 byte host addresses (actually interface addresses), at least in the JUMP driver. One advantage of PPP is that there are very little modifications necessary in UZIX. Another advantage is that host configuration can be done using PAP. If JUMP is treated as ethernet, UZIX has to be configured manually or we would have to write a DHCP client for it. PAP does not configure anything. It handles the login procedure. I think you mean PPP's LCP and IPCP. Not at all. Just hacking the plip driver is done in a few minutes. Are you experienced or optimistic? ;) :) ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 waits for the next data, the sender didn't receive an ack so he doesn't send the next packet... wham. Lock. ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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. Another problem is the granularity of the waiting loops. If you want to avoid self-modifying code, the fastest waiting loop is DJNZ, which takes 9 cycles for the last loop and 14 cycles for the other loops. So if you want to wait 10 cycles, you'll have to round to 23. Timing must indeed be thought of. There is no need to round. Loops that are the same every time can easily be coded. Using JP instead of DJNZ, the number of cycles per loop can be made constant. But it's not possible to get every number of cycles (try 6). Nor is it possible to have any fine-grained control without using self-modifying code. And apart from being complex, self-modifying code doesn't work in read-only memory. I made a SiMPL sample-player once, which (before playing the sample) 'calibrated' itself (see how many samples can be played within an interrupt). If it was too fast, a unit-long wait was inserted. Repeat until too slow. Then lower unit by, say, a factor ten, and start decreasing the wait until it's too fast again, and so on until unit has reached the minimal quantity. I used NOPs to wait, since it's the most precise unit. They were inserted into the code (so the part after the NOP waits was relocatable). It's a bit complex, but accurate. You wouldn't have to design the IP layer, because it already exists. We only have to find out what the minimum packet size is and whether using IP in a JoyNet network will work in practice. 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 (with a good and fast-calculated checksum) and some data. However I suggest to use a simpler protocol. The IP-address for example is 32-bits. You only need 8 bits in this case. And it contains some other parameters which are absolutely not nessecary, and if they are they can be passed as options, not as a part of the default header. Look at ftp://ftp.funet.fi/rfc/rfc791.txt That's the IP documentation. ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 different computer than Ack does. But it's not very difficult to come up with something for a ring... About my protocol: I'll work out an example on my MSX. The basic idea is like this (I have no implementation experience yet though, so it can still be changed): The joystickports are checked regularly. A transfer request is indicated to the peer by flipping ack and setting dat1 and dat2 to 01 or 10, also flipping each time. Why those values? Well, by default the datapins are set to 11, and if the peer MSX is disconnected or off, the datapins are 00. The other then responds, initiating the transfer. The data is transmitted in 4 transmissions on both sides, so 8 in total. If the transfer is bidirectional, the data of the peer is sent together with the ACKs. The first two bytes indicate the packet length (excluding the lenght bytes and the checksum), then the packet is sent, and after the packet a 16-bit TCP-like checksum (excluding the lenght and checksum bytes) is sent: "The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros." Mind you: one's complement. Not two's complement, neither no complement. Check your docs on that (Rodnay Zaks' book on the Z80 features a short description). Short description: when adding data in one's complement, also add the carry. (so ADD A,r:ADC A,0 is a one's complement addition). In one's complement, a negative value is indicated by complementing the value. So -1 is FFFE. And -0 is . But at the same time FFFE is also FFFE (one's complement doesn't limit to -32768 and +32767 if I'm correct... that's a tiny bit confusing)... Then complement the final checksum result. When you receive the data, one's complement add all received words, including the checksum, and if the result is # then all's well. Why a one's complement checksum? Check out rfc1071 (ftp://ftp.funet.fi/rfc1071.txt) and be amazed how cool this checksum is!!! Well that's about it. Simple, eh? However if you have every host connected to two others using a peer-to-peer link (2 computers, so not really a 'network') in both joystickports (which make it a network again), then bidirectional transfer is indeed be possible. The idea of JoyNet was to keep one joystick port free. For example, to play a game using a joystick or game pad. Yes. ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 is 125 clocks for a total 1-bit cycle (data + ack). Given the fact that there are quite a few instructions executed for every bit, there is hardly any waiting at all. Around those numbers any number of cycles is possible. Fine grained control would be large, but not impossible (without self-modifying code). OK, it would be possible. But not elegant. Adriano wrote that he would like someone to write some code to use joynet in uzix. I would like to do it, when the protocol is finished. If anyone else wants to do it (or doesn't want me to do it :P ), let me know, since I could use my time on other things as well. I could do it, but I have too many projects already, so if you are willing to, I prefer that you do it. I would also like to write a network driver for linux, so you can connect it to a router as well and connect the internet and all that. 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 be connected to pppd using pipes. It's less flexible than a kernel driver, but it's also easier to write and won't crash your system if it's buggy. It can be a good intermediate step towards a kernel driver. Hmm, ok. So the parent must be named in every document. By the way I don't keep my old versions of it and I don't expect others to. There is no archive of them, which makes it a bit useless, since you cannot see the tree anyway. There is the mailinglist archive on msxnet.org... But I don't post the document to the mailinglist every time I change it. It's doesn't matter what kind of version system you use personally. The proposed versioning system is only intended for published documents. So it should refer to the last *published* parent document. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 be connected to pppd using pipes. It's less flexible than a kernel driver, but it's also easier to write and won't crash your system if it's buggy. It can be a good intermediate step towards a kernel driver. 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... You see, JoyNet doesn't generate an interrupt to indicate the peer is sending/listening, so you'll need to poll continuously, and your system is completely 'locked' while receiving... And the sender can't execute other tasks until the receiver has acknowledged the send_request and has received all data... It can be done, I think (execute all other processes every int, the transmission will hold then but the rest will at least work). However, execute-on-int (to give it a name) is quite hard to program I think. And you must also watch out that the sender doesn't call the other processes while the receiver just finished calling the other processes (that would result in no bytes being received). That can be solved by letting the sender determine when the int starts and transmit some kind of "Execute Other Processes wait" escape-code when the event occurs, so the receiver can then also execute the processes at the same time. In that case, an (partly optional, implementation-dependant) escape-code-mechanism has to be constructed. However, I don't know how that fits into the architecture of Uzix (I think badly). ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 you use a non-timed protocol. I have had this running for over a year now, except for the fact that it hangs on transmission errors. Transmission errors are rare in a non-timed protocol, but they can occur (I got one after sending about 50MB). 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. A timeout is always needed, because when the cable is disconnected the protocol should be able to handle that. You see, JoyNet doesn't generate an interrupt to indicate the peer is sending/listening, so you'll need to poll continuously, You have to poll once in a while. For systems like PCs polling 100 times per second is no problem. And much higher frequencies are possible as well, although they will start influencing system performance. Anyway, it could be a gradual system: if you haven't had a transfer in a long time, lower the poll frequency. and your system is completely 'locked' while receiving... If you use a non-timed protocol, you can leave interrupts enabled. To improve performance of the JoyNet transfer, you can lift the thread priority a bit above average. And the sender can't execute other tasks until the receiver has acknowledged the send_request and has received all data... That depends on the protocol. It can be done, I think (execute all other processes every int, the transmission will hold then but the rest will at least work). However, execute-on-int (to give it a name) is quite hard to program I think. Do you mean a scheduler? UZIX has one, PC operating systems have one. However, I don't know how that fits into the architecture of Uzix (I think badly). UZIX is multi-threaded. JoyNet send could be a thread and JoyNet receive another thread. When there is no transfer, these threads sleep for a while. When they wake up, they check if a transfer should be started, this is how you get the polling behaviour. If a transfer was started, the thread will remain running until the transfer stops. Note that a running thread is not necessarily active, because there can be many running threads and CPU time will be shared between them. However, if the user is waiting for a JoyNet transfer, there will probably be no foreground process (the user is waiting) and background processes should be set at a lower priority than the JoyNet transfer, so in result the JoyNet transfer will get the majority of the CPU time. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 possible to use JUMP and an incompatible protocol on the same network. So why not demand that every node in the network uses JUMP? I put a note about it in the file. Because JUMP does not need a closed ring, all that is needed to demand the whole network to be JUMP. But the endpoints must be recognisable as non-JUMP. Of course if too many bogus packets are received, the driver may conclude that the connection is not JUMP. A special header could be designed for non-JUMP protocols for when they receive a JUMP packet, but they may choose not to use it. Even that is impossible. If the other protocol uses a different algorithm for sending packets, a node using JUMP wouldn't even be able to receive it's packets. In which case the JUMP side will reject that side of the connection. The other side will probably need a ring network, in which case it will hang, or something. Also, it should be made explicit whether the link with the previous or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs, next.dat0, next.dat1 and prev.ack are outputs. True, this should be explicit. But not next and prev, because the network is bidirectional. sender.A, sender.B and receiver.C should do, I think. The prefixes "prev" and "next" can be used on a bidirectional network. If the nodes are numbered, node N knows neighbour N-1 as "prev" and neighbour N+1 as "next". Especially when using a bidirectional network, "sender" and "receiver" is less clear, because either neighbour can fulfill both roles. True. I shall soon change it. With packets I mean packets that are sent in one go, without executing other code while waiting for acknowledge signals or something. If you do that, you can make use of a timed protocol. So you mean that sending or receiving a packet is an atomic action? Yes. Actually it is the being timed that makes it possible to be bidirectional. A non-timed protocol must have at least two lines (data and acknowledge) on the sender side. For joynet, that means it must be one-directional. 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). The being timed also means you have to wait for the receiver to be ready. Synchronous transfer. Indeed. In modem terminology, isn't SR called RTS (Request To Send)? Yes, I think so. I'm not really familiar with those things. If they are the same, it's better to use the existing term: RTS. I already changed it in the file. Why are packets split up into 32 byte chunks? Usually, packets are the "atoms" of network communication. Packets can be really big (16kB e.g.). Why? See below. I agree with you to chop them , by the way. It is common practice that a higher level protocol chops large data into small chunks. There is no need to send packets as large as 16K. And there is a reason not to do it: a 16K packet needs a buffer space of 16K and memory isn't abundant on MSX. That is why I took 16kB as absolute maximum. A handshake should be able to make it less. But it will be changed anyway. I want to have a check every now and then, to prevent the whole packet having to be resent and to have more secure transmission. This protocol is (without the CRC's) much less reliable than the unidirectional one. It would be much easier to stick to small packets. If packet sizes vary a lot (from a couple of bytes to 16K or larger), you have to pick a CRC that is good enough for the largest packets. If packets are small, you can use a smaller CRC, if you want to send a lot of data, you simply send a lot of packets. True, but I thought it would be much slower. I guess you thought the packets were smaller. We have to watch out for too much packets. every packet, the sender has to wait for the receiver to be ready. This means that the time wasted waiting is proportional to the number of packets transmitted, no matter how large they are. You could make a flag in the header indicating that another packet will immediately follow the current one. The receiver will then return to "ready mode" as soon as it can. That is a good idea :) 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) This is true. There is a way to get around this
Re: (Joynet protocol)
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 be interrupted and the receiver must wait for the sender, resulting in a more complex protocol. 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. "Know the time used for the operation" is not as simple as it sounds. It's different for Z80 at 3.5MHz/6MHz/7Mhz/8MhZ, R800, Z380 and non-MSX machines. And on machines with a cache it's impossible to calculate exactly, you can give only minimum and maximum times, but that's not good enough. Even the simple fact that the R800 doesn't send CAS (or was it RAS?) when it isn't needed adds a lot of complexity to the calculation (it matters how many 512-byte boundaries are crossed by the code). Hm, that makes things awfully complicated, indeed. I don't understand how you can use asynchronous communication with JoyNet. It requires a timer on both sides running both at the same speed. Which you haven't, unless both have a MusicModule or OPL4 plugged in (timings of MM and OPL4 are slightly different, so they have to be equal on both machines), and then the transfer rate will still be very slow compared to synchronous communication and the entire concept of JoyNet (cheap, easy) will be lost. Synchronous communication doesn't require the interrupts to be disabled, and it's faster. However I haven't got ideas on how to implement it (think about it yourself). I do have ideas on how to implement a bidirectional peer-to-peer link using JoyNet (=2 computers only). As far as I can see, it's also not possible to communicate bidirectional using a JoyNet network (2 computers), since it has only 1 dataline (ack) going back to the previous host (for acknowledgement), and the other two datalines (dat1 and dat2) go to the next host. However if you have every host connected to two others using a peer-to-peer link (2 computers, so not really a 'network') in both joystickports (which make it a network again), then bidirectional transfer is indeed be possible. However you haven't got any spare joystickports then, the amount of cables is twice as much, and the setup has to be changed depending on the implementation (some might require 'real' JoyNet ring network, which is actually quite logical, and some might require a semi JoyNet ring with simple peer-to-peer links like described above). ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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#cables:line 2 2 1 3 3 2 4 4 3 etc. 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. That is the negative point of it, indeed. But I still think performance decreases much more by using a unidirectional network, especially when the network is large. Since there usually is a two-way communication, in a unidirectional network the whole ring always needs to be folowed. In a bidirectional network, the shortest path can be taken. In the best case, the bidirectional network will be a factor two faster. However, since the bandwidth in the "backwards" direction is only half that of the forward direction, that lowers the gain somewhat. Another problem is the granularity of the waiting loops. If you want to avoid self-modifying code, the fastest waiting loop is DJNZ, which takes 9 cycles for the last loop and 14 cycles for the other loops. So if you want to wait 10 cycles, you'll have to round to 23. Timing must indeed be thought of. There is no need to round. Loops that are the same every time can easily be coded. Using JP instead of DJNZ, the number of cycles per loop can be made constant. But it's not possible to get every number of cycles (try 6). Nor is it possible to have any fine-grained control without using self-modifying code. And apart from being complex, self-modifying code doesn't work in read-only memory. And after solving all the complex issues, there will be compromises on performance, so the main advantage of a timed protocol may diminish. You may be right. Are you suggesting to rewrite the document to a unidirectional format? Yes, please. And not just unidirectional, but also a protocol without timing. I want to know what other users think of this before I do it. (so please react if you care about what it will be) I'm interested too. A collision means that there are two signals on the same wire at the same time. As far as I know, that will never happen with JoyNet. What can happen, is that two neighbours want to send to each other at the same time, but that's no collision. Hmm, ok. It's a question of definition. I defined a collision as two packets going over the same wire while it can handle only one. The cable is an abstract line that can carry a stream of data, in this case 3 wires of copper. I think the term "collision" is reserved for overlapping signals on the hardware level. For example BNC (coax) networks have collisions, when two network cards send a packet at the same time. When that happens, both packets are destroyed. What you are describing has a lot of similarities, but it happens on a higher level. It is a case where mutual exclusion of two processes (sending and receiving) using a single resource (the wires) must be guaranteed. A difference with collisions is that collisions are undetectable until after they have happened. The mutex (mutual exclusion) can be detected in advance, although they're not easy to deal with: deadlock is possible if you do it the wrong way. Maybe we should make JUMP packets large enough to contain IP packets? That would make IP-over-JUMP a lot easier. Actually, maybe JUMP should only describe the network layer and we can send plain IP packets over that. That is a good idea. But I don't know enough about IP packets to design it. You wouldn't have to design the IP layer, because it already exists. We only have to find out what the minimum packet size is and whether using IP in a JoyNet network will work in practice. 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. I agree with Manuel here. It's not about a "best" version, it is simply useful to know the "evolution tree" of a document. Hmm, ok. So the parent must be named in every document. By the way I don't keep my old versions of it and I don't expect others to. There is no archive of them, which makes it a bit useless, since you cannot see the tree anyway. There is the mailinglist archive on msxnet.org... Sometime soon, I'll post a design for a non-timed protocol that can handle errors. I'm not 100% sure yet it is correct, which is why I didn't release it before. However, I am not making much progress on my own, so I'll publish it hoping for some
Re: (Joynet protocol)
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 done carefully, because too many or badly timed interrupts will kill performance, but at least interrupts no longer influence correctness. It requires a timer on both sides running both at the same speed. Which you haven't, unless both have a MusicModule or OPL4 plugged in (timings of MM and OPL4 are slightly different, so they have to be equal on both machines), and then the transfer rate will still be very slow compared to synchronous communication and the entire concept of JoyNet (cheap, easy) will be lost. Shevek wanted to use instruction length for timing at first, but now he agrees that this is too problematic. Note that you cannot even trust two timers of the same kind to run equally fast. For example, start a music replayer in two MSXes with the same song at the same moment. After about a minute you'll hear that they're out of sync. So even 60Hz isn't exactly the same for every MSX. We should indeed remember that the whole point of JoyNet is to be simple and cheap. If we want high speeds, we'll need different hardware. I'm interested in that, but it's a different project. 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. As far as I can see, it's also not possible to communicate bidirectional using a JoyNet network (2 computers), since it has only 1 dataline (ack) going back to the previous host (for acknowledgement), and the other two datalines (dat1 and dat2) go to the next host. Without fixed timing, bidirectional transfers are indeed impossible over JoyNet. However if you have every host connected to two others using a peer-to-peer link (2 computers, so not really a 'network') in both joystickports (which make it a network again), then bidirectional transfer is indeed be possible. The idea of JoyNet was to keep one joystick port free. For example, to play a game using a joystick or game pad. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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. By the way, if someone wants to write a driver for JUMP and wanna put it in UZIX, contact me please. Due to the actual stage of UZIX development, it's not an easy thing to write low level drivers for it without my help (I hope this problem will finish soon). Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * Number of Vulcans needed to replace a bulb? Precisely 1.000 * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 emphasize the fact that it is not a MSX
protocol, but a protocol for the cable. Any computer that can set the
signals on the cable can make use of the 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 knowing what the other side of the connection does, for example because
it also runs her software, she does not need to follow JUMP. It is
advisable however, to check if the computer is at that time in a JUMP
network, because the network would be suffering from the (for JUMP) bogus
packets that seem to keep coming in.
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. Of course if too many bogus
packets are received, the driver may conclude that the connection is not
JUMP. A special header could be designed for non-JUMP protocols for when
they receive a JUMP packet, but they may choose not to use it.
4. Why JUMP should be used
The reason to have a standard protocol is simple. many coders can make many
network programs and they all want to communicate with each other. If there
is no standard protocol, every computer would need drivers for all
protocols.
In the case where there is only 1 application running on the network, JUMP is
not necessary. However, if you want to create a Joynet ring that really acts
like a network, a protocol like JUMP is necessary. So JUMP is good for TCP/IP
over Joynet, file serving and such.
Exactly. Thank you for expaining.
In the rest of this document, I shall address the lines by the letters A, B
and C. A and B are the lines comping from the buttons. C is the line going
to steer left. A and B are outgoing lines and C is an incoming line on one
side. With the computer on the other side, A and B are incoming and C is
outgoing.
What about naming them "dat0", "dat1" and "ack"? Those names are easier to
remember.
I don't think so. A and B are very logical, because on the msx they are
connected to joystick button A and B. I chose C as `the other line',
because I didn't feel the need for a different name. `ack' suggests that
it is only used for the `acknowledge' pulse, which is not true in this
protocol.
Also, it should be made explicit whether the link with the previous
or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs,
next.dat0, next.dat1 and prev.ack are outputs.
True, this should be explicit. But not next and prev, because the network
is bidirectional. sender.A, sender.B and receiver.C should do, I think.
6.1. General overview
Jump is a protocol that works in packets. There are positive and negative
sides to that. The most important negative point is that the sending
computer has to wait for the receiving computer to be ready. The most
important positive point is that the data flow can be bidirectional.
I don't understand: why are these properties consequences of using packets?
With packets I mean packets that are sent in one go, without executing
other code while waiting for acknowledge signals or something. If you do
that, you can make use of a timed protocol. Actually it is the being timed
that makes it possible to be bidirectional. A non-timed protocol must have
at least two lines (data and acknowledge) on the sender side. For joynet,
that means it must be one-directional.
The being timed also means you have to wait for the receiver to be ready.
So I was actually talking about the results of a timed protocol (which
must nessecarily work in packets).
By the way, are there low-level network protocols that do not send data in
packets? I can't remember seeing one.
I used one in Boulderdash III. You can check out the source on my homepage
if you like: www.fmf.nl/~shevek -msx
6.2. Sending a packet
Before sending, a send request (SR) should be given. After that, the
sending computer has to wait for a reaction (and check for collisions, see
below). When the client has seen a send request, it sends a clear to send
(CTS). After that, the transmission begins. It works as follows:
In modem terminology, isn't SR called RTS (Request To Send)?
Yes, I think so. I'm not really familiar with those things.
Sender sends header
Receiver sends CRC1 and packet size back for confirmation
Sender sends confirmation
While (packetlength = 32) {
Sender sends 32 bytes of the packet
Receiver sends CRC0
Sender sends confirmation
first 32 bytes are cut
Re: (Joynet protocol)
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 does not need to follow JUMP. It is advisable however, to check if the computer is at that time in a JUMP network, because the network would be suffering from the (for JUMP) bogus packets that seem to keep coming in. 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 possible to use JUMP and an incompatible protocol on the same network. So why not demand that every node in the network uses JUMP? Of course if too many bogus packets are received, the driver may conclude that the connection is not JUMP. A special header could be designed for non-JUMP protocols for when they receive a JUMP packet, but they may choose not to use it. Even that is impossible. If the other protocol uses a different algorithm for sending packets, a node using JUMP wouldn't even be able to receive it's packets. What about naming them "dat0", "dat1" and "ack"? Those names are easier to remember. I don't think so. A and B are very logical, because on the msx they are connected to joystick button A and B. I chose C as `the other line', because I didn't feel the need for a different name. `ack' suggests that it is only used for the `acknowledge' pulse, which is not true in this protocol. OK. Also, it should be made explicit whether the link with the previous or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs, next.dat0, next.dat1 and prev.ack are outputs. True, this should be explicit. But not next and prev, because the network is bidirectional. sender.A, sender.B and receiver.C should do, I think. The prefixes "prev" and "next" can be used on a bidirectional network. If the nodes are numbered, node N knows neighbour N-1 as "prev" and neighbour N+1 as "next". Especially when using a bidirectional network, "sender" and "receiver" is less clear, because either neighbour can fulfill both roles. Jump is a protocol that works in packets. There are positive and negative sides to that. The most important negative point is that the sending computer has to wait for the receiving computer to be ready. The most important positive point is that the data flow can be bidirectional. I don't understand: why are these properties consequences of using packets? With packets I mean packets that are sent in one go, without executing other code while waiting for acknowledge signals or something. If you do that, you can make use of a timed protocol. So you mean that sending or receiving a packet is an atomic action? Actually it is the being timed that makes it possible to be bidirectional. A non-timed protocol must have at least two lines (data and acknowledge) on the sender side. For joynet, that means it must be one-directional. That's true. But does it really matter? A unidirectional network seems a lot simpler to me. The being timed also means you have to wait for the receiver to be ready. Synchronous transfer. Before sending, a send request (SR) should be given. After that, the sending computer has to wait for a reaction (and check for collisions, see below). When the client has seen a send request, it sends a clear to send (CTS). After that, the transmission begins. It works as follows: In modem terminology, isn't SR called RTS (Request To Send)? Yes, I think so. I'm not really familiar with those things. If they are the same, it's better to use the existing term: RTS. Why are packets split up into 32 byte chunks? Usually, packets are the "atoms" of network communication. Packets can be really big (16kB e.g.). Why? It is common practice that a higher level protocol chops large data into small chunks. There is no need to send packets as large as 16K. And there is a reason not to do it: a 16K packet needs a buffer space of 16K and memory isn't abundant on MSX. I want to have a check every now and then, to prevent the whole packet having to be resent and to have more secure transmission. This protocol is (without the CRC's) much less reliable than the unidirectional one. It would be much easier to stick to small packets. If packet sizes vary a lot (from a couple of bytes to 16K or larger), you have to pick a CRC that is good enough for the largest packets. If packets are small, you can use a smaller CRC, if you want to send a lot of data, you simply send a lot of packets. This is the complete transmission of a packet. CRC
Re: (Joynet protocol)
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 doing JUMP transfers - it is hard to program on PCs (file serving, internet connection, MSX emulators) You need a clock-independant timer for timing. Most basic setup MSX-es haven't (and that's the idea of JoyNet, simplicity). I think synchonous communication (by the means of sending ACKs) is the most reliable, easiest and fastest way to do it (although you spend 1/3rd of your bandwidth with ACKs, the protocol can operate on the slowest computer's maximum speed instead of on a fixed timer). ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Joynet
oops, I forgot to describe the packet header. Well, we can discuss about
that later anyway. I think this should be enough already for quite some
time to fight about ;)
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44 x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
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 knowing what the other side of the connection does, for example because
it also runs her software, she does not need to follow JUMP. It is
advisable however, to check if the computer is at that time in a JUMP
network, because the network would be suffering from the (for JUMP) bogus
packets that seem to keep coming in.
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?
4. Why JUMP should be used
The reason to have a standard protocol is simple. many coders can make many
network programs and they all want to communicate with each other. If there
is no standard protocol, every computer would need drivers for all
protocols.
In the case where there is only 1 application running on the network, JUMP is
not necessary. However, if you want to create a Joynet ring that really acts
like a network, a protocol like JUMP is necessary. So JUMP is good for TCP/IP
over Joynet, file serving and such.
In the rest of this document, I shall address the lines by the letters A, B
and C. A and B are the lines comping from the buttons. C is the line going
to steer left. A and B are outgoing lines and C is an incoming line on one
side. With the computer on the other side, A and B are incoming and C is
outgoing.
What about naming them "dat0", "dat1" and "ack"? Those names are easier to
remember. Also, it should be made explicit whether the link with the previous
or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs,
next.dat0, next.dat1 and prev.ack are outputs.
6.1. General overview
Jump is a protocol that works in packets. There are positive and negative
sides to that. The most important negative point is that the sending
computer has to wait for the receiving computer to be ready. The most
important positive point is that the data flow can be bidirectional.
I don't understand: why are these properties consequences of using packets?
By the way, are there low-level network protocols that do not send data in
packets? I can't remember seeing one.
6.2. Sending a packet
Before sending, a send request (SR) should be given. After that, the
sending computer has to wait for a reaction (and check for collisions, see
below). When the client has seen a send request, it sends a clear to send
(CTS). After that, the transmission begins. It works as follows:
In modem terminology, isn't SR called RTS (Request To Send)?
Sender sends header
Receiver sends CRC1 and packet size back for confirmation
Sender sends confirmation
While (packetlength = 32) {
Sender sends 32 bytes of the packet
Receiver sends CRC0
Sender sends confirmation
first 32 bytes are cut off packet
}
Sender sends remaining bytes of packet
Receiver sends CRC0
Sender sends confirmation
Receiver sends CRC1
Sender sends confirmation
Why are packets split up into 32 byte chunks? Usually, packets are the
"atoms" of network communication.
This is the complete transmission of a packet. CRC0 is a 8 bit CRC on the
data that has just been received. CRC1 is a 32 bit CRC of all received
bytes*3.
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).
Sending of
bytes is done by sending the bits on a timed basis, as is shown.
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 doing JUMP transfers
- it is hard to program on PCs
(file serving, internet connection, MSX emulators)
Both wait a time t1
Receiver reads bit [i;i+1|i] from [AB|C]
Both wait a time t2
While the receiver reads the bits, the sender is doing nothing. But they
should remain in sync, so either the receive time must be substracted from t2
or the sender must wait an amount of time equal to the receive time.
6.4 Control signals and collision detection
Are collisions possible? If there can be no collisions, collision detection
is not necessary.
Please let me know what you think of it. If anything is not clear or you
want it different, let me know.
What is most unclear to me, is why the design decisions are made. The timing
values, why are they chosen as they are? Why is the packet sent in 32-byte
chunks instead of 16-byte or 256-byte?
One thing you haven't addressed, is ho
Re: (Joynet protocol)
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 complement of each word in the packet). Another interesting one is that used in PPP frames. There is an implementation (FCS - Fast Checksum S-i-dont-remember-what-this- letter-means) that uses a 512 bytes lookup table; the cost of the checksum is two XOR operations per byte and the resulting checksum is a constant for any packet (I don't remember the value by heart). If someone is interested, I can give a source code example. Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * Press any key except... no, No, NO, NOT THAT ONE! * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
joynet pc/msx
I just finished a program to load 16kb roms through a joynet cable connected to a PC. You can download it from: http://www.lsi.usp.br/~ricardo/msx/RBJOYNET.ZIP To use it: 1) type (in the pc) UPLOAD ANTARTIC.ROM 2) type (in the MSX) DOWNLOAD 3) Wait until it loads and have fun times: k6-233 and a turbo-r in r800 mode : 1.6 s (+/- 0.1) k6-233 and a turbo-r in z80 mode : 6.0 s (+/- 0.1) EVERYONE WHO TRIES THIS PROGRAM MUST SEND AN EMAIL TELLING IF IT WORKS OR NOT. Thanks. Ricardo Bittencourt http://www.lsi.usp.br/~ricardo [EMAIL PROTECTED] "Ricardo is subtle, but malicious he is not" -- Uniao contra o forward - crie suas proprias piadas -- MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Fw: I have a question about JoyNet...
Hi. I am a Computer Engineer at Brazil. I was starting a project like the JoyNet. ( About 2 weeks ago ) Good! JoyNet is a child dream! Forever sleeps. Do you think so? JoyNet has a completely different purpose. It is just a standarized cable, because several games used several types of cables, so you had to buy a different cable for each game. Also, JoyNet is VERY low-cost (less than $5), while your nice project will cost... well, I think at least $50 per cartridge. The purpose is entirely different so they can't be compared. JoyNet is meant to be a cheap cable to play multiplayer games, while your project is meant to be a high-end network adapter (if I understand correct). ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit the Datax homepage at http://datax.cjb.net/ MSX fair Bussum / MSX Marathon homepage: http://msxfair.cjb.net/ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Fw: I have a question about JoyNet...
-- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit the Datax homepage at http://datax.cjb.net/ MSX fair Bussum / MSX Marathon homepage: http://msxfair.cjb.net/ - Oorspronkelijk bericht - Van: Senryo [EMAIL PROTECTED] Aan: [EMAIL PROTECTED] Verzonden: vrijdag 3 september 1999 6:10 Onderwerp: I have a question about JoyNet... Hi. I am a Computer Engineer at Brazil. I was starting a project like the JoyNet. ( About 2 weeks ago ) The ideia is USE A PARALEL CABLE BETWEEN MSX AND PC. The different thing, it's like the CABLE will Be done, ( HAS regenerators ). Can be used Any distance You want.. ) A friend of mine a Electrical Engineer is doing the Cable ( with Leds indicators: ON/OFF, TX/RX, CLOCK PULSE ). I am modeling the PROTOCOL. We are doing the PC like a MSX Disk-Driver server. The PC sends to MSX the Files in packets, with timeout, sincronism, and all Things in a Protocol. THE MSX See The PC like a Disk Drive, then You can Read ROMS, GAMES AND OTHER, 5 times more quick than a DISK DRIVE. On PC you have a File ( That store and send datas to MSX ) Like GAMES, files. Or you CAN PUT ON MEMORY. I have 128 Mb RAM on PC. Then I use the RAM Mesmory that is HUNDRED time faster than the HD. It's The START. More later, We will serve, HD, AND ALL I/O COMPONENTS OF PC. AND INTERNET E-MAIL, ALL THE STUFF. WITH 200Kb/s . And a Secure Protocol. Please. Send this MSX to ALL PEOPLE ON MSX LIST, AND JOYNET... Thanks.. My e-mail: [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Fw: I have a question about JoyNet...
K_master wrote: Hi. I am a Computer Engineer at Brazil. I was starting a project like the JoyNet. ( About 2 weeks ago ) Good! JoyNet is a child dream! Forever sleeps. The ideia is USE A PARALEL CABLE BETWEEN MSX AND PC. The different thing, it's like the CABLE will Be done, ( HAS regenerators ). Can be used Any distance You want.. ) A friend of mine a Electrical Engineer is doing the Cable ( with Leds indicators: ON/OFF, TX/RX, CLOCK PULSE ). I make a cable for six stations. Uses the bus/Ethernet scheme. Token Ring is snail-motion. I am modeling the PROTOCOL. Yes! I also! [Pindorama Language On] Entao me envia um mail ! Tb tenho interesse em melhorar o meu protocolo fudeba! [/PLO] MARUJO. ___ _ _ ___ ___ | | |_| |_ __ _ __| WALTER BERNARDO NUNES | | /|| |_ _| \| |/ /| [EMAIL PROTECTED]| \ / || | | |_| / / Graduacao Fisica-UFRGS | \ /|| |_| |_ |_| |/__| \__/__||___|___|___|_|_ / [tag ainda nao disponivel] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Flaw in the JoyNet specification...
*Sigh* this isn't the most clear discussion I heard of... Definitely not. First, the one is wrong, then the other is good, but it is wrong... Rhaaa!!! Sorry about this, but when Werner mentioned this problem, I suggested something because I thought it to be logical. When I made the cable, I found out I was wrong. So I guess only the PC (DB25 /m)-layout has to be changed at my page, eh? That's correct. It should state: 13-1 and 12-2. But is this the good change??? Is the error in the DB25-scheme or in the DB5-scheme? I hope it is the last one, for then I don't need to redraw the figure... The figure is correct. Greetings Richard MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Flaw in the JoyNet specification...
Yes, and I updated the direct MSX-PC JoyNet cable, as you said. Was really wrong. Now is: MSX PC 1-2 2-3 3-4 613 712 810 918~25 But now Laurens must update the official page, at the PC JoyNet cable... PC (DB25 /m) pin layout: 12 - RECV pin 2 13 - RECV pin 1 *Sigh* this isn't the most clear discussion I heard of... Definitely not. First, the one is wrong, then the other is good, but it is wrong... Rhaaa!!! Ok, so the MSX-PC cable has to be changed into the above, am I right? Nooo!!! Dam, the upper diagramme is the diagramme of an 'alternative' MSX-PC-cable... So I guess only the PC (DB25 /m)-layout has to be changed at my page, eh? But is this the good change??? Is the error in the DB25-scheme or in the DB5-scheme? I hope it is the last one, for then I don't need to redraw the figure... Anyways, Maarten ter Huurne, help!!! You have made the official cable and you are using it so pleez make things clear. I think 12 - pin 1 and 13 - pin 2 is the best, but you made this one up so please tell me how it HAS to be. Thanks. ~Grauw "Dam ain't getting no heck of it anymore" MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Flaw in the JoyNet specification...
Laurens Holst wrote: *Sigh* this isn't the most clear discussion I heard of... Definitely not. First, the one is wrong, then the other is good, but it is wrong... Rhaaa!!! Yes, let's all work in Micro$oft ! We would do it good ! Anyways, Maarten ter Huurne, help!!! You have made the official cable and you are using it so pleez make things clear. I think 12 - pin 1 and 13 - pin 2 is the best, but you made this one up so please tell me how it HAS to be. Yes, please help. Did anybody (less Maarten and Richard) make a PC JoyNet cable ? I think not, because if so, they would have discovered the flaw at the official page... []s Werner *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 ! dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes: http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ? MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Laurens, help... Flaw in the JoyNet specification...
Richard states that the correct is the DIN5 (1-13 and 2-12). In my first mail in only stated, that its not correct to connect MSX pins 1-3 (which are inputs only) to PC pin 10,12,13 (which are also inputs only) and to connect MSX pins 6-8 (outputs) to PC pins 2-4 (also outputs). So i just swapped the output pins on the PC with the input pins. I never noticed the possible mixup between pins 12 and 13. After studing the DATAX page, I think (as mentioned in my previous mail) the correct version is RECV DIN5 (1-12, 2-13). This because SEND DIN5 (1-2, 2-3). Therefore (6-13 and 7-12) are correct on my direct cable. I think Richard did make a PC cable, otherwise he wouldn't state that. But was he the only one ? Who have already made a PC JoyNet cable ? I made a PC cable, but not based on the joynet specification. The cable I build goes from PC-lpt to both MSX-joystick and MSX-lpt, but is similar to half a joynet-cable. It can only receive data from the PC and it now only has two wires from PC to MSX and one from MSX to PC. I'm going to expand it to 5 wires PC to MSX and 5 wires MSX to PC. This way I should be able to transfer data at high speeds in both ways, 4 bits at a time. Greetings Richard MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Laurens, help... Flaw in the JoyNet specification...
Laurens Holst wrote: If someone can confirm this / tell me why this is a flaw, then I will update it immediately. See, in the same cable specification at Datax page: JoyNet to PC cable * The DB-25 connector says (1-12, 2-13): PC (DB25 /m) pin layout: 12 - RECV pin 1 13 - RECV pin 2 * But the DIN5 connector says the opposite(1-13, 2-12): RECV (DIN5 180 /f) pin layout: 1 - PC pin 13 2 - PC pin 12 The PC JoyNet cable presented at the official page is to link a PC to an MSX with a standard JoyNet cable, or inserting a PC in a JoyNet ring. At my page I presented the scheme for an 'alternative' JoyNet cable, without the DIN5s connectors, with just a DB9 and a BD25 to link direclty a single PC to an single MSX. But as I dont know which in the PC JoyNet cable is right (1-13 and 2-12) or (1-12 and 2-13), I can't set the correct connections (6-12 and 7-13) or (6-13 and 7-12) at my 'alternative' MSX-PC direct joynet cable. Richard states that the correct is the DIN5 (1-13 and 2-12). Therefore (6-13 and 7-12) are correct on my direct cable. I think Richard did make a PC cable, otherwise he wouldn't state that. But was he the only one ? Who have already made a PC JoyNet cable ? Please people help Greets Werner Kai MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Laurens, help... Flaw in the JoyNet specification...
After studing the DATAX page, I think (as mentioned in my previous mail) the correct version is RECV DIN5 (1-12, 2-13). I was wrong!!! Tonight a made the 10 wires cable I spoke of earlier and wrote the protocol for the msx (assembler) and the pc (c++). When I was debugging them I found out something was wrong. I have the following connection MSX-lpt PC-lpt 2 (d0) to 10 3 (d1) to 11 4 (d2) to 12 5 (d3) to 13 I got the following values: write on msx-lpt read on PC-lpt (after correcting the inverted pin 11) 0001 (1) 0100 0010 (2) 1000 0100 (4) 0010 1000 (8) 0001 In my case I should connect 2-13, 3-12, 4-10 and 5-11. Thus in with joynet, joystick pin 1 should go to pc-lpt pin 13 and joystick pin 2 should go to pc-lpt pin 12. PC (DB25 /m) pin layout: 2 - SEND pin 1 3 - SEND pin 2 4 - RECV pin 3 xxx - nc 10 - SEND pin 3 11 - nc 12 - RECV pin 2 13 - RECV pin 1 xxx - nc 18-25 - SEND / RECV pin 5 RECV (DIN5 180 /f) pin layout: 1 - PC pin 13 2 - PC pin 12 3 - PC pin 4 4 - nc 5 - PC pin 18-25 Greetings Richard MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Flaw in the JoyNet specification...
Richard Gerrits wrote: Thus in with joynet, joystick pin 1 should go to pc-lpt pin 13 and joystick pin 2 should go to pc-lpt pin 12. PC (DB25 /m) pin layout: 2 - SEND pin 1 3 - SEND pin 2 4 - RECV pin 3 xxx - nc 10 - SEND pin 3 11 - nc 12 - RECV pin 2 13 - RECV pin 1 xxx - nc 18-25 - SEND / RECV pin 5 RECV (DIN5 180 /f) pin layout: 1 - PC pin 13 2 - PC pin 12 3 - PC pin 4 4 - nc 5 - PC pin 18-25 Greetings Richard Yes, and I updated the direct MSX-PC JoyNet cable, as you said. Was really wrong. Now is: MSX PC 1-2 2-3 3-4 613 712 810 918~25 But now Laurens must update the official page, at the PC JoyNet cable... PC (DB25 /m) pin layout: 12 - RECV pin 2 13 - RECV pin 1 Greetings, Werner MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Laurens, help... Flaw in the JoyNet specification...
People, I discovered a flaw in the JoyNet specification. I discovered another one. In the section about connecting a MSX to a PC there is something like this: (... ...) It must be at my JoyNet page... I made it based on data at DATAX page (the official page). Now, checking the official page, made by Laurens Holst, I found: Which is correct ? Is the diagram (picture) right ? Since my page CONTAINS the official standard specification the flaw Richard discovered is also a flaw on my page. And since I haven't updated this on my page it's quite logical my page states different than Richard's update. If someone can confirm this / tell me why this is a flaw, then I will update it immediately. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet!
[EMAIL PROTECTED] wrote: Yup :) You could get pretty fast games using screen2 or screen4... And they could be very pretty, with right thinking ^^ Exactly - that's why the OSR-engine uses screen4... One Shot Rising? I should know more about this subject, but actually I know nothing... or forgot what I knew. What's it? =) ...and the gfx really _COULD_ be pretty/nice/fantastic... That's what I meant. I'm such a bad english-writer! =) []s, Parn MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Flaw in the JoyNet specification...
People, I discovered a flaw in the JoyNet specification. I discovered another one. In the section about connecting a MSX to a PC there is something like this: MSX PC 1 /FORWARD (IN)--13 SEL (IN) 2 /BACK (IN)--12 PE (IN) 3 /LEFT(IN)--10 /ACK (IN) 6 /TRG1 (IN/OUT)--2 D0 (OUT) 7 /TRG2 (IN/OUT)--3 D1 (OUT) 8 OUTPUT (OUT)--4 D3 (OUT) 9 GND-25 GND This should be: MSX PC 1-2 2-3 3-4 613 712 810 925 Greetings Richard. MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Laurens, help... Flaw in the JoyNet specification...
Richard Gerrits wrote: People, I discovered a flaw in the JoyNet specification. I discovered another one. In the section about connecting a MSX to a PC there is something like this: MSX PC 1 /FORWARD (IN)--13 SEL (IN) 2 /BACK (IN)--12 PE (IN) 3 /LEFT(IN)--10 /ACK (IN) 6 /TRG1 (IN/OUT)--2 D0 (OUT) 7 /TRG2 (IN/OUT)--3 D1 (OUT) 8 OUTPUT (OUT)--4 D3 (OUT) 9 GND-25 GND This should be: MSX PC 1-2 2-3 3-4 613 712 810 925 It must be at my JoyNet page... I made it based on data at DATAX page (the official page). Now, checking the official page, made by Laurens Holst, I found: JoyNet to PC cable PC (DB25 /m) pin layout: 12 - RECV pin 1 13 - RECV pin 2 RECV (DIN5 180 /f) pin layout: 1 - PC pin 13 2 - PC pin 12 Which is correct ? Is the diagram (picture) right ? Thank you. Werner Kai MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
RE: Games for Joynet ?
- A 2-player RPG??? (with 'mission objectives' of which both players can do the half) Great idea! MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
From: "Werner Augusto Roder Kai" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Games for Joynet ? Date: Tue, 25 May 1999 11:35:16 -0300 sander Niessen wrote: Hi all, Does anyone have a game finished for joynet ? Because I currently own 4 msx'es (Fleamarkets...) and it would be cool if I could play some games on them which use joynet. Greets, Sander Niessen I sent our joynet game through e-mail to several Dutch people (for Tilburg '99). But it seems that nobody even unpacked it :-( No bug reports, no any reports, zero feedback.. :-( I also had a Joynet page in english, but I changed my site and didn't remake the page. Tonight I will do it, and then Laurens will be able to update the link at his homepage. The page will be online from 2h AM here. Then I will send the complete URL to this list. But here is GMT-3, so I think it will be tomorrow there... Greetings Werner Kai *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 ! dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes: http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ? MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) sander Niessen wrote: Hi all, Does anyone have a game finished for joynet ? Because I currently own 4 msx'es (Fleamarkets...) and it would be cool if I could play some games on them which use joynet. Greets, Sander Niessen I sent our joynet game through e-mail to several Dutch people (for Tilburg '99). But it seems that nobody even unpacked it :-( No bug reports, no any reports, zero feedback.. :-( I also had a Joynet page in english, but I changed my site and didn't remake the page. Tonight I will do it, and then Laurens will be able to update the link at his homepage. The page will be online from 2h AM here. Then I will send the complete URL to this list. But here is GMT-3, so I think it will be tomorrow there... Greetings Werner Kai *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 ! dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes: http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ? Hi Werner, Could you please send it to me ? Not to this email address but to the following: [EMAIL PROTECTED] Thanx, Sander Niessen __ Get Your Private, Free Email at http://www.hotmail.com MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet!
"Giovanni R. Nunes" wrote:
- Grand Theft Auto alike, but without cars and with a lot of gangsters. Some
kind of deathmatch. (something for my gfx-engine I think)
This Game I don't know... Sorry. :)
This was released in Brazil as "O Grande Ladrao
de Automoveis" or something... How foolish :)
- Tic-Tac-Toe for 2 MSX-computers (duh!!!)
Jogo da velha ("Old-woman's Game") ?
Yup :) You could get pretty fast games using
screen2 or screen4... And they could be very
pretty, with right thinking ^^
[]s,
Parn
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
At 11:35 AM 5/25/99 -0300, you wrote: I sent our joynet game through e-mail to several Dutch people (for Tilburg '99). But it seems that nobody even unpacked it :-( No bug reports, no any reports, zero feedback.. :-( I carried it with me on a disk (and a cable in my backpack too), but I forgot about it until it was already time to go home :( But I will certainly run it here in my room with some friends once I finish the second cable. Or maybe I'll hack JoyNet support into fMSX... Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
At 05:45 PM 5/25/99 +0200, you wrote:
- Tetris network
(maybe Triplex can be adapted???)
I am working on a Tetris for JoyNet. The MSX2 graphical part works OK, the
controls can be improved but function nevertheless. What is missing is the
communication and inter-player-relations. And MSX1 GFX maybe.
About Triplex: the source is available, but only on paper :(
Anyway, since the communication routines would have to be rewritten anyway,
I don't know if it's worth it to re-use the Triplex code. But maybe I can
re-use some of the algorithms (if Sander still remembers them).
- Tic-Tac-Toe for 2 MSX-computers
(duh!!!)
In general, a turn-based strategy game where both can see the board is not
suitable for JoyNet, because you could just as well play it on one
computer. Only when the board is secret ("zeeslag", the game where you have
to sink the enemy battle ships) or the game is real-time with a lot of
players (Werner Kai's game), using JoyNet adds a dimension to the game.
Maybe OSR can make use of JoyNet??? Anyone knows one of the developers?
I have his e-mail address. And I think he reads this list too.
I don't know if the gameplay of OSR is suitable for multiplayer. But I'm
sure the engine is. I think with a little modification it would make an
excellent Micro Machines engine. It has properties like high-speed
scrolling, wall detection, turning the ship in small angle increments.
Rather than starting to work on many games, it might be better to build a
library of useful functions for JoyNet. Examples:
- a routine that uploads code and data to diskless MSXes (shevek made this)
- an algorithm that automatically numbers the computer in the ring (I
already have some ideas for this)
- a sort-of kernel, which regularly checks whether there is an incoming
transmission (for fast games, checking at 60Hz is not frequent enough)
- CALL commands to use JoyNet from BASIC, to enable more people to program
for JoyNet
Bye,
Maarten
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet!
Hi!,
- Grand Theft Auto alike, but without cars and with a lot of gangsters.
Some
kind of deathmatch. (something for my gfx-engine I think)
This Game I don't know... Sorry. :)
Well, imagine you're a gangster and you walk through a city of flats (in
top-down view). You can encounter other gangsters and then you'll have to
shoot them
You can find boxes with different kinds of contents, like a machine-gun, a
10-second kill frenzy gun etcetera.
In the PC-game Grand Theft Auto, you can also steal cars, buses, tankers and
trains, and drive like a madman, and be chased by the police.
- A Real Time Strategy (although I don't know yet if JoyNet is fast
enough for Strategic Army)
- A Micro Machines (or Greatest Driver 2D Special)-like game (racing
with a top-view, should be possible in screen 4) (has lots of 'egale
vlakken', so screen 4 has enough colors I think)
No problems w/ SCR2/SCR4 graphics, worry with the code... :)
I like draw in this screen mode.
I can code everything.
- A 2-player RPG???
(with 'mission objectives' of which both players can do the half)
A game like XaK 3? But w/ players going to diferent ways, not?
There are some things to complete to go to the next part, i.e. you'll have
to collect a bucket, a key and a scoop. Well the one player can search for
the bucket and the scoop while in the meantime the other one can find the
key. They then meet again at the door where they unlock it and proceed to
the next part.
Something like that.
- Tetris network (maybe Triplex can be adapted???)
It is old, try another idea... :)
Well, I won't try it anyway. It was just a suggestion.
- Tic-Tac-Toe for 2 MSX-computers (duh!!!)
Jogo da velha ("Old-woman's Game") ?
???
Anyways, I like the Micro Machines and Gangster-game most. If you
think one of these ideas is cool and you would like to make it, let me
know, maybe we can co-perate.
I can help you with graphics and algoritms (Z80 Asm code not is my
specialitty).
But it is mine. Anyway, I have not planned anything yet, but if I have I'll
remember you.
~Grauw
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
Maybe OSR can make use of JoyNet??? Anyone knows one of the developers? I have his e-mail address. And I think he reads this list too. I don't know if the gameplay of OSR is suitable for multiplayer. But I'm sure the engine is. I think with a little modification it would make an excellent Micro Machines engine. It has properties like high-speed scrolling, wall detection, turning the ship in small angle increments. Indeed. Rather than starting to work on many games, it might be better to build a library of useful functions for JoyNet. Examples: - a routine that uploads code and data to diskless MSXes (shevek made this) - an algorithm that automatically numbers the computer in the ring (I already have some ideas for this) - a sort-of kernel, which regularly checks whether there is an incoming transmission (for fast games, checking at 60Hz is not frequent enough) - CALL commands to use JoyNet from BASIC, to enable more people to program for JoyNet My idea. But who's gotta program it, eh? It is one of my 5 projects I'm currently working on, but it isn't going very fast (dam I've gotta work harder on that). By the way, the cable of Blokslag, Zeeslag and that other game, from MSX Friesland Noord is NOT compatible with JoyNet. I'll put it on my homepage the next update (haven't got time now). ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Our Joynet page and game online...
Hi, As I promised you, The new URL of our site: http://www.coreclub.cjb.net Our Joynet English page: http://mercury.spaceports.com/~coreclub/english/joyneten.htm From there you can download the two versions of our JoyNet game with a manual in English. Greetings Werner Kai -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 ! dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes: http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ? MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
sander Niessen wrote:
From: "Werner Augusto Roder Kai" [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Games for Joynet ?
Date: Tue, 25 May 1999 11:35:16 -0300
sander Niessen wrote:
Hi all,
Does anyone have a game finished for joynet ?
Because I currently own 4 msx'es (Fleamarkets...) and it would be
cool if I could play some games on them which use joynet.
Greets,
Sander Niessen
I sent our joynet game through e-mail to several Dutch people (for Tilburg
'99).
But it seems that nobody even unpacked it :-(
No bug reports, no any reports, zero feedback.. :-(
I also had a Joynet page in english, but I changed my site and didn't
remake
the page.
Tonight I will do it, and then Laurens will be able to update the link at
his
homepage.
The page will be online from 2h AM here. Then I will send the complete URL
to
this list. But here is GMT-3, so I think it will be tomorrow there...
Greetings
Werner Kai
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 !
dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes:
http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ?
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and
put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED]
(www.stack.nl/~wiebe/mailinglist/)
sander Niessen wrote:
Hi all,
Does anyone have a game finished for joynet ?
Because I currently own 4 msx'es (Fleamarkets...) and it would be
cool if I could play some games on them which use joynet.
Greets,
Sander Niessen
I sent our joynet game through e-mail to several Dutch people (for Tilburg
'99).
But it seems that nobody even unpacked it :-(
No bug reports, no any reports, zero feedback.. :-(
I also had a Joynet page in english, but I changed my site and didn't
remake
the page.
Tonight I will do it, and then Laurens will be able to update the link at
his
homepage.
The page will be online from 2h AM here. Then I will send the complete URL
to
this list. But here is GMT-3, so I think it will be tomorrow there...
Greetings
Werner Kai
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 !
dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes:
http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ?
Hi Werner,
Could you please send it to me ? Not to this email address but to the
following: [EMAIL PROTECTED]
Thanx,
Sander Niessen
__
Get Your Private, Free Email at http://www.hotmail.com
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 !
dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes:
http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ?
snafu.zip
Re: Games for Joynet ?
Maarten ter Huurne schrieb: Maybe OSR can make use of JoyNet??? Anyone knows one of the developers? I have his e-mail address. And I think he reads this list too. I don't know if the gameplay of OSR is suitable for multiplayer. But I'm sure the engine is. I think with a little modification it would make an excellent Micro Machines engine. It has properties like high-speed scrolling, wall detection, turning the ship in small angle increments. Hi all! Phew - OSR 4 JoyNet? - I don't think it's suitable... The gfx-engine would be! ...and I had many nice ideas 4 games too, but I was (?) to realistic not to start them, cause I have to go on 2 finish this thing! Wanna hear some ideas? - Ok... - a side-view-"jumping" maze game... ;) (a ball jumps through the maze, but the ball always would be in the center of the screen - so the rest of the screen have 2 jump...) - a kinda racing game - why not call it "Micro Sliders eXtended"? - a "ball-game" (Projectile): gamefieldsize about 40 screens, 3 players, goals on each side (every player has a goal to defend), and on the 4th side a combination of the 3 different goals, each player has to push the (one and only) ball, he would be pushed away cause of the collision, and so everyone of the three try to push it into a goal (maybe u can imagine what I mean) It could be one of the best things 2 use JoyNet... But I know 2 less of the JoyNet 2 say something exactly... Additional the scroll-engine works in screen4, that means: it's not really easy to design... greetz JJoS aka Chief-gavaman -- -- official developer of O.ne S.hot R.ising -- I hate bugs! - I like Starship Troopers... MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet!
Pablo Vasques Bravo-Villalba schrieb: Yup :) You could get pretty fast games using screen2 or screen4... And they could be very pretty, with right thinking ^^ Exactly - that's why the OSR-engine uses screen4... ...and the gfx really _COULD_ be pretty/nice/fantastic... greetz JJoS aka Chief-gavaman -- -- official developer of O.ne S.hot R.ising -- I hate bugs! - I like Starship Troopers... MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Games for Joynet ?
Hi all, Does anyone have a game finished for joynet ? Because I currently own 4 msx'es (Fleamarkets...) and it would be cool if I could play some games on them which use joynet. Greets, Sander Niessen __ Get Your Private, Free Email at http://www.hotmail.com MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
sander Niessen wrote: Hi all, Does anyone have a game finished for joynet ? Because I currently own 4 msx'es (Fleamarkets...) and it would be cool if I could play some games on them which use joynet. Greets, Sander Niessen I sent our joynet game through e-mail to several Dutch people (for Tilburg '99). But it seems that nobody even unpacked it :-( No bug reports, no any reports, zero feedback.. :-( I also had a Joynet page in english, but I changed my site and didn't remake the page. Tonight I will do it, and then Laurens will be able to update the link at his homepage. The page will be online from 2h AM here. Then I will send the complete URL to this list. But here is GMT-3, so I think it will be tomorrow there... Greetings Werner Kai *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* PARTICIPE do proximo encontro de usuarios de MSX ! MSX JAU' 99 ! dias 13, 14 e 15 de novembro na cidade de JAU'-SP Mais Informacoes: http://www.msxjau99.cjb.net ou http2//msx.jau.99 - EU VOU ! E VOCE^ ? MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
Does anyone have a game finished for joynet ? Because I currently own 4 msx'es (Fleamarkets...) and it would be cool if I could play some games on them which use joynet. Nope... not yet. But I have some ideas: === - Grand Theft Auto alike, but without cars and with a lot of gangsters. Some kind of deathmatch. (something for my gfx-engine I think) - a Real Time Strategy (although I don't know yet if JoyNet is fast enough for Strategic Army) - a Micro Machines (or Greatest Driver 2D Special)-like game (racing with a top-view, should be possible in screen 4) (has lots of 'egale vlakken', so screen 4 has enough colors I think) - A 2-player RPG??? (with 'mission objectives' of which both players can do the half) - Tetris network (maybe Triplex can be adapted???) - Tic-Tac-Toe for 2 MSX-computers (duh!!!) Ofcourse, I'd like to make all these games myself, but ofcourse... that's not possible, I haven't got THAT much time. As I use to say: 5 projects at once is enough. Anyways, I like the Micro Machines and Gangster-game most. If you think one of these ideas is cool and you would like to make it, let me know, maybe we can coöperate. Maybe OSR can make use of JoyNet??? Anyone knows one of the developers? ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Games for Joynet ?
I sent our joynet game through e-mail to several Dutch people (for Tilburg '99). But it seems that nobody even unpacked it :-( No bug reports, no any reports, zero feedback.. :-( Sorry I didn't mention your game in my previous message... Anyway, I HAVE unpacked it, just haven't tried it yet. :) Well, I have tried the first version (the Basic-one). Yes, I know we had to try it out in Tilburg. But the day was so short and... I also had a Joynet page in english, but I changed my site and didn't remake the page. Tonight I will do it, and then Laurens will be able to update the link at his homepage. Great. Let me know. The page will be online from 2h AM here. Then I will send the complete URL to this list. But here is GMT-3, so I think it will be tomorrow there... Greetings Werner Kai Here is GMT +1, so that's 6h AM here. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Games for Joynet!
Hi!,
- Grand Theft Auto alike, but without cars and with a lot of gangsters. Some
kind of deathmatch. (something for my gfx-engine I think)
This Game I don't know... Sorry. :)
- A Real Time Strategy (although I don't know yet if JoyNet is fast
enough for Strategic Army)
- A Micro Machines (or Greatest Driver 2D Special)-like game (racing
with a top-view, should be possible in screen 4) (has lots of 'egale
vlakken', so screen 4 has enough colors I think)
No problems w/ SCR2/SCR4 graphics, worry with the code... :)
I like draw in this screen mode.
- A 2-player RPG???
(with 'mission objectives' of which both players can do the half)
A game like XaK 3? But w/ players going to diferent ways, not?
- Tetris network (maybe Triplex can be adapted???)
It is old, try another idea... :)
- Tic-Tac-Toe for 2 MSX-computers (duh!!!)
Jogo da velha ("Old-woman's Game") ?
Anyways, I like the Micro Machines and Gangster-game most. If you
think one of these ideas is cool and you would like to make it, let me
know, maybe we can co-perate.
I can help you with graphics and algoritms (Z80 Asm code not is my
specialitty).
---
Giovanni Nunes
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://www.geocities.com/ResearchTriangle/2472/
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JOYNET information and MISC
My protocol is delay insensitive. You can't make a delay insensitive protocol and use timeouts at the same time. You can, just set the timeout to, well, 3 minutes (255 interrupts). That will always be ok, because even the slowest MSX can transmit a byte in 3 seconds... Actually flipping both D0 and D1 (happens only as transmission error) is what causes the protocol to hang in the first place. I can ofcourse make my protocol partially delay insensitive. But there is another problem: performance. If I put a timeout counter in the inner loop, the speed will suffer a lot. So now I'm thinking about using the interrupt to generate timeouts. That's true, although if you put it on the interrupt it won't take that mucht time. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JOYNET information and MISC
At 10:22 AM 4/29/99 +0200, you wrote: If you want, I can mail you my source for a communication protocol. It has one major problem though: it cannot recover from errors. Errors are rare, so for testing the protocol is OK, but there errors are just a bit too frequent (once in 80 megs if my memory is correct) to call this protocol reliable. By the way, Maarten, can't you indicate to the opposite computer that an error occurred by BOTH flipping D0 and D1??? (That can be used as an indication to restart the handshake-process...) And if you combine that with some timeouts... You should be able to let it recover from errors. My protocol is delay insensitive. You can't make a delay insensitive protocol and use timeouts at the same time. Actually flipping both D0 and D1 (happens only as transmission error) is what causes the protocol to hang in the first place. I can ofcourse make my protocol partially delay insensitive. But there is another problem: performance. If I put a timeout counter in the inner loop, the speed will suffer a lot. So now I'm thinking about using the interrupt to generate timeouts. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JOYNET information and MISC
On Tue, 27 Apr 1999, Martial BENOIT wrote:
Hello everyone,
Just have two questions:
1/ where to get the JOYNET BIOS and latest specifications for the cable?
On my homepage there is something like a BIOS:
http://fmf.fwn.rug.nl/~shevek
Bye,
/***Use_gcc_to_compile***Don't_mind_the_warning/
int*aaa ,v[ 9];int*main (){int i,j,s=1, k,z ,c[
]={1,4 ,7,4,3,4,6,4 ,1,1,1 ,2,
3,3,3, 4};;;;;;;for (i=0;i ++
9!k;s=-s){k=0;;scanf("%d" ,z) ;v[z]=s ;for(j
=0; j8 ;++j){ z=v[c[j]];k|=z ==v
[c[ j]- c[j+8] ](v[c [j]+c[ j+8
]]==zz); ;}}printf(" %d won\n",- s*k );}
/***Tic-tac-toe.use_0-8_to_play/
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JOYNET information and MISC
information and MISC Hello everyone, Just have two questions: 1/ where to get the JOYNET BIOS and latest specifications for the cable? The latest specs for the cable are on my official JoyNet homepage at http://datax.cjb.net/ Protocols are still in development, however I will try to finish one; but in a few days (before saturday) I will add a section to the page with proposings for a 2-computer and a network-protocol. Which you still have to program, ofcourse. Also, solutions for the "interrupt-problem" will be given (the standard MSX interrupt resets the JoyNet pins). ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JOYNET information and MISC
At 04:33 PM 4/27/99 +0200, you wrote: 1/ where to get the JOYNET BIOS and latest specifications for the cable? There is no such thing as a JoyNet BIOS (not yet, anyway). If you want, I can mail you my source for a communication protocol. It has one major problem though: it cannot recover from errors. Errors are rare, so for testing the protocol is OK, but there errors are just a bit too frequent (once in 80 megs if my memory is correct) to call this protocol reliable. Laurens also made a protocol, I don't know if his sources are avialable (either through WWW or my request). And there is the JoyDsk ROM, a diskROM-like program that enables you to use a PC like a disk drive through the JoyNet cable (DOS1 only at the moment). Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
JOYNET information and MISC
Hello everyone, Just have two questions: 1/ where to get the JOYNET BIOS and latest specifications for the cable? 2/ Anyone having information about a "MEGA" demo for year 2000 where 'old' MSX group are welcome to come and code their lest production for MSX? greetings, Martial. MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JOYNET information and MISC
Hello everyone, Just have two questions: 1/ where to get the JOYNET BIOS and latest specifications for the cable? From the page of Maarten ter Huurne and/or Laurens Holst. URL's are on The Ultimate MSX FAQ, ofcourse (misc section). 2/ Anyone having information about a "MEGA" demo for year 2000 where 'old' MSX group are welcome to come and code their lest production for MSX? Ask Roman v/d Meulen: "Meulen, R. van der" [EMAIL PROTECTED] Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/) PPS: Visit my homepage at http://www.sci.kun.nl/marie/home/manuelbi/ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Flaw in the JoyNet specification...
On Thu, 22 Apr 1999, Maarten ter Huurne wrote: At 04:19 PM 4/22/99 +0200, you wrote: People, I discovered a flaw in the JoyNet specification. Today, I went to the electronics-shop to buy some DIN5's, and there I discovered there are two types of DIN5-plugs: Din5 180 degrees and Din5 270 degrees. Which one is the one we use with JoyNet??? Maarten? Shevek? I hope it is Din5 180 for I bought four of those... Good! I have 180 degrees DIN5s too. (the same ones as used for MIDI) 'Flaw' is such an ugly word, I'd like to call it 'an undocumented feature' ;) Perhaps it was not clearly stated in the text, but I also got DIN5 180's The schemes I've drawn also noted these, altho never really specified in the text. It would be nice if Grauw put a little remark about this on his JoyNet homepage. Greetz, Patsie * . Email: [EMAIL PROTECTED] [note the anti-spam]. * () _ _IRC : Patsie . [IRCnet] | .| () . \_/ * . * . .|-O-| _/ \_ * Who said StarWars was dead! . * | | . * MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Flaw in the JoyNet specification...
People, I discovered a flaw in the JoyNet specification. Today, I went to the electronics-shop to buy some DIN5's, and there I discovered there are two types of DIN5-plugs: Din5 180 degrees and Din5 270 degrees. Which one is the one we use with JoyNet??? Maarten? Shevek? I hope it is Din5 180 for I bought four of those... Good! I have 180 degrees DIN5s too. (the same ones as used for MIDI) 'Flaw' is such an ugly word, I'd like to call it 'an undocumented feature' ;) *grin* Perhaps it was not clearly stated in the text, but I also got DIN5 180's The schemes I've drawn also noted these, altho never really specified in the text. It would be nice if Grauw put a little remark about this on his JoyNet homepage. I already specified "180 degrees" in the latest update (yesterday). Next time, I will add some graphics which show the difference too. In fact, I will add graphics of all connectors and their PIN-layout. Well, I don't know the DB25-layout, but I don know the others. I tried to send an example of a DIN5 180 and DIN5 270 with the email, and also a flyer about JoyNet for Tilburg, but it didn't arrive at the mailinglist (the strange thing is, it didn't get rejected either)(at least it didn't return into my mailbox). ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Flaw in the JoyNet specification...
People, I discovered a flaw in the JoyNet specification. Today, I went to the electronics-shop to buy some DIN5's, and there I discovered there are two types of DIN5-plugs: Din5 180 degrees and Din5 270 degrees. Which one is the one we use with JoyNet??? Maarten? Shevek? I hope it is Din5 180 for I bought four of those... I have attached images of both of 'em. Also, I have attached a flyer about JoyNet for Tilburg. If the connector has to be a 270 degrees connector this must still be changed. ~Grauw P.S. I hope to updated the official homepage... More after Tilburg. I will add some new things, like more info for programmers and a connectors overview. Email me: [EMAIL PROTECTED] Visit my (Grauw Datax') homepage at http://datax.cjb.net/ ... Live long and prosper MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Flaw in the JoyNet specification...
At 04:19 PM 4/22/99 +0200, you wrote: People, I discovered a flaw in the JoyNet specification. Today, I went to the electronics-shop to buy some DIN5's, and there I discovered there are two types of DIN5-plugs: Din5 180 degrees and Din5 270 degrees. Which one is the one we use with JoyNet??? Maarten? Shevek? I hope it is Din5 180 for I bought four of those... Good! I have 180 degrees DIN5s too. (the same ones as used for MIDI) Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet game at Tilburg 99
At 04:08 PM 4/20/99 +0200, you wrote: Yes ! Hey ! Everybody take your Joynet cables to tilburg and try to play the game with more than 4 players... I hope someone has a lot of 'real' JoyNet-cables, because mine is only a 2-computer cable (Since I only have 2 computers...) I have a real one. And components for a second, but I also have to fix some turbo Rs before Saturday, I don't know how much soldering I can cope with. Can everyone who is bringing JoyNet cables confirm this to the list? Then we know if we have enough to do some serious playing and we also know who to gather when we set-up the network. Also, is there anyone who is bringing a PC and who would like a demo of the JoyDsk ROM? In that case, I'll bring my PC JoyNet cable and ESE-SCC. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet game at Tilburg 99
On Wed, 21 Apr 1999, Maarten ter Huurne wrote:
Can everyone who is bringing JoyNet cables confirm this to the list? Then
we know if we have enough to do some serious playing and we also know who
to gather when we set-up the network.
I'm bringing 2, maybe 4 (real ones). But I need 3 of them myself...
Bye,
/***Use_gcc_to_compile***Don't_mind_the_warning/
int*aaa ,v[ 9];int*main (){int i,j,s=1, k,z ,c[
]={1,4 ,7,4,3,4,6,4 ,1,1,1 ,2,
3,3,3, 4};;;;;;;for (i=0;i ++
9!k;s=-s){k=0;;scanf("%d" ,z) ;v[z]=s ;for(j
=0; j8 ;++j){ z=v[c[j]];k|=z ==v
[c[ j]- c[j+8] ](v[c [j]+c[ j+8
]]==zz); ;}}printf(" %d won\n",- s*k );}
/***Tic-tac-toe.use_0-8_to_play/
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet game at Tilburg 99
Yes ! Hey ! Everybody take your Joynet cables to tilburg and try to play the game with more than 4 players... I hope someone has a lot of 'real' JoyNet-cables, because mine is only a 2-computer cable (Since I only have 2 computers...) I have a real one. And components for a second, but I also have to fix some turbo Rs before Saturday, I don't know how much soldering I can cope with. Ok, I'll buy some components and solder one. I will take my MSX with me (we, Datax, have a stand, although we have no products finished). Can everyone who is bringing JoyNet cables confirm this to the list? Then we know if we have enough to do some serious playing and we also know who to gather when we set-up the network. Also, is there anyone who is bringing a PC and who would like a demo of the JoyDsk ROM? In that case, I'll bring my PC JoyNet cable and ESE-SCC Well at least Delta Soft will take their laptop with them. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet game at Tilburg 99
I'll bring both my joynet cables with me. I might even consider taking my MSX turbo R with me to have something to plug the cable into :-) Though, I'm not going to stay all day long. I can leave the cables at the fair and come pick them up at five when the fair closes but I won't leave the computer there without me watching it. Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet game at Tilburg 99
Perhaps you (or somebody else) can show our Joynet game at Tilburg ? The laserbike-game??? Well, I will take my cable with me, and finding another computer shouldn't be too difficult either... I hope your name is in the source, otherwise I should write it down... Yes ! Hey ! Everybody take your Joynet cables to tilburg and try to play the game with more than 4 players... I hope someone has a lot of 'real' JoyNet-cables, because mine is only a 2-computer cable (Since I only have 2 computers...) I found a program called "RAMDISK.BIN" - That is the 'Mapper Ramdisk 2.14 by P. te Bokkel'. Maarten ter Huurne wants that program. Can you please mail it to him? I did send it to him. Thanks. Now I don't have to do that anymore. And no, afaik there is no never version of it. And for Dos1, it is the best program. It is much faster than the DOS2 ramdisk... Well, I never use a RAMDISK. Instead, I use a HD + Diskcache (LUNA). I reserved 1MB of my mapper for that... ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: our joynet game
At 12:28 AM 4/19/99 -0300, you wrote: Perhaps you (or somebody else) can show our Joynet game at Tilburg ? At MSX JAU 98 we had just 4 cables, so we played just in 4 people... Volunteers ? I can bring 1 cable (or 2 if I feel like soldering this week) but no computers or monitors. Who can contribute more JoyNet cables and computers and monitors? I found a program called "RAMDISK.BIN" - That is the 'Mapper Ramdisk 2.14 by P. te Bokkel'. It uses the Mapper RAM and the VRAM to create a RAMDISK (C:) in a MSX with two drives. Can you send it to me? Iwant to disassemble the part where drives are added, to improve the JoyDsk ROM. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 26-pin FDD, our joynet game Mapper Ramdisk
Perhaps you (or somebody else) can show our Joynet game at Tilburg ? At MSX JAU 98 we had just 4 cables, so we played just in 4 people... Volunteers ? The laserbike-game??? Well, I will take my cable with me, and finding another computer shouldn't be too difficult either... I hope your name is in the source, otherwise I should write it down... I found a program called "RAMDISK.BIN" - That is the 'Mapper Ramdisk 2.14 by P. te Bokkel'. It uses the Mapper RAM and the VRAM to create a RAMDISK (C:) in a MSX with two drives. Does anybody know if there is a better/newer version of this software ? Or another mapper ramdisk software (for those that don't have DOS2)? Maarten ter Huurne wants that program. Can you please mail it to him? And no, afaik there is no never version of it. And for Dos1, it is the best program. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet cables
I had the schematic for MSXPC JoyNet able but I lost the damn thing... Can somebody give it to me so I can put it on the official documentation-page??? I posted this design months ago: JoyNet cable for PC parallel port Pin-layout: SEND (DIN5 /m) RECV (DIN5 /f) GND 5 ---+- 5 GND D0 1 --+| +--- 1 D0 D1 2 ---+ || | + 2 D1 ACK 3 + | || | | +- 3 ACK | | || | | | | | || | | | 10 3 2 18-25 13 12 4 PC (DB25 /m) I don't know if it was accepted into the standard. But I can say that it works (built one and used it). Well, now it is. It was the only proposal, if someone had a better one he has had time enough to tell us. Hey, thanks! MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet cables
On Wed, 10 Mar 1999, Frengo wrote: On Tue, 9 Mar 1999 13:48:08 +0100 (MET), shevek wrote: Hi Shevek, Hi, As you might know, I am programming some things for the joynet. Of course I would like everyone to have one joynet-cable per computer. Great idea :-))) Two Question : 1) How about using the Joynet cable to connect the MSX also to a PC (parallel port) ? I know there was just a cable to do that, but I think that Joynet is a standard... I know cables like that have been made, although there is no standard about it. Actually, I don't really see the use of it... If you want power, you take a PC (or a unix, of course) and forget about MSX. If you want fun, you take a MSX (or some other cool home computer). 2) Why not programming something to read a PC hard disk from a MSX ? It would be useful for MSX with no IDE o SCSI interface... It would be really slow, it wouldn't work with normal things like disk-roms and it wouldn't even be that much cheaper. An IDE interface costs about 41 euros. A PC to MSX cable would cost about 8 euros. I agree the difference is 33 euro, which is not little, but if you want a harddisk, it is worth it... Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Joynet cables
Hi, As you might know, I am programming some things for the joynet. Of course I would like everyone to have one joynet-cable per computer. Many people will be able to make their own cables. A description can be found on the hmepage of Laurens Holst: http://www.geocities.com/SiliconValley/Lab/2328/joynet/joynet.html For people who can't/don't want to make their own cables, I am willing to make them. I will sell them at the fair (meeting, whatever) in Tilburg, but only to people who have reserved them. They will cost about 15 guilders (equals about 7 euros), maybe less. If anyone wants me to make cables for him/her, or has any questions, mail me. Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Joynet syncronous protocol
Hi Last week I read somebody was writing a synchronous protocal for joynet. At least that's what I would call it :-). The idea was to send data in packets, during which the interrupts are off. There are 3 ways I could imagine this being done: 1 - Synchronise both interrupts and start sending/receiving at interrupt time. 2 - Just start and wait for the other computer to react. 3 - Use a line-interrupt to synchronise to the other computer's main interrupt. This is really the same as the first one, but easier to implement. If you use the last option, it is possible that the interrupts are timed "wrong", so it is not possible to put a line-interrupt at the right spot. That means you have to count on a long wait time. This is even worse in case 2, of course. If you use that one, you should only send large packets, and not too often. This is not useful for all aplications (and games). The first option is the one my question is about. I know you can change the timing of the interrupt by switching between 50Hz and 60Hz, but this looks bad and I'm not sure how long both computers are timed equally. I think the 50/60Hz is not so accurate, that it stays synchronous for long. My question is: Is it possible to force a vertical interrupt on the VDP, so you can really have both interrupts synchronous? If it is, how is it done? Or is there some other way to do it? Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
At 08:45 PM 3/3/99 +0100, you wrote: Don't bother about Dos, you can just copy it, who cares? And it's very easy to use! By the way, you can redefine ALL RSTs in the Dos-environment. None of them is reserved, exept perhaps the one of the interrupt but you can replace that one too. What about the inter slot call? That's one RST you'd better not redefine. For example, the H_KEYI handler in the NMS8250 uses it. Ain't that #24??? ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
On Thu, 4 Mar 1999, Patriek Lesparre wrote: Shevek wrote: And well, I have my own page-0 routines already anyway. Including memory manager, device manager and string handling routines. Now you're calling it a device manager yourself too, eh? ^_^ You were right it is pretty confusing to call it a file manager. And I am always open for good suggestions :-) Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
At 01:35 PM 03/06/99 +0100, you wrote: Don't bother about Dos, you can just copy it, who cares? And it's very easy to use! By the way, you can redefine ALL RSTs in the Dos-environment. None of them is reserved, exept perhaps the one of the interrupt but you can replace that one too. What about the inter slot call? That's one RST you'd better not redefine. For example, the H_KEYI handler in the NMS8250 uses it. Ain't that #24??? #24 is EnaSlt (slot switch routine) #1C is the inter slot call you mean There are two inter slot calls, the other one is an RST which is used like this: RST #30 db SLOT_ID dw ADDRESS So, you cannot redefine all RSTs under DOS. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
At 03:04 PM 03/06/99 +0100, you wrote: What about the inter slot call? That's one RST you'd better not redefine. For example, the H_KEYI handler in the NMS8250 uses it. ARGH! That is bad... Well, I'll just make sure BIOS is switched in page 0 when I call it. That doesn't happen very often anyway, only when I want to stop the diskdrive. Reading from disk may also need an inter slot call (if your machine contains more than 1 diskROM, for example when you use DOS2). One tip for when you enable the BIOS only when accessing disks: make sure that if DOS2 is present, you call "invalidate disk buffers" before you load. Disk buffers are a kind of cache. It is automatically invalidated after a certain time (less time than any human takes to swap a disk). But if you no longer call the normal interrupt handler, time "freezes" for it. So DOS2 will always think the disk buffers are valid, even though it's possible the disk has been changed in the time its interrupt handler wasn't called. You can solve that problem by always invalidating disk buffers when you start a series of loads. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
] But, as I understand now, you're not writing a universal driver... *snif*... Don't cry too loud. I'm still working on a universal driver. Though, I'm first finishing a different project: Helping Marat in improving the vdp emulation of fMSX. The improvements made up to now have already lead to a good working sd-snatcher! Though, the work is not finished yet, so you all have to be patient. After I'm done with the VDP emulation improvements, I'll continue my work on the universal joynet drivers. And are you going to make use of my idea, so that the BIOS doesn't change the joystik-pins anymore??? And are you going to make a Basic-driver using CMD too??? ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
At 08:42 PM 3/3/99 +0100, you wrote: Now you can make a nice hook which sets SCNCNT to 255 so that the BIOS key/joy-routines aren't used, and then run a copy of the keyboard-routine and add a Joystick-routine which doesn't affect the JoyNet pins... Hey, you got that??? Now you don't even have to do difficult things to a *complete new* interrupt-routine, you can still use your own, and IT WORKS UNDER BASIC!!! And Basic is cool because you can then easily program little test-progs or small games etc... Good idea of me, eh??? Well, you can use BASIC unless you need to read the keyboard. Making for example a simple chat program is not possible. Also, I am not sure it will work on every MSX. A different option is to make a protocol that always ends in the state with the data bits 1 and the strobe 0. That's how I solved the BIOS problems in my implementation. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
At 08:45 PM 3/3/99 +0100, you wrote: Don't bother about Dos, you can just copy it, who cares? And it's very easy to use! By the way, you can redefine ALL RSTs in the Dos-environment. None of them is reserved, exept perhaps the one of the interrupt but you can replace that one too. What about the inter slot call? That's one RST you'd better not redefine. For example, the H_KEYI handler in the NMS8250 uses it. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
] ] But, as I understand now, you're not writing a universal driver... ] *snif*... ] Don't cry too loud. I'm still working on a universal driver. Though, I'm ] first finishing a different project: Helping Marat in improving the vdp ] emulation of fMSX. The improvements made up to now have already lead to a ] good working sd-snatcher! Though, the work is not finished yet, so you all ] have to be patient. ] ] After I'm done with the VDP emulation improvements, I'll continue my work ] on ] the universal joynet drivers. ] ] And are you going to make use of my idea, so that the BIOS doesn't change ] the joystik-pins anymore??? No. I'm making a package based protocol. During the transfer of a single package, the interrupts must remain switched off. The transfer of a package is initiated via a handshake protocol. As a result, it does not matter what happens with the signals at the moment that I'm not transferring data. ] And are you going to make a Basic-driver using ] CMD too??? There is going to be a basic driver. Most probably a memman tsr. I do not know yet if I will use the CMD hook or that I will use the USR command. Anybody any preference? Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
I recently took a look (- :) -) at the BIOS, and I saw that it only looks at the Keyboard when the keyscan-counter SCNCNT reaches 0. What computer was that? I looked into the bios of my NMS 8250 (not recently, ok) and I'm pretty sure it reads the keyboard every vdp-interrupt. Hey, I just found the solution! I'll just switch off the interrupts, using vdp(1). When my program returns from the dos-call, I can switch them on again. :-) Nope... it doesn't read it every interrupt. Every 3rd interrupt (in the normal case). Check it out! Here, this is what the BIOS does: ld hl,#F3F6 ;SCNCNT dec (hl) jp nz,#0D02 ;END_INT blahblah... My solution ALWAYS works, yours only in a specially adapted Assembly-program. Imagine: Someone has written a great Tetris-like game which is extremely fit for use with JoyNet. One problem: he already finished the program, which still uses the BIOS-interrupt, and he doesn't want to have too much work on it (ie. he doesn't want to write a complete new interrupt). Then it's useful to have such a driver ready. But, as I understand now, you're not writing a universal driver... *snif*... Hey, you got that??? Now you don't even have to do difficult things to a *complete new* interrupt-routine, you can still use your own, and IT WORKS UNDER BASIC!!! And Basic is cool because you can then easily program little test-progs or small games etc... Good idea of me, eh??? The idea is good for small things. But actually, I was planning to make big things. Sorry, I mean BIG, or even HUGE. And well, I have my own page-0 routines already anyway. Including memory manager, device manager and string handling routines. I want to add my joynet routines in it. I also will add a multitasker soon. Those are not the kind of things you want to run under BASIC, or with BASIC switched in memory... Yeah ok but I was talking about a universal driver. Using this trick you can easily implement it in other programs; you don't need to write an entire new interrupt. But thanks for the help. Now I do have the answer anyway :-) Indeed, switching off the interrupts is a good idea too. Hey, you know what? I'll add those triks to the JoyNet-page... Now I'm going to do that, has anybody else written (but not yet programmed) (or programmed, even better!) some "protocols" for JoyNet??? I have made a comm-protocol for 2 computers using JoyNet, and a ring connected-protocol which detects if the ring is closed. However, I still haven't made up a protocol which determines how many computers there are and which assigns the computers a number... ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
On Thu, 4 Mar 1999, Laurens Holst wrote: Yeah ok but I was talking about a universal driver. Using this trick you can easily implement it in other programs; you don't need to write an entire new interrupt. That is true, but if you want to use your memory optimal with multiple tasks, it gets pretty unorganised and you might have other programs overwriting your hook, or something. Indeed, switching off the interrupts is a good idea too. Hey, you know what? I'll add those triks to the JoyNet-page... Now I'm going to do that, has anybody else written (but not yet programmed) (or programmed, even better!) some "protocols" for JoyNet??? I have made a comm-protocol for 2 computers using JoyNet, and a ring connected-protocol which detects if the ring is closed. However, I still haven't made up a protocol which determines how many computers there are and which assigns the computers a number... I have done that. I'm planning to write a small program, that should be loaded from cassette on a MSX without a diskdrive and that will read a program from the net and execute it. In the protocol I use, it is nessecary that every computer knows it's ID, so it is also sent (and incremented by every computer is passes). Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
Shevek wrote: And well, I have my own page-0 routines already anyway. Including memory manager, device manager and string handling routines. Now you're calling it a device manager yourself too, eh? ^_^ Greetz, Patriek [EMAIL PROTECTED] ,-. ,. ,-. TNI on the web: | '-.| ,-. \ '-' http://www.xs4all.nl/~newimage/ Member of| ,-'| | | | ,-. The New Image | '--' | | '-' | Check out "MSX Banzai!" at: since 1991`--' '-' http://www.xs4all.nl/~newimage/MSXBanzai!/ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
] But, as I understand now, you're not writing a universal driver... *snif*... Don't cry too loud. I'm still working on a universal driver. Though, I'm first finishing a different project: Helping Marat in improving the vdp emulation of fMSX. The improvements made up to now have already lead to a good working sd-snatcher! Though, the work is not finished yet, so you all have to be patient. After I'm done with the VDP emulation improvements, I'll continue my work on the universal joynet drivers. Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
-Oorspronkelijk bericht- Van: shevek [EMAIL PROTECTED] Aan: [EMAIL PROTECTED] [EMAIL PROTECTED] Datum: dinsdag 2 maart 1999 22:42 Onderwerp: Re: Joynet and BIOS On Tue, 2 Mar 1999, Laurens Holst wrote: The MSX BIOS changes the pins of the joystickport while reading the joystickports. Therefor, you can only send/recieve while interrupts are disabled, or -I perfer this option- you can write your own interrupt-routine which doesn't modify the pins of the joystick-port on which JoyNet is connected. Of course, that is what I do as well. But when I want to access the disk (BDOS), I need to have the bios in page 0 (or at least the slot switching routines). I don't have them in my own 0-page code, or at least not in a dos-compatible way. (They will be dos2-compatible, but they don't switch the usual way on rst 20). So does the BIOS always switch 1's in the buttons and a 0 in the strobe, or is it random? Use Dos... :) ...or... Information about SCNCNT (#F3F6): A counter which keeps track if the keyboard has to be scanned on a VDP-interrupt. This counter is ontrolled by the VDP-interrupt. The value of this counter goes from 3 to 0; if zero is reached then the keyboard is being scanned SCNCNT (ScanCount) is reset to 3. I recently took a look (- :) -) at the BIOS, and I saw that it only looks at the Keyboard when the keyscan-counter SCNCNT reaches 0. If the counter isn't 0 then the BIOS jumps to the end of the hook immediately. But the Joystick read-routines are AFTER the Keyboard-routines so you should be able to (temporarely) disable the Joystickroutines (and the keyboardroutines!!!) by setting SCNCNT to a high value like 255, then it waits 255 interrupts before the next keyboard/joystick readout... Now you can make a nice hook which sets SCNCNT to 255 so that the BIOS key/joy-routines aren't used, and then run a copy of the keyboard-routine and add a Joystick-routine which doesn't affect the JoyNet pins... Hey, you got that??? Now you don't even have to do difficult things to a *complete new* interrupt-routine, you can still use your own, and IT WORKS UNDER BASIC!!! And Basic is cool because you can then easily program little test-progs or small games etc... Good idea of me, eh??? Ofcourse, I'm not sure if this works on every MSX since I can't test it, but I really think it will work... ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joynet and BIOS
I don't want to call it from the dos-prompt, because I am not allowed to distribute the game with dos included. I prefer to have my own "bios" in page 0, because I have rewritten more than just the interrupts. I make use of all the RST commands a lot more efficient then the bios does. Therefor I would really like a way in which I can keep my own RAM in page 0... Don't bother about Dos, you can just copy it, who cares? And it's very easy to use! By the way, you can redefine ALL RSTs in the Dos-environment. None of them is reserved, exept perhaps the one of the interrupt but you can replace that one too. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
