Re: Wanted! Programs that don't run in any MSX emulator
Hi, As far as I know, the best way to make programs to detect an emulator, is checking the VDP timing. So do a copy, and see how much time it takes to finish. Something like that. Bye, shevek On Thu, Mar 14, 2002 at 01:48:44PM +0100, Manuel Bilderbeek wrote: Hi all! I wondered if there are programs (e.g. games) that won't run (correctly) on any MSX emulator (so far)... If you know some, please let me know! Of course, if the program uses GFX9000 or Moonsound, it won't run correctly, but no single emulator has implemented these devices, so that doesn't really count. If there are none, can you tell me what programs are really troublesome and work in only very few emulators? Just give me a list of programs that give *big* problems in emulators, please! :-) Also, I remembered someone had once written a program that could tell whether it was running in an MSX emulator or not. Does this exist? I'd like to have it if it does... In case it doesn't: can anyone make such a program? Thanks! -- Grtjs, Manuel PS: MSX 4EVER! (Questions? See http://www.faq.msxnet.org/) PPS: Visit my homepage: http://bilderbeek.cjb.net/ -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Z8530
I hope UZIX doesn't crash from the buffer overrun? It probably will. But buffer is in high memory area, just before MSX system variables. A big buffer overrun will trash system vars and hangs MSX. It should just drop the data I'd say. If you have TCP connections, that should not be a problem at all. I don't like this approach. With Sunrise IDE, when the buffer is full, I clear the DTR signal and the other host stop sending bits until the buffer has some space available (when the DTR signal raises again). I don't loose data and eveything goes fine. Well, of course you should do that as well. But if it gets ignored and you receive data anyway, then this data should not overwrite anything important. In the linux kernel this aproach would generate an oops, which is considered pretty bad. Bye, shevek -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Z8530
On Wed, Mar 13, 2002 at 05:19:45PM -0300, Adriano Camargo Rodrigues da Cunha wrote: Well, of course you should do that as well. But if it gets ignored and you receive data anyway, then this data should not overwrite anything important. In the linux kernel this aproach would generate an oops, which is considered pretty bad. It's obvious. But remember that MSX has no memory protection. Ignoring data if buffer is full is my last option. If I can't make Z8530 understand the DTR signal, I'll do it. The point is that it is not the Z8530 which has to react. The other computer can just ignore the signal if it feels like it. This should in no case cause data corruption. The fact MSX does not have memory protection and can therefor not be really secure, doesn't mean you shouldn't implement any other checks. You should try to follow the protocol. But if the other computer (which runs untrusted code, in general) doesn't follow it, the MSX should just handle that. That's just good programming practice. Bye, shevek -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Z8530
On Tue, Mar 12, 2002 at 05:01:23AM -0300, Adriano Camargo Rodrigues da Cunha wrote: Hi, Anyone here knows the Z8530 Serial Controller Chip? I'm working on a driver for it for UZIX, but I'm having a problem: clearing the DTR bit (register 5) doesn't make the host stop sending bits to MSX, so I get a buffer overrun and nice CRASH. Any help? Thanks, Hi, I don't know this chip, but I know serial lines in general. Hardware handshake is usually not switched on by default. If you have XON/XOFF handshake, you should send a ^S to stop the data and a ^Q to restart it. This is the more usual approach. The reason is that some serial cables don't actually have conducting lines on the handshake pins. By the way: To be sure, you can just measure the voltage on the pins. The pinout is on several places, among which is the text-terminal-HOWTO for linux. I hope UZIX doesn't crash from the buffer overrun? It should just drop the data I'd say. If you have TCP connections, that should not be a problem at all. Bye, shevek -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
RE: v9938 databook...
I have a pretty good photocopy (at least most of it is pretty good...)
I'll take it with me to Tilburg. Where can I find you?
On Tue, 27 Mar 2001, Hans Otten wrote:
Yes, with the right software (Finereader for example) ocr scanning is a very
mature solution of getting text into editable format again.
But you need quality scans or the original paper and a scanner. The 9938
scans made by Sean Young are too low quality for ocr software.
So if someone has good scans or good original or photocopies...
Hans
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: v9938 databook...
Laurens Holst wrote:
I am manually entering the contents of the v9938 databook into a textfile.
just to let you know, in case someone else is also doing this.
current progress: page 11 of 161 (bareuh...).
This sounds like a very good initiative. But it will take a lot of (your)
time. Isn't there good software nowadays to read graphics into text (I
think it's called OCR or something, but I never used it) ? It may be worth
checking out...
Bye,
shevek
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: How To Get The Murderer of Grison?
On Tue, 13 Feb 2001, Maarten ter Huurne wrote:
I found that I need to hit the slot machine with 3
snatchers' head, then I can get pass the VIP room.
However, I can't do it! It is so hard to hit 3
snatchers' head in the slot machine.
The three snatcher heads are no coincidence: you will always get them after a
few rounds of playing the slot machine. That is, once you have progressed far
enough in the storyline. Before that, it's impossible to get three snatchers,
no matter how long you try.
There is something else you should do first, probably talk to someone or
visit some place in the same town where the casino is. I don't remember what
is was, sorry.
IIRC you should go into the bulding with the CD advertisments first. It's
in the northeast of south downtown. It's a pretty long way before you come
back to the casino.
You asked for a walk-through. There probably is one, but I wouldn't want
it if I were you. The reason this game is so good is mostly because it
gives you the feeling you found out the secrets yourself. If you just
follow the recipe, it would be much less fun.
Bye,
shevek.
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Enanito si, pero con que pedazo!
On Tue, 19 Dec 2000, Sean Young wrote:
On Tue, Dec 19, 2000 at 03:50:07PM +, Maarten ter Huurne wrote:
The MSX mailinglist server only checks for large messages, so small
attachments can slip through. The list is migrating to a different list
server program soon, hopefully with that new software we can disallow all
attachments.
IMHO it would be nice if html messages could be blocked aswell. :)
YES! But html is usually sent as attachment, so most of them will be
blocked thus ;)
Bye,
shevek
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: [OT] Merry X-Mas happy newyear and stuff
Ok, in this case we would want it to let it through, but I bet this filter
catches a lot of spam as well...
Bye,
shevek
On Tue, 19 Dec 2000, by way of Maarten ter Huurne [EMAIL PROTECTED] wrote:
Hi,
And sometimes the mailinglist filters too strong... The following message
from Eric Boon was bounced because it contained the word "un-subscribing".
The hyphen is mine, otherwise this message would be bounced as well. ;)
Bye,
Maarten
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: PSG R#14 bit 6?
On Wed, 22 Nov 2000, Alex Wulms wrote:
] Everything I know is that this bit was used by MegaSCSI in some
] some apps to "blink" the Kana Led (according to the program manuals).
So the answer is that the bit is used for the KANA led, to make it burn or
not burn.
Please remember you're talking about register 14 of the PSG. By writing to
this register you may permanently damage your MSX. So it is definitely not
used for setting a bit...
Bye,
shevek
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: PSG R#14 bit 6?
On Tue, 21 Nov 2000, Maarten ter Huurne wrote:
"0" for syllable layout; "1" for JIS layout
Syllable is not just letters, but special groups ("lettergrepen" in Dutch).
For example, "syllable" itself contains syllables "syl", "la" and "ble".
JIS is "Japanese International Standard", it encodes the latin alphabet,
kanas and kanji.
What I meant, is that I don't know what MSX hardware function this bit
controls.
Perhaps there are two types of japanese keyboard (as europeans have
querty/azerty keyboards). If this is the case, this bit could be read to
check the attached keyboard type.
Perhaps someone who owns a japanese computer can test this. If you can't
write your own test program, let me know and I'll do it.
Bye,
shevek
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: PSG R#14 bit 6?
On Mon, 20 Nov 2000, Daniel Jorge Caetano wrote:
On Mon, 20 Nov 2000 01:29:34 +0100, Sean Young wrote:
According to Portar.txt bit 6 of PSG register 14 is "On japanese machines only".
It's not the KANA led, that's bit 7 of PSG register 15. Does anyone know what
that bit does? The MSX redbook doesn't say anything. The dutch "MSX Handboek
for gevorderden" says the same as Portar.txt. Does anyone know what it is?
Do Japanese MSX computers have an extra key? (The KANA key seems to be the
same as the CODE key on international MSXes).
Yes, it is... except by the fact the "code" in the Japanese Machines
can be locked, in the same way Caps Lock. The "Code Lock" key was
called Kana Key... and when it's locked, the mentioned bit (6) will
be activated...
Caps lock is locked in software. This explanation makes me think it is not
possible to (re)set the state of the kana key in software. Is this
correct? What is the reason for making it a hardware switch?
Bye,
shevek
---
/** mastermind. input 4 numbers 0-5. output right.in the right place **/
main(){int c[4] ,x=3 ,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) ;};}
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
GFX9000 and IDE interface
Hi,
Some time ago, I had a big mess on my desk which accidentally removed half
of my IDE cartridge from my msx (a philips nms8220). In the other slot I
had my gfx9000. I didn't notice, so I switched it on and didn't get
anything useful on the screen. So I checked it out and found the problem.
The fuse in the msx was also blown, so I have to replace that. I tried the
IDE in an other msx (a 8250). It still works well. But the gfx9000 does
not. For the msx, it reacts normal (I can read/write registers and
memory), but it doesn't give any display on the screen. I think I blew up
the D/A-convertor or something. Does anyone know if this problem can be
solved (possibly for little money)?
Thanks for the help/attention.
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: File crypter
On Wed, 27 Sep 2000, pepito sbazzeguti wrote:
Hello!
I've found on the net explaination about DES (Data Encryption Standard) and
I've implemented it in MSX-C.
Do you think a file de/crypter could be useful?
Sure. An encrypted filesystem would be even better, though ;)
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: hardware question
On Tue, 26 Sep 2000, Gerrit van den Berg wrote:
Hi,
I want to include the PS2 mouse with the PC keyboard. I have the SW
for the mouse in digital data style. What are the pulses in Forward,
Back, Left Right pins 1, 2, 3, 4 of the MSX analogic mouse? With
this info I can finish the analogic emulation (*) and then the new PC
Keyboard can include : Mouse Analog/Digital connection, one/two
joystick ports and PSG with stereo power amplifier with digital volume
and input for Audio CD... (see LPE-PSGM-V1).
Are you actually talking about analog MSX mice? I don't know about their
existance (and I can't think of how they could be implemented, given the
MSX hardware). So I shall stick to the digital MSX mice.
The mouse is always in one of 4 states, which are degenerate in pairs
(undistinguishable, or at least allmost). The mouse has 4 bytes of
internal memory, 2 of which keep the X and Y movement since the last
readout and 2 which are needed for output buffering.
When the mouse is in state 0, the strobe is 0. This is the state it should
be in when interrupts are enabled, and the mouse is not currently read
out.
Flipping the strobe to 1 sets the mouse in state 1. This causes the 2
bytes of memory to be copied into the output buffers. After a little time,
the low nibble of the X movement can be read out on pins 1-4 (up, down,
left, right).
Flipping the strobe back to 0 sets the mouse in state 2. This state is
degenerate with state 0, because the MSX can only see the state of the
strobe. While being in state 2, the pins 1-4 contain the high nibble of
the X movement.
The same thing can be done twice more. Flipping the strobe sets the mouse
to state 3 and the pins 1-4 to the low Y movement nibble. Flipping it
again returns the mouse in state 0 and leaves the pins 1-4 to the high Y
nibble movement.
A nibble is put on the pins 1-4 with MSb on pin 4 and LSb on pin 1, so it
is in the correct order when read out by the MSX.
I hope this helped you. If I didn't answer the question you meant to be
asking, please rephrase it and I'll try again.
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, 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: Good news/Bad news
On Fri, 15 Sep 2000, Sander Zuidema wrote:
Hello everybody,
First the good news: I have more than 100 V9958 chips sold. Everyone who has
ordered will get details by the end of this week.
Cool!
The bad news: I'm currently rather ill, so I'm afraid I will
not be able to go to Zandv.. err.. Bussum.
That is a pity. I am moving to a different room myself, so I must use all
my time to paint the walls and decorate the place. Therefore I will also
not be there :( Hope you all have a good time though!
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: News from the CTNG lab :-)
On Wed, 13 Sep 2000, Jon De Schrijder wrote:
The assembly process will also be much faster since the code is already
assembled as much as possible when you are editing. Exact timing results
are not known yet, but I've already measured 2 seconds for Pass1 of a
source of 8000 lines without labels. (7MHz MSX2) Who will need a
cross-assembler ? ;-)
I happen to LOVE vi :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)
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: The MSX Z80 assembler
On Fri, 8 Sep 2000, David Heremans wrote:
If you are reading sectors and you see each byte as octal you can read
Z80 ml much more easilly.
For example with 101 then you can see directly that it means "ld a,b"
The entire Z80 is verry octal based in its opcode structure.
True, except that 101 is `ld b,c':
0 b
1 c
2 d
3 e
4 h
5 l
6 (hl)
7 a
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: The MSX Z80 assembler
On Tue, 5 Sep 2000, Maarten ter Huurne wrote:
On Tue, 05 Sep 2000, you wrote:
The way numbers are written may be
different. Here's how my assembler does it:
starting with a number 0-9, a hexadecimal number is expected.
starting with %, a decimal number is expected.
starting with @, an arbitrary base (2-36) number is expected. first
character is the base (10-1 in the desired base), the rest is the number.
eg to write an octal number, you can use @7nnn. @fxx is an alternative way
of writing hexadecimal numbers.
That makes sources for your assembler incompatible with every other assembler
out there...
H, ok. I can easily make it user defined. It would indeed be a good
idea.
Who need numbers in an arbitrary base anyway? Hexadecimal, decimal and
binary are enough. Octal is supported by many languages, but it is rarely
used in practice (the only use I know is Unix file permissions).
Arbitrary base is easily implemented and might be useful in some cases. I
don't know when really. But I want to give the possibility.
Second thing is that I want header files for use with the assembler. I
want it to be used in combination with the gcc preprocessor, so #includes
can be made. Those header files should contain system variables, bios
addresses, i/o-port numbers, etc. If anyone is interested in writing them
(or help improving the source of the assembler), mail me directly or via
sourceforge.
I have a couple of header files already (for the BIOS, SubROM and hooks).
I'll mail them to you.
Thank you.
Please don't use the C system for header files. It is better to make
the assembler remember which header files are already included and
don't process a single header file twice.
I preprocess the source with gcc -E -P -C. Of course this implies that I
do use the C system for header files. I just don't feel like rewriting the
whole preprocessor again, while I do want its full functionality.
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, 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/
The MSX Z80 assembler
Hi,
For those of you who know sourceforge: I just started a new project there,
called `the MSX Z80 assembler'. It is an opensource initiative to make a
cross assembler with the MSX as target platform. Currently it is written
in C, POSIX compiant I hope.
I still need 2 things to be done though. I will post it via sourceforge as
well, but I think people owning an MSX know more about it and therefore
will be more helpful.
First thing is that the assembler needs to be tested. If anyone has a
large piece of code to run through the assembler and then diff it with a
binairy made with a `trusted' assembler, I would be very happy. However,
there is more to it then just that. The way numbers are written may be
different. Here's how my assembler does it:
starting with a number 0-9, a hexadecimal number is expected.
starting with %, a decimal number is expected.
starting with @, an arbitrary base (2-36) number is expected. first
character is the base (10-1 in the desired base), the rest is the number.
eg to write an octal number, you can use @7nnn. @fxx is an alternative way
of writing hexadecimal numbers.
Second thing is that I want header files for use with the assembler. I
want it to be used in combination with the gcc preprocessor, so #includes
can be made. Those header files should contain system variables, bios
addresses, i/o-port numbers, etc. If anyone is interested in writing them
(or help improving the source of the assembler), mail me directly or via
sourceforge.
Thank you for reading and I hope you all like the initiative. If you have
any comments whatsoever about the assembler, please mail me personally or
place a message in the forum on the site.
my project can be found on http://sourceforge.net/projects/msxz80asm
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: The MSX Z80 assembler
On Tue, 5 Sep 2000, Laurens Holst wrote:
For those of you who know sourceforge: I just started a new project there,
called `the MSX Z80 assembler'. It is an opensource initiative to make a
cross assembler with the MSX as target platform. Currently it is written
in C, POSIX compiant I hope.
Patriek Lesparre (of TNI) has recently written a cross-assembler. It's
available at http://www.tni.nl/
Hehe, I'm a TNI member too, but I didn't know about it :P Anyway, I'll
check it out. Knowing Patriek, it will be for some m$ platform, right?
Mine is quite simple, but really cool anyway, because you can use the gcc
preprocessor.
It's really new, only a month or two old. You can suggest improvements to
Patriek if you have some ideas...
I will
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 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: (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 off packet
}
Sender sends remaining
Re: Sad news (V9958 and YM2431 orders)
will be about 8 dollars.
That's less than 8 euros, right? In that case, I want 4 :)
I currently have some orders yet, but only for 15 chips.
Still 85 to sell...
Hmm, that't quite a lot... Let's see if we can reach it.
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: Sad news (V9958 and YM2431 orders)
The euro exhange rate is not so good, 8 euro is closer to 9 euro. Still a
bargain.
As long as it stays under 10 euro, I'll take 4 anyway :)
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/
No Subject
Hello, This is a pretty long mail, so I shall start by describing it and thus letting you know if you want to read on or not. This mail handles about joynet. I want there to be a standard protocol for communicating over joynet. In the introduction I shall talk about why and when this protocol should be used. The reason I am posting this mail to the mailinglist and the newsgroup is that of course this protocol must be used by everyone. It should be part of the standard that in certain situation a standard protocol is used. I have designed such a protocol, but now I want you, the MSX community, to propose changes/propose a totally new protocol/agree with this protocol, so that in the end, we'll have a protocol that everyone likes and therefore everyone will use. So you shoul read this if you want to help developing the new standard joynet protocol and if you just want to see the prototype. If not, the rest of this mail will not interest you. Please read it while typing a reply, because that way you will not have forgotten most of your comments when you're finished reading :) 0. Version and copyright. This is version shevek-281700a of this document. This document may be freely copied, provided the version number is correctly updated. The version number consists of the name of the last person who made a change, followed by a dash, a serial number and optionally a letter. The serial number should (until the year 1) contain exactly 10 digits, the first 8 of which encode a date. The first 4 are the year. The 5th and 6th are the month, ranging 01-12. The last two digits are the day of the month. Example: the 17th of august 2000 is 2817. This date should be the day of writing. The last two digits of the serial number are the serial number for that day. This should only be different from `00' if more than 1 version of the document is written that day. Additionally, a `a' or `b' may be added if the document is considered alpha or beta (no characters other than ascii in the range 32-127 are allowed in the document, so don't try to make alpha's and beta's. If constructed this way, higher serial numbers will always be later versions of the document. This does not mean it is more up to date. An author can change an old document and add a new serial number. Anyway, let's get to the point. 1. Terminology In this document, every time I said she/her/... it could equally well have been he/his/... I just didn't feel like typing she/he all the time. 2. Introduction Some time ago, joynet was developed for the MSX computer. It is a describtion of a standard cable, which is to be used to connect computers when a network is desired. A protocol was not added to the standard, because it was left to the freedom of the coder to use whatever protocol she wants. This is nice in the case of a program, run on two computers, like a game. But when a program just wants to connect to `the network', without knowing what program is on the other side of the connection, a standard protocol needs to be used. This document intends to describe such a protocol. It is still very alpha. 3. When JUMP should be used 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. JUMP should be used to connect to a network in general. If the coder doesn't know what the network is, for applications like NFS, telnet and ftp. In such a case using JUMP is mandatory. 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. Drivers? Most programs would probably not even offer the possibility for custom network drivers. So a program written by X can only communicate with other software written by X. This is a highly undesirable situation and therefore JUMP was designed. So all the coder has to do is use it. 5. What joynet is Joynet is a standard for a network cable. It can connect MSX's in a ring via their joystick ports. between each two computers, there are 3 lines: The lines connected to button A and B are on the other side connected to steer up and down respectively. The line connected to steer left is connected to the strobe on the other side. For an exact description of the cable, see the joynet homepage by Grauw, `www.fixme.nl'. The information here is all the coder needs. 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
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: Coding question
Hi,
I shall put some comments in the assembly, if you don't agree with what I
say, there's an error in the implementation (or a mistake on my side ;)
I have the following subroutine:
ld hl,(table) ; load table into hl
dynamic start of table: the start address is kept at address table
inc hl ; increase table
inc hl ; increase table
2 bytes per entry
ld a,(hl) ; put value in a
sla a ; *2
sla a ; *2
sla a ; *2
might as well use add a,a. makes it better readable
dec hl ; decrease table
now you only have 1 byte per entry. either you cut out the second dec hl,
or this is a serious error which will cause data corruption.
The question is how do I put the value in a back in the table. I
can't do ld (hl),a. That doesn't work
As others said, it does. but hl must be pointing right.
I hope you can find the problem. Good luck.
Bye,
shevek
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) ;};}
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
