MSXdev'11 - #8 Zombie Incident

MSXdev'11 - #8 Zombie Incident

by wolf_ on 31-01-2012, 22:42
제목: Software
태그: MSXdev, nenefranz
언어 설정:

Entry eight in the MSXdev'11 contest is a page-per-page platform game by nenefranz, with music by John Hassink. Humankind has done it again, their sins made the citadel of Hamartia a place you don't want to wander around any more. It's up to you to return eight stars and restore everything that once was good. What's evident is the polish of this game. Sprite characters feature an extra shade - how often do you see that in an MSX1 game! Everything looks and sound like a potential winner, and considering this game is 'only' a 48KB ROM, that's quite something . But, make no mistake about it: humankind has messed up big time, it's not an easy game to win back peace in Hamartia; it's truly a challenge!

Relevant link: MSXdev'11 - Zombie Incident

댓글 (79)

By Oscar

Hero (517)

Oscar의 아바타

31-01-2012, 23:14

Great game!!! More and more quality games each year! Long life for MSX!! Big smile

By Manuel

Ascended (10042)

Manuel의 아바타

31-01-2012, 23:27

I've seen this game demo'd in Nijmegen and it's really fantastic Smile

By snout

Ambassador (14859)

snout의 아바타

31-01-2012, 23:32

I've had a preview of this game at the 2k11 launch party and was absolutely stunned by its quality. Brilliant stuff, this...

By Oscar

Hero (517)

Oscar의 아바타

31-01-2012, 23:40

This game remembers me Project Arba Minch

By RobertVroemisse

Paragon (1210)

RobertVroemisse의 아바타

31-01-2012, 23:50

I have played the work in progress some months ago and I love to see the subtle changes in gameplay and if I'm not mistaken, some graphics and the music were polished as well. Great work guys!

By mars2000you

Prophet (3826)

mars2000you의 아바타

31-01-2012, 23:51

Version 1.1 is now available on the MSXdev' website !Wink

(bugfix for some machines - you was invulnerable on C-BIOS MSX2 and C-BIOS MSX2+)

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

01-02-2012, 01:54

Very high quality game indeed, and very fun to play!

I also tried it on the MSX AcidTests, and passes the MSX Acid1Test-slots, but sadly it fails to pass the harder MSX Acid2Test-hardware (resets after you press the trigger to begin the game).

By Lord_Zett

Champion (426)

Lord_Zett의 아바타

01-02-2012, 07:52

good looking game this is i love it.

By Valkyr

Hero (579)

Valkyr의 아바타

01-02-2012, 11:12

Hope to see it soon in physical version. It´s a wonderful game.
Only one thing... in real MSX, at 60hz the game starts automatically in the "songs menu"

By hap

Paragon (1916)

hap의 아바타

01-02-2012, 14:37

Hmm, this would be so much better if you (the programmer) had a bit more time, right? Which would be such a shame. I really have the feeling it's not finished yet. Player/enemy collision often messes up (get stuck inside enemy and such). Also, right at the start of the game, i went left over the wall, not supposed to be there I guess. =p

Good game otherwise, especially graphics and animation. And gotta love JH's music, as always. Smile

By Vampier

Paragon (1856)

Vampier의 아바타

01-02-2012, 16:07

By Manuel

Ascended (10042)

Manuel의 아바타

01-02-2012, 17:41

Tip to debug uninitialized memory reads: use this: http://openmsx.sourceforge.net/manual/commands.html#umr_call...

By Sander

Ambassador (1727)

Sander의 아바타

01-02-2012, 18:46

I've seen this one in action. Really amazing how colorful this game is. Also amazing is the speed of which you can control your character. Music fits like a glove! Thumbs up!!

By nanochess

Master (174)

nanochess의 아바타

01-02-2012, 22:20

like this hap? http://www.youtube.com/watch?v=isd7MZgpJYs

In my first play test I got same case.
By the way, very nice two-color sprites.

By nenefranz

Resident (34)

nenefranz의 아바타

01-02-2012, 23:16

Hi all,
Thanks for the compliments, it is comforting to know that people like the game (despite the errors that are appearing).
The "magic travel" to the right of map it's an error ... yes (it's obvious) ... a pitiful mistake that was detected and fixed some time ago. But I don't know how, I'm be able to put in again!!
I'm sorry if I have disappointed someone Sad. It is a inexcusable carelessness, I have no excuses. The problems that are appearing aren't lack of time or unfinished work, it's simply a series of oversights plus a lack of experience.
But, as I said to people of the team, the game will be fixed and updated till become a polished work. I don't know if I will be capable but I will try. Big smile 
Thanks again for the compliments.

Best regards,

By hap

Paragon (1916)

hap의 아바타

01-02-2012, 23:35

This is your first MSX/Z80 game?

By Oscar

Hero (517)

Oscar의 아바타

02-02-2012, 00:04

This game must be in a cartridge!! Big smile

By nenefranz

Resident (34)

nenefranz의 아바타

02-02-2012, 00:05

Yes, my first published msx game ... out of my room!!! LOL!

By MäSäXi

Paragon (1776)

MäSäXi의 아바타

02-02-2012, 08:37

Thank you for your game nenefranz! Smile

First, two little bugs, when I press Space while demo is showing gameplay, nothing happens = game doesn´t start. But I can start game normally after ingame demo ends. Second bug happens when you keep pressing cursor down after jumping, when you land to ground, it gives BRRRRRRRRRRRRRRR! noise as long as you press cursor down. I don´t mind them, just wanted to tell you. Smile

Then I can say my opinion about your game:

AT LAST!!! Someone thought to give shades to MSX-1 sprites!!! Thank you!!!! Big smile They look really great!!!!!!!! Smile There are some few MSX-1 games with shaded sprites but this game surely has the best looking shading EVER!!! I also do like the pastel like background colouring. Smile

John´s music are nice to hear!

It´s a nice feeling that when jumping, you can grab the wall to get even higher!! Smile It also was a surprise to see how my five year old instantly managed to play SO GOOD with so great speed at the very first try!!!! So I must congratulate and thank you for great player control routines!!!!!!!! Smile

On the other hand, I personally feel this game is too easy, as it´s so hard to get energy bar to decrease even when trying hard to do so. (no, not a bug) I feel sad to say that such thing makes my interest fade too soon on this game, as otherwise this game really is something which is never seen on MSX before!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Ok, I played just few tries yesterday evening, so I don´t know how large game map may be, so it may be possible that energy decreasing factor is tuned just right if this game´s map is really big. I am just used to the fact that in the eighties games were usually hard. But this is very good game for young children as game continues for a long time! Smile

So I will congratulate you!! Smile

Oh, player sprite looks like multicolour shaded sprite version of Binary Land´s girl!! Lovely!! Big smile

By wolf_

Ambassador_ (9471)

wolf_의 아바타

02-02-2012, 13:00

I believe John consulted me a few times about music, probably for this game then I guess, in which case the end tune is really well done. (don't remember names/titles/projects, sorry JH Tongue)

By nenefranz

Resident (34)

nenefranz의 아바타

02-02-2012, 13:11

Yes wolf_, I think that John consulted you about music for ZI. "The end" tune is great ... all music for the game is great!! ( and not only for this project!! Wink )

By snout

Ambassador (14859)

snout의 아바타

02-02-2012, 13:23

What a spectacular entry to the MSX community, nenefranz - I hope there is much more to come!

By nenefranz

Resident (34)

nenefranz의 아바타

02-02-2012, 22:53

Thanks to all,

My intention was to create a game that was enjoyable to play for everybody. I didn't want to make a game imposible to beat, like some in the 80's. In order to acomplish this I has let the player recover energy when erase all zombies of a room, or find a star. Maybe this action makes the game too easy.  But to balance the difficulty no always the reward is the same. When player is full of energy the reward of vitality is one or two units, but if player is near death the reward of energy is three or four units. Anyway, an average player with prudence can finish the game without too many problems. I prefer a good game that can be finished that a awesome game that you can ever beat. Smile
Also I have tried to give a point of replayability, so every game the stars are in diferent places (not always in the same rooms).

Best regards,

By [WYZ]

Champion (257)

[WYZ]의 아바타

06-02-2012, 22:29

Most part of us have follow MSXdevs challenges and I'm sure that we've thought that this game is a top ten. Nenefrantz has coded a high quality game and Jonh Hassink has climb a lot of steps in my "Idols list".

It's nice to read that the game was inpired by Mojon Twins's Cheril Perils! Great!

By mars2000you

Prophet (3826)

mars2000you의 아바타

25-04-2013, 22:53

Bugfixed and improved version 1.2 is available :

http://msxdev.msxblue.com/?p=1888

By JohnHassink

Ambassador (4181)

JohnHassink의 아바타

26-04-2013, 04:42

Music is updated, too. Smile
Happy to see the whole thing published, nenefranz!

Quote:

I liked the game story music, sounds exactly like Chrono Trigger’s Burn! Bobonga! Burn!

By nenefranz

Resident (34)

nenefranz의 아바타

26-04-2013, 10:26

I'm sorry I took so long to send the latest version. Tongue
Yes, this new version fixes some little bugs and includes an improved version of musics ... a great work of John. Smile

By Manuel

Ascended (10042)

Manuel의 아바타

26-04-2013, 13:40

The music rocks Smile

By hap

Paragon (1916)

hap의 아바타

26-04-2013, 19:47

Ohh, much improved. I played it and got pretty far.

By Imanok

Paladin (788)

Imanok의 아바타

27-04-2013, 09:36

Great! I was looking forward the bugfixed version Smile

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

30-04-2013, 02:00

@nenefranz

I took the liberty to do the battery of compatibility tests described on the MSX wiki. Here are the results:

- Acid1Test-slots: Passed
- Victor HC-95: Passed
- Sony HB-F500: Failed
- National CF-3000: Passed
- TMS9918 VDP timings: Passed
- Turbo CPU: Passed
- Turbo Blitter: N/A
- Sharp Hotbit: Passed
- C-BIOS: Passed
- Acid2Test-hardware: Failed
- Reads on write-only PSG ports: Passed
- MSX-Music FM-BIOS: N/A

By nenefranz

Resident (34)

nenefranz의 아바타

01-05-2013, 11:26

Thanks sd_snatcher,

The game failed in two tests: Sony HB-F500 and Acid2Test-hardware.
It's okay to have failed two tests only! Smile Is it severe that the game failed in these two tests?
For now, all owners of a HB500 can't play the game, and this isn't good!! Sad
Is Sony HB-F500 a common machine?

I only use BIOS calls and three routines to set page2 to ROM, and page0 to ROM and back to BIOS. I thought that with this way of programming, the rom could be compatible with all machines. Saccopharynx helped me to fix some problems with the game. It had worked ok in a rom, but it failed to run if loaded into ram. In this latest release, this error is fixed and can be loaded into ram too, so a tape release can be made. But it seems that isn't enough to be full compatible.

What is wrong to not pass the tests? Can you give me any clue in order to know where are the errors? What kind of particularities have the Acid2test?

By Poltergeist

Master (217)

Poltergeist의 아바타

01-05-2013, 12:41

Wasn't the HB500 that machine with everything in slot 0 (ROM, RAM) to make it possible to have three cartridgeslots?

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

01-05-2013, 15:09

In Italy was very rare. The few owners I knew, have sold it as soon as possible

By Manuel

Ascended (10042)

Manuel의 아바타

04-05-2013, 10:14

nenefranz and others: some details are on the wiki page that sd_snatcher mentioned.

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

04-05-2013, 20:28

@nenefranz

The tests represent a category, so failing in one of them means that other machines with similar designs will also fail too.

To discover why you game is failing on the Sony HB-F500, I recommend that you use openMSX and it's excellent openMSX-debugger, then run the game step-by-step to see where it is failing.

For the Acid2Test-hardware, I took a quick look: It seems that you're doing direct I/O for both the PPI and PSG, and this is not allowed by the MSX standard. That's why it fails to pass this test. The AcidTests are for testing the MSX compatibility similar to what the ZexAll test is for testing Z80 compatibility.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

05-05-2013, 00:44

Tons of excellent game from the 80's wouldn't pass these tests. The whole thing seems to me just theory nowadays

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

05-05-2013, 02:49

Yes, you're right. But back then it was very hard to get decent documentation to code properly. Most people (including me) just disassembled the BIOS and coded the way seen there. But the BIOS is allowed to do direct I/O. User programs aren't allowed to access the hardware like that.

These days we have a lot of documentation, so it doesn't have to be like that anymore, isn't it? Of course it's up to each one to decide if he wants to overcome this challenge.

And except for the speccy ports (that usually don't run properly even on a plain vanilla MSX), the vast majority of games I looked into were very easy to fix and only had problems because of one or another routine.

Surprisingly or not, games from big names like Konami and Namco usually pass all the tests.

Kralizec was one of the homebrew guys that was getting better and better on this. Their Goonies game passes all tests and the only minor issue is that the PSG replayer doesn't produce any sound on Acid2Test-hardware.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

05-05-2013, 09:23

Using the bios for vdp access is a pure waste of cpu time, it cuts down the I/O bandwidth of the 50% in a machine where the weak point is the slowness of the video I/O. Nothing of advanced could be developed with this limitation.
Only few exotic charts (to upgrade msx1 to msx2) do not use 0x98 and 0x99 as vdp ports.
Today there is no reason to use the bios for vram access.

Today, no home-brew game would gain a single additional user by passing Acid2Test
If I were a game developer I would spend my time developing games instead of trying to get my games pass these tests.

By nenefranz

Resident (34)

nenefranz의 아바타

05-05-2013, 10:02

Thanks to all,

sd_snatcher you are right. I have checked the code and there are two places with direct I/O of PPI and PSG ports. In the replayer PSG ports are directly accessed in the routine that upload values to registers of the PSG. Also, PPI is directly accessed in the routine to select ROM/BIOS on page0. I will try to substitute this code ... if I'm able to. Smile

About the HB-F500, I can't execute openMSX with this machine. The more similar is HB-F500P. Could be the problem with this kind of machines the same routines to set rom/bios of page0? Question

By nenefranz

Resident (34)

nenefranz의 아바타

05-05-2013, 10:53

Well, I have began to check the code, but I realize that the routine to change page0 between ROM or BIOS can't be changed. If I hide BIOS to set ROM on page0, I can't use BIOS to come back again to use BIOS in page0. oO It seems that It isn't possible create a 48KB ROM without direct access of ports. I'm right?. Question Is there any Konami 48KB ROM? Maybe this was the reason. sorry if it is a nonsense question, I'm a beginner in this matter. Sad

By Manuel

Ascended (10042)

Manuel의 아바타

05-05-2013, 13:19

ARTRAG: as the MSX Technical data book says on page 42, it's alright to use the I/O ports directly for VDP access, but you have to read the proper port number from the ROM on locations 6 (R) and 7 (W). That's all. This is the only exception.

Just tested on openMSX with the Neos MA-20 Version up adapter:

?hex$(peek(6))
88

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

05-05-2013, 15:08

Sure, but you are free to unplug that extension chart and use Zombie Incident in your plain msx1 even if it is using ports 0x98 and 0x99 directly.
In order to do a rom that uses the values stored in 0x0006, you have to resort to indirect I/O access using register C.
This is a BIG limitation: you waste a z80 register and a lot of cpu time.
Do you really think that, today, it is wise to replace direct I/O with indirect access only to avoid the use of 0x98 and 0x99 ports ? IMHO this is a dull waste of time and resources.

The question nenefranz is posing is by far more interesting. NO existing msx computer uses vdp ports other than 0x98 and 0x99, but many of them have different memory layouts. Making fully clear how slots should work, seems to me time spent in a more valuable way.
@nenefranz
Actually I do not see any way to swap out page0 to ram or to any other slot without direct access to PPI.
IIRC also the bios entries in page 3 able to manege page0 cannot permanently swap out the bios .

RDPRIM	#F380	5	Routine that reads from a primary slot
WRPRIM	#F385	7	Routine that writes to a primary slot
CLPRIM	#F38C	14	Routine that calls a routine in a primary slot

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

05-05-2013, 20:58

@ARTRAG

Before reading the rest of this post, please keep in mind that I'm not here to pick a fight with you. I'm on this hobby for the nostalgia, the challenge that the platform provides, and the nice active community that build up around it. I'm not even trying to convince you to follow the coding guidelines, since it seems clear to me that you already made up your opinion. Any argument I'll put here is just for those who are already willing to follow the standard, but are not sure if/how to do it, or even if it's possible.

Before the tests, I peeked into this game code and saw that nenefranz was trying his best to do things the right way. This is why his game passed so many tests, and the very few that it didn't passed was caused by one or another routine. And this is why I decided to give him a little help on how to find the bugs more easily (openMSX provide great tools for that).

Also, coding for a 30 years old commercially dead machine does as much sense as deciding to follow or not it's coding guidelines. This means that it's just done for the hobby, and deciding to follow the standard guidelines is one's choice purely.

But please don't state that coding accordingly to the standard is a waste of CPU time and resources, because this is a dogma already proved wrong: nenefranz game is compliant 95% of the time, and it is zippy and enjoyable. FireHawk-HDD and Space Manbow are action games that are compliant to the standard and are very fast. FireHawk-HDD works much faster and do a lot more (on-the-fly MSX-Audio translation!) now that it is compliant than the original disk version that didn't followed the guidelines. That without mentioning that now it supports turbo for a even smoother gaming experience.

I worked fixing enough games so I can state this based on personal experience: illegal direct I/O gives an illusion that things are going faster, but in the end you end up:
- Reimplementing everything the BIOS does, by yourself. This is also a waste of time.
- With a lot of compatibility issues. The game will run just on a handful of similar models
- Focusing on futile micro-optimizations and leaving the big algorithm optimizations aside
- Fighting the BIOS all the time against glitches and freezing. This one gets worse for each MSX generation. It's much easier to fool the MSX1 BIOS and code a MSX1-only game, but things get a LOT more complicated on MSX2 and MSX2+. If you ever tried to code a MSX2+ game you know what I'm talking about.
- Creating incompatibilities with extensions, TSRs, etc. The game will always require that the user remove everything from his computer to be able to run it. Somehow this reminds me of the hell that was to run PC games on MS-DOS era. The MSX was so more pleasant to use, because everything just worked.
- As a consequence of the two previous ones, you end up restricted to ROM games on MSX1. Disk support becomes troublesome, hard-disk support becomes a nightmare. The more extensions the machine has (MSX-DOS2? MSX-Audio? MSX-MIDI? RS-232?), the worst your incompatibilities become. Even the Sub-ROM will cause you headaches. You will be fighting the entire MSX ecosystem.
- Hindering the flexibility, interactivity and creativity allowed by the standard. Nice initiatives the PSG->SCC redirector from NYYRIKKI become impossible, or can only be implemented by expensive hardware solutions. Not MSXish at all. The OPLL->OPLn translation of the MSX-Audio BIOS v1.3 is also only possible to be done cheaply (it's just a ROM! Can't be cheaper than that) because the MSX is based on BIOS abstraction layers. Otherwise, the only solution would be by a expensive/complex/not-upgradeable hardware solution that wasn't even possible back in the 80s. It's like attaching an external V8 engine to your classic 80's Ford Fiesta just to prove that it can run faster while fooling yourself that it keeps the original Kent 1.3L engine under the hood.
(Hey SuperSoniqs guys, I meant no offense to the MIDI-PAC, Ok? ;) )

Obviously, the BIOS ecosystem far from perfect. It has bugs, it has some design issues, it doesn't cover all possible situations. But this is when creativity is required to overcome the problems.

@nenefranz

It seems that there are some regional variations of this same machine: HB-F500P, HB-F500D etc. The only difference is the keyboard layout, or 50/60Hz. All of them will behave exactly the same on the tests. So you can safely use the HB-F500P for the testing.

You're right, 48K/64K plainROM games are troublesome on the MSX standard. This is why they were rarely deployed and software houses decided to skip them and jump into MegaROM bandwagon. The barebones MSX1 BIOS/system provides very few support for 48K roms, both for the software or hardware side.

On the hardware side:
- There's no such thing as a 48K EPROM. The maker would have to resort to a 32KB+16KB design, or choose a 64KB EPROM and waste 16KB of it. The 64KB would be the easier choice.
- The cartridge for a 32KB+16KB would be almost as complex as a MegaROM, because the MSX slot provides the /CS1 and /CS2 pins for 16KB EPROMs (4000h and 8000h respectively), and the /CS12 pin for 32KB EPROMs. So back then you would need extra hardware to handle the extra 16KB. "Extra hardware just for 16KB? Just build the MegaROM already!" - probably thought the gamehouses back then.

On the BIOS side:
- The lack of routines to do the slot handling on the page-0 of RAM was fixed by the Disk Interface extension. So, if someone wants to use the page-0 with RAM, a disk BIOS is usually a requirement.

For your specific case, it is as it happens on life: there's always that time when you can't have everything and you have to choose what will be left out. :)

For your game, the choice is:

1) Continue with the 48KB plainROM format. You will be able to support ROM cartridges and the diskless MSX1 with 64KB of RAM using tapes. Future compatibility will be compromised by violating the standard.

2) Move to a 48KB MegaROM. You will be able to support ROM cartridges and Megarom-loader cartridges, like MegaRAM or MegaFlashROM. Future compatibility is assured by compliance to the standard. MSX1 with 64KB by tape media will not be supported (but will supported by cartridge, of course).

Last but not least, regardless of the format you choose: your game is very enjoyable and a nice gaming experience. Keep up the good work and bring us more of those gems. You're no rookie, this game is the work of a Pro! You should also try some MSX2+ games, since there are so few of them, and most of them don't have this kind of smooth gaming experience you achieved.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

05-05-2013, 21:15

@ sd_snatcher

Your post (especially the second part), is incredible, you speak of compromising the "future compatibility" (?!)...
According to your view 48K roms shouldn't be allowed for plain msx1...
I've no further comments...
Yours is a religion war, any attempt to have a rational discussion would be a waste of time.

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

05-05-2013, 22:30

@ARTRAG

Yes, future compatibility. "future compatibility" doesn't need to be the MSX version 7 with a 3D video card and 10GHz CPU. "Future" is anything that isn't designed yet, but can be. For example:

- IDE interfaces never existed for the MSX back in the 80s. But all programs/games that were coded thinking about "future compatibility" were able to work on them right on the release day. If everybody just did direct access to the FDC "to optimize disk speed", the IDE interfaces would have become impossible or almost inutile as it happens on other 8bit computers that allowed direct access. Certainly the games would have achieved much faster disk performance back then by doing direct I/O to the FDC, but none of them would be able to even get close to the performance of the "slow, compliant" programs using DiskBIOS/BDOS on IDE.
- Some RS-232 software don't work on the Harukaze and Gradiente CT80Net interfaces. That happens because they use different UARTs (16550C and Z8530, respectively) and those software do direct I/O. And both interfaces have a BIOS. If software were coded according to the standard, they would work perfectly without any issues.
- Not a long ago there was no other compatible implementation of the MSX-Music standard. All of them were based on an OPLL chip (either YM2413, UM3567 or U3567) and most had the same copy of the internal "APRLOPLL" BIOS even being external. But now there's the MSX-Audio BIOS v1.3. All games that were properly coded thinking about "future compatibility" worked out of the box, while the "uber optimized direct I/O" software fails.
- I was going to design a very cheap PS/2 keyboard interface, to help those who's keyboard is broken, or nearly impossible to find (like the HC-90/HC-95). The interface would use a i8251 chip and would cost less than $10. This is allowed by the MSX Standard (the MSX Technical Handbook even mentions serial infrared keyboards, for God's sake!), and if software were properly coded for "future compatibility" it would work right away. But now the only possible solution seems to be an expensive board with a microcontroller to translate everything to the i8255 interface format. Prone to delays and bugs.

This is the path were the direct I/O leads you. Keyboard? Translated by a external processor. Mouse? Translated by another external processor. Music? Translated by an external processor. FloppyDisk? Translated to SDcard by a external processor with a double-digit LCD. Don't you think that this is the real waste of resources and money? Suddenly, the MSX that was originally designed to be a cheap home computer turns into an expensive mess with a lot of I/O processors that add costs, but don't sum on the processing power.

But there will always be those who unfortunately prefer to code their MSX like a ZX-Spectrum and hinder any possible future expansion.

If following this philosophy is considered a religion war, then call me like that. But I produce both software and hardware and can list the problems on both sides, and this is why I have the experience for the reasons that I explain calmly and rationally. And I'm still yet to hear rational arguments in favour of direct I/O other than "I don't like coding like this".

It's just my to cents. You have the right to your opinion and I respect that. I just hope not to be burned at the stake for believing on the advantages that the standard envisioned.

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

05-05-2013, 23:18

Quote:

According to your view 48K roms shouldn't be allowed for plain msx1...

And no, I didn't said that. I said that it isn't advisable to use that combination, since it's troublesome. It up to each one to decide if that trouble is acceptable or not.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

05-05-2013, 23:42

Wasn't you suggesting to move zombie incident to a megarom just to respect the msx standard ?
Anyway, you can also profess Pastafarianism, it is your business, just do not ask me to believe.

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

06-05-2013, 00:47

One thing is to suggest a possible alternative for a problem that someone has. Another completely different thing is to say that something is forbidden/not allowed.

And please stop the aggressive attitude. I'm not here for that, and I'm not being aggressive to anyone. It's fine with me if you don't agree with the idea, but please just don't attack because you don't agree.

And lets get back to doing nice MSX productions, be it compliant or not to the standard.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

06-05-2013, 07:54

Just a side note:
-Manuel Pazos produces a flash chart for 48K games, just ask him (it is not listed in his site, email him).
-Matra produces and sells many 48K games (DDA is one of them) without any additional cost.

By PingPong

Prophet (2605)

PingPong의 아바타

06-05-2013, 10:49

ARTRAG wrote:

This is a BIG limitation: you waste a z80 register and a lot of cpu time.
Do you really think that, today, it is wise to replace direct I/O with indirect access only to avoid the use of 0x98 and 0x99 ports ? IMHO this is a dull waste of time and resources.

I agree. the 98h and 99h port addresses can be, today "considered" standard addresses.
the need to use BIOS or to read the port from the rom location does not balance the loss of power you need to deal with.
there are imho too much disadvantages, compared to a hypothetical advantage of being compatible with a soo small exotic machines.
Just remember:

we have a z80 @3.5Mhz not a Pentium 4-cores that allow us to waste a lot of power
we have a I/O based vram access, not exactly the ideal solution for fast vram access.

The problematic hw for vdp port is imho less than 1%.

Different thing is imho the slot issue. Here the differences are too much, and there is a true possibility that a lot of machines refuse to run the sw. Here the percentage of failing machines is greater than 1%.

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

06-05-2013, 15:48

Not that I'm trying to win any argument, but I just remembered another case of future compatibility that would be nice to share to those who like the subject:

If games were coded using the MSX-Music BIOS, future compatibility would have been assured to the R800 CPU since its release. No FM overrun would ever happen on turbo mode.

@PingPong

I agree that we don't have a multicore pentium at our hands, but the Z80 is a very valiant CPU. Have you played FireHawk HDD? The nifty Z80 handles to run that full of action game completely complying with the coding guidelines, and It even had enough CPU power left to run the MSX-Audio BIOS v1.3 on-the-fly OPLL->OPLn translation! I mean, can the MSX architecture be more awesome than that? Smile

I love the MSX architecture for its potential. Running Naked in a Field of Flowers

By nenefranz

Resident (34)

nenefranz의 아바타

07-05-2013, 00:20

Hi all,

There are some nice ROMs of 48KB (theCure, QBIQS) that works on Sony HB500 ... so, I'm sure I'm doing something wrong. Maybe a rom of 48KB it's a rare and complex configuration as sd_snatcher said, but it's possible to build compliant ROM of this kind. I must investigate a bit more to find a way to fix this problem.

I definitely want to finish the project, but I want to avoid the hard task to update the game to a megarom, well If I can. Maybe next time I will try from the beginning a megarom Wink

I have tested a 16KB ROM on HB500 and HB500P and failed too ... but this rom doesn't have any slot-changing rutines!! ... again I'm doing something wrong!! Crying

I understand sd_snatcher when he says that the right thing is to program accordingly to the standars to assure compatibility. But, on the other hand, I understand what ARTRAG said ... could a few exceptions ruins the compatibility? ... I don't know, but I hope no. I like to see how appears imaginative solutions in order to achieve games that we think imposible in our beloved MSX. Although, I will continue making games only with BIOS ... and a few routines out of BIOS (replayer, etc) ... as I said ... I'm not a expert in MSX, I am confortable doing simple things. Tongue Zombie Incident is like is thanks to John Hassink and Sun. And no only for their great music, they advised me how to improve the gameplay.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

07-05-2013, 12:02

If your own 16K test Rom does not work on hb500 the problem should be different by direct PPI access.
Have you used a debugger to see where the Rom hangs or are you referring to Acid Tests?

By nenefranz

Resident (34)

nenefranz의 아바타

07-05-2013, 12:49

No. I did not debugged the 16KB ROM. Now I'm at work. Tonight if I could, I will try to debug that 16KB ROM. On the other hand, when I debugged ZI ROM, it failed when trying to setting screen 2 (call INIGRP) Sad
Could be needed to do some initializations of slots (in this machines) before I use BIOS calls?

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

07-05-2013, 22:46

If you want to see how we did with Deep Dungeon-Adventure (48K rom sold by Matra) its source is available at this link

PS
Sorry, but the code accesses to PPI directly, assumes 0x98 and 0x99 for vdp I/O and has never been tested on HBF500 (and I suspect it wouldn't work).

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

07-05-2013, 23:03

@nenefranz

For the Sony HB-F500 problem: It seems that the SubROM is freezing because of the direct access to the PPI. It's very similar to two other situations:
1) When the MSX-DOS2 freezes because of direct access to the Memory Mapper ports.
2) When some DiskROM freezes because of incorrect direct access to the SubROM

These are known symptoms, and why I mentioned that when circumventing the rules, the programmer endup fighting the entire MSX ecosystem.

@ARTRAG

Out of curiosity, I tried it on the HB-F500P. Its interesting that the original game from MSXdev2011 runs fine, but this newer version doesn't. I just did a quick test, without investigating why.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

07-05-2013, 23:53

The original Deep Dungeon is a 32K rom.
The advanced version is a 48K rom due to the intro animation, the Easter Egg game and to to few small additions to the game.

PS
The direct access to the PPI cannot be the case of the 16K test rom that fails even without using the PPI.

By nenefranz

Resident (34)

nenefranz의 아바타

08-05-2013, 00:23

Thanks ARTRAG, the sources of DDA is another source of info ... to learn more.

Well, I did some tests on 16KB ROMs ... and it works on HB500P.
But on HB500 there are some 16KB ROMs that don't work.
if start address of ROM is $4000 then the game works ...
but if the start address is $8000 then the ROM doesn't works!!

The ROMs of 48KB that work on HB500 seem to be a bit different. Page0 seems to be ROM instead BIOS (or seem to work like this), this implies more work to handle interrupts.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

08-05-2013, 23:56

I think that program roms can start only at 4000h.
From the msx red book:

Quote:

This routine is used during power-up to perform an extension ROM search. Pages 1 and 2 (4000H to BFFFH) of each slot are examined and the results placed in SLTATR. An extension ROM has the two identification characters "AB" in the first two bytes to distinguish it from RAM. Information about its properties is also present in the first sixteen bytes as follows:

    +------------------------+
    | Reserved               |  Byte 10-15
    | BASIC Text Address MSB |  Byte 9
    | BASIC Text Address LSB |  Byte 8
    | DEVICE Address MSB     |  Byte 7
    | DEVICE Address LSB     |  Byte 6
    | STATEMENT Address MSB  |  Byte 5
    | STATEMENT Address LSB  |  Byte 4
    | INITIALIZE Address MSB |  Byte 3
    | INITIALIZE Address LSB |  Byte 2
    |       42H (`B')        |  Byte 1
    |       41H (`A')        |  Byte 0
    +------------------------+
Figure 48: ROM Header.

Each page in a given slot is examined by reading the first two bytes (7E1AH) and checking for the "AB" characters. If a ROM is present the initialization address is read (7E1AH) and control passed to it via the CALSLT standard routine. With a games ROM there may be no return to BASIC from this point. The "CALL" extended statement handler address is then read (7E1AH) and bit 5 of register B set if it is valid, that is non-zero. The extended device handler address is read (7E1AH) and bit 6 of register B set if it is valid. Finally the BASIC program text address is read (7E1AH) and bit 7 of register B set if it is valid. Register B is then copied to the relevant position in SLTATR and the search continued until no more slots remain.

SLTATR is then examined for any extension ROM flagged as containing BASIC program text. If one is found its position in SLTATR is converted to a Slot ID (7E2AH) and the ROM permanently switched in via the ENASLT standard routine. VARTAB is set to C000H, as it is not known how large the Program Text Area is, TXTTAB is set to 8008H and BASROM made non-zero to disable the CTRL-STOP key. The system is cleared (629AH) and control transfers to the Runloop (NEWSTT, 4601H) to execute the BASIC program. - 205 - 5. ROM BASIC INTERPRETER Address ... 7E1AH

Quote:

[...] Note that the entries for page 0 (0000H to 3FFFH) and page 3 (C000H to FFFFH) will always be zero as only page 1 (4000H to 7FFFH) and page 2 (8000H to BFFFH) are actually examined. The MSX convention is that machine code extension ROMs are placed in page 1 and BASIC program ROMs in page 2.

No idea if in some machines can accept code roms at 8000h, but you should have only basic roms there.

By nenefranz

Resident (34)

nenefranz의 아바타

09-05-2013, 12:39

Thanks ARTRAG for the info. I did some tests of 16KB ROMS classic games:
- pippols (konami) start: $4000 -- OK
- kingsvalley (konami) start: $4000 -- OK
- tawara (ascii) start: $8000 -- FAILED

All tests were made in blueMSX (machine Sony HB500) and openMSX (machine Sony HB500P).
Tawara failed on Sony HB500. It started well, but it freezed in menu screen.

Later I made some simple ROMS of 8, 16, 32 and 48 KB. The ROMS only change to SCREEN2,
redefine some tiles and play PT3. 8 and 16KB roms not include slot-changing routines.
48KB ROM hold the PT3 track in page0 to test changing slots.
All ROMs passed the tests!! ... for 32 and 48KB ROMs I needed to force MIRROR ROM on
blueMSX to detect correctly the rom, but they worked ok. For 8 and 16KB ROMs I made
two versions (starting on $4000 and $8000) and they worked!!

So I need to rebuild step by step Zombie Incident ROM to find why doesn't work ok in
this machine, and the test ROM yes.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

09-05-2013, 21:21

I wouldn't care to support the HB-F500 but for the sake of the science it could be interesting to investigate the issue.

The key has to be in the fact you had to set mirror rom to pass the tests.
I do not know how they work ecsactly, but IIRC that mirror roms under certain conditions mirrors at 0x4000 the content of 0x8000 and vice versa.

I have an half idea about the fact that, if the initialization code is fully relocatable, even if you planned an entry point in the 0x8000 the rom could boot correctly... It is just a guess, and it does not explains why the same rom fails on HB-F500 and not on other machines.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

09-05-2013, 23:03

just for info
http://www.msxblue.com/manual/rommappers_c.htm
it seems that at 0x8000 we have only basic roms

By nenefranz

Resident (34)

nenefranz의 아바타

10-05-2013, 00:59

EUREKA!! I have found the problem with the Sony HB-F500!!! My error is embarrasing!! Sad
Well, the key again is PROGRAM ACCORDING TO THE STANDARDS!!
the very first piece of code of all roms is something like this (for a 32KB ROM, asmsx notation):

	...
INIT_ROM:
	di
	im	1
	ld	sp, $F380		; initialize Stack before system vars
	ei
	.SEARCH			; put ROM in slot2 (for 32KB ROM)
	...
	...

This is OK for all MSX machines ... nearly all ...
This simple code is wrong, because I make and bad assumption:
"$F380 is always a valid address for initialize the stack"

The correct code will be something like this:

	...
	HIMEM	.equ		$FC4A	; High free RAM address available (init stack with)
INIT_ROM:
	di
	im	1
	ld	sp, [HIMEM]	; initialize Stack before system vars
	ei
	.SEARCH			; put ROM in slot2 (for 32KB ROM)
	...
	...

Now all ROMs of any size I have tried works with this machine!!!

Thanks ARTRAG for your help. It seems that make a ROM starting at $8000 is valid too.
I suppose that $8000 is for basic roms because page1 can remain with BASIC.
But there isn't any problem in make a ROM that starts at $8000 and not need BASIC.

I think that any rom that fails with this machine has the same problem of initialization
of stack, the problem isn't the size of rom. Maybe when I tested my 32 and 48KB test-roms,
I arrive to a erroneous conclusion, that they worked because I forced blueMSX to MIRROR ROM.
They worked ok because the right initialization of the stack. Tongue

thanks sd_snatcher, this is another example of incompatible rom because I don't follow the standard guideline.
Another lesson learned!! Tongue

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

10-05-2013, 19:39

humm, in DDA, AFAIK, I do not init sp, are you sure this is the sole reason of the hang ?

By nenefranz

Resident (34)

nenefranz의 아바타

10-05-2013, 20:36

for ZI is the only reason, because I recover the code of this last release and only change the initialization of sp. For another project 16KB ROM, no slots changes, I change this initialization of sp and works too.
The test-roms that I made, they worked well because I use an improved set of routines compared to used in ZI.
Although I admit that seems very strange, because when I debugged ZI and others roms that failed, it seemed that the problem was with slots, because I seen very strange behavior. But after I changed the sp initialization it worked!!
Have you tested DDA in these machines?

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

11-05-2013, 00:08

@nenefranz

Excellent! I told you that you're no rookie! That's a lesson for me to!

I'll add this to the list of fixes for my ROM patches, and the info to the compatibility testing wiki. BTW, this stack things work a bit different for MSX-DOS programs, ok? I also added this info on the wiki article.

By Manuel

Ascended (10042)

Manuel의 아바타

11-05-2013, 08:13

sd_snatcher: the wiki text suggests that 0x3F80 is the correct HIMEM address, but as I understood nenefranz this is exactly what was wrong: he assumed it was 0x3F80, but it wasn't on the F500.

By nenefranz

Resident (34)

nenefranz의 아바타

11-05-2013, 10:19

The correct initialization of SP will be the 16bit value at address $FC4A.
I think this is true for all msx machines, not only HB-F500 and family.
Initialization code:

ld sp, ($FC4A)

or (asmsx notation):

ld sp, [$FC4A]

I think that only changing at wiki:

Quote:

For ROMs and BASIC, use the recommended top memory position indicated by HIMEM (F380h).

by

Quote:

For ROMs and BASIC, use the recommended top memory position indicated by HIMEM (FC4Ah).

will be enough.

On the other hand, when I try to execute "Acid2Test-hardware" machine I see this error message in openMSX Catapult status-info:

SHA1 sum for 'MSX-Audio BIOS' does not match with sum of 'E:/EMULS/MSX/openmsx-0.9.0-windows-vc-x86-bin/share/machines/Acid2Test-hardware/roms/msxaudio.rom'.
SHA1 sum for 'MSX-Music ROM' does not match with sum of 'E:/EMULS/MSX/openmsx-0.9.0-windows-vc-x86-bin/share/machines/Acid2Test-hardware/roms/ExpertTurbo_msx2psub-fmbasic.rom'.
SHA1 sum for 'Memory Mapped FDC ROM' does not match with sum of 'E:/EMULS/MSX/openmsx-0.9.0-windows-vc-x86-bin/share/machines/Acid2Test-hardware/roms/phc-70fd2_disk.rom'.

It executes with rare behavior. I can't testing with this machine. Sad

@sd_snatcher: how can I send you the latest version of ZI in order you can test it?

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

11-05-2013, 19:55

@manuel

Ops! My mistake. I typed the default contents of HIMEM mentioned on the Red Book, not the variable actual address. Just fixed that, and rewrote it a bit more clearly.

Thanks for noting!

@nenefranz

Tip: It's better for code legibility and maintenance to use the variable names instead of hardcoded addresses.

ld sp,(HIMEM)

About the Acid2Test errors, check if those ROMs have the following SHA1 checksums:

msxaudio.rom: 7f115ff923a1cc0d1944cf280168add946fde854
ExpertTurbo_msx2psub-fmbasic.rom: ca79a8cc7714a5d48d2e567a2d4d7ba3fe587825
phc-70fd2_disk.rom: 9efa744be8355675e7bfdd3976bbbfaf85d62e1d

You can get most of the correct ROMs on the blueMSX site.

What openMSX version are you using?

My e-mail is inside the FireHawk patch README file, on on my website. ;)

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

11-05-2013, 21:10

@sd_snatcher I've just tested DDA on HB-F500P and it works.
You have to boot holding SHIFT pressed to disable the disk (it has to take more ram than usual on this crappy HB-F500P machine).

@nenefranz
Booting with SHIFT pressed would have solved also the ZI problem without patching. Try yourself.

By sd_snatcher

Paragon (1559)

sd_snatcher의 아바타

11-05-2013, 21:40

Yes, nenefranz discovered what was the problem, and indeed all that's needed to avoid it is to code according to the standards. He already seems to have fixed his game.

The problem will manifest on any machine that has a disk interface (or MSX-DOS2 cartridge) connected to a slot with a lower number than the game slot. In fact, any extension that allocates some RAM before the game boots will cause the games affected by this kind of bug to freeze.

By mars2000you

Prophet (3826)

mars2000you의 아바타

11-05-2013, 22:20

Let's not forget that we are speaking about MSX1 games and that MSX-DOS2 is not part of the MSX1 or MSX2 standard. Pressing SHIFT to get more memory is also required on 3 MSX1 games/tools in rom format(Nausicaa - Computer Music Composer - Poiny X Senryosakusen) and this on any machine, so it's not so really surprizing. I think there's also a key to disable MSX-DOS2 when booting ('1' key on TurboR, ? SELECT for MSX-DOS 2.2, I don't remember exactly).

Finally, I think this perfectionism is just a way to force MSX-DOS2 to become fully part of the standard, what's the case actually only with TurboR. For my part, I consider that MSX-DOS2 needs only to be required for COM files when the R800 power is used. In all other cases, a COM file should be launched also with MSX-DOS1. I don't speak here about IDE/SCSI/ etc... extensions that require generally MSX-DOS2, I speak about standard using of the MSX games and applications.

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

11-05-2013, 23:04

@sd_snatcher
there are case where you need that ram and pressing shift while booting is part of the standard
ps
I wouldn't care to have disks initialised to run a game rom that does not use them...

By nenefranz

Resident (34)

nenefranz의 아바타

12-05-2013, 10:12

@ARTRAG
You are right artrag; I checked again the unfixed version and works if I start MSX machine pressing SHIFT key. I remember time ago to I have used this way of start msx for some game. But I don't remember if only for disk games, or ROMs too. Tongue This tip may be the solution for already games sold without the correct initialization. For games that need more RAM, maybe It could show a message to remember the user to start the machine with shift key pressed (or include this tip in the manual).

@sd_snatcher
I use openMSX 0.9.0. I have downloaded from blueMSX web the roms for "Ciel Expert 3 Turbo" and "Wavy PHC-70FD2", but the sha1 checksum of these roms don't match. Sad

By ARTRAG

Enlighted (4679)

ARTRAG의 아바타

12-05-2013, 11:52

Pressing SHIFT while booting disables disks, so it was used both for roms and cassette games.
Pressing CTR while booting disables the second disk only and was used for disk games needing more ram.

By Manuel

Ascended (10042)

Manuel의 아바타

12-05-2013, 14:13

nenefranz: I recommend to always use the latest release of openMSX (0.9.1). You could even use the latest developer build from http://openmsx.fixato.net if you like.

By nenefranz

Resident (34)

nenefranz의 아바타

12-05-2013, 18:27

@artrag:
I didn't know this about the CTRL. Thanks

@Manuel:
thanks ... I have updated my version of openMSX and have added the link to my browser. Wink

By mars2000you

Prophet (3826)

mars2000you의 아바타

18-05-2013, 22:03

Version 1.2 has been updated with bugfixes in relation with remarks made here

http://msxdev.msxblue.com/?p=1888

My MSX profile