Re: The MSX Z80 assembler
Alex Wulms wrote: However, on 8-bits and on 16-bits systems, octals are not so convenient to use, for obvious reasons. 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. David Heremans .--. |o_o | In the beginning the Universe was created. |:_/ | This has made a lot of people very angry // \ \and been widely regarded as a bad move. (| | ) /'\_ _/`\ (Taken from THHGTTG) \___)=(___/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: Last News over me works (MIMAS Architecture at 8 / 29 / 2.000).
"Airam Rguez." wrote: 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 :(. The best (or maybe the only) way to buy hardware from Ademir is using some help from brazilian MSX people, like Daniel Caetano, when you're too far from him (Ademir). Ademir has some hardwares ready to sell (and its now cheap since our local currency is depreciated with de dollar) , but he doesn't read e-mail, he only talks using the phone, and that would be too expensive for you, since you live in europe (you would have to be able to speak english, but I don't think that would be a problem for you). In that case, you talk with Daniel or other people who lives near to Ademir, like Ricardo Bittencourt, or anyone else, and he could tell you the price, you would make a IPO to Daniel and he would send the hardware you want . Don't worry about e-mails with Ademir, I bought many things with him already, we talk a lot about MSX and I always give some suggestions about new hardwares for MSX, and I almost never get an answer from him using e-mail. :-) []'s Mauricio Braga. "Computadores fazem arte Artistas fazem dinheiro... " Chico Science. Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: V9958 and FM again....
Hello. Some time ago, someone (I don't remember his name) was asking for people wanting to buy v9958 and FM. Well, I want one fm and a v9958 too, and there's a lot of brazilian people that wants it too. Ademir will for sure want at least 20 of them to use in his new MSX motherboards (ACE002). There was someone here making a list, can you tell me who he is? Hah, that was Sander Zuidema. Mail him at [EMAIL PROTECTED] The V9958 should be no problem then, but the YM2413 will be, unless you order 100 of them. The point is that he has to order at least 100 pieces of each and no-one else was interested in the YM2413. Also note that you have to pay in advance to Sander, so that he will not run any risks. 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/
RE: V9958 and FM again....
Hi Mauricio, That person is Sander Zuidema [[EMAIL PROTECTED]]. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mauricio Braga Sent: Friday, September 08, 2000 12:27 PM To: [EMAIL PROTECTED] Subject: V9958 and FM again Hello. Some time ago, someone (I don't remember his name) was asking for people wanting to buy v9958 and FM. Well, I want one fm and a v9958 too, and there's a lot of brazilian people that wants it too. Ademir will for sure want at least 20 of them to use in his new MSX motherboards (ACE002). There was someone here making a list, can you tell me who he is? []'s Mauricio Braga. "Computadores fazem arte Artistas fazem dinheiro... " Chico Science. Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: V9958 and FM again....
Hah, that was Sander Zuidema. Mail him at [EMAIL PROTECTED] Oops, [EMAIL PROTECTED] (I think? Shit, I should have let him reply himself!) or [EMAIL PROTECTED] 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/
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: V9958 and FM again....
Oops, [EMAIL PROTECTED] (I think? Shit, I should have let him reply himself!) or [EMAIL PROTECTED] Hmm this way it is just fine ;) Greetz, Sander Who has no time at all at the moment, but will send all people that ordered one or more chips a message soon, because it seems that today we have reached 100!! So everybody who still wants to buy a chip order soon! (I will wait for ademir etc.) Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: OPLL emulation
Hello Albert, Yes, fMSX-DOS has a pretty good OPLL emulation. : I'm not sure about this. I asked for a wave based OPLL emulation. fMSX-DOS emulates OPLL by using the OPL3 generator contained inside my Sound Blaster. I'd like to get a MSX emulator that uses the Sound Blaster PCM for emulating the OPLL. Greetings, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) Visit MSX Warau Home Page http://msxjam.web.com msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
RE: OPLL emulation
I'd like to make a good PCM emulation of a OPLL. But i'm still looking for some good and free source code. Hello Albert, Yes, fMSX-DOS has a pretty good OPLL emulation. : I'm not sure about this. I asked for a wave based OPLL emulation. fMSX-DOS emulates OPLL by using the OPL3 generator contained inside my Sound Blaster. I'd like to get a MSX emulator that uses the Sound Blaster PCM for emulating the OPLL. Greetings, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) Visit MSX Warau Home Page http://msxjam.web.com msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/ 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: The MSX Z80 assembler
Alex Wulms wrote: However, on 8-bits and on 16-bits systems, octals are not so convenient to use, for obvious reasons. 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. IMHO it's very binary based. There is definately a logic in it, but it's not octal. Octal can be useful for some byte-register instructions; there are 8 registers so the registernr. in 8-bit instructions is represented by three digits. And if this 'accidentally' starts at an 3-bit 'offset' (bit 2, bit 5), then it can look very logical. But at the other hand, most (if not all) 16-bit instructions use a 2-bit register descriptor (BC, DE, HL and SP), and those don't appear to be logic at all in octal notation. I think it's quite coincidental (with a higher chance because of the similarities with the binary system). ~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)
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: OPLL emulation
At 17:03 8-9-00 +0200, you wrote: Yes, fMSX-DOS has a pretty good OPLL emulation. I asked for a wave based OPLL emulation. fMSX-DOS emulates OPLL by using the OPL3 generator contained inside my Sound Blaster. You didn't write that (I think). You just asked for good FM-emulation. In that case, I don't really know. Are there any emulators that have FM-emulation? GreeTz, BiFi Visit my Home Page at www.bifi.msxnet.org mail me at: [EMAIL PROTECTED] FTP: ftp.bifi.msxnet.org ICQ #36126979 Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: MSX turbo R
Albert Beevendorp soltó algo así como: You mean in BASIC? In assembly, it's BIOS call #0180 and #0183. I knew that already, I do mean in Basic. DEFUSR=H180: A=USR(0) DEFUSR=H183: A=USR(0) :) 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: OPLL emulation
Hello Tristan! IIRC, fMSX-DOS uses the OPL3 and not wave based emulation. BTW. I don't think wave (pcm?) based emulation will do any good. A mathematical emulation of 2-operator FM synthesis would be more suitable. The OPLL has some pretty hard to emulate stuff (hardware voices) which gives it it's unique sound... :?? 'Hardware voices' are simple presets contained on a small ROM inside the OPLL ! Furthermore, I've seen a Master System/MarkIII emulator that uses the PCM to emulate the YM2413, so it could be done for a MSX emulator as well. 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: The MSX Z80 assembler
On Fri, 08 Sep 2000, you wrote:
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.
In the very few cases anyone needs it, they can simply take a calculator and
convert the number to decimal.
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.
On most Unix systems, gcc is already installed. But on Windows or Mac, it
would require a separate installation, which is quite large as well.
You don't have to write the whole preprocessor again, only the parts you
need. Implementing file inclusion is straightforward.
I'm not in favor of using C macros in assembly. I'll give a simple example
that shows a problem with C macros. First the program in Pascal:
program Example;
const X = 1 + 1;
begin
writeln('2X = ', 2*X);
end;
Now the program that has been carelessly converted to C:
#define X 1 + 1
int main(void)
{
printf("2X = %d\n", 2*X);
return 0;
}
The Pascal program prints "2X = 4". However, the C program prints "2X = 3".
Why? Because C macros use substitution: "2*X" is expanded to "2*1+1", the
value of which is 3. Braces can be placed around the definition of X
to avoid this kind of problem:
#define X (1 + 1)
But the core of the problem is that the macro doesn't express what X really
is: a constant.
I know that C also has constants using the "const" statement. However, these
are actually variables that don't allow assignment. Using a typecast, you can
change the value of such a "constant". But the most important difference is
the way it's compiled: a constant is always placed in memory. But it's more
efficient to calculate constant expressions in advance, which is impossible
if the value is in memory. That's why C macros are often used in constants.
Bye,
Maarten
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
