Re: [MSX] new MSX Pad
On Thursday 12 September 2002 19:05, [EMAIL PROTECTED] wrote: Correct it seems to take a long time for my message to arive to the list : You are posting from multiple addresses that are not subscribed to the list. Therefore your postings are helt for approval. I usually check those every evening, so something sent during the day may not appear until that evening, or later if I am busy or forget to check. You should have received an automatic notification though. I add each address from which I approve a message to a white list, so the next messages from the same address will reach the list immediately. I'm sorry for the inconvenience, but the amount of spam makes this necessary. I delete about 3 spam mails per day that were sent to the mailinglist. Bye, Maarten ___ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
Re: [MSX] Why should it work in 128K? (was: English version of the site and HardDisk version of Snatcher)
On Sunday 01 September 2002 00:45, [EMAIL PROTECTED] wrote: I'm not saying that all new soft should be developped for Turbo-R with 1MB RAM and hard disk. But just to place in a reasonable mid term: it still seem a sort of sin to develop programs with somewhat high hardware or just memory requirements. But most tims this makes impossible to develop good programs. I guess MSX developers do not like the attitude some (not all) PC developers have, of skipping optimisation and let the powerful hardware compensate for sloppy software. On the other hand, if higher system requirements are necessary to build a program at all, or will save months of development time, it is better to release it with higher requirements. I think the translated Snatcher is a good example. Daniel optimised it enough to run on 128K from floppy. However for running it on harddisk you need 256K, because making it run from harddisk on 128K would be a huge effort. Actually, I don't think there are many people whose MSX has a harddisk but no more than 128K of memory. So, what is my proposal? To set the current MSX minimal standard to MSX2 with DOS 2 and 256K RAM. Even requiring hard disk would not be a nonsense for some applications. I don't think we really need such a standard. For each program the requirements are different: - For programs that dynamically allocate memory, use files that can be anywhere on the system etc DOS2 makes sense. However, a game which has fixed memory requirements and will save to a predefined location does not benefit much from DOS2. - Ofcourse any program that works with files over 720K (such as a movie player) needs a harddisk. But something like a text viewer does not need it, it would take no effort at all to make it work on floppy (which uses the same DOS2 calls). So it's a matter of finding the balance between how much easier will development be and how many people will not be able to use my software.
Re: [MSX] SD-Snatcher for Mapper and SCC+ music
On Monday 26 August 2002 20:14, kuipers wrote: I did not recieve the mail in html crap... Probably you did, but your Outlook processed it like HTML so it was invisible to you. I did see the HTML. From: Daniel Caetano [EMAIL PROTECTED] There is absolutely NO html here. If it's arriving on the list in HTML format is because any of the receiving servers is converting it. Since I send it directly to [EMAIL PROTECTED], I don't know why this is happening. But I can just send no more messages to this list. That's all. It was not your mail that was in HTML, but the one from Robert Wilting. Please keep posting your Snatcher translation updates, they are very interesting.
Re: [MSX] SD-Snatcher for Mapper and SCC+ music
On Monday 26 August 2002 22:32, robert wilting wrote: I think you are right. Since Hotmail automatically chooses rich text. I hope that setting the rich text editor of hotmail off will help if not then I might put the mailinglist on a different adress which will solve the problems. This is much better. Thank you. Bye, Maarten ___ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
Re: [MSX] Disk copy program that copies anything
On Sunday 18 August 2002 17:49, Snout wrote: Wow, how did this happen? I sent this one 6 days ago! From the mail headers: Received: from mail7-sh.home.nl (mail7.home.nl [213.51.128.26]) by skynet.stack.nl (Postfix) with ESMTP id 74A624018 for [EMAIL PROTECTED]; Sun, 18 Aug 2002 17:37:18 +0200 (CEST) Received: from cc159835a ([213.51.88.191]) by mail8.home.nl (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id 20020812173018.XWDI14744.mail8.home.nl@cc159835a for [EMAIL PROTECTED]; Mon, 12 Aug 2002 19:30:18 +0200 It seems the mail went camping on one of the @Home mail servers for almost a week. (and IIRC it already appeared on the list too...) Nope. Finally, I'd like to add a remark related to the subject: it is not possible to copy everything on MSX, because the FDC does not allow access on a low enough level. Well, not the FDCs in the Philips and Sony machines anyway; I doubt significantly different FDCs were used in other models. Not all protections can be written in sector-at-once mode, for example overlapping sectors. And because some values have a special meaning to the FDC, these values cannot be written in track-at-once mode. So there is a theoretical limit to what you can copy. In addition, there is a practical obstacle in reading the input. You can do a track-at-once read, but there is no easy way to know which magic byte sequences indicate a sector start and which magic byte sequences are decoys. A really smart program which be able to figure it out, but I have never seen a general purpose program that can copy a Micro Cabin/Sunrise type protection, even though it is possible to write those protections on MSX. Some may say Formula can copy Cabin games, but in fact it doesn't write the protection, instead it applies a crack to the copy (the data files that come with Formula are crack templates for specific protections). This is why you can copy a Formula copy of a Cabin game with any other copy program such as FastCopy, while those programs cannot copy the original. Bye, Maarten ___ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
[MSX] Mailman migration
Hi, We're running on GNU Mailman now and it seems to be working fine so far. I really like its web interface, it's more convenient than the e-mail administration of Majordomo. Mailman also has much more finegrained control over the list. From now on only subscribed members can post to the list. If you want to post from another address, notify me or Wynke and we can add that address to a white list (Mailman supports this out-of-the-box :). I am sorry if this causes inconvenience, but the spam made it necessary. For list members there are a lot of new options to configure now. If you don't reconfigure anything, the list will continue to work pretty much as it always did. But if you for example like to receive digests instead of individual messages, you can. Or you can disable messages for a while, for example if you go on holiday and don't want to get MSX mail in the mean time but still stay subscribed. You can get your initial password by using the Email My Password To Me button. Bye, Maarten ___ msx mailing list ([EMAIL PROTECTED]) New info page: http://lists.stack.nl/mailman/listinfo/msx Old info page: http://www.stack.nl/~wynke/MSX/listinfo.html
[MSX] Member list
Hi, The list of subscribed addresses is only accessible to members. This should stop address harvesters from getting your address from the web. If you are more paranoid than that, you can choose to have your address not shown in this list, by configuring your personal settings (see previous mail). The poster's address does not show up in the mail archive either. It did for the very first Mailman post made by Wynke, but not for any post made after that. I guess mail addresses in the message body do show up though, so be careful with that. Testing: [EMAIL PROTECTED] (this address is doomed anyway, it's already on the web and in newsgroup archives). Bye, Maarten ___ MSX mailing list ([EMAIL PROTECTED]) New info page: http://lists.stack.nl/mailman/listinfo/msx Old info page: http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MGN
On Tuesday 16 July 2002 00:57, The MSX Files wrote: MGN? What's that? MGN is the MSX Gaming Network, a site devoted to games being developed for MSX! Only recent games will show on the site. That's a good initiative! Maybe it's a good idea not only to highlight the games being developed, but also offer some support for the people creating them. There are always many ideas for MSX games, only some make it to the demo stage and very few are finished. Maybe if there is more sharing of knowledge and resources, more games will be finished. For example some game makers can write a couple of tutorials including examples (design/code/gfx/music, depending on the subject). Maybe a tutorial about integrating the MoonBlaster replayer in your game is useful, there were several questions about that recently on this list. You don't have to be an expert to write a tutorial: if you managed to accomplish the task, you can teach someone else. And some tooling that is useful for game developers. Compilers/assemblers (links to distributers or downloads, depending on the license), graphics conversion tools, raw sector writers (dcopy, rawrite etc), data compressors etc. Personally I would focus on cross-development: let the heavy programs run on a PC and target the output to MSX. Just downloads would not be enough, a description of how to use the tool is necessary for someone to get started with it easily. Most tools are already somewhere on the net, the added value of MGN could be to bring them all together and tell the game maker when to use what tool. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: De nieuwe PALM website
On Thursday 11 July 2002 21:33, David Heremans wrote: I asked them to remove [EMAIL PROTECTED] from their list. I wonder what they are going to reply :-) I sent them the same request. I also suggested that sending spam is not a good way to improve your brand image. Usually spam is sent by hard-to-trace people offering shady deals, but this appears to be sent by Palm themselves, which is a wellknown company. I sure hope that this is not the start of a trend.
Re: Convert to inline
On Sunday 30 June 2002 15:46, Frederik Boelens wrote: Why not just make the game in assembly in stead of TP?. Imho this seems much more diffecult, and with assembly you've got a lot more oppurtunities ;) Programming in a higher level language is much easier, because you have things like type checking, easy control statements (if, for, while), subroutine calls with a parameter list, mathematical expressions are very compact etc. I wouldn't recommend using assembly unless you absolutely need it, to get maximum performance or to get maximum control over the system. We now created the following situation in the source: dw start,einde-04000h dw start2,start and we get no errors anymore. But when we do this: dw start,einde-04000h+start2 The error is back. so it looks like the start2 is going wrong. but what does dw do? define word, it inserts a word in the output. For example, dw 01234h inserts 034h, 012h in the output (low byte is stored first in memory on Z80). It's rather similar to inline in TP, I guess. This particular dw is probably creating a BLOAD header. If so, the statement before it is db 0FEh (db is define byte). The BLOAD header looks like this: db 0FEh ; magic number dw start ; start address dw end ; end address (inclusive) dw exec ; execution address It's the same as the parameters you add after a BSAVE command in BASIC. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Convert to inline
On Sunday 30 June 2002 16:36, Patriek Lesparre wrote: Maarten ter Huurne wrote: I wouldn't recommend using assembly unless you absolutely need it, to get maximum performance or to get maximum control over the system. Spoken like a true PC-programmer :/ I used to code everything in assembly, but I've learned a few things since then. I now see assembly as an optimisation strategy. There are some widely accepted rules about optimisation: 1. Only optimise if you need more performance. There is no point in spending effort to decrease CPU usage if your game already runs at full frame rate. Or to take 10ms off a loading routine. 2. Optimise the code that is called most often. If you make code that is running 1% of the time twice as fast, the program as a whole becomes 0.5% faster. If you make code that is running 50% of the time only 10% faster, the program as a whole becomes 5% faster. 3. Don't start optimising before the algorithm is working. Optimised code is usually harder to read and to maintain. I often programmed routines in BASIC, tested and improved them until they worked correctly and then wrote an assembly version. Development in assembly will take longer than in a higher level language. If it's not necessary to write a certain part of a program in assembly, why would you spend your time doing so when you could be doing something more useful or more fun? IMO, with the state of Z80 cross compilers and/or native MSX compilers and given the power of the 3.58MHz Z80, it's hardly practical to program in anything higher than assembly for serious projects. Much of Uzix is written in C and I would certainly call that a serious project. On Sunday 30 June 2002 16:42, Frederik Boelens wrote: Ofcourse, you are right about the 'fact' that higher level languages are easier. but does it also counts on msx? Raymond had nothing but troubles implementing the mbwave replayer. And to make a good playable game with Turbo Pascal on msx seems very hard to me. Raymond had problems getting an assembler compiling the MWM replayer. None of the problems mentioned were caused by Turbo Pascal, as far as I can tell. Ofcourse assembly (and the algorythms) can be hard to learn to.. especially if you want to make demo's like Almost Real ;) But with some important preprogrammed routines you can make some nice things already very fast. Indeed we couldn't have written Almost Real in anything but assembly. But if the focus of a demo would be graphics, music (Impact) or jokes (Snout), it can be written in a higher level language as well. This doesn't go for all type of games, but don't you think most of them do need assembly to get a good gameplay? It depends on the type of game. If you have a turn-based puzzle or strategy game without a CPU-intensive AI, assembly is not necessary. Simple action games (Pacman, Athletic Land) could work as well. Or adventures like Snatcher. Things you probably want to do in assembly are the music replayer and the graphics decrunching. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Anti-Spam !!!
On Monday 24 June 2002 23:56, eMeSiX wrote: This mail is for the people who mantain the MSX List That is me and Wynke. I'm speaking only for myself in this mail. First: Kill *ALL* HTML mail Filtering out !DOCTYPE and HTML should kill most HTML, but maybe not 100%. Note however that not all HTML mail is spam, there are users trying to post HTML as well. Most of that is multipart, which is blocked already (same filter which blocks Outlook worms). Second: Users who aren't on the list can't mail to the list I was against this before, but the spamming is getting pretty bad now, so I'll reconsider. Would anyone who has a problem with no longer being able to post from non-subscribed addresses please mail me personally? Depending on the number of objections we might decide to try and implement this. Third: If somebody starts spaming kill the user Killing is a bit too much, but shutting them up would be nice. However, I have no idea how to find out who the spammer is. Remember that the From: field is very easy to forge, most addresses either don't exist or are from innocent people. I have sent mails to abuse addresses of several ISPs in the past, but usually there is only an automated reply, sometimes not even that. It seems they just don't care. Just some stupid idea's to stop the spaming If the spamming doesn't stop in a moth i will quit the list. Thank you for your suggestions. I cannot promise in what timeframe we will have anti-spam measures in place though. The MSX mailinglist is using the Stack infrastructure for free, so we cannot make hard demands, only ask nicely. There are various other lists using the same infrastructure; some changes might have to be system-wide and will therefore affect other lists as well. But we will do our best. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Anti-Spam !!!
On Tuesday 25 June 2002 00:49, d-fader wrote: Well.. If it can't be settled, then we just have to settle it for ourselves, I think almost anyone with a 24h inet connection is willing to serve the community... I even can run a spam-filtered-server that'll forward the messages sent to me e.g. We'll eventually arrange something Jorge, don't worry... I don't expect problems getting anti-spam measures installed at Stack, I just wanted to state that the matter is not completely in my hands. Therefore negotiation is required and that can take some time. So I cannot promise that we can block 100% of the spam or that we can do so within a month. I only promise to do my best to filter out more spam than right now. I think the MSX mailinglist runs pretty good at Stack, so I would prefer to keep it there. They have reasonably reliable infrastructure (more reliable than many ISPs, in any case) and they can use the network under a very broad definition of fair use. I don't think it's possible to run a mailinglist this reliable from a standard cable/ADSL internet account, where you may have an ISP that gives you a dynamic IP address, limits your traffic, forbids you to run servers, goes bankrupt or doesn't provide service if you move to a different area. I have been subscribed to this list since 1994 and it existed before that. Does anyone actually know when the list was started? Maybe we can celebrate a 10-year anniversary in the not-too-distant future. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: About the new CF Sunrise cart
At 13:37 23-6-02 +0200, you wrote: What do you think about this cartridge? http://www.msx.ch/sunformsx/products/hardware/ideflash.html A great idea, isn't it? Yes, some people I know bought it on the fair in Tilburg last April. Works nice, have allready bought several different CF-cards... Made some suggestions to Sunrise, why not make a combination of IDE (hardisk) and CF-Card... You can use an IDE interface and the IDE-to-CF adapter. Use an IDE cable for 2 harddisks and connect the real harddisk to one connector and the IDE-to-CF adapter to the other connector. The IDE-to-CF connector works on PC as well, by the way. I have a Sharp Zaurus PDA and I was able to mount my CF card (256MB) on my Linux desktop without a problem. The filesystem is VFAT, so it will work in Windows as well. Documentation isn't complete, have allready tested 16 MB and even 8 MB CF-cards and they work fine. Only had some problems with the cards I used when I put them back in my Digital Camera (cannot format card, camera says it cannot support this card)... Have formatted it on my PC with Multi CF-Card reader/writer... Maybe if you use FAT16 on MSX, you can read the files both on MSX and on PC? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Games for sale
On Saturday 22 June 2002 09:17, Albert Beevendorp wrote: At 01:50 22-6-02 +0200, you wrote: Am I the only one receiving ooold mailinglist posts twice? For some strange reason, I am missing posts that I do get replies on. So I have it exactly the other way round :/ I cannot find your mail address in the error messages, so I guess the mail is lost after it is delivered. Maybe a misconfigured filter? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Games for sale
On Saturday 22 June 2002 02:18, I wrote: Seriously, I don't know exactly what is happening. Looking at the headers, the mail was delivered Wednesday by the MSX mailinglist to [EMAIL PROTECTED] For some reason a mail server at multiweb.nl/quicknet.nl (is that the same thing?) decided to send the message back to [EMAIL PROTECTED] on Saturday. Patsie replied that QuickNet/Multiweb is moving and is therefore using different mail servers. So I hope this is a temporary problem. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Games for sale
On Saturday 22 June 2002 01:50, Sander Zuidema wrote: Am I the only one receiving ooold mailinglist posts twice? There weren't enough answers yet, so we decided to repost every message... ;) Seriously, I don't know exactly what is happening. Looking at the headers, the mail was delivered Wednesday by the MSX mailinglist to [EMAIL PROTECTED] For some reason a mail server at multiweb.nl/quicknet.nl (is that the same thing?) decided to send the message back to [EMAIL PROTECTED] on Saturday. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX Emulator comparison
On Tuesday 11 June 2002 13:32, Roel de Wit wrote: Hmmm I've tried the standard Unix version of fMSX.. It compiled okay but said it couldn't open a window in X-Window... The colour depth of fMSX is fixed at compilation time. Does the colour depth (BPP) specified in the fMSX Makefile match the colour depth of your X server? From what I've heard mini-GL comes in the form of Mesa which isn't too optimised yet for the PS2 hardware The main 300 Mhz CPU isn't too powerfull (about 200-300 Mhz Pentium with gcc compiled standard stuff).. The power lies in the Video Units (VU ?) which can do video related mathematics very quickly.. If they aren't used an Open-GL implementation doesn't really make sense IMHO.. The VU are the vector units. Since openMSX doesn't do tricky vector stuff (just quads specified using 2D integer coordinates), you won't miss them. However, support for accelerated texture mapping is necessary for decent performance. But even if GL won't work, you can always try SDL. The PS2 has a very fast bus and RAM, so SDL should be able to push its pixels to VRAM in little time. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Ontsla Stephany uit de bar!!!!!!
On Monday 10 June 2002 08:03, Joost Yervante Damad wrote: Hi, I thought this list blocked HTML only mail? The list only blocks multipart mails (for example, text + HTML), not HTML-only. Maybe it should. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX Emulator comparison
On Friday 07 June 2002 10:01, Roel de Wit wrote: Hmmm what's the best emulator currently available for Linux (in source code) ?? I just received my Playstation 2 Linux Kit and want to do some recompiling :) I know the following MSX emulators for Linux: - fMSX from Marat - fMSX-SDL (not sure if code is already available) - MESS (MSX1 only) - Zodiac (I don't know the status, look at SourceForge) - openMSX (most MSX2 features implemented) There may be more, does anyone (Sander?) know? For the PS2 Linux I think openMSX is a good choice, because it has both SDL and OpenGL renderers. I read that PS2 Linux has an SDL port and also has a mini-GL library. So you can try both and see which works best. On PC the GL renderer works pretty well (if you have decent hardware acceleration, such as nVidia's drivers). For example, in SCREEN2 every 8*8 block is a texture and the screen is drawn by texture mapping squares with the right textures. It uses very little CPU time or bus bandwith. In OpenGL it's also relatively cheap to use interpolation, draw scanlines or use alpha blended overlays (these are planned but not implemented yet). If interested, look at http://openmsx.sourceforge.net/ The current CVS version has much better GL support than the latest release. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX Emulator comparison
On Thursday 06 June 2002 23:34, Sander Zuidema wrote: The MSX Resource Center tested six popular MSX emulators for the Windows platform and compared them to each other. Are emulators as good as the real thing? Does all MSX software run on every emulator? Which of these emulators is the best choice? This and more in the first MSX Resource Center Emulator Comparison! URL? http://www.msx.org That's a nice and thorough review. Compliments! Any chance of a similar review of MSX emulators running under Linux? About the speed test programs: could you publish those? I would like to run them under openMSX and see how it scores. And can you say something about the amount of CPU power that is required by the emulators? For people with gigahertz machines that may not matter, but for people with older machines it is important to know whether an emulator can run at realtime, and if it cannot, which features you can disable to make it run faster. I like seeing Almost Real among the test programs. For those interested in the technical details, I can give some background info that can explain why emulators failed at certain moments: - _AR is a BASIC command which triggers a hook which starts the loading. RuMSX failing on this probably means a problem in disk emulation. - fake SCREEN 0 is actually SCREEN7. The VRAM uses a different addressing in SCREEN7 and 8 and Almost Real compensates for that. If the emulator does not implement this different addressing, the display will be garbled from the moment the logo starts rolling in. - The multilayer scroll in the title part is a lot of line interrupts and polls, which time colour and horizontal adjust changes. If things are displayed wrong here, VDP timing is off. - I don't really know why the loading pictures are so hard to get right - I can't get openMSX to display them correctly either (yet!). There may be different code for MSX2 and MSX2+ in this part, I'm not sure, Mark wrote it. - The hang in the fractals part can occur on real MSX as well, so it's a bug in Almost Real. However, on real MSX it is pretty rare, but if emulator timing is off you can get it 100% of the time. This bug can occur on turbo R, I'm not sure whether it can occur on MSX2. By the way, I assume you mean the emulated MSX hung on this part. If the emulator itself hung, something is very wrong. shameless plug We're still looking for someone to port openMSX to Windows. For details, visit http://openmsx.sourceforge.net/. If you're interested, post a message on our mailinglist. /shameless plug Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX Emulator comparison
On Friday 07 June 2002 00:46, Sander Zuidema wrote: About the speed test programs: could you publish those? I would like to run them under openMSX and see how it scores. I'll mail them to you in private so not everyone can have a laugh at what I call benchmarks ;) Thanks! openMSX results: CPU: 998.7 VDP: 979.4 In the CPU test, none of the subtest deviated more than one from 100. In the VDP test, most subtests were pretty close to 100, except for one 107 and one 112. Ofcourse these benchmarks only test part of the emulation, but as there is already a lot of variation in the scores of the different emulators, it at least shows that emulation accuracy is not optimal yet. It would be interesting to have some kind of MSX emulator testkit, which runs various tests and displays how close to real a MSX the emulator is performing. Emulator programmers can use this to make their emulator more accurate. Apart from timing tests, feature tests and display/sound tests are interesting as well. The first two can easily be automated, display and sound tests would be judged by a human. By the way, did you make sure all emulators used the same (8250) ROMs? Different ROMs may have slightly different routines, especially the interrupt handler installed by the disk ROM. And can you say something about the amount of CPU power that is required by the emulators? It;s an interesting thought for the future, but hard to test. I think I will have to rely on the information the developers give me then. You can get an approximation by looking at the CPU usage and comparing that to the total CPU speed. For example, if CPU usage is 80%, then a much slower machine has little chance of running the emulator at full speed. However, what is usually the determining factor is how fast the screen is rendered. So the drawing method is important (how much pixels are rewritten every frame) and also AGP/PCI bus speed. So CPU power is certainly not everything. And as soon as someone ported it, it will be in the comparison as well! (Be prepared) In the Linux-comparison, openMSX will be present as well. I am very curious in the results of this new approach. Keep in mind that we're still in the 0.X version range: openMSX is not fully functional yet. Some things work very well, other things are pretty broken. Still, I think in it's current state a review is possible. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Apologies for previous mail, wrong address
On Wednesday 29 May 2002 15:04, J. Lukens wrote: Again, sorry... The previous mail never reached the list: the list filters block admin requests. The filters also block multipart mails, so everyone please post in plain text, not text + HTML. This filter stops a lot of mail worms and spam, so we're definately keeping it. Two people tried to post in multipart format today, please retry in plain text. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Confirmation: Your CNET newsletter selections
On Wednesday 15 May 2002 01:50, CNET Newsletters wrote: Thank you for subscribing to CNET newsletters. You have been removed from the following lists: -- CNET Tools for Software Developers -- Download.com Dispatch for PC -- CNET Announcements -- CNET Delivers -- Handhelds Newsletter Some clarification: - I don't know who subscribed the MSX mailinglist to these newsletters. Either CNET did it or some annoying person. My guess is the former, because the categories are somewhat related to the list; a hooligan would have checked everything. Normally I wouldn't assume a wellknown company would do such things (it's almost spamming), but it seems lack of cash makes them loose on morals. - I unsubscribed [EMAIL PROTECTED] from all lists. Afterwards I changed the address to my own address, so if CNET ever decides to create new lists and auto-subscribe everyone to them, those mails will not go to the mailinglist. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: harddisk read only?
On Sunday 12 May 2002 13:22, Vincent van Dam wrote: I also know of some games which use it - although I don't think I can name one of those right now, I don't remember very well. Wasn't Firehawk one of these games? Yes it is. But if you have a PAC, you can save in that instead. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: converter of images for MSX from SCREEN8-TO-SCREEN12
On Saturday 11 May 2002 18:33, Laurens Holst wrote: I don't know about other people but this is definately starting to annoy me... Please stop sending the same emails to the MSX Mailinglist over and over again. If you have a question, you only need to ask it once. Apparently he wasn't subscribed to the list, so he never saw the answers to his questions. He is subscribed now, so this reposting should be fixed now. By the way, there is an archive of the MSX mailinglist at www.msxnet.org, very useful to look up old messages. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: harddisk read only?
On Saturday 11 May 2002 00:04, Alex Wulms wrote: I hope that the amount of daily spam that I receive does not increase due to me posting again in a (public) mailinglist, which might very well be being monitored by spam email address collectors :-( Note that there are no anti-spam measures on the MSX mailinglist. If you want to be safe, use a dedicated address. Some providers allow constructs like [EMAIL PROTECTED], so you can create as many e-mail addresses as you like for easy filtering, but also for tracking the origin of spam. In my opinion, spam should be fought at the source, namely the people sending it. Anti-spam measures like putting e-mail addresses in images instead of text may work against address collectors, but also make it harder for legitimate users to contact you (no more mailto: links). Client-side filtering may reduce the amount of spam in your inbox, but the bandwith used transmitting the spam is still wasted. What is really depressing is that apparently it pays to send spam. If no-one would ever buy something from a spammer, there wouldn't be so much spam being sent, often the same messages repeated many times. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Spam the mailinglist... (was: harddisk read only?)
On Saturday 11 May 2002 11:41, Hans-Peter Zeedijk wrote: Maybe I can put some lite on it: Probably the problems were caused by me (deeply ashamed!) because my computer was breevly invested by that new KLEZ virus and because I am member of the list, a lot may have had that virus from me resulting in generating KLEZ invested rubish mails from them as well. Because I can send no attachments, I cannot sent a tool I got from Symantec to find and remove the virus. Please look on the sites from major Antivirus company's for this tool and scan your PC's Sending clean-up programs is a bad idea anyway, because some viruses pretend to be clean-up programs themselves. Isn't KLEZ one of those? If you want to help people scan and clean up, just post URLs to wellknown anti-virus sites offering clean-up programs. (ofcourse you with Linux, Apple or MSX computers used for reading mail are not infected) Sometimes it's an advantage to be different... :) SORRY, SORRY SORRY, Hapzee. (Hope you will not block me from the list) I think it's brave of you to confess this, which should not be punished. Ofcourse you should learn from this and be more careful next time. Things to do to avoid most infections: - Make sure you regularly install fixes for your Outlook, or start using a more secure e-mail client. Many serious security leaks have been discovered in Outlook in the past and new leaks are still found regularly. - Uninstall Windows Scripting Host. If you don't know what this is, you don't need it, but many viruses/worms do. - Do not start executable attachments in any format (exe, bat, pif, scr, vbs etc). Not even if the mail comes from someone you know or claims to be a virus cleaner. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: To send for favour an programme of image converters from SCREEN 8 TO SCREEN 12
On Saturday 04 May 2002 20:53, Andrea Gasparrini wrote: Andrea Gasparrini ha scritto: Hello all you of MSX, Send me for favour an programme of image converters from SCREEN8 TO SCREEN12. Send me soon your news. Writing to the address: [EMAIL PROTECTED] Good bye Andrea Gasparrini software from Italy. INSERT COIN There is no need to reply to your own messages. Please don't do it; people have read your first message, don't worry about that. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Tilburg info
(mailinglist filters are too strict, so I manually repost this one) -- Forwarded Message -- From: N=?ISO-8859-1?Q?=e9stor_Soriano_?= [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Help! (Tilburg info) Hey obsoletes! I need information and photos about the Tilburg fair for SD MESXES#16 which is about to be released... I should have it today, or tomorrow at the most late. Someone can help me? Thankxs!! *** XXI MSX USERS MEETING IN BARCELONA: MAY 5th 2002 *** - Konami Man - AKA Nestor Soriano (^^)v http://www.konamiman.com- [EMAIL PROTECTED] ICQ#: 18281450 Happa ichi mai areba ii. Ikite iru kara lucky da! - -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Tilburg public transport info
Hi, If you're coming to Tilburg by public transport, this might be interesting for you. Tomorrow there are no trains between Eindhoven and Tilburg. Instead, there are NS buses, so prepare for a slightly longer trip. From Tilburg station to the fair site, you can use the city buses, line 44 or 45 direction north (noord). It takes a bit over 20 minutes. Get off at the Beethovenlaan/Schubertstraat stop. The fair address is De Schans 123. I think there is a small map at the bus stop (bushokje), but if you want to be sure use http://kaart.ilse.nl/ or something similar. (I'm not responsible for errors in this description. I'm using both my memory and http://www.ovr.nl/.) An alternative is the train taxi, which is more expensive than the bus but less expensive than a real taxi. Fair is from 10:00 to 16:00. Poster is at http://www.cgv.myweb.nl/fr_posterY2.htm. I hope to see many of you tomorrow. And I should be getting some sleep now. :) Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: 3D modeller for MSX in BASIC
On Thursday 04 April 2002 04:06, you wrote: My browser crashed. This page is obviously direct link forbidden page. To reach properly, visit http://www.vega.or.jp/~tanaka/hiroshi/ then click Software for MSX. Strange. Mozilla didn't crash, and the link worked with me, without problems... Konqueror didn't crash, but showed a 403 - Forbidden page. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Msx archivers
On Tuesday 02 April 2002 18:24, you wrote: Where can I find source code for pmext / pmarc? You can't. :( But Maarten ter Huurne made a nice extension for LHA that allows it to extract PMA files. Check his webpage: www.stack.nl/~mth http://www.stack.nl/~mth/msx/crossdev/ It contains C source code. I also have Java code, if you prefer that, mail me. I based the decompression routines on UnPMA by Alwin Henseler, which is written in Z80 assembly: http://huizen.dds.nl/~alwinh/msx/software/index.htm From the README.PMA of the PMA-enhanced LHA: === PMA files are generated by PMARC, a CP/M archiver by Yoshihiko Mino that was popular among MSX users. While the archive structure of PMA files was understood by LHA, the compression method (-pm2-) wasn't. I took the (MSX assembly) sources of Alwin Henseler's UnPMA program, translated them to C and integrated them with the LHA sources. The result is an LHA program that can extract everything the original LHA could, and PMA files as well. The new source is in the pm2* files, take a look if you're interested. These sources were tested with success on Linux, FreeBSD, Solaris and HP-UX. Hopefully they will work on other systems as well. I fixed some warnings by adding #include statements. If your system complains about a missing include file, try removing the corresponding #include statement. === Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX PLAYer news
On Sunday 24 March 2002 13:07, you wrote: Alex Wulms wrote, in reply to Richard Atkinson: ] generations too early. Also, do not *ever* run Marat software. Do I need ] to explain this one? ;) Why is everybody picking so much on Marat? Because he's an evil megalomaniac greedy thinks-he-knows-it-all asshole. Do I really need to explain this?! I have a very different view of Marat. I don't think he has any more of a know-it-all attitude than the average programmer has. And why greedy? He is giving fMSX-Unix away for free, including source. The reason Windows users pay is for the effort he puts into them (creating the GUI and support). Marat never stopped anyone from creating a Windows port of fMSX, instead he even links to them. If you think of Marat in that way, so be it. I just wanted to state publicly that this view of Marat is not shared by everyone who has dealed with him. Note that fMSX is the father of many other MSX emulators that currently exist. Even the much heralded NLMSX is derived from fMSX. I wouldn't exactly call that a good thing. I'd call it inbreed! Although AFAIK NLMSX doesn't contain much, if any, fMSX code anymore. I haven't seen the NLMSX codebase. But even if it would have very little fMSX code anymore, using fMSX as a starting point has made development a lot easier than starting from scratch. fMSX is not perfect and I don't think it will ever be; there are some design limitations that will be hard to overcome. But I do have a lot of respect for it. fMSX was the first MSX emulator and it's still very much alive and kicking. No, I'm very glad a new MSX emulator is being developed that will stop the senseless cloning of fMSX! *hint hint* I think openMSX will be able to shine on its own merits, there is no need to speak ill of fMSX and its derivatives. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Ikeda MSX Print: More news on MSX Player
On Sunday 24 March 2002 12:13, you wrote: ] Price of MSX Player. Windows version is free price. And Yokoi wants ] OPEN SOUCE CODE LICENSE like GNU. But some program code writters donot ] like it. They wants protect their program technology from other people. ] ] He cannot license the code under GPL without permission from Marat. You ] cannot give away something you don't own. That is exactly his point. Yokoi would prefer to make it open source but some program code writers (like Marat) do not like that. Which indeed means that it can not be put under open source. I want to offer the MS Windows code under GPL. But I cannot, because I do not own it. Saying I want to is an empty gesture, in my opinion. MSX Association could have seen this coming. If a GPLed emulator was their goal, they should not have started with fMSX as their codebase. Stating (approximately) two years later that Marat does not allow them to release MSX Player under GPL is a bit misleading. But that is not a problem anymore. Last couple of month, several people have been working on a brand new MSX emulator, called OpenMSX. This MSX emulator is opensource. It has been rebuild from scratch, based on some new concepts regarding communication and synchronisation between the various processors in the MSX. This new communication and synchronisation model will eventually lead to a (near) perfect MSX emulation. I know. :) ] What is copyright of MSX? MSX emulators are written using publicly ] available information and reverse engineering. There is no copyright ] necessary to create an MSX emulator. The copyright is on the base design. I don't think the MSX standard is copyrighted. A certain implementation (MSX machine blueprints) can be, or a book describing the standard. But not the standard itself. Note that I could summarise a book and place that summary online without violating any copyrights. Only if I would duplicate sections longer than a normal quotation from the book, it would violate copyrights. Please view copyrights the way they were intended: to protect authors, so that they can make a living off their creative works. Many companies are now trying to use copyrights to gain as much money and control as possible, but that is not what copyrights are for, and in many cases that is not what the law provides for either. And don't make them fool you that the old rules no longer apply just because content has gone digital. Normally, you need to take a license to build an MSX and use the MSX trade mark. Is MSX a trade mark? Then why isn't there a tm or (R) on my 8250 boot screen? Did Philips, Sony etc pay royalties to anyone? Doesn't a trade mark expire if it isn't defended for a prolonged amount of time? Can you even trademark three letters? (486 wasn't trademarkable.) I am not willing to assume anyone has rights to MSX without proof. Note that building your own products based on reverse engineering is these days forbidden in the USA, thanks to the 'digital millenium rights act', which is some new legislation around copyright, etc that was created somewhere around 1999/2000. I know and I am very much concerned about these kinds of laws. However, fortunately until now Europe has remained mostly sane, so I am still able to create MP3s of CDs I bought and to reverse engineer my MSX. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Ikeda MSX Print: More news on MSX Player
On Thursday 21 March 2002 23:58, you wrote: I did not interest in MSX Player. Because we can use other Emulators like fMSX, JAVA MSX Emulator, Zodiac, RuMSX and freeM etc.. But Hidekatsu Yokoi told me that MSX Player can emulate many MSX softwares more than the other Emulators. Probably it is No.1 emulate function. And MSX Player is fine work with The souce of Power produced by ANMA. It is cool thing! fMSX can do that for over a year now. In fact, I sent some patches to Marat that make the Source of Power run. This is not something that MSX Player added. I don't like the way they take advantage of the huge effort Marat put into fMSX and also the contributions made by Alex Wulms, myself and several others, without giving proper credit. I don't want cash, I don't even care much if my name isn't mentioned, but someone else taking credit for work I did makes me furious. Price of MSX Player. Windows version is free price. And Yokoi wants OPEN SOUCE CODE LICENSE like GNU. But some program code writters donot like it. They wants protect their program technology from other people. He cannot license the code under GPL without permission from Marat. You cannot give away something you don't own. But Yokoi will fix this problem use via their barrister. Long time, Yokoi doesnot contact with Marat. Because Marat told that I can wait. At first, Yokoi negotiations with MicroSoft more than Marat. Message to Marat: You need not worry. Yokoi will pay royalty till distribute the MSX Player. At less than a month before the planned release date, they'd better hurry. And Nishi paied many money to buy copyright of MSX from ASCII Corporation. Now, MSX Associations has Copyright of MSX, NOT ASCII Corp! What is copyright of MSX? MSX emulators are written using publicly available information and reverse engineering. There is no copyright necessary to create an MSX emulator. Okazaki made very cool emulator of FM Music. And Yokoi discuss about it with Yamaha Corporation. Yamaha will NOT appeal to the law! Because this emulator is NOT use technology of Yamaha at all! That is good news, but not a surprise really. In fact, Yamaha realised that it is allowed to create a piece of software that is compatible with a piece of hardware, when that software is written based on publicly available information and/or reverse engineering. If this is true for OPLL, why wouldn't it apply to any other piece of MSX hardware? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Regular expressions
On Friday 22 February 2002 12:36, you wrote: Just for fun, I'm wandering how a regular expressions parser could be implemented on MSX. If you just want to tokenize config files, you don't need full regex support on MSX. From the regular expressions for your config language, create a state machine. You can do this step using any convenient language, I would suggest something like Python or Perl, but you can use an MSX language instead if you like. Then implement a small engine in MSX assembly that executes a state machine. Advantages: - INS won't increase much in size: only state machine and engine would have to be integrated, the rest is an external program - you can do most programming in a high-level language - the state machine generator and engine are independent of the config language, so you don't have to re-write them if the config syntax changes Example of state machine: Let's say you have 2 keywords, being on and off. The state machine would look like this: 0 --(o)-- 1 1 --(n)-- 2 1 --(f)-- 3 3 --(f)-- 4 Where: 0 is the initial state 2 is the end state for on 4 is the end state for off --(x)-- means you perform this state transition if the current input character is x If there is no valid transition, the string you're reading is not a recognised token. In most languages, you would scan until a separator and the result is an identifier (non-keyword token). In a language without separators you would have to jump to the correct internal state, which is hard, so don't design such a language unless you actually need it. Ofcourse on | off is a very trivial regex, but any regex can be expressed as a state machine. A non-trivial regex would make a too large example, this is also why state machine generation should be automated. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: 2 games and few robot arms
On Monday 28 January 2002 10:33, you wrote: Cart of Ashguine 311 Euro I didn't know Ashguine 3 existed. Is it like Ashguine 2? Although I didn't understand that game at all, I enjoyed playing it. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: 2 games and few robot arms
On Monday 28 January 2002 22:23, you wrote: I didn't know Ashguine 3 existed. Is it like Ashguine 2? Although I didn't understand that game at all, I enjoyed playing it. just a hint, but take a look at the game on MSX Files, the rare section ;) Thanks! I downloaded the game, it seems like an action RPG. Demo is not nearly as good as Ashguine 2. The in-game scrolling is weird: sometimes the map scrolls, at other times you walk into the next room. However, it is unclear when which will occur, this is very disorienting. The idea behind combat system seems nice (evade enemies a la SD Snatcher, if you hit one you can find them in an action screen, which looks a bit like Golvellius). But all in all it doesn't have the appeal part 2 did. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Vote for MSX! come to MSX fair MSX-NBNO 19 januari 2002
On Friday 18 January 2002 15:17, you wrote: At the dutch site www.tweakers.net you can vote for the most popular homecomputer/console ever. Please go to the site and vote for MSX ;) I vote for msx who is next How many times can one vote (on the same IP) ? :) It's a poll, not a popularity contest. There is no point in artificially raising the count for MSX. Instead, write some nice things about MSX in the reactions section. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: weird mail flood
On Tuesday 18 December 2001 23:23, you wrote: Do some other people on this list also receive all this 0.1K mails from [EMAIL PROTECTED] ? At has just two empty lines ! I don't receive them. I don't get any unusual error mails from the list server either. Could you forward one (including headers) to my private mail address? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: ScanMail Message: To Recipient virus found and action taken.
Hi, A combined reply: PIF's don't get opened automatically here. I got an pop-up dialog in which I could select 'open', ofcourse I didn't do it, heh, I'm dumb, but not a moron... Although... Ahwell.. that's something to discuss, but I think ppl who know a BIT about computers won't open that file manually, since it doesn't have a subject and it comes from a stranger, and they still got in mind not to interact with strangers, har! I think this is one of the worms that, in some Outlook versions, get executed automatically. The mime type says audio/x-wav which makes Outlook think it's safe, so it passes the file on to Windows which doesn't know mime types and looks at the .pif extension and then decides to execute it. This is a recently discovered Outlook/IE vulnerability. The list was already configured to block binary attachments. This has stopped quite a few worms in the last months. But since this one was multipart/alternative, which wasn't recognised as an attachment. Also, it was small enough to fit under the size limit. Just a thought: The majordomo has the list of ppl subscribed to this mailing list. Why not set up a filter that only accepts mails from a subscribed address. Hm, as I'm typing this, I already know the answer: it's pretty simple to fake a FROM field in a mail, so filtering on that won't do any good. That's not the problem. These worms are sent by infected machines, not by people with hostile intentions. It's a simple fixed algorithm, not some cracker trying to figure out a hole in the filters. Unless a mailinglist member's computer gets infected, the filter you suggest would block the worms. The problem with that filter is that many legitimate posters also use non-subscribed addresses, for example because they read mail at different locations or because sometimes someone who isn't subscribed wants to post an announcement. Good work Wynke but the users need to have a good Virus scanner. En keep it up to date. Actually, I think virus scanners are only a workaround. The solution to this problem would be more care for security from software manufacturers. It would help if more users would show some consideration for security, for example by making security on of the criteria for selecting their mail client. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: [NL only!] Ordering V9958 VDP(s)
On Thursday 13 December 2001 22:14, you wrote: Yes, just 64K videoram wont be any good for VP9938 or 9958. So an upgrade is indeed required. V9938 (and V9958 too, probably) can cope with 64K VRAM. However, SCREEN7/8 need 128K. Even though a single page in those modes is 54K, it needs two parallel ICs to meet the timing demands. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: SFG-05 register write routine
On Monday 03 December 2001 00:44, you wrote: ORG #9000 IN A, (#A8) PUSH AF OR #03 OUT (#A8), A LD A, address BUSY LD (#3FF0), A AND #80 JRNZ BUSY LD A, data LD (#3FF1), A POP AF OUT (#A8), A EI RET This routine simply hung, presumably on the loop that waits for the YM2164 status register to return a not busy signal (bit 7 = 0). Any ideas why, and what I should do differently / add to this? First of all, you forgot the DI statement at the start. Switching the interrupt routine (#0038) away is a bad idea. Maybe your actual program did have DI though, since you do have an EI at the end of the program. Second, the BUSY loop does not read any status register. So it will be executed either once or forever, depending on bit7 of address. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
A2000 mail problems
Hi, It seems A2000 addresses no longer work. They are generating huge (200K each) error messages; I just received 11MB of mail in the timespan of half a day. I tried to send a mail to various postmaster@ addresses, but they came back undelivered. I am unzubscribing all problematic addresses right now; that is all zubscribed A2000 addresses and any address metioned in the error messages (may be forwarded to A2000). If you have an A2000 address and are receiving this message, please mail me. If anyone knows more about this, please inform me. Usually I am more patient with malfunctioning addresses, but I don't want my regular mail getting lost because of these absurdly large error messages. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Mail formats
Hi, Please everyone send just plain text mails. Lately I've seen a couple of messages where URLs were in some kind of attachment. Since the mailinglist server is configured to block attachments (stops viruses and helps people without broadband), these messages are blocked as well. Some HTML mails are blocked as well. So if you want to be sure your message gets through and everyone can read it, please send it in plain text. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX slot interfaced to PC
If the new one chip msx comes out you can connect the hardware tru usb maby that wil work also on usb from a pc ro ? In an emulator, it is possible to freeze the MSX until whatever acts like a cartridge responds. On a real MSX, there are strict timings and I don't think USB can make those deadlines. By the way, even disregarding latency and only looking at bandwidth, I think USB 1.0 is not fast enough. When executing code from a cartridge (running a game ROM), there will be a merory read about once in 7 cycles (rough estimate). At 3.5 MHz that is 500 kilobyte per second. USB 1.0 has a bandwidth of 2 megabit per second (correct me if I'm wrong), which is 250 kilobyte per second. This is disgarding any overhead of the USB protocol and disregarding the fact that the address being fetched should also be communicated, so the actual number will be even lower. USB 2.0 is said to be a lot faster, but this higher speed can only be delivered under certain conditions. I think USB 2.0 will have enough bandwidth to act as an MSX cartridge, although you might need a dedicated cable with no other devices attached. However, I guess the latency will still be too large to allow this solution to work on a real MSX. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Just a question...
On Monday 24 September 2001 23:02, you wrote: How many bytes could I send approximately in one interrupt by using a serial cable (com port on PC and joystick on MSX)? Don't connect the COM port to anything other than RS232, because the COM port signals are at 12V. JoyNet can be used between a PC parallel port and an MSX joystick port. You can find the schematics on Laurens' site. If you want a simple low-cost cable, please use JoyNet. Its speed is good enough for multiplayer games or telnet, but it's a bit slow for transferring files. Just by making a little program on MSX that keeps checking for data... On an MSX2 I got about 3.5 kilobyte per second, on turbo R about 14 kilobyte per second. (At the other side of the cable was the same PC in both cases.) As you can see, the bottleneck is the CPU, not the cable. The joystick port is not very convenient for I/O, because you have to switch PSG registers a lot (between reg 14 and 15). Also, there is no buffering (RS232 has FIFOs and you can send bytes to the interface instead of single bits). Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Fw: Novaxis MAP syntax
Hi, This is a message from Manuel Bilderbeek, which was rejected because it contained an attachment. The full message (excluding attachment) is below. It's attached. The file is also here: http://www.funet.fi/pub/msx/utils/harddisk/novaxtab.pma Sorry for posting it on the newsgroup, I'm too lazy to make seperate posts. It's probably filtered out on the mailinglist... :-) No, it is not filtered; it is sent to the admins who have to clear up your mess... Grmbl... (no hard feelings, just don't make a habit of it) Bye, Maarten -- Forwarded Message -- Roderik Muit wrote: My mailer screwed up and didn't CC the news message to mailboxes... Ah, thanks anyway for your response! I'm writing here a small reaction. I'm not in the tech stuff, but very interested anyway. Hi, Well, some people still know me (and flood my mailbox) It's OK, I've woken up now.. ;-p Since I'm seeing this message from 4 directions, I'll answer them all too. Thanks again! :-) (amazing to see a mailinglist + a newsgroup both still working... I had no idea...) It has been all the time! Well, yeah, maybe. I'm not so good at keeping backups from things that were '5 harddisks ago'. I can find out over the weekend whether I still have something... Please do so. I guess anything is useful. For starters, - MAP.COM was written by Gert de Boom - the Novaxis SCSI BIOS was written by Jurgen Kramer - you've got the info from that one on ftp.funet.fi already, apparently. Those docs seem to be quite good. The problem was to get the info about the partition types... - NFDISK was written by me, using windowing routines from Jeffrey Timmer and in v1.2 some code from a friend from a friend in Tilburg, whose name I forgot... What changed in version 1.2? I myself have always used 1.2. As far as I can make out, it's the info on the partition types you're looking for. Exactly. [info about partition types] I think I wrote some documentation on it. I hope so, since I'm not planning to delve into assembly code in order to get that info. (Although it would be nice to see how unstructured I programmed back then :-) Please try to find that documentation back! :-) But thanks already for your remembered info! The 'Extended' format uses sectors elsewhere on the disk, as does the BERT/HPN format. The fourth entry in the 'normal pc' partition table in this case does not contain data about a partition, but points to another sector somewhere on the harddisk which holds data on more partitions (i.e. more sets of these 32 bytes, at the same position as sector 0). That's the main idea. On normal PC's, this is only done once, i.e. you have maximum 2 sectors with partition data - one with info about 3 partitions + a pointer to the second sector, and one with 4 partitions. So you can have max. 7 partitions on a PC. Note that this format is NOT supported by NFDISK (or any other MSX program You mean the PC way of doing it is not supported by NFDISK? I know). Back then I did not know anything about how the PC does extended partitions, so I just created some partitions with a BERT interface, saw how they did it, copied that, and assumed that that was how the PC did it too. Apparantly it is not: according to Maico Arts you can only read the first three partitions of an MSX harddisk with Extended partition table. So the pointer in the fourth table is not recognised... (it seems). What they do is: in sector 0 of the harddisk there are 2 * 32 bytes of info; the first holding data about partition 1, the second being a pointer to another sector. In this sector there are 2 * 32 bytes of info; the first holding data about partition 2, the second being a pointer to another sector. In this sector there are 2 * 32 ...(reiterate until you get to partition 32. If I remember correctly that 32 partitions was the maximum - anyway, it's an arbitrary limit.) Yes, 32 is the maximum (which I have on my 1GB disk... ;-) It's not a big deal, since it's not that useful to have 1GB harddisks on MSX, but I'm still surprised you limited it... Or is this really necessary? (I thought that this format was PC compatible. I now don't really think it is, because the PC only does a pointer to another sector once. It may be compatible depending on how the particular PC's BIOS is implemented, perhaps, maybe, kind of, idunno...) See above: it doesn't even seem to work with the first pointer. So in NFDISK 1.1/2 I added the 'BERT/HPN' format. (There must be a very small utility around -on some Quasar disk anyway- that converts Extended to/from BERT format. If someone knows this by any chance, please tell me - because there may be documentation included that proves whether I'm talking nonsense here or not.) It's attached. The file is also here: http://www.funet.fi/pub/msx/utils/harddisk/novaxtab.pma Sorry for posting it on the newsgroup, I'm too lazy to make seperate posts. It's probably filtered out on the mailinglist...
Greetings from Uzix 0.2.0
Hi, This message is sent from my turbo R, connected to the net using a Sunrise IDE+RS232C interface and a null modem cable to my Linux box. Uzix 0.2.0 is really cool! Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: I have a dream.. bogus?
The list filters screwed up again. Apparently typing only the first 6 letters of configuration is interpreted as an admin request are therefore prevented from going to the list. Here is the original message: (except I replaced the word that triggered the filter) --- Date: Sat, 25 Aug 2001 04:23:12 +0200 To: [EMAIL PROTECTED] From: Patriek Lesparre [EMAIL PROTECTED] Subject: Re: I have a dream.. bogus? How many MSX users have Turbo-R + GFX 9000 + Moonsound ? Me me me! Except the Gfx9000 is a Video9000. And add a LPE-Z380 to that configuration please :) Patriek -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: About Powerbasic
On Saturday 25 August 2001 13:36, you wrote: Because it was mentioned by someone of you that Punx will use Powerbasic: Why is that Powerbasic in a seperate cartridge?. it should have been easy to implement it on the ROM of the GFX9000 The GFX9000 doesn't have a ROM. But I think on the turbo R, Power BASIC can be run from RAM, using the shadow RAM option (DRAM mode). By the way, I have turbo R + GFX9000 + MoonSound as well. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: About MegaSCSI
On Saturday 25 August 2001 13:40, you wrote: Is that Mega SCSI still a do-it-yourself thing? I mean you have to make your own cartridge? Or is it for sale somewhere? (I am not afraid to use a soldering iron, but I don't know to mutch of electronics and nothing of making my own printed cirquit boards) I think there are people selling MegaSCSI cartridges, but I do not remember who. By the way, you don't actually have to make a PCB and a cartridge case yourself. You can start with a MegaROM cartridge and add SRAM and the SCSI IC and some others to that. The SCSI IC is quite expensive, so you have to be confident in your soldering skills. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: But what the hell happens with page 1 switching???
On Tuesday 31 July 2001 12:24, you wrote: - Obtain the slot currently switched on page 1 by reading the slot selction register, connecting the slot of page 1 into page 3 and reading address #. Save this slot+subslot value on OLDSLOT. You should ofcourse complement what you read from #. I assume your code does, but you didn't mention it here. - Save contents of work area #FCC5 to #FCC8 (the sublot registers saving area) as OLDSUB What are these for, anyway? - Switch NestorMan slot on page 1 with ENASLT Watch out: ENASLT does an EI. Since you store values on fixed addresses, the interrupt handler is not re-entrant. You have to guard against interrupt-within-interrupt. The previous code you sent to the list did that (interrupt in progress flag). Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: FM-PAC questions
On Sunday 08 July 2001 20:43, you wrote: About the original FM-PAC (Panasonic) How many Kbytes of S-RAM does it have? 8K, if I remember correctly. Just look at the size of the .PAC save files, those are the SRAM size plus a few header bytes. I've seen in the label of the cartridge something about 32 Kbytes but I'm not sure if they are the total amount of S-RAM or the minimum RAM required to use the cartridge. Probably the latter. In what year was released (exactly)? I don't know exactly, my guess would be 1987. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX World ONLINE!
On Tuesday 26 June 2001 11:59, you wrote: The site is 100% working with (minimum required:) Internet Explorer 5.0 or Netscape Navigator 4.7, What about Mozilla, Opera, Konqueror, NetPositive, FudeBrowser and all the other browsers out there? You can check your pages against the HTML standard using W3C's validator: http://validator.w3.org/ Valid pages work in most browsers. And when they don't, it is the browser's fault. in resolutions 800x600 and 1024x768. My screen resolution is 1024x768, but the browser window is about 700x700, of which 700x570 is available for the document. You cannot assume everyone uses a maximized browser window. Be sure that your browser is compatible with Javascript, frames (are there people which have browsers that are not?), and PHP (will come). As Sean said as well, PHP is server-side, so it is independant of the browser. There are browsers that do not support frames, for example Lynx (text mode browser). Also, some people dislike frames, especially if they prefer navigating using the keyboard instead of the mouse. Please don't be discouraged by the comments on your HTML. Many pages cause troubles because they do not conform to the HTML standard. Combined with the fact that many designers only check with IE, this means using an alternative browser will cause broken displaying that would not occur if the designer stuck to the standard. This is a frustration of almost any non-IE user. Web pages should be flexible enough to be displayed on a large number of browsers and resolutions. It's useless to demand a certain browser or resolution, because no-one is going to change the way they surf the web just to view your (or anyone else's) page. If necessary, use a simpler layout that will work for more viewers. By the way, if you look at sites that get many visitors, those often have a simple layout. Google is a good example. Also, most sites use tables instead of frames nowadays, users seem to prefer that. And remember that a slick look may give a good first impression, but good content makes sure visitors come back. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Just a thought
On Tuesday 05 June 2001 18:51, you wrote: Wasn't there a plan for this? The .msx format? A discussion WHICH COMPLETELY DIED WITHOUT ANY RESULT! :-( Please be more patient. Standardising and then implementing takes a lot of time. MSX developers have studies or jobs and other projects going, so they're not always working on emulators. But the Unified MSX Format will be implemented. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Exclusive interview about Konami and the S.C.C.
On Friday 01 June 2001 20:21, you wrote: The English translation is available on The MSX Games Box ( http://www.msxgamesbox.com ) From the interview: === After one year of 'counter-cracking', Konami sales were gearing up et piracy was decreasing at the times games like Nemesis 2, Salamander, King's Valley 2, Nemesis 3, F1 Spirit were about to come out. === I wasn't aware of any copy protections in those games. The large size (128K or more) made cracking difficult ofcourse, but that's a side effect of larger games, not a protection mechanism. I never cracked those games, but I don't know of any MegaROMs having copy protection measures. === In the case of a S.C.C. cartridge, a part of the hooks table  reserved for routing sounds to PSG  is replaced by instructions to redirect the sounds to the S.C.C. microchip located in one of the cartridge ports. A simple POKE H,y redirects the instructions. === This is new to me. Can anyone confirm or deny it? === Mars Up-One: If I am not wrong, the S.C.C. chip is not only a sound processor but also a memory mapper which handles the 16Kb blocs of the game ... what are the interactions with the memory mapper used on high-end MSX2 machines? === The SCC IC contains a mapper of 8K blocks, it is not related to the main RAM memory mapper. Details about this and other MegaROM mappers can be found on Sean Young's pages: http://www.msxnet.org/tech/megaroms.html Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Exclusive interview about Konami and the S.C.C. (plus cracking software stuff)
On Friday 01 June 2001 23:07, you wrote: SEGA ? What SEGA has to do with MSX ? Remember, SEGA holds parts from patents that were from ASCII regarding MSX dedicated LSIs such as the VDPs (V9938 and V9958) and since they gave up from hardware I think it will be more dificult to get authorizations to build compatible devices legally ... I hear a lot of people talking about patents on MSX chips. Could anyone point out exactly what parts of the designs are patented and by who? Since the stories about patents are so vague, I am starting to believe they are rumors rather than facts. After all, patent claims are always published, that is part of the concept. This is not criticism against you, it's just a general feeling that's bothering me increasingly. However, if you could give some details on SEGA's patents, it would ease my mind. I think you guys know what I mean ... Why act so mysteriously? The MSX Revival project is not a secret, we can discuss it openly. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: 2 mapper speed question
On Thursday 31 May 2001 20:39, you wrote: The situation: NMS8250: internal mapper 128kB, external 1MB How do I prevent the use of the internal mapper so I don't lose time switching slots? Can I block or disable the internal mapper (with a programm)? What programs are you running? And under what environment (BASIC, DOS1, DOS2)? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: 2 mapper speed question
On Thursday 31 May 2001 19:36, you wrote: I try to load megaroms with execrom.com or loadrom.com, in dos1 or dos2 On a 8250, under both DOS1 and DOS2 the primary mapper will be your 1024K external mapper. Unless execrom.com or loadrom.com explicitly select blocks from other mapper (unlikely), they will use blocks from the external mapper. So you are probably getting maximum speed already. If the games run too slow, look for cracked versions instead of ROM images. Cracked versions can be faster; it depends on how well the crack was done. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Uzix installation on Novaxis SCSI
On Saturday 26 May 2001 14:09, you wrote: Anyway, the normal program to change partitions with on Novaxis is called MAP.COM or MAP32.COM (most people renamed it to MAP32.COM to avoid confusion with that MAP.COM that fixes direct mapper access in DOS2.). That MAP.COM doesn't fix anything: it's a hack that allows broken programs to run under DOS2. If you run MAP.COM on a turbo R with more than 512K of memory, it will hang the system. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: z80 disassembler
On Wednesday 02 May 2001 10:17, you wrote: Anyone know a good one, or should I start writing my own, or patch z80asm? I am working on a Z80 command line assembler/disassembler in Java. Assembling is about 75% finished, major thing missing is calculating labels and expressions. Disassembling is not started yet, but there is neatly formatted ASCII output functionality that I used to debug the parser. Also, there is the abstract syntax tree implementation from the assembler that can be reused. A disassembler would have to read Z80 opcodes and create the corresponding abstract syntax tree. If you are going to write a disassembler, maybe we can join forces. A license like GPL is acceptable to me. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Self criticisms
On Tuesday 01 May 2001 12:38, you wrote: What Yurei told me was, that he thinks some people, all of them Japanese, are trying to control the MSX users. Why does he think that? It sounds rediculous. We have a quite open discussion with the MSX Revival project. Not only .jp people. It's not really that open. Some people (who?) weren't happy to see Nishi's speech and slides published on the net. Nishi handed out copies of those slides and saw people with microphones recording the speech, so I assume that if Nishi that objected to them being published, he would have said so in Tilburg. The meeting on Sunday was only for people invited. Understandable because of the small meeting room, but far from open. The information given there was not published for the benefit of those not present. Yokoi said things that he would probably not have said in public. The design made by Japanese MSX users was not presented to the Dutch MSX users. Neither directly or afterwards. There is sense in letting two groups develop independently, but it's not open. The fact that MSX Player is in fact fMSX-Intent was not known before Tilburg. Not in Europe, not in Japan. Even Marat didn't know. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: IDE interface not detected
On Wednesday 02 May 2001 02:11, you wrote: - I dumped the content of the area occupied by the IDE interface: All are filled with FFh. Maybe some broken program accidentally wiped the FlashROM. Try to re-flash the IDE BIOS. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Dreamcast video
Hi, The company who designed the Dreamcast video is called Imagination Technologies. So either Nishi got the name wrong, or he was misquoted. http://www.imgtec.com/ Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Full report of Nishi's lecture
On Saturday 21 April 2001 22:30, you wrote: I've just put a (almost) complete report of what Nishi told today at the fair on the MSX resource center (www.msx.org). Nice. If you read anything of which you think I misinterpreted, please let me know. (email is [EMAIL PROTECTED]). I'll post them here instead, so other people who attended can check my corrections. Nishi's goal to realize the single-chip MSX were still on, and he contacted Toshiba to create the chip. They accepted and made a chip which only integrated sound, but not video. Nishi got very angry about that and got a fight with Toshiba. In addition to that, Toshiba asked license costs that were too high for ASCII. Arm is going to be the CPU, Intent and Linux are the OS. MSX one-chip is linux all the way. The one-chip MSX is going to have an ARM core: the ARM processor is included as part of the IC, it's not a separate chip. The one-chip MSX runs Intend on top of Linux, it's not Linux-only. Q: Did you come here just for the fair? A: Yes, I did (editors note: I don't think so) Please tell us your reason for thinking that. It looks strange if you state it this way. Q: They new msx has tv out, why? With radio communication we like to use wireless communication! A: We have a name (nanny) for the microcontroller, it is a nanochip with flash and io but no video. I thought he was talking about a controller (like PSX pad) which is called "Lanny" (it uses wireless LAN). But I didn't hear this part well, maybe I'm completely wrong about this. Q: But what if it becomes very popular, is there no way to competition? A: no. Q: Never? A: I do not want to say never. This part was specifically about competing with PC. Q: What will be the price of the one chip MSX? A: From 15/20$ to 10$ Clarification: that's for the chip itself, not the entire device. The device would be $100 or less. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Pictures of Tilburg 2001 (today) added to site
On Saturday 21 April 2001 22:07, you wrote: I'd agree that's not more than actually marketing his new idea -- which is a nice idea indeed. Assuming this is true, why did he come to Tilburg see 50-odd people to tell us about his new "MSX"? To Spread The Word (word of mouth is very powerful marketing tool of course). Another reason is to tell MSX developers that they can publish their software through ASCII once the MSX Server is up. He claims they want to keep the clockrate of the CPU down to spare battery power, but also want people to program for the thingy in MSX code instead of native 'intend?' code... Seeying that a CPU needs to be between 10-30 times as fast as the original emulated CPU this seems an illogical remark.. I asked Nishi the question "If there is also Linux and Intend on the same machine, why would developers choose to program MSX?". Nishi stated that they didn't have to program MSX, they could choose freely. In practice, this means most developers will choose Intend, because it's easy (compared to plain Linux) and powerful (compared to MSX). MSX emulation is there to allow old games to run and maybe a handful of new MSX productions, but certainly not the majority of software written for this new device. Also, filling the FPGA with MSX related programming is just one of the options. It could also be GameBoy emulation, or video (de)compression or whatever needs relatively simple tasks done at a very high speed. The name "new MSX" is a bit misleading, it's actually a flexible machine that is very suitable for MSX emulation, but is not inherently MSX compatible. It's NOT emulated. The one-chip-solution is on FPGA, which can be loaded with an MSX. So it is NOT emulated; the FPGA can easily handle MSX speeds. As I understood it, the FPGA only handles the performance sensitive parts of MSX emulation, like the VDP and the sound chips. Things like memory, I/O to peripherals, disk emulation etc could be done by the ARM core. Respects go to Nishi though... even though he seems to claim that he invented the wheel from time to time. I had that feeling too; the connection between MPEG and MSX is still unclear to me... Also this one-chip idea -- which is FPGA of course -- is meant to be 100% like the MSX computers we're using now. It will definately be different, for example in the sense that there is no disk drive and no cartridge port. Nishi said that it is possible to create an MSX cartridge adaptor using the USB 2.0 connection, but he clearly did not make a commitment that ASCII would produce such an adaptor. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Pictures of Tilburg 2001 (today) added to site
On Saturday 21 April 2001 23:51, you wrote: Basically I think that making it 'MSX compatible' is a way to reach the by then older group (still large) of 'ex-MSX' users who would get MSX games to play on their new Palmtop for free with the actual computer.. I doubt "for free" will be true. ASCII will want to make some money using the MSX Server and the company who made the game will probably not license it for free either. It's not sure the MSX Player will accept ROM and DSK images from arbitrary sources. Or if for example the games section on funet won't be closed down after pressure from ASCII. As Nischi said he wants to have chips in his shoe.. Many laught but I found this a serious remark. It's certainly possible to put chips there. Maybe even powered by energy from the walking movement. But what useful function can it perform? I have no interest to know how many steps I walked in a day. Maybe runners like to know, but for the average person this is nothing more than a gimmick and the chip will soon suffer from boredom when the user no longer cares about the information it provides. Red Dwarf fans will know the AI Toaster, which is an excellent example of useless embedded technology. A small quote: The toaster is persistent, is apt to remind crewmembers of the last time they had toast, and when you objected (and you surely would), it would become defensive and say, "What's the point of buying a toaster with artificial intelligence if you never want any toast?! I toast therefore I am." (from http://www.sadgeezer.com/RedDwarf/toaster.htm) Sure it will be possible to build a toaster with AI some time in the future. But the whole point is that the AI functionality doesn't make it a better toaster, in fact it makes it quite annoying. In the anecdote about his grandmother using ballpen, calculator, tv and phone instead of a computer, Nishi wondered how he could get her to use a computer. That's a very technologically driven approach: I can create this wonderful device, now how can I get people to use it? One might get better results by doing to opposite: I have this situation, how can I improve it? For example, the TiVo and similar harddisk video recorders solve problems like "I am too lazy to program my VCR" and "I want to see this movie without commercials". What would be better then giving much of these devices a display with interface with basic capabillities all offered by a (in say 2008) a simple but standardized and cheap massproduced chip ? Exactly. eZ80 or similar chips suffice for most IP enables devices. The one-chip "MSX" is unique because of it's FPGA, but that also makes it more expensive and programming the FPGA is more difficult than programming an ordinary processor. So manufacturers will only use it if they can actually do something useful with the FPGA, like signal processing or emulation or anything else that performs poor on CPUs. The idea of reconfiguring a chip to act as another chip is great though. The Atari Jaguar was highly programmable, I think it included a user programmable DSP. Although powerful, it was also more complex than the other systems around and therefore wasn't popular among programmers. (I read this in a FAQ.) The PlayStation 2 is also highly programmable (vector units and the general architecture), but programmers are complaining. So I think a few competent programmers (like Tsujikawa) will create FPGA programs, for MSX emulation, for MP3 decoding etc and most applications will use those through a kind of library. I don't expect an average application to reprogram the FPGA. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX Revival Project - One Chip MSX
On Sunday 22 April 2001 10:08, you wrote: intent by the way is just a uniform os which runs java code. so it's machine-independant. Intent also has its own virtual machine, AFAIK. It's optimized for multimedia, which is an area where Java is not strong. Actually I'm more exited about that one-chip idea that the idea that it has something to do with MSX... Respects go to Nishi though... even though he seems to claim that he invented the wheel from time to time. Bush 'invented' the internet (or was it Gore?). And Gates also 'invented' lots of stuff... That was (wasn't) Gore. I doubt Bush ever invented anything... I think it's strange the computer runs on Linux. First, as far as I know Linux is a Unix-clone for IBM-compatibles. It started that way, but today Linux can run on PowerPC, Alpha, Sun Sparc, embedded devices, even on mainframes (and that's not the full list). The one-chip-msx is not an IBM-compatible. But I guess the name Linux is more common and more 'accessible' to the public than Unix (which sounds even more complex for the common user than Linux does). The average buyer of a device running Linux will probably never notice Linux. And there is no reason they should, an OS should just do its job quietly. Note that on Linux the GUI is separated from the OS, unlike Windows. Second, Intent can run on it's own, it doesn't need another layer like Linux. So why is Linux there? Ah, ofcourse I am glad it is there because it's not a JIT, like Intent is, and therefor faster. But it's less portable. Linux code is pretty portable, but at source level, not at binary level like Java or Intent. Why Linux? Partially marketing: it attracts programmers, others use it (PS2 devkit). Linux is cheap (no license costs). And there is an increasing amount of driver support from manufacturers. the MSX-player is also a platform on which they can experiment with the server-database (or whatever it is called) idea. They call it "MSX Server". The idea of reconfiguring a chip to act as another chip is great though. yess! why waste transistors (hence speed and expandability) on old hardware if you can _perfectly_ emulate it through software??? FPGA uses a lot of transistors as well. And currently unused FPGA gates could be considered wasted transistors, but they are necessary to add new functionality in the future. Also, Nasu informed us today that manufacturing embedded FPGA at an affordable price is not possible yet. It may be possible in the future, Nishi is actually doing research on that at MIT. I doubt "for free" will be true. ASCII will want to make some money using the MSX Server and the company who made the game will probably not license it for free either. It's not sure the MSX Player will accept ROM and DSK images from arbitrary sources. It's based on fMSX so according to the GNU public licence (or whatever it's called) it _must_ be open source. Hence adaptations can easily be made. fMSX is not under GPL. Besides, even with GPL licenses, a piece of software can be released under multiple licenses. Since commercial use is not allowed by the public fMSX license, ASCII will have to buy a license from Marat. Depending on the details of that agreement, ASCII may or may not be required to open up anything. Or if for example the games section on funet won't be closed down after pressure from ASCII. that might be an issue, yes. but instead you will get a huge database featuring those same games. only usable in MSX-Player and One Chip MSX though, yes. but don't forget the Funet CDs... I just wanted to indicate the implications this project could have on the MSX world. Currently no company cares about ROMs on funet, because they don't lose money on it. But if the games are being sold again, their attitude might change. Basically, it depends a lot on how easy it is to use illegal images. Napster was acted upon by record companies, yet binary newsgroups with MP3s still thrive. However, binary newsgroups are too hard for many users, while Napster is easy to use. Copyright holders only care whether the masses are able to copy their product. One problem is that it's almost impossible to make a distinction between illegal images and custom images. What if I want to cheat in some game? I would want to use the modified ROM image in the MSX Player. Or if I made my own game, I want to test that ROM image. So MSX Player should accept custom images, but if it does that, it will also accept illegal images, because it cannot see the difference. eZ80 or similar chips suffice for most IP enables devices. The one-chip "MSX" is unique because of it's FPGA, but that also makes it more expensive and programming the FPGA is more difficult than programming an ordinary processor. So manufacturers will only use it if they can actually do something useful with the FPGA, like signal processing or emulation or anything else that performs poor
Etiquette
Hi, It's probably useful to inform new subscribers about the etiquette of this list, as well as reminding long time subscribers. When writing to the MSX mailinglist, please stick to the following rules: No attachments: If you want to spread files, put them on HTTP or FTP and mention the URL in your message. No HTML mail: Not every mail reader can handle it. It increases message size. And it doesn't really add anything useful to the message. Write in English: Since your message will be sent to all people on the list, make sure they are able to understand it. If you have a message that is only interesting to people in a certain language area, please explain why that is in English and below that you can write the message in Dutch or Portuguese or whatever. It's best to mention it in the subject line as well, for example "[Dutch] I am looking for a ride to Tilburg". Write on-topic: This is not a very strict rule, since a little off-topic discussion can be both interesting and fun. Just don't go too far off-topic. Only write what you think people will be interested in and remember that those people subscribed to an MSX mailinglist. Reply personally if appropriate: If your reply is only interesting to one person, send it to that person directly. Remember that the default reply address is [EMAIL PROTECTED], therefore your reply will go to the list unless you fill in another address manually. Bids on for-sale items and requests to mail files are examples of messages that are better not sent to the list. Don't ask for warez: You shouldn't ask for copies of either non-MSX software or MSX software that is still being sold. I have no problems with requests for out-of-production MSX software, but only if you have done some thorough web searching and couldn't find it anywhere. General netiquette: Don't quote more than you need to. Gather related responses in a single message. Read the FAQ. Be nice to each other. Don't overuse exclamation marks and capitals. Etc. Thanks in advance. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Tilburg?
On Wednesday 11 April 2001 07:40, you wrote: Can the orginizers send a document with all the attendants at the fair and what they will show and/or sell at the fair and where to contact them? I would be most pleased! You should tell them your e-mail address. Your mail incorrectly stated it as [EMAIL PROTECTED] Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Tilburg?
On Wednesday 11 April 2001 17:13, you wrote: Stupid Idea to have an "Open Day" at the same day as the great MSX-Fair in Tilburg! It's probably not an MSX-only club... Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Ys 1 won't save?
On Thursday 05 April 2001 15:38, you wrote: When attempting to save, Ys 1 asks me for a userdisk. When I put in my disk with my SD Snatcher saves or a formatted floppy, it complains of an "invalid userdisk". Can anyone help me? Don't use your SD Snatcher save disk for anything else, or anything else for an SD Snatcher save disk! SD Snatcher saves to sectors and will overwrite any file that happens to be in those sectors. I think a formatted floppy should work for Ys 1. Maybe you have to initialise it from within the game? It's a long time ago I played the game, so I don't remember exactly how it worked. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: HOW to change email adress ??
On Wednesday 04 April 2001 10:40, you wrote: Sorry forgot the tekst :-) butt how do you change your email adress ?? You zubscribe the new address and unzubscribe the old address. The mailinglist info page (see mailinglist signature) tells you how to zubscribe and unzubscribe. I misspelled these words on purpose, because the mailinglist filters them out to block zubscribe requests that are sent to the list. In the future, please send questions about subscription and other administrative tasks to [EMAIL PROTECTED] Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: TILBURG FAIR
On Wednesday 04 April 2001 07:47, you wrote: I heard that there will be a pressconference with ASCII. Is that true. What's the program of that 'special' saturday. There is an archive of this mailinglist at www.msxnet.org, you can find the messages about ASCII and Tilburg there. Since two days I joined the mailing list so maybe I missed that info. I only recieved stuff about 'GAY MARRIAGE'. There is some off-topic discussion on this list, but most is on-topic. It just happens that the last two days were pretty much off-topic. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: NMS-8250/55/80 FDD
On Monday 02 April 2001 17:57, you wrote: Ive read somewhere that the FDD of these computers doesnt have a rubber belt. Is that true? Yes, it's true. They have Mitsumi drives that are much like modern PC drives, although about half a centimeter higher. The drives often develop a problem when ejecting, where the disk is partially thrown out but the internals of the drive go back down again, so the disk is stuck in the drive. But at least their lifespan is longer than that of drives with rubber belts. Mine is still somewhat functioning after 15 years, with 10 years of that in very regular use (I didn't have a harddisk). Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: old games
On Friday 30 March 2001 10:45, you wrote: The other one starts with a spacecraft crash, and you then have to reassemble the pieces of your spacecraft core in order to take off again. The main person is a round ball guy, which can move in two modes, walk and hover. There also are teleport pots in the game, and spots to regen energy. I actually finished this game, I think with help of maps in mccm. (Or did I make my own? :) Maybe this is "Star Quake"? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX-logo
Scan the logo from a manual or something, should be a large picture and scanned at let's say 150dpi. Then start Adobe Illustrator and trace the lines. Now you've got yourself a vector based MSX logo. Resizing doesn't matter anymore, any size will be the right size. Ok, were can I find a free trial version of this adobe ilustrator for i386-linux? or an alternative ? Try it with GIMP :) GIMP is bitmap only, it doesn't do vectors. Well, there is the paths thing, but that's only to create selections; I don't think you can export paths. I think Corel ported their bitmap to vector conversion program to Linux. I doubt it is free though. But cheaper than Illustrator probably. Hmm, that could be kind of a problem ;) You never told us you don't use Windows. I think he did, just not recently. But why do you assume everyone uses Windows? Windows is on about 90% of the desktops; that is a lot but 10% is certainly not neglible. And I dare to say that non-Windows operating systems are relatively popular among MSX users. Anyway, let's leave it at that, before we set off another pro/contra MS flame. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Getdisk
On Monday 19 March 2001 16:33, you wrote: Getdisk in combination with putdisk are the MSX equivalents to DCOPY on the PC. btw, do PC drives read single sided floppies??? The drives do, but some operating systems have problems with the filesystem of a single sided disk. As long as you are reading or writing images, there should be no problems. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Floppy cable not working?
On Friday 16 March 2001 01:02, you wrote: I'm having a problem with the floppy drive cable I (finally) got to connect the new PC floppy drive into my NMS 8250. It only works when hooked up one certain way, where it detects the drive as the B: drive. Part of the cable is twisted, but nothing I do seems to be able to make it recognize is as an A: drive. The cable looks something like this (5.25" connectors are being excluded): Maybe you inserted the connector the wrong way around at both the drive and the motherboard. In that case, the straight wires are right, but the twisted ones are wrong (instead of drive select, some other signals are swapped). Try turning the connectors 180 degrees at both the drive and the motherboard. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Cartridge question
On Tuesday 13 March 2001 13:07, you wrote: Unfortunately, that command doesn't help me much here. The problem is that cartridges use whatever video mode is active when they are booted. Therefore, even though the cartridges were written for NTSC televisions, they boot in PAL on my NTSC television. I was hoping for a way to boot directly to cartridge after I've done vdp(10)=0, so that the 60Hz mode would be conserved; in the softboot, the screen merely returns to 50Hz as it boots up again. Maybe you can modify the BIOS ROM to boot in 60Hz by default. Does anyone know how easy/hard it is to replace the 8250 BIOS by an EPROM? It was done for MSX2 to MSX2+ expansions, so it's possible. Another option is to build a switch on your cartridge port, to enable/disable slot select. Although an 8250 is pretty resilient against inserting cartridges when power is on, it's not something you should do on a regular basis. Using a small machine code program, it's possible to boot most cartridges (only cartridges that use the disk drive fail, like King's Valley 2 and Metal Gear 2). The program looks like this: (programmers, please verify it) SLOT: equ 1 ; Cartridge slot containing ROM org #C000 ; SCREEN 2 - avoid display problems on MSX1 ROMs ld a,2 call#005F ; select ROM in page 1 and 2 ld a,SLOT ld h,#40 call#0024 ld a,SLOT ld h,#80 call#0024 ; get start address and jump there ld hl,(#4002) jp (hl) Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Pool
On Thursday 08 March 2001 15:52, you wrote: I'm making a little pool. Do you mean "poll"? If you want a lot of reactions, maybe it's better to set up a form on a web page. It's possible to have HTML form results sent by e-mail, you don't need any advanced server software to create something like that. Do you think that a MSX2 and 256k RAM are high requirements for Internet access with MSX? MSX2 - no problem 256K RAM - acceptable, altough 128K would be nice The Philips NMS series was sold with 128K and it's the most common MSX2 in the Netherlands, maybe in all of Europe. There are still many machines that didn't receive a RAM expansion. Besides Internet access with MSX, you also get a multitask and multiuser OS. Uzix? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Spam
On Saturday 03 March 2001 17:45, you wrote: This absolutely isn't funny anymore... Agreed. Spamming a mailinglist is bad, but doing it three times on a row is horrible. However, with the current mailinglist software there isn't much I can do about blocking it. Fortunately, I managed to find this company's website hoster (www.cottagesoft.com) and I sent them an abuse report. They advertise with a strong spam filter, so let's hope they are as serious about stopping spam being sent as they are at preventing spam being received by their members. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Putting PC drives in a 8250
On Thursday 01 March 2001 10:53, you wrote: Anway, I added this all to the FAQ, see the misc fAQ section. Could you check for me if it is okay and complete? - This question is not listed in the table of contents (FAQ first page). - These tips also work on the NMS8255 and probably the 8280 as well. - Typo: "(over a length of aboyt 4 cm!)" - If you want to use HD disks in the drive regularly, you also short the sensor that checks for the HD hole. - You could add that it's possible to put two drives on one cable, as long as one reacts to DS0 and the other to DS1. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Putting PC drives in a 8250
On Friday 02 March 2001 01:39, you wrote: I have a question about that; is the flatcable you modify the drive cable itself that connects the drive to the MSX2? Yes, it's the 34-wire cable between the drive and the main board. If you don't want to modify (twist) the cable yourself, you can use a standard PC floppy cable instead. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: SCART to composite
On Wednesday 28 February 2001 18:21, you wrote: Check if there is a D(rive)S(elect) jumper on the diskdrive... many diskdrives do not have jumpers but are soldered (SMD-resistor!). Be sure that DS=0 for drive A en DS=1 for drive B. Good one! I forgot about that. Try [files "B:"] in BASIC and see if the drive reacts. I'm using a PC-like twisted floppy cable in my 8250, but it's been a long time since I opened it, so I forgot about it. I put two drives on a single cable and used the second drive connector to place the jumper over pin 33 and 34. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Konami MSX Antiques - compression
On Wednesday 28 February 2001 18:55, you wrote: I'd like to have a try, just for fun. However, I don't have that MSX Antiques Collection here. Could someone send me a pair of Antiques/Original ROM to my e-mail address ( [EMAIL PROTECTED] )? You can get the compressed ROM from the URL Tristan posted. The original ROM is available on komkon, as AntarcticAdventure.rom.gz. It doesn't matter which pair, I just want to test Maarten's theory... I have been working a bit on a decompression routine since and the theory is wrong. Well, not totally wrong, but incomplete. There are many more encodings in the compression format than I expected. They just don't occur in the first 100 bytes of the file. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: programming question
On Tuesday 27 February 2001 15:33, you wrote:
I have to make a ball disappearing routine just like in puyo
puyo/klax/collumns
and all those other games.
for example, if I have this matrix (serie of ball's):
12436531
14312262
41222432
it has to change in something like this one:
1101
10110011
01000111
Exactly what is your disappearing rule?
It seems that groups of 3 or more balls of the same kind are removed. A group
is a set of balls that are connected horizontally, vertically or diagonally.
I think the union find algorithm works well for this problem. Union find is a
datastructure that devides a set into classes. In this case, the set consists
of all balls and the classes are the groups. Every class is denoted by a
special element, the representant, which is an element of that class.
Here is an implementation of union find in Java:
(excuses for the Dutch comments - this code is taken directly from the
standard algorithms library of our programming contest team)
===
class UnionFind
{
// Datatype waarmee je klassen kunt representeren.
// Ook handig om samenhangende deelgrafen te vinden.
int[] repr;
UnionFind(int nrElem)
{
repr = new int[nrElem];
for (int r=0; rnrElem; r++) repr[r] = r;
}
int find(int elem)
{
// Zoek representant
int r = elem;
while (repr[r] != r) r = repr[r];
// Collapse path
while (elem != r) {
int h = repr[elem];
repr[elem] = r;
elem = h;
}
return r;
}
void union(int k1, int k2)
{
k1 = find(k1);
k2 = find(k2);
if (k1 != k2) repr[k1] = repr[k2];
}
}
class UnionFindTest
{
public static void main(String[] args)
{
UnionFind uf = new UnionFind(100);
uf.union(0, 1);
uf.union(1, 2);
uf.union(2, 3);
uf.union(1, 4);
System.out.println(uf.find(3) == uf.find(4));
System.out.println(uf.find(0) == uf.find(5));
System.out.println(uf.find(3) == uf.find(4));
}
}
===
You start with an empty data structure, that is where every ball is in a
group by itself. Then you iterate over every ball in the field and look at
all its neighbours. For every neighbour of the same color (you used the
numbers 1..6 for this, I'll call it color) you merge the groups with a
union(ball1,ball2) call. When you have done this for the entire field, you
have found all groups: for every ball the representant returned by the
find(ball) call is a ball number that uniquely represents the group that ball
is in.
Now you can count the number of balls in each group: take an array the size
of the number of balls on the screen and zero it out. Then iterate over every
ball, asks its group representant and increase the counter for that
representant. Once you have done this for all balls, the counters beloning to
representants contain the number of balls in that group and the counters
belonging to other balls are still zero.
Now iterate through the balls one last time, for every ball look up its
representant, then look up the group size in the counters array. If group
size = 3, the ball should be removed.
I think it's best to program the algorithm in a language like Java, Pascal or
C first before you translate it into assembly. I think it's possible to merge
the first two iterations: the calculation of the representants and the
counting of the group size. If you need the performance, you can try that
optimization.
I hope I explained it well enough. It's not that complicated, but it's not
trivial either. If you have any questions, please ask.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: programming question - an example
Hi, I'll add an example, I hope that helps understanding the algorithm. I'll take your example game field: (the numbers are the colors of the balls) 12436531 14312262 41222432 I'll label the balls using uppercase letters: ABCDEFGH IJKLMNOP QRSTUVWX The initialisation of the union find data structure creates an array just like the one above: every ball is in its own group and therefore the representant of that group: ABCDEFGH IJKLMNOP QRSTUVWX Now ball A is considered. It has 3 neighbours: B, I and J. Only neighbour I has the same color. So those two belong in the same group and a union call is performed. Now the array looks like this: ABCDEFGH AJKLMNOP QRSTUVWX You'll notice that the I has been replaced by an A, because they both belong to the same group. I could have chosen to replace the A by an I instead, that doesn't make a difference. After processing all balls in the same fashion, the resulting array looks like this: ABCDEFGH ACDLMMOP CAMMMVWP Then the group size counting is performed, this is the resulting counters array: A : 3, B : 1, C : 3, D : 1, E : 1, F : 1, G : 1, H : 1 I : 0, J : 0, K : 0, L : 1, M : 5, N : 0, O : 1, P : 2 Q : 0, R : 0, S: 0, T : 0, U : 0, V : 1, W : 1, X : 0 This leads to the following "removal matrix": 0101 00110011 0111 Balls belonging to groups A, C and M should be removed. I noticed that your removal matrix looks a bit different: 1101 10110011 01000111 In this matrix, group A isn't removed. Is that a mistake in your example or did I misunderstand your removal rule and should group A in fact not be removed? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: programming question
On Tuesday 27 February 2001 16:28, you wrote: I was thinking about an algorithm similar to the maze-pathfinder... Percolation... Recursive What about that, oh great programming guru Maarten? That's possible as well, to use a recursive flooding algorithm. But I think it's messier to implement, especially in assembly. You have to remember the points you already visited, otherwise you could end up in an infinite loop. And in assembly recursion isn't as easy as in a higher level programming language, you have to stack the local variables manually. And make sure it all fits on the stack. Duh - ripping an Java algorithm of the internet and presenting that on a silver platter is not the essence of a 'programming guru'. That's more like 'script kiddie'... Eric (*real* programming guru) huge ;-) /huge dutchIk moet toch even happen.../dutch (inaccurate translation: I can't resist to react) I wrote that I took it from our standard algorithms library. Guess who put the algorithm in there... Anyway, it is an existing standard algorithm and real programming gurus know they shouldn't re-invent the wheel. ;) Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: programming question - an example
On Tuesday 27 February 2001 16:50, you wrote:
your "ballremoving" routine was very nice, but actually I only want the
balls to be removed, if there are 3 or more balls
connected to eachother horizontally, vertically or diagonally.. (and if
some of these balls have neighbours with the same
color, they have to be removed too)
OK, it can be fixed.
The first step, calculating representants using union-find, is unmodified.
After this step you know all the groups. The group size is no longer
relevant, so the old second step is scrapped, as well as the old third step.
The new second step is to search for lines of 3 balls on a row, you can do
this easily by doing a linear search for every ball in 4 directions:
right-up, right, right-down, down (or 4 other directions, as long as they
represent the entire 8-direction star). You can do the search using a single
routine, with delta-x and delta-y as parameters.
Example: ("o" is the ball in question, "x" are balls searched, "-" are balls
not seached)
- - - - x
- - - x -
- - o x x
- - x x -
- - x - x
You don't have to search every direction because they are searched from the
ball on the other end of the line. (A line walked in the opposite direction
is still the same line, no need to check it twice.)
A simple trick is to use sentinels: mark the edge of the playing field with
balls of a color that doesn't occur in the game. Now you no longer have to
check for the coordinates being outside the playing field, instead you can
rely on the fact that no line will ever extend beyond the border of sentinel
balls.
Example: (this is the bottom part of a playing field)
9 1 2 2 3 4 9
9 2 1 2 4 3 9
9 2 2 1 4 1 9
9 9 9 9 9 9 9
Here the balls of color 9 are the sentinels. They also help in other places.
For example, gravity doesn't cause balls to fall out of the playing field,
because the lower line of sentinels will stop them (no coordinate checking
necessary). Also, the side walls form barriers when calculating whether a
sideways move (by the player) is possible.
If balls diagonally connected to a line of balls are neighbours, you only
have to search for lines of length 3. If balls are only considered neighbours
if they are horizontally or vertically next to a line, you should search for
the longest possible line.
All balls on the line are marked for removal, as well as all balls in the
same groups as these balls. An easy way to implement this is as follows:
Step 3a: for every ball on the line, mark its representant for removal.
Step 3b: for every ball, check if the representant is marked for removal, if
it is, mark the ball itself for removal as well.
There is a very useful optimization you can use: once you have all the
datastructures for the current game field, re-use them when the next balls
are dropped. You don't have to recalculate everything, you can apply the
group calculation and the line searching only for each of the new balls. Note
that in this case you do have to search lines in 8 directions, searching half
of them is no longer sufficient because there is no search initiated from the
balls on the other end of the line.
Whenever you remove balls, you will have to recalculate everything. However,
a game typically displays an animation when this happens, so you'll have some
spare CPU time to do the calculation.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: SCART to composite
On Wednesday 28 February 2001 01:38, you wrote: Well, I bought the thing a new floppy drive, connected pins 33 and 34 of the main board (where it connects to the cable) with a jumper, connected it... nothing. It still complains about "disk offline". Any ideas, anyone? Does the drive spin when you access it with a disk in it? Does the drive LED turn on when you access it? And when you don't, is it off? You are using a DD disk, not a HD disk, are you? Can you format a disk? (use CALL FORMAT from BASIC) Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: SCART to composite
On Saturday 24 February 2001 20:39, you wrote: I already have a cable that plugs into the SCART port on the MSX2, and on the composite plugs on the television. This outputs an RGB signal, and, since RGB is the same for either PAL or NTSC, I should be getting the image, displaying in proper colours, correct? (It would still be rolling until I use vdp(10)=0, of course.) If the cable plugs into the composite input of the TV, it cannot possibly deliver a RGB signal. Like Maico Arts said, a SCART plug contains both RGB and composite signals, your cable is probably using only the composite signal. I think the only way to get color from a 8250 on an NTSC display is find a monitor or TV with RGB input. I'm running NTSC PlayStation games on my PAL TV using an RGB cable with no problems. However, I did need to buy an RGB cable, the cable that came with the PlayStation is one with a three tulip plugs to SCART converter, which only supplies composite video. It may be possible to adapt the 8250 internally to change the color encoding, but I have no idea how difficult that is. I do know that the 8250 has a rather large audio/video board (the orange one above the green main board), it has few integrated components there so replacing the color encoding is probably not too hard once you know how. About the disk drive: AFAIK, 8250 drives don't have a rubber belt. The rubber belt problem occurs with the 8235/8245 and the turbo R models. You can easily replace a 8250 drive with a standard PC disk drive. The only modification you need, is to place a jumper over pin 33 and 34 of the second drive connector on the main board. Pin 33 is ground and pin 34 is /RDY, the ready signal, a signal that modern PC drives no longer have. Connecting the pins will tell the 8250 that the drive is always ready, the 8250 DiskROM has no problems with that. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Konami MSX Antiques - Emulator
On Saturday 24 February 2001 08:11, you wrote: I wonder why they chose to compress the ROMs, there is plenty of space on a CD to store a couple of MSX ROMs. So people wouldnt use em on real msxes? Just a guess ;-) Well, there are plenty of sites with the ROMs on the net, it's rather pointless to take a lot of trouble to rip them from the Antiques CDs. It could also be to make it harder to replace the ROMs with other MSX games and create your own Antiques collection. However, encryption would have done a better job than compression, especially this compression format which isn't too hard to reverse engineer. Really strange to compress the files, when a dummy block of app. 16MB can be found on the CD. This has no meaning :-(. For some reason the PSX can't read the final part of a session. Therefore all games should have dummy data at the end of their session. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: FDD belt
On Friday 23 February 2001 17:50, you wrote: Something about the HB-F1XDJ FDD: http://www.amy.hi-ho.ne.jp/nakajima-jr/com/xdj.htm At the above page you can also see that theres a schematic about a RGB-SCART japanese connector. Japanese RGB21 is not SCART. The connector is the same, but the signals are on different pins. Takamichi found out when the GFX9000 cable didn't work on his TV. If you compare the table on the above page with a SCART description, you'll notice it's wired differently. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Konami MSX Antiques - Emulator
On Friday 23 February 2001 17:28, you wrote: The antiques collection ROM format is a type of compressed file, when rom is loaded in PSX memory, is exectly the same to original rom. That's interesting. Do you know what kind of compression algorithm it is? I wonder why they chose to compress the ROMs, there is plenty of space on a CD to store a couple of MSX ROMs. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Konami MSX Antiques - compression
Hi, The antiques collection ROM format is a type of compressed file, when rom is loaded in PSX memory, is exectly the same to original rom. It turns out there are two different versions of Antartic Adventure. The one called AntarcticAdventure.rom on komkon is the one used in the Antiques collection. I have a guess about the compression format. The base unit is one byte. Repeated patterns are encoded by storing a length and offset into the already unpacked data. The meanings of the various bytes are: : special/unknown 11nn: uncoded, length=n+8 10nn: length=n+2, offset=d+1 0nnn : length=n+3, offset=d So far the #FF byte seems to have no meaning, but I doubt Konami doubt have put it there if it was useless (it's compression after all). I found the table above by manually examining the first #60 bytes (approximately). To verify this theory, a program must be written that attempts to unpack the file using the codes in the table, then the unpacked file must be compared to the Antarctic Adventure ROM. I'm sleepy so I won't write that program now, feel free to write it yourself and post the results. If no-one writes it tomorrow I might have a go at it on Sunday. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Konami MSX Antiques - compression
On Saturday 24 February 2001 04:03, I wrote: The meanings of the various bytes are: : special/unknown 11nn: uncoded, length=n+8 10nn: length=n+2, offset=d+1 0nnn : length=n+3, offset=d I read this again and I guess it isn't really clear. "Uncoded" means that after the byte that contains the length, there will be that many raw bytes, bytes that can be copied directly to the output. Example: C1 01 02 03 04 05 06 07 08 09 The C1 announces 9 (1+8) uncoded bytes, which follow directly after. The bottom two cases are repeated patterns, if such a code is found while the current output address is X, then output[X-offset,X-offset+length) must be copied to output[X,X+length). Note the interval notation: including start index, excluding end index. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Snatcher translation...
On Tuesday 20 February 2001 12:12, you wrote: Just want to know if anyone ever visits http://SnatcherTranslation.cjb.net ... We really need to get that game translated, please help by visiting... Well, just visiting won't get the game translated. Recently someone asked about progress on the Snatcher translation mailinglist, the text below is taken from my reply. === To do the reverse engineering efficiently, we need an emulator that has good debugging functionality and a save state option. Debugging is necessary to see what Snatcher is doing, save state is necessary to test translations without having to restart Snatcher every time: using the Snatcher save system is too tiresome. Preferably the emulator source is available, so Snatcher specific debugging code can be added. fMSX has source available and a primitive debugger, it would need a better debugger and save states added. MESS has a good debugger according to Sean, but MSX2 support is incomplete and there is no save state option either. I don't know about the Windows emulators, because I do all MSX development in Linux nowadays. [Addition: Some people replied that RuMSX has both a save state option and a built-in debugger.] The reverse engineering itself is difficult because Snatcher apparently keeps almost everything in a single data structure. Not just the texts, but also the menus, the animation scripting, the game scripting etc. Anyway, that's the impression I got when I was hacking at it, because I didn't understand all of it I cannot be 100% sure. As you may know, Japanese is a lot more compact than English. So the translated text will take more space than the original text. I already know how to replace any Snatcher text with an English text of equal length, but that's not good enough. Fortunately, Snatcher uses 2-byte characters but also supports the display of 1-byte characters. So a factor 2 is saved by using the Latin alphabet (as English does), but a factor 2 is not enough. There are three ways to solve this: 1. Shorten the English text: leave out parts of the messages. 2. Compress the English text. 3. Increase the available space: re-arrange the Snatcher data. It's possible to use a combination of methods. Shortening should be avoided as much as possible, otherwise the quality of the translation will be poor. It's probably impossible to create a good translation by using only shortening. Compression requires a few modifications to the Snatcher routines. It's a pretty useful method, but there are limits to how tight you can compress text with simple algorithms. And complex algorithms need too much changes in the Snatcher routines. Increasing the space is done by gathering unused space and taking advantage of space saved elsewhere. Extra space must be freed both on disk and in memory in order to be useful. In memory, a lot of space (about 20 to 30K, I forgot the exact amount) can be freed by removing all kanas and kanjis from the font. On disk, we'd have to look for empty sectors and parts of script sectors that are unused. The largest problem is rearranging all data so that the extra space is located in a useful place: it's useless to have small empty areas all over the place, it has to be concentrated. When the data is rearranged, the game should know the new location of the data. Those pointers should be calculated automatically, because calculating by hand is a lot of work and error prone. So there is a lot of reverse engineering and tool building needed to make this work. Note: On Solid Snake, we (Takamichi and I) used all three methods. Oasis only used shortening. I hope this info will help you in understanding where the problems of Snatcher translation are. === There is an overwhelming public interest in a Snatcher translation. However, enthousiasm alone doesn't get the job done. There are concrete problems to be handled, only if those are solved the translation can become a reality. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
