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 however. It should be used. I did not talk about it yet, since I forgot about it. It
Re: Programming external modems with MSX
Send a PAP auth request. If they deny it, shutdown the line. :) NO! Servers supporting it will also deny it. Instead, reply (as said) with a NAK to the PPP Configuration_Request. And in fact this is correct. If an authentication protocol should be used is pretty much the choice of the ISP. If the ISP receives a PAP AuthReq, and don't like it, it should NAK it, not REJ it... Ofcourse, you are right. But somehow sending an Authentication Protocol Option it is being rejected on all the ISP's I tried. So it's best to passively wait for one (mind you, I am talking about the option in the Conf_Requests here, not about the PAP protocol itself!) Hehehehehe... C is cool... :) Assembly is fast. I know. But maintaining an assembly code is hard. I am a Z80 assembly programmer. Except for that I hardly know how to code C (on an MSX), I chose Assembly because I have absolutely no idea how fast the MSX is exactly when it's about modems, and I don't want problems with the MSX not keeping up with the modem. ~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: Programming external modems with MSX
The primary site is here: ftp://cs.anu.edu.au/pub/software/ppp/ Various components of this package have different licences (GPL, BSD, other). Anyway, I'll send the file directly to Laurens. Just to avoid questions like "how do I unpack .tar.gz?"... ;) Bwoa, WinZIP does that. But you are right, it is a nice question if you never used a Unix clone. ~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: Last News over me works (MIMAS Architecture at 8 / 29 / 2.000).
Perhaps that I was confused. As far as I know, there is a Z380 project to build a new 32-bit MSX and another Z380 project to make a Z380 card to be inserted into an existing MSX. I thought that the above mentioned project was the Z380 card project. But maybe I'm mistaken. I should better look this up in the MSX hardware list on "The MSX Plaza" ;-) Both are the same project. You can use z380 card with MSX or alone as part of the MMSX project. If you put a LPE Z380 card in an Evolution4 expander, and put another card in it with all standard MSX peripherals like VDP, PSG, Keyboard-interface, Joystickports, etc. Then you've got a new MSX. Such a card is now easier to make since it appeared the v9958 is still available, and most other devices have already been created in FPGA form by Ademir and ESE etc. However, it seems very hard to co-operate on this point. ~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)
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: 7MHz in A1WX
Very interesting. So this MSX2+ has a Z80H instead of a Z80A? No, this MSX2+ have a Z80B, and it can run on 6MHz mode, and don't on 7 MHz. Roberto Vargas Caballero Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: Last News over me works (MIMAS Architecture at 8 / 29 / 2.000).
However, it seems very hard to co-operate on this point. Sad but true. I don't want to end up with three new types of new MSX computers, you know... Greetz, Sander Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
6MHz in A1WX
-Alkuperäinen viesti- Lähettäjä: Manuel Bilderbeek [EMAIL PROTECTED] Vastaanottaja: [EMAIL PROTECTED] [EMAIL PROTECTED] Päivä: 4. syyskuuta 2000 3:07 Aihe: Re: 7MHz in A1WX Correct way to change 3.5 MHz to 7MHz mode in Panasonic A1WX (MSX 2+) is: OUT 64,8:OUT 65,0 Very interesting. So this MSX2+ has a Z80H instead of a Z80A? Robertö Caballero answered already. He gave you right information (in speed, too. Sorry). And it is only software-switchable? Yes Is this feature documented in that machine? No, I have only those japanese user's manuals witch were delivered with the computer. I cann't find a word of it. I have no technical manual/guide for it, but I doubt it's not mentioned officially anywhere. Does any software use it? As far I know the answer is No regards Ahti Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
RE: Last News over me works (MIMAS Architecture at 8 / 29 / 2.000).
Hi all However, it seems very hard to co-operate on this point. Sad but true. I don't want to end up with three new types of new MSX computers, you know... which three new types? I only have seen one ;) Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
RE: Last News over me works (MIMAS Architecture at 8 / 29 / 2.000).
Hi Laurens Perhaps that I was confused. As far as I know, there is a Z380 project to build a new 32-bit MSX and another Z380 project to make a Z380 card to be inserted into an existing MSX. I thought that the above mentioned project was the Z380 card project. But maybe I'm mistaken. I should better look this up in the MSX hardware list on "The MSX Plaza" ;-) Both are the same project. You can use z380 card with MSX or alone as part of the MMSX project. If you put a LPE Z380 card in an Evolution4 expander, and put another card in it with all standard MSX peripherals like VDP, PSG, Keyboard-interface, Joystickports, etc. Then you've got a new MSX. Such a card is now easier to make since it appeared the v9958 is still available, and most other devices have already been created in FPGA form by Ademir and ESE etc. Padial is working on these boards with FPGA technology. See the others emails from him. With only software patchs you can run your LPE-VDP Card as a v99xx. And same with Sound board. However, it seems very hard to co-operate on this point. In my opinion is very dificult. Regards Airam Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: Last News over me works (MIMAS Architecture at 8 / 29 / 2.000).
which three new types? I only have seen one ;) You know what I mean. A lot of people are creating new computers based on the MSX standard Some use Z180, others Z380, etc. etc. etc. In order to keep MSX a standard like it always has been, these developers need to contact each other and share their knowledge. Greetz, Sander Zuidema Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: 7MHz in A1WX
Correct way to change 3.5 MHz to 7MHz mode in Panasonic A1WX (MSX 2+) is: OUT 64,8:OUT 65,0 Very interesting. So this MSX2+ has a Z80H instead of a Z80A? And it is only software-switchable? It is switchable trough the MSX-Engine. And I think it is 6MHz, not 7Mhz Un saludo, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) ¡Suscríbete a HispaMSX! http://www.egroups.com/group/hispamsx [EMAIL PROTECTED] msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: 6MHz in A1WX
On Mon, 04 Sep 2000, you wrote: Does any software use it? As far I know the answer is No I think Kyokugen supports it. You can select CPU speed from 3.56MHz, 6MHz and R800. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
RE: 6MHz in A1WX
Hi I think Kyokugen supports it. You can select CPU speed from 3.56MHz, 6MHz and R800. Yes, kyokugen supports 6 Mhz on A1WX. Regards Airam Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
RE: Last News over me works (MIMAS Architecture at 8 / 29 / 2.000).
Hi which three new types? I only have seen one ;) You know what I mean. well... A lot of people are creating new computers based on the MSX standard Some use Z180, others Z380, etc. etc. etc. In order to keep MSX a standard like it always has been, these developers need to contact each other and share their knowledge. I think it too. But Brasilian developper (Ademir Charcano) don't have time to it. For example: I was trying to contact with Ademir to bougth some of his hardware and to ask to him about his prices in Euros and I never seen a reply of him :(. Regards Airam Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: Programming external modems with MSX
I know. But maintaining an assembly code is hard. I am a Z80 assembly programmer. Except for that I hardly know how to code C (on an MSX), I chose Assembly because I have absolutely no idea how fast the MSX is exactly when it's about modems It follows the golden rule: You network connection is allways slower than your computer. :) Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * Bill Gates, have 'em write _real_ code... * 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 discussion. UZIX can be useful to test
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: 6MHz in A1WX
On Mon, 04 Sep 2000, you wrote: Does any software use it? As far I know the answer is No I think Kyokugen supports it. You can select CPU speed from 3.56MHz, 6MHz and R800. But this is not standardized, is it? IT would be nice if all MSX computers could be switched to higher clockrates in a standardized software way. How about the sound-quality? Is still as normal I guess, while running on 6MHz? If indeed so, this method should be used on all MSXs running on 3.5MHz! Is this 6MHz circuit comparable to the hobby-7MHz circuits? Also switching back for VDP access and such? Best regards, Manuel --- Pre-PS: After 30/9/2000, I cannot use this address anymore. Therefore, from 25/9/2000, please send all mail to [EMAIL PROTECTED], my always- valid address. I can also read that mail from here in Japan. Thank you. PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/ ) PPS: Visit my home page at http://bilderbeek.cjb.net/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
