Dutch: MSX for SALE
Aangeboden: Msx Computer Prijs: FL 500.- MSX 8280 scsi hd 60 Mb scsi cdrom scsi interface muziek module fm pack Dos 2.2 Home office Kleuren monitor Muis joystick + spellen (div ) printer star NL 10 Prijs totaal FL500.- kk M. van den Oever Ollandseweg 67 5491 GR St Oedenrode. Tel 0650884243 -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Disk-Drive is making nosie and is no longer reading disks!
Em dom, 21 jan 2001, Mari van den Broek escreveu: > When I insert a disk in the disk-drive of my Panasonic FS-A1GT and type the > command "files" the disk-drive is making noise and I get a "disk-offline" > message! > > It does that with all the disk I put in the disk-drive... > > I allready tried cleaning the heads of the disk-drive, but that doesn't seem > to work... Is it possible that the belt that drives the disk isn't of the > correct lengt and tension? > > Maybe someone reading this message has a solution to get my Turbo-R going > again... It seems to be the disk-drive strap, which is old and maybe rotten. -- Ricardo Jurczyk Pinheiro - M. Sc. Numerical Modelling - [EMAIL PROTECTED] - 3635907 [EMAIL PROTECTED] - Anime, ABU, MSX, Linux, Gospel, ST, Rock, Math Sola Scriptura - Sola Gratia - Sola Fide - Solo Christi - Soli Deo Gloria Any socialism involves more slavery than democracy. -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: IDE interface trouble with CD-ROM
Em dom, 21 jan 2001, Bjørn Boye Skjoldhammer escreveu: > IDE standard says that the cable must be no longer than 50 cm. > Maybe your cable is too long? > > BTW does anyone know why the limit is 50cm?? IDE wasn't done to be used in peripherals which are outside of the PC cabinet. SCSI, otherwise, can have much longer cables. I've a 2 m SCSI cable, and I think Maarten - or was Alex Wulms - has a 6 meters-long SCSI cable. ByE! -- Ricardo Jurczyk Pinheiro - M. Sc. Numerical Modelling - [EMAIL PROTECTED] - 3635907 [EMAIL PROTECTED] - Anime, ABU, MSX, Linux, Gospel, ST, Rock, Math Sola Scriptura - Sola Gratia - Sola Fide - Solo Christi - Soli Deo Gloria C:\WINDOWS;C:\WINDOWS\RUN;C:\WINDOWS\CRASH;DEL *.* -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
- Original Message - From: "Manuel Bilderbeek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 22, 2001 8:00 PM Subject: Re: extended ROM format > > > Afaik, there is no ROM in PAC (only 8KB SRAM). > > What is the trick to dect the SRAM? > > > I have somewhere a program for dos to save/load SRAM saves from PAC. > > I also have such a program, but I think it is in Dutch or English. It is on > my > harddisk somewhere... The program itself is in english. I´ll have too look up if the manuals are also in english, maybe you´re right. But it´s written by a jap. guy... > > > There is sourcecode for it too. The documentation is in jap. If someone = > > is interested I can put it on my page. > > Well, why not? > Ok, I´ll put in online when I update my msx hp. > > Has someone got a translation of the original jap. FM-PAC manual? > > I will attach (I guess this small file is okay, it is only 4224 bytes) a text > made by Takamichi that explains the FM-PAC commander's messages. I also have > a > translation of the manual itself somewhere on my harddisk again... If you > like > I can try and find them this weekend. Would be wonderful to get it :-)) > > > I=B4m interested in the pages which explain the PAC copy functions and = > > about blocks on p. 23 > > Well, that manual is a joke, actually. It is about a magical wizard, see > below. > > Can someone confirm if there is ROM in the PAC? Is there a way to manage the > PAC data like in the FM PAC? Greetings from Bjørn Boye Skjoldhammer How to contact? See: http://www.geocities.com/msxtrd/data.html ICQ #20449307I have the opened cartridge in front of me, I see: SMD chip DAMB8674175UJ 8806 Z08 ? Some controller for SRAM?? D4464C-15L 8801PU772 This must be the 64kbit SRAM IC A lithium battery > > Grtjs, Manuel > > PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/) > PPS: Visit my home page at http://bilderbeek.cjb.net/ > > Here's the text: > > > fmpactransl.txt > > Translations of Messages shown by FMPAC > July 26, 1998 by Takamichi > >Overview > > Internal file management software of FMPAC is called > Pac Commander. To boot the software, insert FMPAC into MSX, > turn on the power, then type in CALL FMPAC from BASIC. > > Messages in Pac Commander assumes that MSX is a wizard who is > managing FM-PAC. Sections names in the initial menu screen > are called "spells". > My comments are enclosed by []. > > Decision; SPACE = yes, ESC = no. > Also, a dialogue window on upper-right shows "Yes" and "no". > Use cursor key to select, and then SPACE. > > "PAC" might be either a FMPAC, or PAC without FM module. Slot > spell is invalid if anything other than one single FMPAC is > inserted to MSX, though. > > Slot no. that Pac Commander indicates may be different with > actual slot no. of your MSX. This is why Slot spell is necessary. > Pac Commander always uses slot no. shown with slot spell. > > Change spell swaps entire contents of two PACs. > ---Spell menu > Clear > Copy > Change > Delete File > Slot > Background Music > ---Spell 1: Clear > MSX said, "Password and data at Slot n disappear. OK?" > [n stands for slot no. which FM-PAC is inserted in] > --Press SPACE > MSX used Clear magic. > Pf. > ---Spell 2: Copy > PAC -> PAC > PAC -> Disk > Disk -> PAC > --PAC -> PAC > What is PAC you copy from? > --Choose a PAC you want to copy from. > [If 3 or more PAC are present] > What is PAC you copy to? > [choose a PAC you want to copy to.] > MSX said, "Password and data at destination (n) disappear. OK?" > [n stands for slot no. where destination PAC is inserted in] > --Press SPACE > MSX used Copy magic. > Pipipipi, copy > --PAC -> Disk > [Prompt for file name appears] > Destination file: > --Input file name; use BS key to delete a character > --Press SPACE > MSX used Copy magic. > Pipipipi, copy > --If there are already existing data, their list appears. > --Overwrite; move cursor to the file you want to overwrite and press SPACE. > MSX said, "Overwrite . OK?" > [ = file name.] > --Disk -> PAC > [PAC can use only drive a:] > [A list of data files appear] > [Move cursor to file name you want to copy from] > Original file: > --Press SPACE > MSX said, "Password and data at destination (n) disappear. OK?" > [n stands for slot no. where destination PAC is inserted in] > --Press SPACE > MSX used Copy magic. > Pipipipi, copy > ---Spell 3: Change > --Press SPACE > [Valid only if there are two PACs] > MSX used Change magic. > Chachacha, change!! > ---Spell 4: Delete file > [List of files appears] > [Move cursor to the file you want to delete] > MSX said, "Delete . OK?" > --Press SPACE > MSX used Delete File magic. > Dee, lee, tee!! > ---Spell 5: Slot > [Invalid if there are more than one FMPAC] > MSX used Slot magic. > MSX said, "PAC is in slot (n). Did you write it down?" > [n stands for slot no. where your FMPAC is inserted in] > ---Spell 6: Background Music > Samp
Re: MSX game format example
On Monday 22 January 2001 20:39, you wrote:
> What about Required=SCC ? I need to make some tests, but I believe
> the game will not run if the SCC mapper is not present (by SCC mapper
> I mean the bankswitch when you write 3F to the last bank register).
> Even if the users wants to turn off SCC due to performance problems,
> I believe the mapper still needs to be present, so the SCC must
> have Required status.
Maybe we're putting SCC into the wrong category. The "Required", "Optional"
and "Extra" keywords are used for describing the system the cartridge can run
in. SCC is part of the actual cartridge. For a disk-based software (a game by
TeddyWareZ or an SCC demo) the SCC is a system requirement. For Konami SCC
cartridges, the SCC is inside that cartridge. We're not specifying
"Required=MegaROM mapper" either.
> I don't like the idea of making GM2 an Optional. I think Game
> Master should be mentioned in the Comment field of the database server,
> but not listed inside the msxsoft.ini.
GM2 can be used in two ways: as a separate software (to run the built-in
games or to cheat) and as an SRAM cartridge, like the PAC. If it's used as an
SRAM cartridge, not the entire GM2 is used, only a signature ("YZ") and a
handful of routines. The emulator wouldn't even have to load the entire GM2
ROM, I think a single 8K block is sufficient.
I agree that the complete GM2 should be considered a separate software. But I
do think that the GM2 as an SRAM cartridge should be an option. It's a way of
saving rather than a piece of software. Just like the disk ROM, which can be
located in a cartridge, but we don't think of it as a separate program.
> If we allow GM2 inside the ini,
> then we should also make things like this...
>
> Name=Salamander
> Required=MSX
> Required=SCC
> Optional=Nemesis 2
> Optional=Penguin Adventure
>
> ...and I don't think this is a good idea. Things like that should
> belong to the .msx database.
This is much the same case as the GM2. To activate the combo secrets, you
only need a cartridge signature ("AB" at #4000 and "CD" plus the right RC
code at #4010). The ROM of the combo game isn't needed, only the RC number.
By the way, what does Salamander do when Penguin Adventure is found?
> > The "5000-57FF" notation is easier to read, but it's not equivalent to
> > the "5000/07FF" notation.
>
> What about preserving the 5000-57FF notation, but require
> the values to be valid addr/mask pairs ? In this case 5000-57FF
> would be a valid argument but 1234-5678 would not.
That would be possible, but I'm not sure it's actually much of an advantage.
It's easier to read "5000-57FF", but when writing an info file the creator
must think "is this possible as an addr/mask pair"?
Also, what happens if some cartridge disregards A12..A1 but does care about
A0? Using the range notation, you would need 4096 lines to describe it. The
advantage of the addr/pair notation is that it is closer to the hardware.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format continued
On Monday 22 January 2001 20:11, you wrote: > > Because errors should be caught before the file is distributed, I propose > > that an emulator should abort on any error in a .msx file. Aborting means > > it should abort the starting of the game, it doesn't necessarily mean it > > has to abort the emulator program. > > Uh... I guess it would be better only issuing > a warning to the user, but trying to go on with > emulation. Of course, this would be at program- > mer's criteria, but it's more useful to us. > Just in case we, final users, want to do some > fiddling with .msx files... =) But if you changed something in a .msx file and it's an error, do you really want to continue emulation? Or do you want to fix the error and try again? Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Monday 22 January 2001 20:20, you wrote: > > What about Required=SCC ? I need to make some tests, but I believe > > the game will not run if the SCC mapper is not present (by SCC mapper > > I mean the bankswitch when you write 3F to the last bank register). > > Even if the users wants to turn off SCC due to performance problems, > > I believe the mapper still needs to be present, so the SCC must > > have Required status. Until recently, fMSX didn't support the reading of the SCC instrument data. This broke SCC autodection algorithms, but all Konami games ran without problems. Nemesis 3 will run with just the mapper description. > SCC has two functions: sound processor and MegaROM mapper. > It's necessary as a mapper, but not necessary as a sound > processor (although it's recommended). I think it's weird > to treat it as one sole thing. In a real cartridge, of > course SCC is one IC, but these are two functions to be > emulated. I don't know if I can make myself clear about > this point... The mapper and the sound part are not 100% independant: they share the same address space. After all, the SCC is located in mapper page #3F. And its instrument data is overlayed over the data in the ROM; in the Solid Snake cartridge or a 512K ESE-SCC, you can witness that behaviour. I agree that we should try to separate the sound part of the SCC from the mapper part as much as possible. But it's not immediately clear where the separation line is. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
> What about Required=SCC ? I need to make some tests, but I believe > the game will not run if the SCC mapper is not present (by SCC mapper > I mean the bankswitch when you write 3F to the last bank register). > Even if the users wants to turn off SCC due to performance problems, > I believe the mapper still needs to be present, so the SCC must > have Required status. SCC has two functions: sound processor and MegaROM mapper. It's necessary as a mapper, but not necessary as a sound processor (although it's recommended). I think it's weird to treat it as one sole thing. In a real cartridge, of course SCC is one IC, but these are two functions to be emulated. I don't know if I can make myself clear about this point... And, please, don't forget SCC+. =) []s, -Parn (ICQ#1693182) /| | | |\ \| ___ |/ http://parn.overclocked.org/ \/ - \/ Parn's Music Station | | Game Music XMs and more! -- --Izati Aba Mehinam Eto Kafe Nan -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
Manuel Bilderbeek wrote: > Another thing: if you have a game of e.g. 3 disks, > how can you ever decompress it on MSX? It would > take ages to decompress Probably you would download it with a faster computer anyway, and nothing would really stop you from uncompressing it (usually they're not distributed as .DSK files, but as .LZH or .ZIP files, or even .GZ) with this faster computer. > If you want to do this still, the .msx format is not really usable on real MSX > computers. That is a real pity. I would need other hardware (pc e.g.) to > extract the stuff and use it on my MSX... Well, .ZIP is also unusable, and .LZH is not very practical when using .DSK files. It's OK for ROMs, but not very usable for people without hard disks. I personally would always use the PC for this kind of job. []s, -Parn (ICQ#1693182) /| | | |\ \| ___ |/ http://parn.overclocked.org/ \/ - \/ Parn's Music Station | | Game Music XMs and more! -- --Izati Aba Mehinam Eto Kafe Nan -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format continued
Maarten ter Huurne wrote: > Because errors should be caught before the file is distributed, I propose > that an emulator should abort on any error in a .msx file. Aborting means it > should abort the starting of the game, it doesn't necessarily mean it has to > abort the emulator program. Uh... I guess it would be better only issuing a warning to the user, but trying to go on with emulation. Of course, this would be at program- mer's criteria, but it's more useful to us. Just in case we, final users, want to do some fiddling with .msx files... =) []s, -Parn (ICQ#1693182) /| | | |\ \| ___ |/ http://parn.overclocked.org/ \/ - \/ Parn's Music Station | | Game Music XMs and more! -- --Izati Aba Mehinam Eto Kafe Nan -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format continued
On Mon, 22 Jan 2001, Pablo Vasques Bravo-Villalba wrote: > I believe this format only > supports one .ini file, am I right? If so, then > it wouldn't matter the name (nemesis3.ini, > gofayabo.ini and such): it just would be neces- > sary to scan for an .ini file and use it. I don't think we will ever need two .inis in a single package, so this solution can work. The name of the ini file can be the same as the GameID, so in the case of Penguin Adventure we would have a penguin_adventure.msx containing: penadv.ini penguin.rom sshot.png Ricardo Bittencourt http://www.lsi.usp.br/~ricardo [EMAIL PROTECTED] "Ricardo is subtle, but malicious he is not" -- Uniao contra o forward - crie suas proprias piadas -- -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format continued
Ricardo Bittencourt Vidigal Leitao wrote: > > If we stick to 'msxsoft.ini' or 'msxgame.ini' or something like that, it will > > be just a matter of time before for example a nemesis3.msx file exists on the > > internet that actually has the ini definition for aleste2 Besides, it's bothersome if we, for some reason, want to do some batch processing and unarchive some .msx files in a directory, everything turns into a big mess. I believe this format only supports one .ini file, am I right? If so, then it wouldn't matter the name (nemesis3.ini, gofayabo.ini and such): it just would be neces- sary to scan for an .ini file and use it. It's also easy to work around this if we really need to use more than one .ini file. []s, -Parn (ICQ#1693182) /| | | |\ \| ___ |/ http://parn.overclocked.org/ \/ - \/ Parn's Music Station | | Game Music XMs and more! -- --Izati Aba Mehinam Eto Kafe Nan -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Mon, 22 Jan 2001, Maarten ter Huurne wrote: > (about equal signs inside comments) > You are right, it is possible. But we would still have to document which > characters can and cannot be at the start of a keyword. I think a single > comment style would be simpler. Then let's just make ";" our comment delimiter and that's it. > > Name="Nemesis 3" > > Required=MSX > > Optional=SCC > > Optional=MSX2 > > And also 'Optional=GM2' for Game Master 2. However, I do feel that SCC is > more needed than the other two, so it seems wrong to have them in the same > level. For one, SCC is part of the Nemesis 3 cartridge, so the real thing > cannot be run without SCC. What about Required=SCC ? I need to make some tests, but I believe the game will not run if the SCC mapper is not present (by SCC mapper I mean the bankswitch when you write 3F to the last bank register). Even if the users wants to turn off SCC due to performance problems, I believe the mapper still needs to be present, so the SCC must have Required status. I don't like the idea of making GM2 an Optional. I think Game Master should be mentioned in the Comment field of the database server, but not listed inside the msxsoft.ini. If we allow GM2 inside the ini, then we should also make things like this... Name=Salamander Required=MSX Required=SCC Optional=Nemesis 2 Optional=Penguin Adventure ...and I don't think this is a good idea. Things like that should belong to the .msx database. > The "5000-57FF" notation is easier to read, but it's not equivalent to the > "5000/07FF" notation. What about preserving the 5000-57FF notation, but require the values to be valid addr/mask pairs ? In this case 5000-57FF would be a valid argument but 1234-5678 would not. > Multiple access methods to a single mapper register is a rare thing, I don't > think we have to create special syntax to make its notation shorter. I think one of our goals is to make the syntax as simple as possible, so the notation I introduced in the last email cannot be used, since it is redundant. In this case let's forget about that. Ricardo Bittencourt http://www.lsi.usp.br/~ricardo [EMAIL PROTECTED] "Ricardo is subtle, but malicious he is not" -- Uniao contra o forward - crie suas proprias piadas -- -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> ]] If you want to do this still, the .msx format is not really usable on real > MSX > ] computers. That is a real pity. I would need other hardware (pc e.g.) to > ] extract the stuff and use it on my MSX... > You need other stuff (unix, mac, linux, windoze) anyway to download it from > the internet. So, if some general tools are available to extract .dsk or .rom With Uzix, that will change really soon. And who prevents spreading those .msx files on cds (readable by MSX) or just on floppy disks? > from the .msx file, you can use those tools to extract the relevant > information to your msx. So, apart from letting them be used in emulators, there should be tools to use them on MSX. But okay, just doing unzip would of course be enough, right? It would be cool to have a .msx file creator for MSX. Insert a cart or rom in the MSX and ask some parameters to the user, and the program makes the necessary files in the right syntax. Then you can zip it on the MSX (if you are very masochistic and someone made the right software) or you move the uncompressed stuff to a pc (or so) and zip it there... Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/) PPS: Visit my home page at http://bilderbeek.cjb.net/ -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format continued
On Mon, 22 Jan 2001, Alex Wulms wrote: > nemesis3.msx > contains > nemesis3.ini I don't think this will work. As defined before, filenames inside the .msx archive must be 8.3 names, however names outside the .msx archive can have any size. We could have nemesis_3_the_eve_of_destruction.msx and it would be a valid archive. > If we stick to 'msxsoft.ini' or 'msxgame.ini' or something like that, it will > be just a matter of time before for example a nemesis3.msx file exists on the > internet that actually has the ini definition for aleste2 I think that's why Maarten proposed a "test phase" for every .msx game. The game would be exaustively tested before it is released, so this kind of mistake should not happen. Ricardo Bittencourt http://www.lsi.usp.br/~ricardo [EMAIL PROTECTED] "Ricardo is subtle, but malicious he is not" -- Uniao contra o forward - crie suas proprias piadas -- -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
On Sun, Jan 21, 2001 at 12:07:48PM +0100, Jose Angel Morente wrote: > > o Like mentioned above, two games I know of have a D/A. > > Almost three. Playball (the MSX1 32K one) has a DAC as well :) I've been playing around with this game, and it only seems to be writing a few bytes to 7fffh: Write 06 to 7fff in cartridge slot #1 Write 06 to 7fff in cartridge slot #1 Write 06 to 7fff in cartridge slot #1 -snip- Write 02 to 7fff in cartridge slot #1 Write 02 to 7fff in cartridge slot #1 Write 02 to 7fff in cartridge slot #1 -snip- Write 0a to 7fff in cartridge slot #1 Write 0a to 7fff in cartridge slot #1 Write 0a to 7fff in cartridge slot #1 -snip- Write 09 to 7fff in cartridge slot #1 Write 09 to 7fff in cartridge slot #1 Write 09 to 7fff in cartridge slot #1 Does anyone know if my rom dump is bad, or how this D/A works? Cheers, Sean -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
] On Sunday 21 January 2001 23:27, you wrote: ] ] > You can use xsc/xsd compression algorithm. Sources can be found on "The MSX ] > Plaza" in the section "XSA format". ] ] Thanks, I'll keep that in mind. Is XSA compression only (like gzip and bzip2) ] or does it handle multiple files as well (like ZIP and LZH)? ] ] However, I think that the final standard will be a lot like the proposal by ] Ricardo, meaning it will use an archive and a text-based info file. If that ] approach is used, it's easier to use an archive format that is already ] wide-spread. XSA would be a good choice if the format can only be edited ] using special tools. XSA header supports multiple files if needed (the A stands for archive...). However, I'm not proposing to follow XSA format but to simply use my compression/decompression algorithms inside the .msx file archive. Advantage of my algorithms: They are fast (on MSX reading and decompressing files from floppy is faster then reading uncompressed files from floppy). They do not need much memory. Compression needs a small buffer and decompression does not need any extra memory. Apart from the generic cross-platform C implementation, there is also an MSX specific assembly implementation. Disadvantage: Compression ratio is less then gzip or pmarc. It is somewhere between popcom and pmarc. Kind regards, Alex Wulms -- Visit The MSX Plaza (http://www.inter.nl.net/users/A.P.Wulms) for info on XelaSoft, Merlasoft, Quadrivium, SD-Snatcher on fMSX, the MSX Hardware list, XSA Disk images, documentation, Japanese MSX news from Ikeda and lots more. -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format continued
] I prefer "Unified MSX Format". There's no need to insert "game" ] in the name, since the format can be used for apps that are not games. ] However, which would be the name of the ini file? msxgame.ini would ] not be acceptable anymore, what about msxsoft.ini ? .msx contains ini file .ini E.g. nemesis3.msx contains nemesis3.ini This makes it easier to manage the .msx files. Especially if you are creating or extracting many .msx files at the same time it can be very confusing if they all contain an ini file with the same name. If we stick to 'msxsoft.ini' or 'msxgame.ini' or something like that, it will be just a matter of time before for example a nemesis3.msx file exists on the internet that actually has the ini definition for aleste2 Just my 2 cents. Kind regards, Alex Wulms -- Visit The MSX Plaza (http://www.inter.nl.net/users/A.P.Wulms) for info on XelaSoft, Merlasoft, Quadrivium, SD-Snatcher on fMSX, the MSX Hardware list, XSA Disk images, documentation, Japanese MSX news from Ikeda and lots more. -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
]] If you want to do this still, the .msx format is not really usable on real MSX ] computers. That is a real pity. I would need other hardware (pc e.g.) to ] extract the stuff and use it on my MSX... You need other stuff (unix, mac, linux, windoze) anyway to download it from the internet. So, if some general tools are available to extract .dsk or .rom from the .msx file, you can use those tools to extract the relevant information to your msx. Brs, Alex -- Visit The MSX Plaza (http://www.inter.nl.net/users/A.P.Wulms) for info on XelaSoft, Merlasoft, Quadrivium, SD-Snatcher on fMSX, the MSX Hardware list, XSA Disk images, documentation, Japanese MSX news from Ikeda and lots more. -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Monday 22 January 2001 18:02, you wrote: > > But then no comment could include an "=" character. > > Why not? Let's suppose someone writes a line like that: > > -- I thought Machine=MSX2 but actually it is MSX2+ > > The parser would read the line and extract two strings: > > Tag="-- I thought Machine" > Value="MSX2 but actually it is MSX2+" > > It will then search for "-- I thought Machine" in the list of > valid tags. When it does not find it, it will just ignore the entire line. > As you can see, equal signs can be safely used inside comments, as long as > you place some identifier in the beginning of line, such as ";" , "//" , > "--" or any other one. You are right, it is possible. But we would still have to document which characters can and cannot be at the start of a keyword. I think a single comment style would be simpler. > > We would limit the choice of characters to lower case latin and digits. > > Note that we're talking about the game ID here, the name field can have > > SJIS characters, that's no problem because it's never used as a filename > > or in a URL. > > That's ok to me, but the database manager will need a japanese > translator from time to time, to help design the six-letter acronym > for the game. In the case I mentioned earlier, it could be "yumeta", > but "jpgame" would not be acceptable. That's also the case for the file names, so it is not a problem specific to using a string for the game ID. > I think every ROM cartridge should have generic mapper > description. For instance, > > Name="Antartic Adventure" > Banksize=16 > Initial[4000]=0 Agreed. > > Super Lode Runner writes to # > > in slot 0, not in the cartridge slot. But the cartridge does switch banks > > on such a write, because it ignores the slot select signal. So writing to > > # in any slot is a write to the mapper register. > > We could add a flag in the register field: > > Register[*]=8000 > > A "*" next to a register address means this particular address > does not process the slot select signal. OK. > What about defining three levels of optionals? > > We could make three tags, "Required", "Optional" and "Extra". > Required means the game will not run without it. Optional means > new features are enabled with this hardware. Extra means no new features > are enabled, but game improves performance. This syntax also makes > the tag "Machine" obsolete: > > Name="Nemesis 3" > Required=MSX > Optional=SCC > Optional=MSX2 And also 'Optional=GM2' for Game Master 2. However, I do feel that SCC is more needed than the other two, so it seems wrong to have them in the same level. For one, SCC is part of the Nemesis 3 cartridge, so the real thing cannot be run without SCC. > > (about Register[8000-87FF]) > > Should we allow any range, or just ranges that can be formed using a > > bitmask? > > Since we allowed Banksize=1, then we should allow any possible > range too. The reason is the same: we never know which strange cartridges > are out there. We allowed Banksize=1 mainly because there was no cost involved. We're not allowing Banksize=3 because powers of two are easier to handle than arbitrary bank sizes. There is always the theoretical possibility of a cartridge that cannot be described using the generalized mapper. The only way to avoid that, is to make the mapper description as powerful as a programming language (more exact: as a Turing machine). We don't want that, we want a simple and fast algorithm. So we have limit our attention to a certain class of possible mappers. > > I think those are the only ones used in hardware and they're probably > > faster to implement. We could even modify the syntax accordingly: > > Register[5000/07FF]=XX > > I think the syntax Register[5000-57FF] is easier to read. > The emulator should be able to get the bitmask from the range assigned, > an easy task, since all it need to do is (57FF)-(5000)=07FF. > Human readness is key here, we should make syntax easier for the human, > and not for the machine. The "5000-57FF" notation is easier to read, but it's not equivalent to the "5000/07FF" notation. For example, what if I want to express "1234-5678". That cannot be solved using a single "addr/mask" pair. It can be decomposed into multiple "addr/mask" pairs, but that would be a rather long list: "1234/0003" | "1238/0007" | "1240/003F" | "1280/007F" | "1300/00FF" etc. > > And should we allow that a single mapper register is accessed through two > > separate ranges? For example: > > Register[7000]=7000 > > Register[8000]=7000 > > I see no problem with that. An alternate syntax could be: > > Register[7000,8000]=7000 > > And we could even allow trickier syntax... > > Register[7000,8000-87FF,*9000]=7000 > > ... which means there is a register in 7000, lots > of registers in the range 8000-87FF, a
Re: extended ROM format
> Afaik, there is no ROM in PAC (only 8KB SRAM). > What is the trick to dect the SRAM? > I have somewhere a program for dos to save/load SRAM saves from PAC. I also have such a program, but I think it is in Dutch or English. It is on my harddisk somewhere... > There is sourcecode for it too. The documentation is in jap. If someone = > is interested I can put it on my page. Well, why not? > Has someone got a translation of the original jap. FM-PAC manual? I will attach (I guess this small file is okay, it is only 4224 bytes) a text made by Takamichi that explains the FM-PAC commander's messages. I also have a translation of the manual itself somewhere on my harddisk again... If you like I can try and find them this weekend. > I=B4m interested in the pages which explain the PAC copy functions and = > about blocks on p. 23 Well, that manual is a joke, actually. It is about a magical wizard, see below. Can someone confirm if there is ROM in the PAC? Is there a way to manage the PAC data like in the FM PAC? Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/) PPS: Visit my home page at http://bilderbeek.cjb.net/ Here's the text: fmpactransl.txt Translations of Messages shown by FMPAC July 26, 1998 by Takamichi Overview Internal file management software of FMPAC is called Pac Commander. To boot the software, insert FMPAC into MSX, turn on the power, then type in CALL FMPAC from BASIC. Messages in Pac Commander assumes that MSX is a wizard who is managing FM-PAC. Sections names in the initial menu screen are called "spells". My comments are enclosed by []. Decision; SPACE = yes, ESC = no. Also, a dialogue window on upper-right shows "Yes" and "no". Use cursor key to select, and then SPACE. "PAC" might be either a FMPAC, or PAC without FM module. Slot spell is invalid if anything other than one single FMPAC is inserted to MSX, though. Slot no. that Pac Commander indicates may be different with actual slot no. of your MSX. This is why Slot spell is necessary. Pac Commander always uses slot no. shown with slot spell. Change spell swaps entire contents of two PACs. ---Spell menu Clear Copy Change Delete File Slot Background Music ---Spell 1: Clear MSX said, "Password and data at Slot n disappear. OK?" [n stands for slot no. which FM-PAC is inserted in] --Press SPACE MSX used Clear magic. Pf. ---Spell 2: Copy PAC -> PAC PAC -> Disk Disk -> PAC --PAC -> PAC What is PAC you copy from? --Choose a PAC you want to copy from. [If 3 or more PAC are present] What is PAC you copy to? [choose a PAC you want to copy to.] MSX said, "Password and data at destination (n) disappear. OK?" [n stands for slot no. where destination PAC is inserted in] --Press SPACE MSX used Copy magic. Pipipipi, copy --PAC -> Disk [Prompt for file name appears] Destination file: --Input file name; use BS key to delete a character --Press SPACE MSX used Copy magic. Pipipipi, copy --If there are already existing data, their list appears. --Overwrite; move cursor to the file you want to overwrite and press SPACE. MSX said, "Overwrite . OK?" [ = file name.] --Disk -> PAC [PAC can use only drive a:] [A list of data files appear] [Move cursor to file name you want to copy from] Original file: --Press SPACE MSX said, "Password and data at destination (n) disappear. OK?" [n stands for slot no. where destination PAC is inserted in] --Press SPACE MSX used Copy magic. Pipipipi, copy ---Spell 3: Change --Press SPACE [Valid only if there are two PACs] MSX used Change magic. Chachacha, change!! ---Spell 4: Delete file [List of files appears] [Move cursor to the file you want to delete] MSX said, "Delete . OK?" --Press SPACE MSX used Delete File magic. Dee, lee, tee!! ---Spell 5: Slot [Invalid if there are more than one FMPAC] MSX used Slot magic. MSX said, "PAC is in slot (n). Did you write it down?" [n stands for slot no. where your FMPAC is inserted in] ---Spell 6: Background Music Sample 1 Sample 2 Sample 3 Sample 4 Sample 5 Stop [Choose a music and press SPACE to change music.] ===- Error messages Error messages are always shown in yellow box. (1) Hmm, write protected!! Try again? [Reason: Disk is write protected.] (2) Disk is not set!! Try again? [Reason: Disk is not set.] [Reason: Disk is in a drive other than a: [Reason: Disk is not formatted.] (3) MSX said, "file not found." [Reason: You chose wrong file name.] MSX cannot use this disk!! Try again? [Reason: Disk is not of a format usable with MSX.] [Reason: Disk is broken. (4) This disk seems broken!! Try again? [s
Re: MSX game format continued
On Mon, 22 Jan 2001, Sean Young wrote: > Well we can call the format "unified msx game format", and the extension is > .msx -- how's that? I prefer "Unified MSX Format". There's no need to insert "game" in the name, since the format can be used for apps that are not games. However, which would be the name of the ini file? msxgame.ini would not be acceptable anymore, what about msxsoft.ini ? > Just for a remark, someone on messdev is working on diskdumps which are "mfm > disks". It actually contains the dumps of the tracks, so it should work in > any case. This would be the perfect solution for copy protected disks. For disks without protection, we could use the standard .dsk files, but a detailed information would be required: Name=YS 3 - Wanderers from YS Diskimage=y3a.dsk,80,2,9,512,B,Scenario Disk Diskimage=y3b.dsk,80,2,9,512,N,Data 1 Disk Diskimage=y3c.dsk,80,2,9,512,N,Data 2 Disk Diskimage=y3d.dsk,80,2,9,512,N,Data 3 Disk Diskimage=y3e.dsk,80,2,9,512,N,User Disk The arguments for Diskimage are: 1. name of .dsk inside the .msx package 2. number of tracks 3. number of sides 4. sectors per track 5. size of a sector 6. bootable flag 7. description of the disk The extra information about the disk is very important. Some emulators cannot run Famicle Parodic since they assume all disks are 720kb and this is not always true. The description of the disk is the only parameter seen by user. When the game asks him for "Scenario disk", all he need to do is clicking on some button to load the correct .dsk > IIRC RuMSX has some format where apart from the .dsk file there is another > file which basically indicates which sectors are bad. IMHO .mfm disks is > much nicer as it's far more near to the real MSX. I agree with you, a raw dump of all the track info is enough to cover all kinds of copy protections, plus it can also cover unusual formats (such as the brazilian game Lenda da Gavea, unplayable on all emulators due to unusual formatting). > Also on second thought I do agree we can better the just have a number than > some system that describes the mapper; describing the workings is not going > to complete (think of Super Load Runner) -- another funky mapper. In the > real world, implementing specific types is easier and faster than a general > one (from a description). And we're looking at probably about 20 different > ones, which isn't that bad really. I do not agree with you this time. Suppose we adopt the fmsx numbering system, and suppose also someone finds a new cartridge with a different mapper. In this case, everyone should wait until an emulator author has free time available to implement the new mapper. In the generic mapper case, the mapper is described in the .msx archive and then all emulators can play the game, without the need for a new emulator release. I think the second scenario is better by far. Ricardo Bittencourt http://www.lsi.usp.br/~ricardo [EMAIL PROTECTED] "Ricardo is subtle, but malicious he is not" -- Uniao contra o forward - crie suas proprias piadas -- -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format continued
On Mon, Jan 22, 2001 at 06:08:53PM +, Maarten ter Huurne wrote: > Hi! > > In this mail I'll list some issues that weren't mentioned yet. > > * Name > > The standard needs a name. Some suggestions: > - Unified MSX Game Format > - .msx (pronounced "dot em-es-iks") > - MSX Software Format > > I prefer the first. Maybe we can drop the "Unified" if you don't like it, but > I think the power of the format is that it's unified in two ways: one format > for ROM/DSK/BASIC/COM and one format for all emulators. Well we can call the format "unified msx game format", and the extension is .msx -- how's that? > Copy protection emulation was an issue I raised before, but no-one responded > to it. I think it doesn't have priority so it shouldn't be in the first > version. But I would like to get some opinion on whether we should include it > in the future. Just for a remark, someone on messdev is working on diskdumps which are "mfm disks". It actually contains the dumps of the tracks, so it should work in any case. This is rather difficult to implement though, as the disk controller emulation will have to interpret the tracks into sectors if you're reading sectors. IIRC RuMSX has some format where apart from the .dsk file there is another file which basically indicates which sectors are bad. IMHO .mfm disks is much nicer as it's far more near to the real MSX. > There was little discussion on SRAM yet. I think this is an important issue > that should be resolved before the standard is released. It would be nice if > a generalized SRAM implementation is possible, just like the generalized > mapper. For the actual SRAM data, I suggest we use a plain dump -- just the binary data from beginning to end. We need to decided on an extension. Options: .sram, .ram. ,.sram, .nv (non-volatile), .mem? For FM-PAC we could save as .pac files. Also on second thought I do agree we can better the just have a number than some system that describes the mapper; describing the workings is not going to complete (think of Super Load Runner) -- another funky mapper. In the real world, implementing specific types is easier and faster than a general one (from a description). And we're looking at probably about 20 different ones, which isn't that bad really. Sean -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Mon, 22 Jan 2001, Maarten ter Huurne wrote:
> > If we're going to stick with INI-style syntax (where
> > every sentence have the form XXX=YYY), then there's no need
> > to define which character indicates a comment. If a given
> > line doesn't have a XXX=YYY syntax, then it is a comment.
>
> But then no comment could include an "=" character.
Why not? Let's suppose someone writes a line like that:
-- I thought Machine=MSX2 but actually it is MSX2+
The parser would read the line and extract two strings:
Tag="-- I thought Machine"
Value="MSX2 but actually it is MSX2+"
It will then search for "-- I thought Machine" in the list of
valid tags. When it does not find it, it will just ignore the entire line.
As you can see, equal signs can be safely used inside comments, as long as
you place some identifier in the beginning of line, such as ";" , "//" ,
"--" or any other one.
> We would limit the choice of characters to lower case latin and digits. Note
> that we're talking about the game ID here, the name field can have SJIS
> characters, that's no problem because it's never used as a filename or in a
> URL.
That's ok to me, but the database manager will need a japanese
translator from time to time, to help design the six-letter acronym
for the game. In the case I mentioned earlier, it could be "yumeta",
but "jpgame" would not be acceptable.
> This also allows non-mapped ROMs to be described in this format. Such a
> cartridge simply has no Register statements, but does have Initial
> statements, so you can for example mirror a 16K ROM four times.
I think every ROM cartridge should have generic mapper
description. For instance,
Name="Antartic Adventure"
Banksize=16
Initial[4000]=0
Name="Knightmare"
Banksize=32
Initial[4000]=0
Name="Painter"
Banksize=64
Initial[]=0
> > Name="Super Lode Runner"
> > Banksize=16
> > Register[]=8000
> > Initial[]=0
> > Initial[4000]=0
> > Initial[8000]=0
> > Initial[C000]=0
>
> That's all true, but it's not complete. Super Lode Runner writes to # in
> slot 0, not in the cartridge slot. But the cartridge does switch banks on
> such a write, because it ignores the slot select signal. So writing to #
> in any slot is a write to the mapper register.
We could add a flag in the register field:
Register[*]=8000
A "*" next to a register address means this particular address
does not process the slot select signal.
> > Name="Nemesis 3"
> > Banksize=8
> > Register[5000-57FF]=4000
>
> Does the actual cartridge have this behaviour? (reacting to all those
> addresses)
Yes, it has. It is cheaper to make cartridges this way,
because you don't have to add extra logic to process the lines A0-A10.
> > Register[B000-B7FF]=B000
> This should be "=A000".
You're right, this was a typo.
> > Initial[A000]=3
> > Extra=SCC
> > Extra=MSX2
>
> As I wrote in the very long mail, I don't think one level of "optional" is
> enough. There should be an indication of how much the option will be missed.
> The emulator can use that info to display warning messages ("game performance
> will be lower because of missing feature 'SCC'") or decide how to trade-off
> options (embedded systems low on memory may not allow all options to be
> enabled at the same time).
What about defining three levels of optionals?
We could make three tags, "Required", "Optional" and "Extra".
Required means the game will not run without it. Optional means
new features are enabled with this hardware. Extra means no new features
are enabled, but game improves performance. This syntax also makes
the tag "Machine" obsolete:
Name="Nemesis 3"
Required=MSX
Optional=SCC
Optional=MSX2
Name="Kyokugen"
Required=MSX2
Optional=MSX Music
Extra=MSX turboR
-- MSX turboR improves speed of the game
-- but introduce no new feature
Detailed message errors describing what happens when each option
is disabled should be stored in the .msx database server, together with
manuals, scans and stuff.
> (about Register[8000-87FF])
> Should we allow any range, or just ranges that can be formed using a bitmask?
Since we allowed Banksize=1, then we should allow any possible
range too. The reason is the same: we never know which strange cartridges
are out there.
> I think those are the only ones used in hardware and they're probably faster
> to implement. We could even modify the syntax accordingly:
> Register[5000/07FF]=XX
I think the syntax Register[5000-57FF] is easier to read.
The emulator should be able to get the bitmask from the range assigned,
an easy task, since all it need to do is (57FF)-(5000)=07FF.
Human readness is key here, we should make syn
MSX game format continued
Hi! In this mail I'll list some issues that weren't mentioned yet. * Name The standard needs a name. Some suggestions: - Unified MSX Game Format - .msx (pronounced "dot em-es-iks") - MSX Software Format I prefer the first. Maybe we can drop the "Unified" if you don't like it, but I think the power of the format is that it's unified in two ways: one format for ROM/DSK/BASIC/COM and one format for all emulators. About the second: We can still talk about .msx files, but I don't think this is a good name for the standard itself. About the third: The format is not really specific to games. For example, you could start GraphSaurus from a .msx file. However, games are the reason it was developed and will also be what it's used for 98% of the time. * Booting On a multiple disk game, which disks can be booted? Usually, this is the first disk. But let's take Aleste 2 as an example (also see Ricardo's mail that is dated last Tuesday - are you a fortune teller?). Aleste 2 has 3 disks, all of which can be booted. The first disk is the intro disk, which you should boot if you want to watch the intro. The second disk is contains stage 1-4, which you can boot to skip the intro. The third disk contains stage 5-8, which is usually not interesting to boot, but when you activate the built-in cheat mode to select a stage, it is. So in the case of Aleste 2 it makes sense to allow all disks to be booted. But in other games, booting a different disk either crashes the MSX or just displays an "insert disk 1" message. The emulator shouldn't offer to boot those disks. In conclusion, the MSX game info file should contain whether or not a certain disk is bootable. We could add a description string that tells the user what to expect when choosing that boot option. Example for Aleste 2: BootDesc[0][en]=Intro BootDesc[1][en]=Stage 1-4 BootDesc[2][en]=Stage 5-8 For BASIC and COM games, it's also useful to allow a choice which file is to be booted. For example, one version starts the original game and another activates a cheat. * Error handling If there is an error in the info file, what should the emulator do? Or in the case of a front-end, what should the front-end do? I think we need some directions for this, either rules or guidelines, depending on how strict it should be. If we don't, things will become a mess (like HTML). Currently, we have two types of lines: - comment lines - statement lines A line that is neither is an error. A comment line doesn't have any formal meaning and can therefore never contain an error. Statement lines have the form "keyword=value". Unrecognised keywords are ignored, this allows the format the be extended by introducing new keywords while not breaking existing emulators. A value can be invalid, for example a number that is out of range. Some keywords are mandatory, for example the bank size of a MegaROM, if they are missing it's an error. Apart from syntax errors, there are configuration errors. For example, you want to play an MSX2 game in an emulator that only supports MSX1. I've listed a couple of cases where errors can occur. This list is by no means complete, but it is useful to create examples. There are two phases in the "life" of a .msx file. It is first created and tested by one person, then it is distributed and played by many persons. After the first phase, the .msx file should no longer contain errors. The first reason is that it's hard to fix errors once the file is in the hands of many different people. The second reason is that the person who creates the .msx file is someone who knows the format and who knows MSX, while the person who wants to play the .msx file doesn't necessarily have that knowledge. Because errors should be caught before the file is distributed, I propose that an emulator should abort on any error in a .msx file. Aborting means it should abort the starting of the game, it doesn't necessarily mean it has to abort the emulator program. * Small remarks For the MSX1 VDP, it must be possible so specify either a 50Hz or a 60Hz VDP. Unlike the V9938, the MSX1 VDP comes in different versions for 50Hz and 60Hz. I think they're called V9918 and V9928, but I'm not sure which is which. Copy protection emulation was an issue I raised before, but no-one responded to it. I think it doesn't have priority so it shouldn't be in the first version. But I would like to get some opinion on whether we should include it in the future. There was little discussion on SRAM yet. I think this is an important issue that should be resolved before the standard is released. It would be nice if a generalized SRAM implementation is possible, just like the generalized mapper. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> [EMAIL PROTECTED] said: > >AFAIK, FM-PAC is just PAC + FM. Although I have an FM-PAC, I never saw > >a FM-less PAC, so I cannot be certain. But it would make sense that > >both SRAMs are the same, otherwise games that save in PAC SRAM would > >no longer work with the FM-PAC. > > You can check out my PAC if you like (bought one in Japan), but I guess it is > absolutely the same. > I was wondering how a program that uses PAC to save data recognizes it? Afaik, there is no ROM in PAC (only 8KB SRAM). What is the trick to dect the SRAM? I have somewhere a program for dos to save/load SRAM saves from PAC. There is sourcecode for it too. The documentation is in jap. If someone is interested I can put it on my page. But I guess not many people do own the REAL PAC!? and the original FM-PAC has its own save/load manager I´ll have to check if it works also on FM-PAC, it should in that case. Has someone got a translation of the original jap. FM-PAC manual? I´m interested in the pages which explain the PAC copy functions and about blocks on p. 23 Greetings from Bjørn Boye Skjoldhammer How to contact? See: http://www.geocities.com/msxtrd/data.html ICQ #20449307 -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Mon, Jan 22, 2001 at 09:37:30AM +, Maarten ter Huurne wrote: > A question to Sean: > The file to specify a mimetype for an extension on Apache, can that file be > created by any user or is it system wide? If the latter is true, people will > have to ask system administration to make the changes and they may be > reluctant to do so. Per user. If anyone has a problem configuring this, you ask me. I don't know anything about Microsoft IIS though. I think it has to be done system-wide anyways on these bogus servers. Does anyone know about IIS? Sean -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Mon, Jan 22, 2001 at 10:23:39AM +0100, David Heremans wrote: > On Monday 22 January 2001 10:37, you wrote: > > > The file to specify a mimetype for an extension on Apache, can that file be > > created by any user or is it system wide? If the latter is true, people > > will have to ask system administration to make the changes and they may be > > reluctant to do so. > > In true Unix tradition. Both, one could configure appache to read a users > configuration for the mime types, however 99.99% of the installations of one > mime-type file which is system-wide. This kind of stuff is something you > would like to keep under strict controll by the sysadmin. Otherwise all kind > of (mis/ab)use could be made of it. This is the default installation, and all installations I've seen allow you to change/add mime-types through .htaccess files and the ``AddType'' command. All sites I've had access to using Apache allowed this, including user-homepages at isps. How can changing the mime-type be misused/abused? Quite often it is necessary, like when you Apache doesn't know about .png or .rm files. > Not to mention all the extra overhead one would introduce in the systems to > parse the mimetype-list for each request of a user-page. IIRC Apache caches .htaccess files, based on the time-stamp of the file. I can remember something like that in the source but I'm not sure. This is all standard behaviour. Try downloading: http://www.msxnet.org/penguin.msx Sean -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Monday 22 January 2001 06:09, you wrote: > > > -- start of msxgame.ini > > > > We could use ";" for comments instead, I think that's more of a > > standard. It's also a bit easier to parse (some people will want to > > write their own parser, instead of using lex & yacc). Unix formats > > often use "#", but that's not familiar to DOS/Windows and MSX users. > > If we're going to stick with INI-style syntax (where > every sentence have the form XXX=YYY), then there's no need > to define which character indicates a comment. If a given > line doesn't have a XXX=YYY syntax, then it is a comment. But then no comment could include an "=" character. Also, I think it's easier if people can tell whether a line is a comment by looking at the start of the line rather than scanning the entire line with their eyes. From a parser's perspective you are absolutely right, but this format is supposed to be human-readable. > There's one drawback with this approach: XXX=YYY strings > must fit on one line. I think that's ok, all multi-line information, > such as the Comment field, was thrown to the .msx database server. > We can even remove the quotation marks, Machine="MSX" can > safely be replaced by Machine=MSX in this new syntax. Strings > now begin at the "=" and end at CR or LF. I think that's the reason why the .desktop format doesn't have quotes around strings. > > > GameID=1.0 > > > > Why not use strings instead? Penguin Adventure could be "penadv". > > This could be done, but what if a japanese user submit a game > to the database, whose only Name entry is: > > name[jp]=²å¤Ahx`[ > > What six-letter string should the manager give to this file? We would limit the choice of characters to lower case latin and digits. Note that we're talking about the game ID here, the name field can have SJIS characters, that's no problem because it's never used as a filename or in a URL. > Patriek suggested using CRCs as GameIDs, but I don't think > this is a good idea. It works fine for ROMs, but what about > multi-disk games? Should use the CRC from the first disk? From the > last? Should we append all the disks and take the CRC of the result? > In this case, in what order should the disks be appended? Using CRCs as IDs is only useful for automatically finding IDs of ROMs that are not in .msx format. I don't think this is important. > > By the way, I think "us" is not a valid language code. It's probably > > "en_US" or something like that. After all, the language is still > > English (although some UK people will deny this ;), US specifies the > > "dialect" (it's not really a dialect, but I don't know the proper > > word). > > I made a search on the web and couldn't find the RFC. > If it is not available anywhere, we should make our own > language codes. I'm not sure whether it's an RFC or an ISO standard. But I'll look for it. > > One thing that isn't documented yet, is how to handle memory that > > is not controlled by the mapper. We could say it is filled with #FF > > (the data bus pulled up), but I'm not sure if that's correct for all > > MegaROMs. > > I can't see anything wrong with that. Every part of memory > not initialized with a Initial[]=Y statement should answer > with FF when read. Ofcourse, using Initial is the solution. I was thinking of returning #FF for memory areas that didn't have a mapper register assigned to them, which is not a good idea. But any memory area that is not mentioned in an Initial statement doesn't have any part of the ROM associated with it and therefore should return #FF. This also allows non-mapped ROMs to be described in this format. Such a cartridge simply has no Register statements, but does have Initial statements, so you can for example mirror a 16K ROM four times. > > Another thing is how to specify that a cartridge ignores slot > > select (like Super Lode Runner does). This is bad design from the > > cartridge manufacturer, but it has happened so now we have to deal > > with it. > > Can you please explain in details what is the problem > with Super Lode Runner? I thought its mapper was just: > > Banksize=16 > Register[]=8000 > Initial[]=0 > Initial[4000]=0 > Initial[8000]=0 > Initial[C000]=0 That's all true, but it's not complete. Super Lode Runner writes to # in slot 0, not in the cartridge slot. But the cartridge does switch banks on such a write, because it ignores the slot select signal. So writing to # in any slot is a write to the mapper register. > I think not. I/O extensions should be defined in a > tag called "Extra". The Extra tag would include everything that is > not required by the game to run, but can improve gameplay. The > generic mapper for Nemesis 3 would be: > > Banksize=8 > Register[5000-57FF]=4000 Does the actual cartridge have this behaviour? (reacting to all those addresses) > Register[7000-
Re: MSX game format example
Maarten ter Huurne wrote: > > Actually I now think that a single extension is better. An emulator > can register the .msx extension, so that file managers like Explorer > and Konqueror will know what to do when you open a .msx file. With > for example .msx.zip, the program registered for ZIP will open the > file instead. I agree with that. Sean already showed us how to solve the problem in the server side, so bad downloading shouldn't be a problem anymore. > > -- start of msxgame.ini > We could use ";" for comments instead, I think that's more of a > standard. It's also a bit easier to parse (some people will want to > write their own parser, instead of using lex & yacc). Unix formats > often use "#", but that's not familiar to DOS/Windows and MSX users. If we're going to stick with INI-style syntax (where every sentence have the form XXX=YYY), then there's no need to define which character indicates a comment. If a given line doesn't have a XXX=YYY syntax, then it is a comment. VHDL programmers can use "--", assembly programmers can use ";", C++ programmers can use "//" and so on. There's one drawback with this approach: XXX=YYY strings must fit on one line. I think that's ok, all multi-line information, such as the Comment field, was thrown to the .msx database server. We can even remove the quotation marks, Machine="MSX" can safely be replaced by Machine=MSX in this new syntax. Strings now begin at the "=" and end at CR or LF. > > GameID=1.0 > Why not use strings instead? Penguin Adventure could be "penadv". This could be done, but what if a japanese user submit a game to the database, whose only Name entry is: name[jp]=²å¤Ahx`[ What six-letter string should the manager give to this file? Patriek suggested using CRCs as GameIDs, but I don't think this is a good idea. It works fine for ROMs, but what about multi-disk games? Should use the CRC from the first disk? From the last? Should we append all the disks and take the CRC of the result? In this case, in what order should the disks be appended? > It is a good idea to have a major ID and a minor ID. Most uses of > the game ID do not depend on the minor ID. For example, save games > for the Japanese and English Solid Snake are exchangable. It also saves space on the server. For instance, I could scan the entire manual of Penguin Adventure and place it in the server, wasting about 5 MB. We don't want to waste another 5 MB for every variant of the game. > By the way, I think "us" is not a valid language code. It's probably > "en_US" or something like that. After all, the language is still > English (although some UK people will deny this ;), US specifies the > "dialect" (it's not really a dialect, but I don't know the proper > word). I made a search on the web and couldn't find the RFC. If it is not available anywhere, we should make our own language codes. > One thing that isn't documented yet, is how to handle memory that > is not controlled by the mapper. We could say it is filled with #FF > (the data bus pulled up), but I'm not sure if that's correct for all > MegaROMs. I can't see anything wrong with that. Every part of memory not initialized with a Initial[]=Y statement should answer with FF when read. > Another thing is how to specify that a cartridge ignores slot > select (like Super Lode Runner does). This is bad design from the > cartridge manufacturer, but it has happened so now we have to deal > with it. Can you please explain in details what is the problem with Super Lode Runner? I thought its mapper was just: Banksize=16 Register[]=8000 Initial[]=0 Initial[4000]=0 Initial[8000]=0 Initial[C000]=0 > Is it useful to allow I/O ports for writing to mapper registers? I think not. I/O extensions should be defined in a tag called "Extra". The Extra tag would include everything that is not required by the game to run, but can improve gameplay. The generic mapper for Nemesis 3 would be: Banksize=8 Register[5000-57FF]=4000 Register[7000-77FF]=6000 Register[9000-97FF]=8000 Register[B000-B7FF]=B000 Initial[4000]=0 Initial[6000]=1 Initial[8000]=2 Initial[A000]=3 Extra=SCC Extra=MSX2 > Is there any game that reads the mapper registers, or is it > always write-only? BrMSX-dos does not implement reading of the mapper registers, and all the games I have run fine with it. > > -- select a banksize with 8kb > > Banksize=8 > Is any bank size allowed, or just 8kB and 16kB? 8 and 16 would be enough, but we can extend the format to all powers of 2, just for completeness. We never know when a strange cartridge will appear, and the format should be flexible enough to support an new, unknown mapper. > We could also specify banks by using th
Re: extended ROM format
At 13:31 22-1-01 +0100, you wrote: > > I never found a suitable use for the expansion ram (as it is called > > formally), so it could be useful now. > >I hope so. I have released my source so make good use of it all... :) > > HL = Address (16-bits, bit 17 ignored), B = 0 for read, B = 64 for write. > > You can read and write using port #0 ($98) and if you want to use vram > > again then you should call resExp. > >Thank you very much. No problem. >BTW, do you know if there is a ASCII or PDF version of >V9938 Technical Handbook? No, AFAIK there is no ASCII or PDF of it. GreeTz, BiFi Visit my Home Page at www.bifi.msxnet.org mail me at: [EMAIL PROTECTED] FTP: ftp.bifi.msxnet.org ICQ #36126979 -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Double Dragon
OK, I looked up the magazines this week-end. I found two smal articles about Double Dragon on MSX article 1: -- MSX Club Magazine nr 33 (jan-feb 1991) No screenshots, 8 lines review Summary: Producer is Zemina, made for MSX1, graphics rather good,joystick is recommended, flickering of sprites from time to time. Recommended if you like sport/karate games. article 2: -- MSX Computer Magazine nr.47 (June 1991) One screenshot, 7 short paragraphs(max 5 lines) Summary: Finally DD available for MSX, alas MSX1 no MSX2(+) version, short storyline of DD, rather difficult to control (no documentation doesn't help), a lot of kicks and punches available. Nice game to add to collection. Producer Zemina, imported by MSX Centrum, computer MSX1, ROM, one player, no FM-PAC, no S-RAM, price 50 guilders Is the ROM already available from somewhere ?? David Heremans -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> Hmmm. Is there any emulator supporting 192KB VRAM? I thought RuMSX supported 192 kVram... Can't check it here though... Regards, Arnaud -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
Hello ! > > Print out the code, read it a couple of times, that will catch most bugs. > > But you have to read carefully then... An art that not many people master. ;-) Yep. As a matter of fact, ir is a very difficult task to detect bugs by reading the code only I often need to test it. > > Then mail the program to Manuel and let him test it. > > Can do so, but my MSX with 192kB VRAM is at my parent's place, so it will have > to wait until next weekend. But I am sure there are more people with expansion > VRAM on the list. Hmmm. Is there any emulator supporting 192KB VRAM? Un saludo, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) ¡Suscríbete a HispaMSX! http://www.hispamsx.com [EMAIL PROTECTED] msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
Hello Albert, > >Hmmm. It's not a bad idea. Some megaroms (like Kenpelen Chess) use > >all the 128KB VRAM, so there is no room to allocate any ROM page there. > >... except if you have 192KB :) > > > >I'll study how the extended VRAM works :) > > Here's how the V9938 technical databook describes it which is already coded to > assembly here: > > setExp: ld a,64; Set expansion ram > out ($99),a > ld a,128+45 > out ($99),a [] > I never found a suitable use for the expansion ram (as it is called > formally), so it could be useful now. I hope so. > HL = Address (16-bits, bit 17 ignored), B = 0 for read, B = 64 for write. > You can read and write using port #0 ($98) and if you want to use vram > again then you should call resExp. Thank you very much. BTW, do you know if there is a ASCII or PDF version of V9938 Technical Handbook? Greetings, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) Visit MSX Warau Home Page http://msxjam.web.com msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> Print out the code, read it a couple of times, that will catch most bugs. But you have to read carefully then... An art that not many people master. ;-) > Then mail the program to Manuel and let him test it. Can do so, but my MSX with 192kB VRAM is at my parent's place, so it will have to wait until next weekend. But I am sure there are more people with expansion VRAM on the list. Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/) PPS: Visit my home page at http://bilderbeek.cjb.net/ -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
On Monday 22 January 2001 12:04, you wrote: > > The easiest way to access the extended VRAM is through port #98. You can > > also use VDP commands to access it, but there is no HMCM command, so you > > can only transfer from extended VRAM to CPU at the pixel level, not at > > the byte level. This is bad, because you have to know the screen mode. > > Also, in SCREEN5 it's twice as slow as transferring bytes. > > Aha ... > Maybe it will be too slow for the mapping routine Hmm. If you access it through port #98, it's just as fast/slow as ordinary VRAM. > I have another question. How can I do to detect if extend VRAM exists or > if not? Write data into it, read it back, if it matches there is extended VRAM present. Just use a small string or something as data. > There is another trouble: my GT doesn't have extende VRAM, so I don't > know how to test routine :( Print out the code, read it a couple of times, that will catch most bugs. Then mail the program to Manuel and let him test it. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
At 12:38 22-1-01 +0100, you wrote: > > > Now I'm working in a new mapping routine which uses VRAM to store ROM > page= s > > > there. Thus, 128KB machines will be able to run some MegaROM games. > > > > You could also use the extended VRAM, some people have 192kB of VRAM in > their > > MSX2, like me. Then it would be finally used! > >Hmmm. It's not a bad idea. Some megaroms (like Kenpelen Chess) use >all the 128KB VRAM, so there is no room to allocate any ROM page there. >... except if you have 192KB :) > >I'll study how the extended VRAM works :) Here's how the V9938 technical databook describes it which is already coded to assembly here: setExp: ld a,64; Set expansion ram out ($99),a ld a,128+45 out ($99),a ld a,h ; Write address bits 14 and 15 rlca rlca and 3 out ($99),a ld a,128+14 out ($99),a ld a,l ; Write address LSB out ($99),a ld a,h ; Write remaining bits with access specification and 63 or b out ($99),a ret resExp: ld a,0 ; Reset expansion ram out ($99),a ld a,128+45 out ($99),a ret I never found a suitable use for the expansion ram (as it is called formally), so it could be useful now. HL = Address (16-bits, bit 17 ignored), B = 0 for read, B = 64 for write. You can read and write using port #0 ($98) and if you want to use vram again then you should call resExp. GreeTz, BiFi Visit my Home Page at www.bifi.msxnet.org mail me at: [EMAIL PROTECTED] FTP: ftp.bifi.msxnet.org ICQ #36126979 -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> > I'll study how the extended VRAM works :) > > In VDP register 45, bit 6 specifies whether you want to access the normal > VRAM or the expansion RAM. > > The easiest way to access the extended VRAM is through port #98. You can also > use VDP commands to access it, but there is no HMCM command, so you can only > transfer from extended VRAM to CPU at the pixel level, not at the byte level. > This is bad, because you have to know the screen mode. Also, in SCREEN5 it's > twice as slow as transferring bytes. Aha ... Maybe it will be too slow for the mapping routine Hmm. I have another question. How can I do to detect if extend VRAM exists or if not? There is another trouble: my GT doesn't have extende VRAM, so I don't know how to test routine :( Un saludo, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) ¡Suscríbete a HispaMSX! http://www.hispamsx.com [EMAIL PROTECTED] msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
On Monday 22 January 2001 11:38, you wrote: > I'll study how the extended VRAM works :) In VDP register 45, bit 6 specifies whether you want to access the normal VRAM or the expansion RAM. The easiest way to access the extended VRAM is through port #98. You can also use VDP commands to access it, but there is no HMCM command, so you can only transfer from extended VRAM to CPU at the pixel level, not at the byte level. This is bad, because you have to know the screen mode. Also, in SCREEN5 it's twice as slow as transferring bytes. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> > Now I'm working in a new mapping routine which uses VRAM to store ROM page= s > > there. Thus, 128KB machines will be able to run some MegaROM games. > > You could also use the extended VRAM, some people have 192kB of VRAM in their > MSX2, like me. Then it would be finally used! Hmmm. It's not a bad idea. Some megaroms (like Kenpelen Chess) use all the 128KB VRAM, so there is no room to allocate any ROM page there. ... except if you have 192KB :) I'll study how the extended VRAM works :) Thank you for your suggestion ! Un saludo, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) ¡Suscríbete a HispaMSX! http://www.hispamsx.com [EMAIL PROTECTED] msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> How would we describe games requiring a turbo machine
> (ciel with 7mhz for example)? Would they be listed as
> just "MSX2+", with an Extrahardware=5 ("5" being Z80 at 7MHz) ?
But my MSX2 can run on 8MHz ad 3.5MHz. 7.16MHz oscillators are hard to find
nowadays. Hence the 8MHz oscillator was chosen for my Z80H.
Another thing: if you have a game of e.g. 3 disks, how can you ever decompress
it on MSX? It would take ages to decompress
If you want to do this still, the .msx format is not really usable on real MSX
computers. That is a real pity. I would need other hardware (pc e.g.) to
extract the stuff and use it on my MSX...
[EMAIL PROTECTED] said:
>AFAIK, FM-PAC is just PAC + FM. Although I have an FM-PAC, I never saw
>a FM-less PAC, so I cannot be certain. But it would make sense that
>both SRAMs are the same, otherwise games that save in PAC SRAM would
>no longer work with the FM-PAC.
You can check out my PAC if you like (bought one in Japan), but I guess it is
absolutely the same.
Also, the creator ID of the .msx file is quite important. If this succeeds,
there will be many .msx files of the same games. But they can have different
versions or screenshots or whatever... Using a full name seems a rather unique
ID, although not 100% safe...
Just my 2 cents...
Grtjs, Manuel
PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/)
PPS: Visit my home page at http://bilderbeek.cjb.net/
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
> Now I'm working in a new mapping routine which uses VRAM to store ROM page= > s > there. Thus, 128KB machines will be able to run some MegaROM games. You could also use the extended VRAM, some people have 192kB of VRAM in their MSX2, like me. Then it would be finally used! Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/) PPS: Visit my home page at http://bilderbeek.cjb.net/ -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
Laurens Holst wrote: > > Indeed, this is even more intuitive than numbering. > > Let's them make the strings be "MSX", "MSX2", > > "MSX2+" and "MSX turboR". > > What if I write MSX 2+ and MSX turbo R??? No, a number is much more clear I > think. Then you write a syntax error. That is always possible, in the case of numbers you could write a "5" which is not defined, or an "A" which is not even a number. No matter whether we choose numbers or strings, you still need a documentation file when writing the INI. But strings are more readable. It's hard to remember what "1" means, is it MSX1 or is it MSX2 (as in the #002D ID byte)? > And if you use my 'system' I proposed in my prev. message, you can > define a seperate 'option' named 'altered CPU speed'. That option is a good idea, but it can be used in a text-based info file as well. > I don't like the idea of AND a seperate file AND those seperate files > compressed again in one file, it can be done the way I described too which > is much more transparant and easy, the emulator doesn't need difficult > unzip routines for example. Unzip consists of two parts: - decompression - archive directory handling You can avoid decompression only by not compressing the data. This choice is independant of the choice between single file and archive. About archive directory handling, this is similar to the chunks system you described. Archive directories are more complex, but also more powerful. So there is really not that much of a difference. The advantage of using a known archive and compression format, is that there are no new tools needed to create such files. > You can edit it through emulators and/or an > external tool. Like editing the ID3 information in MP3's through Winamp. I > don't think that's a pain... Adding this functionality to the emulator is not a good idea, because it hardly has any overlap with existing emulator functionality. A separate tool is possible, but it's easier to use existing tools like a unzip and a text editor. Consider what has to be done when the format is extended. A new specification document must be released. In the case of a text-based info file, that's all there is to it. But if there is a separate tool, the tool has to be upgraded as well. > And I DO think files with lots of text in it > are suited for configuration files etc, but they are an awful waste of > space when they are used for every ROM file on your computer's hard disk. How large are those files anyway? Probably a couple of hunderd bytes. Since they are stored in an archive file, they don't use an entire cluster on a FAT filesystem, which is the main reason why many small files eat up a lot of space. > There is a big difference between what you describe and what I describe. > Your idea is dedicated to emulator use (including preview images etc.), and > mine is, as the title describes, an extended ROM format, purely about the > ROM information, to which as well useful (ROM mapper type) as unuseful > (release date) can be added. It can easily be extended, and it doesn't need > a lots-of-work unzip routine and a harder-to-code parser (from an MSX > perspective). If ROM mapper type is all you care about, just write a good auto-detection algorithm. The one in fMSX is pretty simple, but I haven't seen it guess wrong yet. The power of a unified MSX game format comes from combining a number of different features: - losing the distinction between ROM/DSK/BASIC/COM - info like full name, company etc - a screen shot to easily recognise the game - knowing the system requirements - generic mapper algorithm - finding related info on the web Note that most of those features are independant, for example a screen shot can be used for both ROM and DSK games. If we made an extended ROM format, we'd have to duplicate all the work when we want an extended DSK format. > I think it's essential to keep it all in one file, 'cause multiple files > mess up your directory and make it less simple to copy (imho lots of > seperate sram and save game files in your game directory are a crime). I > also think it's not the task of this file format to compress the file (it's > an extended ROM format, not an emulator-optimized "ROM in a zip-file" > format, which actually is two formats in one). Why do you consider keeping it in a single file a task of the file format, but not compression? > The user can decide if he > wants to compress the file or not, it should be seperate from the file > format. That's the philosophy of .tar.gz, separating the archive directory (tar) from the compression (gz). But we would actually need the opposite order (.gz.tar) for optimal performance, so that a single file could be decompressed. The info file and the screenshot have to be decompressed before the rest. In the case of large ROMs or DSK images, this makes a difference. And if the screenshot is a PNG, it could be stored in the archive with zero compression to allow fa
Re: Rom Formats
> But I was wondering, how does my MSX handle all these ROM types ? > because if I insert a r-type cart, my MSX run's it with no problems. So > do all emulator's have a bug in the memory handeling ? Or does nobody > know how a real MSX handles those ROMs ? Because if a emulator can > detect it also, I only have to choose a ROM file, and not a type. > > Or am I complete wrong ? :) Emulators has to emulate the MSX machine, but not the only thing. MegaROMs have a hardware piece inside (the rom mapper). Because of this, it is needed to implement every kind of known mappers in emulators. Un saludo, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) ¡Suscríbete a HispaMSX! http://www.hispamsx.com [EMAIL PROTECTED] msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Monday 22 January 2001 10:37, you wrote: > The file to specify a mimetype for an extension on Apache, can that file be > created by any user or is it system wide? If the latter is true, people > will have to ask system administration to make the changes and they may be > reluctant to do so. In true Unix tradition. Both, one could configure appache to read a users configuration for the mime types, however 99.99% of the installations of one mime-type file which is system-wide. This kind of stuff is something you would like to keep under strict controll by the sysadmin. Otherwise all kind of (mis/ab)use could be made of it. Not to mention all the extra overhead one would introduce in the systems to parse the mimetype-list for each request of a user-page. David Heremans -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Rom Formats
On Monday 22 January 2001 09:21, you wrote: > Hi, > > for the last few day's I'm following the discussion about the extended > ROM etc. I saw in a e-mail from Sean Young that he has 15 diffrent ROM > types. *SNIP* > > But I was wondering, how does my MSX handle all these ROM types ? > because if I insert a r-type cart, my MSX run's it with no problems. So > do all emulator's have a bug in the memory handeling ? Or does nobody > know how a real MSX handles those ROMs ? Because if a emulator can > detect it also, I only have to choose a ROM file, and not a type. > > Or am I complete wrong ? Simply put, your MSX doesn 't know how to handle them! All the memory handling is don inside the cartridge , by the chips on the PCB. What the emulator progranmmers have to do in this case is not to emulate only an MSX. The numbers of Sean Young are actually emulating parameters to emulate the right cartridge-electronics. As far as the (real or emulated) MSX are concerned they just ask the cartridge: "Give me the byte on location X" or "write byt X to location Y". once this command enters in the cartridge, it is the cartridge who (unvisible for the MSX) starts to do all kind of memmory handling on its own. To emulate that game you need to emulate a) an MSX b) a cartridge. The whole discussion about the memmory handling here has been how to emulate the cartridge, and not the MSX. For end--users however this can be rather confusing ofcourse because they just see the total picture and not the two (seperate) devices that are emulated. David Heremans -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: extended ROM format
On Sunday 21 January 2001 23:27, you wrote:
> You can use xsc/xsd compression algorithm. Sources can be found on "The MSX
> Plaza" in the section "XSA format".
Thanks, I'll keep that in mind. Is XSA compression only (like gzip and bzip2)
or does it handle multiple files as well (like ZIP and LZH)?
However, I think that the final standard will be a lot like the proposal by
Ricardo, meaning it will use an archive and a text-based info file. If that
approach is used, it's easier to use an archive format that is already
wide-spread. XSA would be a good choice if the format can only be edited
using special tools.
> It is a variant of the LZ77 algorithm, which is in my knowledge still
> patent free.
If it's patent free today, it will be patent free forever. Something that is
already used by others ("prior art") cannot be patented.
> LZW (which was suggested in another message) can not be used. It is
> patented by Unisys.
True, I dismissed that algorithm for that same reason.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format
On Sunday 21 January 2001 20:37, you wrote: > > 3. Compression > > > > TRD said storage capacity is cheap nowadays, so we don't have to use > > compression. I don't agree, for a couple of reasons. For one thing, not > > every file is a 16K ROM. MegaROMs are often 128K or 256K, some as large > > as 2MB. If we include disk games as well, games of several megabytes > > exist. Having a couple of hunderd games on your harddisk, the space does > > add up. And on a real MSX storage size matters a lot more. The second > > reason is that network capacity is not nearly as large as storage > > capacity, so we should also think about download times and bandwidth use. > > Download times? Are the ROM / DSK etc. not already packed with > zip/lha/lzh/pma when you download from internet today? True, that point isn't as strong as I thought it was. Although not having to unpack manually is a bonus. There were several people asking me "what do I do with a .zip file?" after they downloaded Solid Snake. > Well if we are > talking of implementing this standard for DSK images/ other file based > games too I agree that the compression would save some space. But this > will only apply to emulators. The main target for the format is emulators. Making it possible to be used on real MSX is a bonus. > I agree on the fact that the 128K/256K ROMs take MUCH space on msx´s floppy > disks / harddisk but decompression speed on msx is too low for such > operation (unless you don´t care about the speed). It would take ages to > load anything. How do you imagine to decompress 128K/256K ROMs on msx? It depends on the compression algorithm. The SQueeZe algorithm I made is very fast, when loading from floppy it's actually faster than uncompressed (the time saved loading is more than the time needed to unpack). Ofcourse, SQueeZe doesn't compress as tightly as ZIP or LZH. SQueeZe is similar to the algorithm used by POPCOM. The current SQueeZe implementation uses 16K of extra memory to unpack, but the algorithm can be modified to not need any extra memory at all. > An individual decompression routine for MSX would be enough, to manually > decomress / extract the files. This is probably a good compromise. To allow this, we should limit the filename length to 8.3 characters. > > Although the PAC SRAM can be shared by many games, this is not a good > > idea. The user must remember which blocks are in use by which games, and > > many games don't even allow to user to choose the SRAM block but use a > > fixed block instead. It's a lot easier to use a separate PAC SRAM for > > every game. > > Just a question: > Is there a difference between the SRAM in PAC /and FM-PAC cartridge AFAIK, FM-PAC is just PAC + FM. Although I have an FM-PAC, I never saw a FM-less PAC, so I cannot be certain. But it would make sense that both SRAMs are the same, otherwise games that save in PAC SRAM would no longer work with the FM-PAC. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: Rom Formats
On Monday 22 January 2001 08:21, you wrote: > But I was wondering, how does my MSX handle all these ROM types ? > because if I insert a r-type cart, my MSX run's it with no problems. There is hardware inside the cartridge that handles the mapping. If you open a MegaROM cartridge, you will typically see two ICs, the large one is the ROM and the small one is the mapper. In the case of Konami SCC games, the mapper and the SCC are integrated into a single IC. The point is: a cartridge is more than just a ROM. So when an emulator emulates a MegaROM cartridge, it needs more info than just the ROM file. The emulator has to know what other hardware there is in the cartridge. That's what the ROM type is for. Bye, Maarten -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
Re: MSX game format example
On Sunday 21 January 2001 22:19, you wrote:
> I downloaded the file using Netscape Navigator 4.73
> and Internet Explorer 5.00, in the Windows 95 environment.
> Netscape tried to open the file as an ASCII text, and Explorer
> recognized an unknown extension and asked me if I wanted to
> save it to file (cripes, at least once Explorer made the service
> better than Netscape). It seems we will need Maarten suggestion
> about using .msx.zip extensions.
Actually I now think that a single extension is better. An emulator can
register the .msx extension, so that file managers like Explorer and
Konqueror will know what to do when you open a .msx file. With for example
.msx.zip, the program registered for ZIP will open the file instead.
A question to Sean:
The file to specify a mimetype for an extension on Apache, can that file be
created by any user or is it system wide? If the latter is true, people will
have to ask system administration to make the changes and they may be
reluctant to do so.
> -- start of msxgame.ini
We could use ";" for comments instead, I think that's more of a standard.
It's also a bit easier to parse (some people will want to write their own
parser, instead of using lex & yacc). Unix formats often use "#", but that's
not familiar to DOS/Windows and MSX users.
> -- Games are numbered in order of submission
> -- to the mantainer of .msx database
> -- so "1" means Penguin Adventure and "0" means original media
>
> GameID=1.0
Why not use strings instead? Penguin Adventure could be "penadv".
We need a way to know which save game files belong to which game. Using the
game ID is a good way to implement that. And if we do that, "penadv.sav" is
more readable than "1.sav". By limiting the game ID to 6 characters, up to
100 save games can be stored per game in a 8.3 filesystem ("pendav00.sav",
"penadv01.sav" etc).
It is a good idea to have a major ID and a minor ID. Most uses of the game ID
do not depend on the minor ID. For example, save games for the Japanese and
English Solid Snake are exchangable. Walkthroughs are as well, although
walkthroughs for the Japanese version incorrectly state that Snake is smoking
before using the hang glider to calm his nerves, while he is actually
checking the wind direction (or is he? ;).
> -- name is following Maarten syntax
> -- japanese name uses Shift-JIS
>
> Name[us]="Penguin Adventure"
> Name[jp]="²å¤Ahx`["
>
> Manufacturer[us]="Konami"
> Manufacturer[jp]="Ri~"
I proposed to use this syntax for the MSX game info files, but it's not my
standard. As I wrote, I got the idea from the KDE/GNOME .desktop file
standard.
By the way, I think "us" is not a valid language code. It's probably "en_US"
or something like that. After all, the language is still English (although
some UK people will deny this ;), US specifies the "dialect" (it's not really
a dialect, but I don't know the proper word).
> -- this next field could use a string also,
> -- for instance we could adopt
> -- Gametype="Cartridge"
>
> Gametype=0
I propose to use strings wherever possible. No matter what we choose, we'll
always need documentation containing a list of possible values. But strings
are more readable and easier to remember.
> -- This is the generic mapper algorithm
> -- this code snippet would be available in
> -- the .msx file format home page
> -- .msx authors would just copy+paste this code
> -- inside theirs msxgame.ini
One thing that isn't documented yet, is how to handle memory that is not
controlled by the mapper. We could say it is filled with #FF (the data bus
pulled up), but I'm not sure if that's correct for all MegaROMs.
Another thing is how to specify that a cartridge ignores slot select (like
Super Lode Runner does). This is bad design from the cartridge manufacturer,
but it has happened so now we have to deal with it.
Is it useful to allow I/O ports for writing to mapper registers?
Is there any game that reads the mapper registers, or is it always write-only?
> -- select a banksize with 8kb
> Banksize=8
Is any bank size allowed, or just 8kB and 16kB? By the way, make sure you
write the "B" as a capital, otherwise people may misunderstand it to mean
"bits". Remember that "mega" in MegaROM refers to "megabit".
> -- this means we have the following banks
> -- 0 = -1FFF
> -- 1 = 2000-3FFF
> -- 2 = 4000-5FFF
> -- 3 = 6000-7FFF
> -- 4 = 8000-9FFF
> -- 5 = A000-BFFF
> -- 6 = C000-DFFF
> -- 7 = E000-
We could also specify banks by using the address the bank starts at. So
instead of "3", we would write "6000".
> -- if we wanted to define multiple registers,
> -- like in fmsx mapper 3 (konami with scc)
> -- we could make Register[5000-57FF]=2
I think that's just a hack to allow more than one actual mapper to be
emulated using a single fMSX MegaROM type. AFAIK, there is no game that
writes to more than one address to switch. If that's true, there i
Rom Formats
Hi, for the last few day's I'm following the discussion about the extended ROM etc. I saw in a e-mail from Sean Young that he has 15 diffrent ROM types. # 0 standard (no mapper) # 1 msx-dos 2 # 2 konami5 with SCC # 3 konami4 without SCC # 4 ascii/8kb # 5 ascii/16kb # 6 Game Master 2 with SRAM # 7 ascii/8kb with 8kb SRAM # 8 ascii/16kb with 2kb SRAM # 9 r-type # 10 Konami mah-jong 2 (majutsuhi) # 11 Panasonic fm-pac # 12 Super Load Runner # 13 Konami Synthesizer # 14 Cross Blaim But I was wondering, how does my MSX handle all these ROM types ? because if I insert a r-type cart, my MSX run's it with no problems. So do all emulator's have a bug in the memory handeling ? Or does nobody know how a real MSX handles those ROMs ? Because if a emulator can detect it also, I only have to choose a ROM file, and not a type. Or am I complete wrong ? Regards, Sandy Generation MSX http://www.generation-msx.nl -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
