cbios-devel Mailing List for C-BIOS
C-BIOS is an open source BIOS for MSX computers.
Status: Alpha
Brought to you by:
mthuurne
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(28) |
Dec
(27) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(6) |
Feb
(6) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2006 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2010-10-02 02:54:16
|
Feature Requests item #3079834, was opened at 2010-10-01 23:54 Message generated for change (Tracker Item Submitted) made by sd-snatcher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=697340&aid=3079834&group_id=123693 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None Status: Open Priority: 5 Private: No Submitted By: FRS (sd-snatcher) Assigned to: Nobody/Anonymous (nobody) Summary: Diagnose beep codes on boot Initial Comment: Please implement diagnose beep codes like the most PC-BIOS have. http://networking.ringofsaturn.com/PC/beep.php This can help to diagnose problems that occur on boot. The standard MSX BIOS has nothing like that, leaving the users on dark when any component of the MSX is defective (RAM, PPI, VDP, etc) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=697340&aid=3079834&group_id=123693 |
From: Joost Y. D. <jo...@da...> - 2009-01-01 07:45:44
|
On Thursday 01 January 2009 07:57:50 Patrick wrote: > It's fine with me, but I won't test all the games for every bios and every > emulator out there :) I think the point of keeping the data for older emulators also is to detect/verify regressions and fixes. In practice people should only test target on the latest emulator releases. Joost |
From: Patrick <vam...@gm...> - 2009-01-01 06:58:00
|
It's fine with me, but I won't test all the games for every bios and every emulator out there :) Patrick -----Original Message----- From: Albert Beevendorp [mailto:bi...@ms...] Sent: Wednesday, December 31, 2008 10:18 AM To: Patrick Cc: cbi...@li... Subject: C-BIOS list addition request Hi, Currently we've experienced differences with games and different MSX versions of C-BIOS, due to improved accuracy of openMSX (which is probably the most used emulator to test stuff with, at least within the team). Titles not working on C-BIOS MSX1 for example while it works on C-BIOS MSX2 or C-BIOS MSX2+. Because of the improved accuracy in openMSX it's useful to have a list of the most common used MSX emulators at the moment added to the database as well. I'd propose to add at least the last 2 releases of each emulator, especially where significant improvements are introduced, like the VRAM size bit support for MSX1 VDPs, the joystick port output signals support, and other things which could cause C-BIOS to fail at something. I'd propose to include MSX emulators that already ship C-BIOS (openMSX, blueMSX, RuMSX, meisei) to the list. Of course that list can be extended with unlisted emulators. I've requested it on IRC, and Vampier asked me to mail it as a reminder. Following the past from IRC: <BiFiMSX> could you add two more fields to the cbios list? <BiFiMSX> 1. emulator and version it was tested with <BiFiMSX> 2. the cbios msx version <BiFiMSX> it seems now that titles may not work correctly with CBIOS MSX1 and works correctly with CBIOS MSX2 (or MSX2+) <BiFiMSX> and tests done with openMSX 0.7.0 could react differently than openMSX 0.6.3 or even blueMSX or meisei GreeTz, BiFi Visit my Home Page at www.bifi.msxnet.org mail me at: bi...@ms... FTP: ftp.bifi.msxnet.org |
From: Albert B. <bi...@ms...> - 2008-12-31 18:34:20
|
Hi, Currently we've experienced differences with games and different MSX versions of C-BIOS, due to improved accuracy of openMSX (which is probably the most used emulator to test stuff with, at least within the team). Titles not working on C-BIOS MSX1 for example while it works on C-BIOS MSX2 or C-BIOS MSX2+. Because of the improved accuracy in openMSX it's useful to have a list of the most common used MSX emulators at the moment added to the database as well. I'd propose to add at least the last 2 releases of each emulator, especially where significant improvements are introduced, like the VRAM size bit support for MSX1 VDPs, the joystick port output signals support, and other things which could cause C-BIOS to fail at something. I'd propose to include MSX emulators that already ship C-BIOS (openMSX, blueMSX, RuMSX, meisei) to the list. Of course that list can be extended with unlisted emulators. I've requested it on IRC, and Vampier asked me to mail it as a reminder. Following the past from IRC: <BiFiMSX> could you add two more fields to the cbios list? <BiFiMSX> 1. emulator and version it was tested with <BiFiMSX> 2. the cbios msx version <BiFiMSX> it seems now that titles may not work correctly with CBIOS MSX1 and works correctly with CBIOS MSX2 (or MSX2+) <BiFiMSX> and tests done with openMSX 0.7.0 could react differently than openMSX 0.6.3 or even blueMSX or meisei GreeTz, BiFi Visit my Home Page at www.bifi.msxnet.org mail me at: bi...@ms... FTP: ftp.bifi.msxnet.org |
From: Maarten t. H. <ma...@tr...> - 2008-12-23 19:05:12
|
Hi all, I migrated the C-BIOS code and web site from CVS to SVN. You can check out the development version with this command: svn co https://cbios.svn.sourceforge.net/svnroot/cbios/cbios/trunk cbios Bye, Maarten |
From: Joost Y. D. <jo...@lu...> - 2006-09-07 07:13:09
|
Hi, it seems the cbios-commits list is no longer working somehow. I checked out the CVSROOT and updated the loginfo script according to the site-docs of sf.net, but even though it says the mail is sent, I don't see any email arriving at my PC. Maarten, could you perhaps as list-admin of the commits list check if some setting is incorrect on the mailinglist? Greetings, Joost Damad -- The planet Andete is famous for it's killer edible poets. |
From: Jussi P. <cc...@pp...> - 2006-05-14 22:24:40
|
Hi, I built a list of BIOS calls made by all GOODMSX games. It's available at http://cbios.sourceforge.net/goodmsx.txt. Search through it with more or less. --=20 Jussi Pitk=E4nen |
From: Maarten t. H. <ma...@tr...> - 2006-05-12 05:23:57
|
Hi, SourceForge is busy rolling out a new CVS infrastructure. Patrick said it already works for him; for me it doesn't work yet (home dir not found), but in any case it seems it is nearing completion. In the new infrastructure, the CVS root changes: Old: cvs.sourceforge.net New: openmsx.cvs.sourceforge.net cbios.cvs.sourceforge.net If you have no local changes, you can simply do a new checkout. If you have a local checkout you want to preserve, there are tools to migrate it: http://www.red-bean.com/cvsutils/releases/ This is a collection of tools, one of which is "cvschroot" which can set a new CVS root for an existing checkout. You can use it like this: cd ~/src/openMSX (the location of your CVS checkout) cvschroot :ext:use...@op...:/cvsroot/openmsx Be careful with the other tools in that package, since several of them clean up the checkout quite rigorously. And although the help says it takes .cvsignore files into account, in my test run it did not, so it removed "derived" for example. So I removed execute permissions from the cleanup tools, to avoid running them accidentally. The "cvsu" tool seems very useful though: it lists local changes, like "cvs up" does, but does not require a connection to the server. Bye, Maarten |
From: Claudio C. <cl...@c3...> - 2006-05-03 11:04:45
|
Hi guys, I´m very new using openmsx (3 days only), but I used the real hardware for more than 5 years (since I was 12 years old :). I´m just like to congratulate you all for this great peace of software and for you commitment with it (24 hours to a fix of THIS level.....man, if that wasn´t commitment, I don´t know what is....) Thanks again for all of you for your time and promptly help and to allow us to remember the very old and gold time ;-) Best Regards, Claudio Cuqui Maarten ter Huurne escreveu: > On Tuesday 02 May 2006 18:19, Manuel Bilderbeek wrote: > >> Claudio Cuqui wrote: >> >>> I just tried running openmsx with the option below and the glitch was >>> gone. >>> >>> ./openmsx -machine C-BIOS_MSX1 ./PINGPONG.ZIP >>> >>> Again, thanks for your time and help. >>> >> Ah, it seems it is a bug in C-BIOS! I can reproduce the problem with >> C-BIOS_MSX2+ and C-BIOS_MSX2. >> >> C-BIOS folks: please take a look at this. >> > > I fixed it in C-BIOS CVS. > > The problem is that Ping Pong contains a bug: it calls FILVRM with the address > in DE, while it should be in HL. This happens at 0x47BB in the ROM. > > So the value that happens to be in HL is used as an address and when using > 14-bit addressing (for MSX1 with 16K VRAM) this address wraps around and > happens to clear the crucial VRAM areas. However, C-BIOS MSX2/2+ was using > 17-bit addressing, so the address does not wrap around and unused VRAM areas > are cleared. > > The fix is to use 14-bit addressing for SCREEN 0..4 and 17-bit addressing for > SCREEN 5+, like the original BIOS does. Why it uses 14-bit addressing for > SCREEN 4 is beyond me, but that's what it does, so C-BIOS now mimics that > behaviour, to avoid incompatibilities. > > Bye, > Maarten > |
From: Patrick <vam...@gm...> - 2006-05-03 03:17:16
|
Thanks for the quick fix. I'll try to pick up testing soon. Patrick ----- Original Message ----- From: "Maarten ter Huurne" <ma...@tr...> To: <ope...@li...> Cc: "Manuel Bilderbeek" <ma...@ms...>; "Claudio Cuqui" <cl...@c3...>; <cbi...@li...> Sent: Tuesday, May 02, 2006 17:38 PM Subject: [openMSX-devel] Re: Problem with konami´s Ping Pong > On Tuesday 02 May 2006 18:19, Manuel Bilderbeek wrote: >> Claudio Cuqui wrote: >> > I just tried running openmsx with the option below and the glitch was >> > gone. >> > >> > ./openmsx -machine C-BIOS_MSX1 ./PINGPONG.ZIP >> > >> > Again, thanks for your time and help. >> >> Ah, it seems it is a bug in C-BIOS! I can reproduce the problem with >> C-BIOS_MSX2+ and C-BIOS_MSX2. >> >> C-BIOS folks: please take a look at this. > > I fixed it in C-BIOS CVS. > > The problem is that Ping Pong contains a bug: it calls FILVRM with the > address > in DE, while it should be in HL. This happens at 0x47BB in the ROM. > > So the value that happens to be in HL is used as an address and when using > 14-bit addressing (for MSX1 with 16K VRAM) this address wraps around and > happens to clear the crucial VRAM areas. However, C-BIOS MSX2/2+ was using > 17-bit addressing, so the address does not wrap around and unused VRAM > areas > are cleared. > > The fix is to use 14-bit addressing for SCREEN 0..4 and 17-bit addressing > for > SCREEN 5+, like the original BIOS does. Why it uses 14-bit addressing for > SCREEN 4 is beyond me, but that's what it does, so C-BIOS now mimics that > behaviour, to avoid incompatibilities. > > Bye, > Maarten > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > openMSX-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openmsx-devel |
From: Maarten t. H. <ma...@tr...> - 2006-05-03 00:36:43
|
On Tuesday 02 May 2006 18:19, Manuel Bilderbeek wrote: > Claudio Cuqui wrote: > > I just tried running openmsx with the option below and the glitch was > > gone. > > > > ./openmsx -machine C-BIOS_MSX1 ./PINGPONG.ZIP > > > > Again, thanks for your time and help. > > Ah, it seems it is a bug in C-BIOS! I can reproduce the problem with > C-BIOS_MSX2+ and C-BIOS_MSX2. > > C-BIOS folks: please take a look at this. I fixed it in C-BIOS CVS. The problem is that Ping Pong contains a bug: it calls FILVRM with the address in DE, while it should be in HL. This happens at 0x47BB in the ROM. So the value that happens to be in HL is used as an address and when using 14-bit addressing (for MSX1 with 16K VRAM) this address wraps around and happens to clear the crucial VRAM areas. However, C-BIOS MSX2/2+ was using 17-bit addressing, so the address does not wrap around and unused VRAM areas are cleared. The fix is to use 14-bit addressing for SCREEN 0..4 and 17-bit addressing for SCREEN 5+, like the original BIOS does. Why it uses 14-bit addressing for SCREEN 4 is beyond me, but that's what it does, so C-BIOS now mimics that behaviour, to avoid incompatibilities. Bye, Maarten |
From: Manuel B. <ma...@ms...> - 2006-05-02 16:19:25
|
Hi, Claudio Cuqui wrote: > I just tried running openmsx with the option below and the glitch was gone. > > ./openmsx -machine C-BIOS_MSX1 ./PINGPONG.ZIP > > Again, thanks for your time and help. Ah, it seems it is a bug in C-BIOS! I can reproduce the problem with C-BIOS_MSX2+ and C-BIOS_MSX2. C-BIOS folks: please take a look at this. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ |
From: Wouter V. <wou...@sc...> - 2006-02-28 08:48:21
|
On Mon, 27 Feb 2006, Patrick wrote: > btw I'm going to bring in an game ID which will be linkable to the > cheat database (XML format) I want to make sure this database will be > compatible with bluemsx... What do you mean with a 'game ID'? An extra field per game with some arbitrary unique number? I don't like the words 'arbitrary' and 'unique', because it makes it more difficult to maintain the database in a distributed way. Would it be possible to reuse the SHA1 field as an ID? (I know one game can have multiple SHA1 values, but there are solutions to this problem). Wouter |
From: Patrick <vam...@gm...> - 2006-02-27 23:02:46
|
I think I missed an SHA1 field :) no biggie... I will eventually get = them all btw I'm going to bring in an game ID which will be linkable to the cheat = database (XML format) I want to make sure this database will be = compatible with bluemsx...=20 Which brings me on the following... I know you are looking for cheats... I am thinking about making a SQL = database with a new front end so we can add cheats to the list.. this = way we have one list. We can either stored this list on the bluemsx = server or openmsx or www.vampier.net the romdb is already on = vampier.net. Just an idea... this way you can add cheats to the database.. I will = make it you can get the complete SQLdatabase with all the fieldsfor your = own use. I want to work together with you guys to give users a better game = experience and hopefully we will top all the emulators out there and set = a new standard. Just an idea. Patrick ----- Original Message -----=20 From: Beno=EEt Delvaux=20 To: Patrick=20 Sent: Monday, February 27, 2006 2:45 PM Subject: Re: Cheats Hello ! Yes, that's right, these 10 CRC32 values can also be found in the = remaining little romdb.dat file. But actually, there is more than these = 10 CRC32 values. Actually, I've still not yet decided to delete the remaining crc32 = values in the xml file for blueMSX. Finding the remaining 50 roms is not = a prioity and there's no emergency to drop the crc32 support in blueMSX. Besides, I don't understand how you can find only 16 new sha1 values = in the blueMSX database; there is really more : for example, all the = Arabic roms have now a sha1 value and are integrated in the general MSX1 = section (with exception for 1 or 2 roms that are in the MSX2 rom); for = the other games, I've generally respected the original order of the = roms, so you should easily find the correspondance between the crc32 and = the sha1 value. I hope really that it can help you. I hope also that the RuMSX author = will change for sha1 values ! Beno=EEt =20 ----- Original Message -----=20 From: Patrick=20 To: Beno=EEt Delvaux=20 Sent: Monday, February 27, 2006 2:04 AM Subject: Re: Cheats Hola, 9CEF3A37=20 53FA8533=20 00C15010=20 3E19F0A2=20 142109000000=20 F5330590=20 4A5FB958=20 C69A32D2=20 1E62F3B1=20 7FAAF10C=20 Check for these values in your rom database.. you still have CRC32 = values in there. I just updated to romdb file with the missing sha1 values that where = in bluemsx but not in openmsx. About 16 entries more it seemed.... I = also generated a rom database without the crc32 values.... they are = still in the database because they can come in handy in the future. Patrick ----- Original Message -----=20 From: Beno=EEt Delvaux=20 To: Patrick=20 Sent: Friday, February 24, 2006 11:30 PM Subject: Re: Cheats Hello ! I can understand that you do trainer.tcl updates only on Saturday = and Sunday, there's no emergency to add my cheats. I was though surprised that you didn't have seen last week-end my = 3 mails of 13 february with new cheats or additions/corrections of = existing cheats. Of course, I could send you the file with my updates at the end of = the file when it concerns cheats for new games. But it seems me more difficult for you if it concerns additions to = already trained games. I don't know how you can easily find the = additions in this case. Beno=EEt ----- Original Message -----=20 From: Patrick=20 To: Beno=EEt Delvaux=20 Sent: Saturday, February 25, 2006 6:15 AM Subject: Re: Cheats As you can see I don't do trainer.tcl updates during the week... = I explian briefly why this is I wake up at 5:10 get to work at 6:00 come home at 16:30 (if I'm = lucky) and the last thing on my mind are TCL files or MSX emulators. if you want to have the cheats in quicker add them to the latest = trainer file and send the file to me, I check my e-mail eveyr night. Patrick ----- Original Message -----=20 From: Beno=EEt Delvaux=20 To: Patrick=20 Sent: Monday, February 20, 2006 8:41 AM Subject: Cheats Hello ! I've just seen your last additions in CVS (version 1.58) What about my previous mails (new cheats and/or additions to = existing cheats) ??? Besides, the correct spelling of my name is "Beno=EEt = Delvaux"; eventually, if the accented character is source of problem in = the xml file, you can use "Benoit Delvaux". Beno=EEt |
From: Manuel B. <ma...@ms...> - 2006-02-24 20:24:35
|
Patrick wrote: > don't get it =) > > I tells me a message... no disk activity yet It loads the first sector of the disk and shows some (all? don't remember) data of it. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ |
From: Patrick <vam...@gm...> - 2006-02-24 03:09:15
|
don't get it =) I tells me a message... no disk activity yet ----- Original Message ----- From: <bo...@mm...> To: <cbi...@li...> Sent: Thursday, February 23, 2006 10:47 AM Subject: [C-BIOS] I just want to show > Hi, > > http://www.emucamp.com/boukichi/cschijf.zip > > this is what I just want to show. > > if you have a courage and skill to do on a real machine,please report me > :) > > ------------------ > BouKiCHi > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > cbios-devel mailing list > cbi...@li... > https://lists.sourceforge.net/lists/listinfo/cbios-devel |
From: <bo...@mm...> - 2006-02-23 18:46:47
|
Hi, http://www.emucamp.com/boukichi/cschijf.zip this is what I just want to show. if you have a courage and skill to do on a real machine,please report me :) ------------------ BouKiCHi |
From: <cc...@pp...> - 2005-12-06 17:03:51
|
Hi, I've been playing with the idea of Forth environment running on top of C-BIOS for a while. Previously there haven't been many home computers with Forth as their default operating system and programming language. This is most likely because those machines weren't intended for programmers: BASIC is more conventional and thus easier to grasp for beginners. I would, however, love to have an MSX machine with Forth environment lying on my desk. It would make a wonderful machine to hack on when you feel like doing something different. It would be nice to have alternatives like this for the usual BASIC. And, in my opinion, C-BIOS could potentially provide a good foundation for them. To pep up these ideas and to wake up everyone from daydreaming I started working on C-Forth last weekend. It grew into something marginally usable so I thought it was the time to inform the mailing list about it. I haven't really written any Forth applications before. This is actually quite funny as I partly learned how Forth operates by implementing one myself. It also reveals one thing about Forth: while being highly flexible to use it's also relatively simple to implement. C-Forth already has the most used things you usually find in Forth. On the other hand, it has quite some hacky and poorly factored code. Even so, I'm quite happy what I've got at the moment; it's a good base to evolve. I made a patch against the current CVS tree. It has a new source file src/forth.asm and a documentation file doc/cforth.txt. The only diff to the existing files is Makefile where I just added it to be built as a separate ROM. I would be ready to commit the patch to CVS, but what do you think? Please also read doc/cforth.txt. It has got a few Forth code examples to try on C-Forth and some text about internals. It also has a preliminary proposal for a block editor. The patch and the ROM are currently available here: http://bree.homeunix.net/~ccfg/temp/forth.diff http://bree.homeunix.net/~ccfg/temp/cbios_forth.rom Some pointers to Forth information: http://en.wikipedia.org/wiki/Forth_programming_language http://www.zetetics.com/bj/papers/ Any thoughts on these matters are appreciated. --=20 Jussi Pitk=E4nen |
From: Laurens H. <lh...@st...> - 2005-07-13 15:17:05
|
Maarten ter Huurne wrote: >Hi, > >Because various MSX programs are jumping directly into the BIOS (bypassi= ng the=20 >entry points), we have several fixed-address routines. Each fixed addres= s is=20 >the start of a "memory area". BouKiCHi encountered a problem that when a= dding=20 >code, one memory area grew too long and started to overlap the next.=20 >Specifically, when adding code to GRPPTR, the area starting at $0200 and= =20 >containing "util.asm", "video.asm" and "debug.asm" will bump into the=20 >interrupt routine exit sequence at $0D01. > =20 > The best solution would be to divide all subroutines in separate=20 =E2=80=98units=E2=80=99, where each unit starts with a segment of code th= at is only=20 entered by means of a call or a jump, and ends where the routine exits=20 (by means of a return or a jump). A subroutine is an example of a unit,=20 and a routine which contains a construct like: loop: dec a jp nz,continue ... jp loop continue: can also be divided into two units. Next, you specify fixed start addresses for some of the labels (e.g.=20 entry points of a number of routines), and units which have such a label=20 are considered to be =E2=80=98address-fixed=E2=80=99. For the others, the= address is=20 =E2=80=98flexible=E2=80=99. Now, the assembler should assemble the units with fixed addresses first,=20 and once they are in place, fill the remaining space sequentially from=20 the bottom up with the rest of the units. If a unit doesn=E2=80=99t fit i= n a=20 certain area because there is a fixed address unit ahead, not leaving=20 enough room, it should start after the fixed address unit. To optimize space usage, you could even divide the available space based=20 on an optimizing algorithm. However, that will cause related pieces of=20 code not being close to eachother, so unless space is growing really=20 tight, I do not think that is necessary nor desirable. Anyways, I do not think you are able to do this with your current=20 assembler... Although maybe using a linker you could. A clever assembler could even automate the division into units, not=20 having to explicitly define where a unit starts and ends. Fixed=20 addresses could be determined by detecting duplicate labels where one is=20 flexible, or introducing a new variant of =E2=80=98equ=E2=80=99, e.g.: Some_routine: equ #50D ;fixed start address UNIT Some_routine: ret ENDUNIT Ah well. ~Grauw --=20 Ushiko-san! Kimi wa doushite, Ushiko-san!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Laurens Holst, student, university of Utrecht, the Netherlands. Website: www.grauw.nl. Backbase employee; www.backbase.com. |
From: <cc...@pp...> - 2005-07-13 14:22:47
|
On Fri, Jul 08, 2005 at 10:12:33PM +0200, Maarten ter Huurne wrote: > The problem is that the area containing "util.asm", "video.asm" and > "debug.asm" does not have enough space to grow. As a short-term measure, we > could get rid of the empty space at $018C-$01FF and move "util.asm" and > "debug.asm" elsewhere. That will free 184 bytes, which might be enough for a > couple of additions in "video.asm", but will not last very long. > > Another option would be to move "video.asm" to another area. If we move > "slot.asm" and the system messages elsewhere, we have an area of 3540 bytes > available, while "video.asm" is currently 2723 bytes. > > Finally, we don't actually need MSX2 and MSX2+ routines in "video.asm": the > MSX BIOS puts those routines in the sub ROM and uses an inter slot call to > execute them. Only the MSX1 versions have to be in the main ROM. The MSX1 > version of "video.asm" is only 1855 bytes long. Moving "video.asm" to another area might be a good move for now. It would probably postpone the next issue with a memory area growing into another for longer. After doing that we have also some time to think how to put the MSX2/2+ video routines in the sub ROM properly. While this might sound the easiest path, it might be the best we can take at the moment. Deciding about the eventual memory map for C-BIOS wouldn't be easy at this point of development while we still have a lot of code to do and existing software to test. We can quite easily expect which areas will grow but we can't know for sure whether there will be more crucial FIXED areas of memory. -- Jussi Pitkänen |
From: <bo...@mm...> - 2005-07-10 12:40:23
|
Hi, > I took a hex editor and looked at the C-BIOS ROM image. About 40% of the ROM > image is still empty (zeroes). So the problem is not that the image is full, > but that the empty space is in the wrong locations. is that 40% included the subrom? I think that it might be marked that memory after statements.asm is reserved by BASIC > Finally, we don't actually need MSX2 and MSX2+ routines in "video.asm": the > MSX BIOS puts those routines in the sub ROM and uses an inter slot call to > execute them. Only the MSX1 versions have to be in the main ROM. The MSX1 > version of "video.asm" is only 1855 bytes long. actuall MSX2 bios is called SUB ROM via EXTROM. if we'd like to emulate more exactly, we should make it to call SUB ROM as well. > I'm not sure yet which steps we should take next: > - Go for a long-term solution right away or apply the short-term solution > first to give us some more time to think? I guess,we need to go a long-term solution anyway, so we might discuss when we'll go there. > - What would be a good eventual memory map for C-BIOS? Which areas do we > expect to grow and which to stay approximately the same? I don't know exactly, but now we have that didn't implement routines in video.asm and main.asm. for example,STRTMS,part of other screen mode of GRPPRT,etc. > - How can we put the MSX1 video routines in the main ROM and the MSX2/2+ video > routines in the sub ROM in an elegant way? it might be nice that we make "video_main.asm" and "video_sub.asm" and also those sources use definition to detect version. ------------------ BouKiCHi |
From: Maarten t. H. <ma...@tr...> - 2005-07-08 20:10:41
|
Hi, Because various MSX programs are jumping directly into the BIOS (bypassing the entry points), we have several fixed-address routines. Each fixed address is the start of a "memory area". BouKiCHi encountered a problem that when adding code, one memory area grew too long and started to overlap the next. Specifically, when adding code to GRPPTR, the area starting at $0200 and containing "util.asm", "video.asm" and "debug.asm" will bump into the interrupt routine exit sequence at $0D01. I took a hex editor and looked at the C-BIOS ROM image. About 40% of the ROM image is still empty (zeroes). So the problem is not that the image is full, but that the empty space is in the wrong locations. Here is an overview of the memory areas that currently exist. The addresses are for the MSX2+ version, which should have the largest code size since it has to support the most features. The areas marked with "FIXED" must start at the addresses they are at now. $0000-$018B: FIXED: entry points $018C-$01FF: empty $0200-$0209: util.asm $020A-$0CAC: video.asm $0CAD-$0CE6: debug.asm $0CE7-$0D00: empty $0D01-$0D11: FIXED: exit of interrupt routine $0D12-$19A4: routines from main.asm $19A5-$1BBE: empty $1BBF-$23BE: FIXED: font $23BF-$2555: slot.asm $2556-$2736: system messages from main.asm $2737-$3192: empty $3193-$31BB: FIXED: routines from statements.asm $31BC-$392D: empty $392E-$3A71: FIXED: rombas table and debug routine from statements.asm $3A72-$3FFF: empty The problem is that the area containing "util.asm", "video.asm" and "debug.asm" does not have enough space to grow. As a short-term measure, we could get rid of the empty space at $018C-$01FF and move "util.asm" and "debug.asm" elsewhere. That will free 184 bytes, which might be enough for a couple of additions in "video.asm", but will not last very long. Another option would be to move "video.asm" to another area. If we move "slot.asm" and the system messages elsewhere, we have an area of 3540 bytes available, while "video.asm" is currently 2723 bytes. Finally, we don't actually need MSX2 and MSX2+ routines in "video.asm": the MSX BIOS puts those routines in the sub ROM and uses an inter slot call to execute them. Only the MSX1 versions have to be in the main ROM. The MSX1 version of "video.asm" is only 1855 bytes long. I'm not sure yet which steps we should take next: - Go for a long-term solution right away or apply the short-term solution first to give us some more time to think? - What would be a good eventual memory map for C-BIOS? Which areas do we expect to grow and which to stay approximately the same? - How can we put the MSX1 video routines in the main ROM and the MSX2/2+ video routines in the sub ROM in an elegant way? Your thoughts on these subjects are appreciated. Bye, Maarten |
From: <bo...@mm...> - 2005-06-15 14:50:20
|
Hi everyone, at the moment, C-BIOS logo is placed at around $3000, but official MSX BIOS is using around $3000 for ROM BASIC routines, and some cartridges call those routines. (if you have seen list,you might recognize blue's exsistance) We thought some plans how to do. 1, move the logo into new made logo display cartridge. 2, move the logo into the sub rom or other space on BIOS's page0. 3, we wait to make any idea by someone. :) 4, other. If you have any suggestion or something,please reply to this one. Regards, ------------------ BouKiCHi |
From: Joost Y. D. <jo...@lu...> - 2005-06-07 09:32:59
|
On Tuesday 07 June 2005 02:31, Maarten ter Huurne wrote: > Hi, > > I just uploaded C-BIOS 0.21 to SourceForge and submitted a newspost to MR= C. > > Special thanks for this release go to: > - Vampier and BiFi for the MSX2 version of the boot logo > - ccfg for the new ROM search > - BouKiCHi for last-minute bug fixes > And of course thanks to everyone who helped in one way or another! > > Rudolf: I think I fixed all VDP initialisation issues with this release. = If > any remain, please tell me. I also included the updated RuMSX config files > you sent. > > Joost: Can you make a .deb of this release? Will it show up in "stable" > shortly, or will it remain in "testing" for a while? I will make a .deb real soon. It can't enter stable anymore as stable has b= een=20 released (with cbios 0.20). see also:=20 http://qa.debian.org/developer.php?login=3D...@lu... It will enter testing as soon as the new testing is opened. (given it gets = no=20 bugs in unstable after the initial period). Joost |
From: Maarten t. H. <ma...@tr...> - 2005-06-07 00:29:25
|
Hi, I just uploaded C-BIOS 0.21 to SourceForge and submitted a newspost to MRC. Special thanks for this release go to: - Vampier and BiFi for the MSX2 version of the boot logo - ccfg for the new ROM search - BouKiCHi for last-minute bug fixes And of course thanks to everyone who helped in one way or another! Rudolf: I think I fixed all VDP initialisation issues with this release. If any remain, please tell me. I also included the updated RuMSX config files you sent. Joost: Can you make a .deb of this release? Will it show up in "stable" shortly, or will it remain in "testing" for a while? Bye, Maarten |