While I'm in this topic... Do we know who the dev team was on Parodius for MSX? I interviewed the programmer and he refused to name the person in charge, or main designer, since they're still at Konami apparently.
Heavy politics at Konami, which ruins the feeling you get nowadays when thinking of Konami in it's current state. At least for me
There is so much wrong with the Parodius picture that I'm suspecting that we are actually looking picture editor with some concept graphics. (Salamander style option bar with the yellow selection, wrong color lasers, those sweat drops, little penguins etc.)
updated links from this topic:
interview:
http://hg101.kontek.net/metalgear/toshinarioka.htm
HP 64000 computer
https://en.wikipedia.org/wiki/HP_64000
That explains why all Konami megarom games always seemed to be designed for a machine with a faster Z80 processor, thus run on 3.57MHz MSX machines skipping frames constantly: The 64252A Z80 emulator pod had only two possible speeds:
1) 3.6MHz without waitstates
2) 4MHz with waitstates when accessing the memory
Do you have sources for the quoted 3.57 abd 3.6 and 4 MHz speeds? I want to write a footnote and make sure I'm not screwing it up
EDIT:
Found a source:
https://doc.lagout.org/science/0_Computer%20Science/0_Comput...
My book quote:
JS: I've read that its 64252A Z80 emulator pod had two speeds: 3.6Mhz and 4Mhz, but the MSX2 was 3.57Mhz. Is that right?
TO: Ahhhh... I do not remember exactly. I cannot really give precise details on that. So I feel we had something like that? Your point is that the were different, and I'm speculating here... We could not accommodate the differences in clock speed, so therefore by using whatever means necessary it must have been adjusted to compensate. The hardware staff worked on the circuit boards that had to be connected - the ICE or In-Circuit Emulator. It's possible those hardware guys used some tricks in order to adjust the clock speed, but I can't be certain.
Footnote:
Figures taken from user SD_Snatcher on MSX.org forums, some places quote 3.58 for the MSX2; basically, if you've ever felt that MSX2 games feel slightly more sluggish than they should, it's down to the fact they were developed on a system which operated slightly faster
Even if the development hardware ran in the 3.58 MHz clock mode (which would seem a logical thing to do), the MSX inserts an M1 wait cycle at the start of each instruction, which makes it ~10% slower than a plain Z80. If the development hardware did not have this M1 wait (which is not unlikely), that could also be what Toshinari refers to by “I feel we had something like that”.
By the way, 3.6 / 3.57 MHz refer to the same common clock frequency of 3579545 Hz (= 3.58 MHz), just rounded differently. So you should adjust your footnote to avoid confusion to the reader there.
This is why I love this forum.
You've just earned yourself fame and prestige in a footnote!
Grauw from MSX.org: "The 3.6 / 3.57 MHz refers to the same common clock frequency of 3579545 Hz, just rounded differently. Even if the development hardware ran in the 3.58 MHz clock mode (which would seem a logical thing to do), the MSX2 inserts an M1 wait cycle at the start of each instruction, which makes it ~10% slower than a plain Z80. If the development hardware did not have this M1 wait (which is possible), that could also be what Oka refers to by 'I feel we had something like that'." ; HP pod figures taken from its own advertising leaflet; basically, if you've ever felt that MSX2 games feel slightly more sluggish than they should, it's down to the fact they were developed on a system which operated slightly faster
If it helps to expand at all: it's a standard NTSC colour clock crystal, probably both because the TMS9918 can supply that clock and because those crystals were plentifully and cheaply available, and fairly close to the 4Mhz rating of the Z80. The MSX standard inserts an extra cycle into each Z80 M1 because all Z80 memory access cycles are three cycles long except the M1 cycle. M1 is "machine cycle one" — it's when the Z80 fetches the next opcode. That fetch is four cycles total but it's divided into two cycles to read the opcode, then two for DRAM refresh. If you chuck an extra wait cycle in at the start, you go from needing a memory subsystem than can respond in two cycles but only sometimes needs to, to just needing one that can respond in three cycles. So you can use cheaper RAM and/or slower intermediary logic. The Z80 announces the difference between an M1 cycle and any other cycle, so the extra logic is cheap.
@Szczepaniak; a few people are known for Parodius like one of the guya who made the music. But I'm guessing you already know those.
@Szczepaniak; a few people are known for Parodius like one of the guya who made the music. But I'm guessing you already know those.
Nope! I don't know ANYONE who worked on MSX Parodius. I've been using MobyGames for credits:
http://www.mobygames.com/game/parodius__
Who worked on it?
Anyway, my interviewee, who was a programmer, has gone all silent and doesn't want to talk about the game any more. Sadly. :(