joyrex

Looks like a very cool game!

Porting from these systems to MSX is a lot easier though, you don't need to modify the original code to make it relocatable to some fixed address. You can rely on having 64K RAM available and just move the code to RAM to its original location. The biggest effort is porting the sound. Marcel de Kogel wrote a ColecoVision emulator for MSX which runs quite a lot of games. See here.

Konami released Juno First on the MSX as one of their first games. Both Mappy and Rally X also got official Namco(t) ports on MSX, part of the 'GameCenter' series; which is a collection of 12 games (including Galaga, Pac Man and some others) Taito also officially released Front Line on the MSX.

I would guess the same, LD indices and the patterns the user has to input with the controler.

I think the MSX Dragon's Lair had the same approach as you probably have in mind; converting every frame with its own tileset. Looking at the screenshots, it looks like you also changed the palette (v99x8?). Another interesting approach is done by Arturo Ragozini. He created a video encoder that does a search for the optimum tileset for a couple of frames, rather than an optimum tileset for a single frame of video. You don't really require that if you take the flashcard as a medium, but it can provide you more cpu time during playback (and dedicate that to eg. sound). Interesting reads about his approach; http://www.msx.org/forumtopic7309.html http://ragozini.googlepages.com/vdpenc

Thanks for the feedback! The controls are indeed intended to give a feeling of swimming under water. I aggree the difficulty is a bit high, making the games short. Although if it will be more easier, it might get too repetetive. I like the suggestions on improvements, I'll have a think about it. My personal highscore is around 2500 I think. The original used rle compression on the graphics, music and intro data. It decompressed to ram (which is required for the intro and music). The biggest chunk was over 1.5k, so including compression as is wouldn't work. Since the original fitted 8k exactly, including the compression again would require some rewriting and I could end up just a bit over 8k again. That's why I removed the compression in its whole. Btw, if you don't start a game, it will go into attraction mode a few moments later, wow

Hey guys, I ported a MSX production I made a few years ago; Kobashi. It's a small game where you have to survive as a fish by eating the food dropped from the surface. The original was ranked 2nd at the MRC Underwater Challenge and was released as a 8k rom, this version became 16k mostly due to removing the compression of data. Anyway, hope you like it. kobashi.zip

Great demo, love this!

When I had my ps3 for a couple of days, I went to a friend who tried to demo PAIN for me. I remember when he wanted to start the game, it looked like it went into an endless loop of updates, it didn't took 20minutes, but it took at least 5. I still bought PAIN the same evening (and had to go through the same updates as he had to do earlier that day). However, that's actually the only game that was this dramatic. With other games, updates are usually quite fast, and the firmware update as well. I have the 360 also, but I still prefer the ps3. Mostly because I like the media player capabilities more of the ps3. The xbox just makes way too much noise for watching movies.

Yeah, mine too! I am curious about this demo, is it on youtube?

It is not read-only. However there is no R/W signal available at the cartridge port, so you can't easily distinguish between read and write accesses. So each address has to be used for either reading or writing. Ah, now I understand. But, then it would also allow some logic to swap a whole block into write only mode. Eg, when reading on some control address, the upper 4k could be swapped to allow writing to ram, but reading would fail. When reading that control address again, the upper 4k would be in read only mode again. It will probably slow down your programm when using this construction though.

Great job! I have a few questions though; I thought the data bus on the Coleco cartridge port was read-only? Since you mention writing the actual bank, that doesn't seem to be the case? If not, a coleco cartridge could be far more advanced than I thought before (eg. adding static ram). Why not use the flash for savegames? We have done that in one of our msx games.

Sorry for the radio silence. We don't have a release date yet, but we do have some news We both went to the MSX Info Update party in Helsinki where we demonstrated the 2 player mode. It was a huge succes, and you could see people play it the whole day (a few got really addicted to it). In the evening there was a competition on the big screen. There were still a few bugs in the tracks which allowed some cheating, this was exposed pretty quickly and everytime people tried to cheat everybody started yelling ("cheat cheat" and some finish which probably meant the same). On the MSX Info Update site there are some pictures and links to a few youtube videos with the gameplay and atmosphere. Some other videos are and here. On the ALT Party in Helsinki again it is playable again (though both Daniël and I won't attend), not sure if it will be playable on the big screen though.

Yeah, we are planning to release it for both platforms on cartridge. The difference between them, as it looks now, will be limited to the sound engine. Not sure if the Coleco steering wheel will be supported on MSX also, that depends if I get it to work on a MSX. It should be relatively easy to support the SVI, and SG-1000 too; but we don't have those consoles. They seem hard to get. Also, I don't know if someone already created a cartridge homebrew for either of those consoles, which would make production more complicated.

We actually made quite some progress and have a multiplayer engine ready (micro machines like approach). At the MSX Info Update 2008 meeting (Finland), which we will both attend, a competition will be held with the new multiplayer engine. We are very excited about this, it probably produces a lot of helpfull feedback Offcourse, the version run there will run on a MSX, but the implementation itself works on both Coleco and MSX. I was hoping to get the Coleco steering wheel working on MSX too for that meeting, but unfortunately I had little time to work on that. Though, who cares if you have a Coleco

Thanks, this is exactly what I need!

I want to connect the coleco steering wheel to a MSX, but I have a hard time figuring out what the connections are, and what the logic is applied behind it. Does anyone know what the pinout is, or can point me to some documentation. I already found a description of the Adam joystick connector here, and the schematics of a regular controler done by DanB. I also opened up a steering wheel to see what's in it, and found 5 signals. I think I identified gas, gnd and the int signal, but that leaves two other connections. Maybe my identification is also incorrect, it wouldn't surprise me Any light that can be shed on the steering wheel, or how the spinners work from a hardware point of view is very much appreciated.

1. I must ask whether it is VDP 9938 or VDP 9958 you have modified your ColecoVision with ?. 2. Is it a PAL CBS ColecoVision ?. 3. And it may simply be replaced directly ?. It's the VG8020 modded Coleco, by heart, I think it's a tms9928. I have 2 v9958's still lying around. I bought them a few years back to mod one (two ) of my msx's to 2+, but I never got around to do it. I probably would never mod a coleco to a v9958. Same as with msx, I love to original specs of the coleco, and if I would do a 'rich' production for a Coleco, I would want it to run in unmodded (or better; original) hardware. I think the only extension that would be possible with this requirement in mind would be a bankswitching scheme that triggers on reading specific addresses in the cartridge rom area.

Ah, great. We weren't able yet to test it on a ntsc. The pal console I tested on is heavily modded (other videochip), and probably isn't a reliable reference machine. I am also glad dioniso didn't see problems on his original pal console. Cool Incidently, I bought a paperback with sudoku's a few weeks ago, and I am kinda hooked on them since a couple of days. Although we made a sudoku too, I actually never played many of them with our version (others did though ) Keep up the good work!

Thanks! I really enjoyed meeting you after a few years, and I enjoyed previewing your new game Hm, strange... Anyway, you have a great eye for detail, I didn't notice this yet. We will probably change the looks of the car in the final product. This is the same car as Lotus, which probably has the same problem.

Thanks Although the engine is nearly finished, there is still a lot to do. Especially a two player mode will be quite a challenge.

This version already supports the steering wheel, it checks both regular controlers as well as the steering wheel

Here's an updated version that should work better in emulators. dvik_joyrex_wip_teaser.zip

It looks like MEKA is neglecting to set the INT (vblank) bit of the status register when it hangs; the game is hanging while waiting for the vblank by polling the vdp status register.

That would be very much appreciated; unfortunately we were only able to try it on a PAL ColecoVision at the moment (this will change in though).