MSXdev'11 - #8 Zombie Incident

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

This game remembers me Project Arba Minch

Version 1.1 is now available on the MSXdev' website !

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

good looking game this is i love it.

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.

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

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.

This is your first MSX/Z80 game?

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

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 )

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

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!

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

The music rocks

Great! I was looking forward the bugfixed version

Thanks sd_snatcher,

The game failed in two tests: Sony HB-F500 and Acid2Test-hardware.
It's okay to have failed two tests only! 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!!
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?

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

@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.

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.

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.

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?

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

@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.

@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.

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.

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.

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?

I love the MSX architecture for its potential.

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?

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).

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.

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

    +------------------------+
    | 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.

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

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.

EUREKA!! I have found the problem with the Sony HB-F500!!! My error is embarrasing!!
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.

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

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?

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.

@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. ;)

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.

@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...

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.

@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.