At 08:47 PM 7/20/99 +0200, you wrote:
>> Easier said than done. How can you tell apart an opcode from a sequence of
>> data bytes? Example: a byte with contents #3E, does it mean "LD A,n" or
>> does it mean the number 62?
>> Maybe an adapted emulator could report all addresses of executed R800
>> instructions...
>
>No, no, in contrary. It's quite easy. First, all those instructions have
>multi-byte opcode, don't they? Do the chance you get something wrong is
>already minimized.
Probality of a two-byte code popping up in a random stream are 2^-16.
Ofcourse a game isn't random data, but I have no idea whether that will
increase or decrease the probality.
Anyway, disk-sized games have a lot more data than code. You can expect
about 10 false hits per disk.
As you said, when you examine the area around it it's usually easy to see
if it's code or not. But it would have to be done manually and it would
take time. It's similar to the process of cracking megaroms.
>Yeah, okay, that's cool. But not the OPL4-way, because the OPL4 sampleunit
>really SUCKS!!! It can play nice samples but there are three disadvantages:
>1. The sample always has to loop at the end, you can't just let it stop.
That's not a real problem, because you don't have to loop the entire
sample. You can simply add some silence at the end and loop that.
>2. Therefor, the OPL4 can't generate an interrupt if the sample is finished,
>and
"Therefore" is not true. The MSX-AUDIO can loop samples and generate an
interrupt when the looping happens.
>3. You can't play sound and access the SampleRAM at the same time.
This is a real problem.
>What I'm trying to say is for example in case of a
>screensplit: try not to assume it arrived at a certain line after some
>initializations before the real lineinterrupt, but keep track of the amount
>of H_BLANKs, even if this makes you to put the screensplit a few 'lines'
>higher.
The amount of H_BLANKs doesn't have to be the same every interrupt. For
example if the interrupts were disabled to a while, it can be longer. Or
image an interrupt routine that doesn't execute the exact same code every
time. Or a future MSX system with a cache.
What I do is estimate a worst case, say 4 lines. I put the initial line
interrupt 4 lines before the real line. When the interrupt occurs, I put
the real line in the line interrupt register and start polling the line
interrupt status.
>1. Can this archive easily be automated? (a program which copies the
>messages, eventually filters them and auto-uploads them to a server, in the
>right directory, right layout?), and
I think so.
We could ask Sean, I bet he didn't upload all those mails manually.
>2. This summary would be a hell of a job. The number of today's messages for
>example was 43 (!!!). Well okay three days ago I only recieved 8 but still,
>eh? Although ofcourse only the messages with [Phoenix] in the subject have
>to be summarized.
It would be a lot of work, but not too much. Large parts of messages do not
have to be part of the summary. And someone actively following the Phoenix
discussion would read all messages anyway.
I think a summary is really useful, both for the people discussing and as a
kind of "newsletter" to the outside world.
Rotating the summary task between people sounds like a good idea to me.
>By the way, why is WWW.MSX.COM still not occupied? It definately is a nice
>URL, and more logic then, for example, www.msxnet.org or www.msx.org .
.org is for non-profit organisations, .com for commercial ones.
I'm not sure if there is a kind of law enforcing it or that it's just
guidelines, but anyway that's the logic behind it.
>Hey, if we think this is a good idea, and we can get some people go for it,
>donating some money (I am willing to pay about 10 to 25 bucks monthly or so
>for it, provided I am one of the webmasters :)).
Sorry to disappoint you, but I'm not willing to spend that amount of money
for that purpose.
But if there are enough people who do, please go ahead and centralize those
useful MSX information sites. Simply give the people who already provide
those services an account on the new server. And give some disk space to
Arnaud, so he doesn't have to move his files around from one free web space
provider to another...
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
