Terrahawks MSX conversion

Who doesn't remember Gerry Anderson's BBC series Terrahawks. In the year 2020 (!) an android space armada, lead by the android Zelda, conquer the human colony on Mars. This is your chance to help one of the Dr. Ninesteine clones to defend the colony on Mars.

Recently releasd,AGD is an awesome tool to create new MSX games or convert games created with it. And MRC User Fish has been playing around with the MSX version to developed a conversion of Terrahawks, a shooting game released in 1982 on the Philips Videopac (also known as the Magnavox Oddessey) as cartridge#51.

The game is optimized for 50Hz PAL, which will be forced on the disk version.

Comments (40)

By hamlet

Scribe (4106)

23-02-2020, 09:17

Isn’t DeltaSoft’s TheKid also a clone of Dr. Ninestein?
The gameplay is very smooth and fast, the music is great, like Kate Kestrel’s OST to the series. I like it very much. Good example to make use of the AGD system.

By Maggoo

Paragon (1218)

23-02-2020, 15:01

Cool! Terrahawks was one of my favorites Videopac games (still wishing for a port of KC Krazy Chase). Glad to see AGD used for making this port, the soft sprites are a good way to avoid flickering.

The enemies movement patterns seems a little off from what I remember tho? Great job nonetheless.

By CASDuino

Champion (360)

23-02-2020, 18:28

Any possibility of making a ROM version so that it can be converted to CAS?

By Fish

Resident (46)

23-02-2020, 21:07

No problem CASDuino, just tell me your mail address and I'll send it to you!

By Juanmi

Master (155)

23-02-2020, 21:27

Hi Fish,

I´m trying to load the game (.dsk) from the Megaflash SCC+ SD in a MSX turbo R ST and the game only shows the loading screen and freeze in a black screen.

By CASDuino

Champion (360)

23-02-2020, 21:50

buleste@gmail.com.

Once it's converted and definitely working as a CAS I'll send you the file.

By Fish

Resident (46)

23-02-2020, 22:28

Juanmi, I could send you the rom version of the game. the disk version makes use of the onedrive tool, it could be it's not compatible with a Turbo R (can''t test it myself)

By hamlet

Scribe (4106)

23-02-2020, 22:35

We could add the rom version to the download db, Fish.
Anf the version for the CasDuino ofcourse, too.

By Manuel

Ascended (19683)

23-02-2020, 23:08

Fish wrote:

Juanmi, I could send you the rom version of the game. the disk version makes use of the onedrive tool, it could be it's not compatible with a Turbo R (can''t test it myself)

You can do at least basic testing on an emulator...

By Juanmi

Master (155)

24-02-2020, 07:22

Fish wrote:

Juanmi, I could send you the rom version of the game. the disk version makes use of the onedrive tool, it could be it's not compatible with a Turbo R (can''t test it myself)

You can send me the rom to this EMAIL

But as Hamlet said, it's better if you add the .rom version to the mrc downloads.

Thank you.

By TheKid

Paragon (1238)

24-02-2020, 07:55

Haha, Yet another great series made by the gerry andersons team, although I Always was more of a Thunderbirds guy
But, nice game.

By gdx

Enlighted (6438)

24-02-2020, 09:38

I converted the game to Rom and added the joystick support in the menu.

Download: https://mon-partage.fr/f/Y7ckEBCw/

Fish, was you who converted Terrahawks for MSX?
It works on more MSXs by removing the call "CD BB 9D".

By hamlet

Scribe (4106)

24-02-2020, 10:38

Added gdx' .rom file to our db.
Thanks!

By Pippo

Hero (521)

24-02-2020, 12:06

Very, very interesting conversion.
The music is pretty beautiful, really.
Congratulations!

By Robby

Master (219)

24-02-2020, 12:54

gdx wrote:

I converted the game to Rom and added the joystick support in the menu.

Download: https://mon-partage.fr/f/Y7ckEBCw/

Fish, was you who converted Terrahawks for MSX?
It works on more MSXs by removing the call "CD BB 9D".

No first option for the creator itself to release it as a romfile?

Personally, i think it's obvious in the newspost that fish is responsible for the conversion.

By hamlet

Scribe (4106)

24-02-2020, 13:19

I have no problems to accept a third party ROM adaptation.
The intellectual property remains untouched. Fish's work is not modified by this.
If the author has problems with it, I will of course delete the ROM version from the db immediately.

By Fish

Resident (46)

24-02-2020, 19:05

thanks gdx for making the game work on more MSX machines. I guess there is a bug in the RAM based distribution from AGD MSX suite.

By CASDuino

Champion (360)

24-02-2020, 19:45

And because absolutely no one wanted it except me. The CAS file can be downloaded from here.

By jltursan

Prophet (2619)

24-02-2020, 20:34

I'll implement the CAS support sooner or later, in fact it's partially supported but I need to find and test a good set of CAS tools able to handle the files inside a CAS file.

About the RAM distribution, not really a bug but a careless implementation. The stack initialization is based on the HIMEM variable and if you load the disk image from a bloated environment like the one you 've when using a MFR+MultiMente+other tools, the RAM can't handle it. Of course I'm only guessing, although I've all this hardware, I'm reluctant to leave apart OpenMSX to check compatibilities so I need to check the MFR compatibility of this emulator to start the tests.

If you simply run the dsk image dumped to a real diskette it works, there's no problem with the MSX models themselves, only with the multiple tools used to load the games. I encourage the ROMs just because this, easier to load and run from mostly whatever combination (beware that I've recently uptaded the suite with some fixes about ROM initialization).

By Juanmi

Master (155)

24-02-2020, 20:40

Continuing with MFR SCC+ SD + turbo R ST, now the rom works fine at 60hz, but forcing the rom at 50hz, the ingame freeze.

By CASDuino

Champion (360)

24-02-2020, 20:56

If you ever need anyone to help with the cas implementation, let me know. At the moment using caslink3 to convert to a WAV and the castoolsgui to convert to a CAS you need to add the /r reset switch so that the game will work on real MSXs, otherwise it seems to struggle on MSX2s

By jltursan

Prophet (2619)

24-02-2020, 21:29

I'll do thanks!, for now, the CAS tools I need must be console based as they need to be called from the build script.

Quote:

Continuing with MFR SCC+ SD + turbo R ST, now the rom works fine at 60hz, but forcing the rom at 50hz, the ingame freeze.

The AGD games works always by default at 50Hz (forced) if the machine is a MSX2 or higher, no need to force it externally.

By gdx

Enlighted (6438)

25-02-2020, 00:00

It is not a good idea to force in 50 or 60Hz. Most Japanese monitors / TVs do not support 50Hz. In other countries, it is the opposite (although it is less common).

By Wlcracks

Hero (572)

25-02-2020, 07:18

The TMS MSX1 video chip doesn't even support switching interrupt frequency.

By gdx

Enlighted (6438)

25-02-2020, 09:17

I played a little the game on a real MSX1 at 60Hz. It's crashes after a moment of game. I suspect access to VDP too fast or an access to a register upper the 7.

By jltursan

Prophet (2619)

25-02-2020, 19:08

Quote:

It is not a good idea to force in 50 or 60Hz. Most Japanese monitors / TVs do not support 50Hz. In other countries, it is the opposite (although it is less common).

Agreed, the forced 50Hz is part of the initialization code, probably the older code of the engine.I need to think about he best strategy, probably let the game run at default freq and offer a hotkey to change it.

Quote:

I played a little the game on a real MSX1 at 60Hz. It's crashes after a moment of game. I suspect access to VDP too fast or an access to a register upper the 7.

I've tested it in both emulators (BlueMSX and OpenMSX) and seems to work fine. Openmsx doesn't warns either about too fast VDP acceses, the engine has been hugely tested against this situation. Anyway some heavy uses of particles and a lot of sprite scripting could cause some frame overloads; but it usually must last very little time and generate garbage not crashes.
I doubt that a register higher than 7 can happen, except the palette, there're no MSX2 features and if it's a bug, most probably it would appear easily in other ROMs. I'll give it a quick look tho
I've tested your ROM version, does the game crashes right after it boots up or during gameplay in some specific way?. I've some japanese MSX1 so I can try to test also these models...

Thanks for the feedback!, it's useful to have some user reports

By gdx

Enlighted (6438)

26-02-2020, 02:09

Now, I'm pretty sure it's because of too fast access to VDP because the game seems to work well on Turbo R in R800 mode but not in Z80 mode even at 50Mhz.

jltursan wrote:

Anyway some heavy uses of particles and a lot of sprite scripting could cause some frame overloads; but it usually must last very little time and generate garbage not crashes.

I have already seen crashes due to too fast access.

jltursan wrote:

I've tested your ROM version, does the game crashes right after it boots up or during gameplay in some specific way?.

It crashes randomly after a few moments during a game.

BlueMSX warns only if you are using debug mode with the option "breakpoint when VDP access too fast" checked but it is not always reliable.

By gdx

Enlighted (6438)

26-02-2020, 09:02

Finally the game crashes also on emulator. It is rarer but it happens too.

By jltursan

Prophet (2619)

26-02-2020, 18:58

What emulator?, OpenMSX?. If so, does it even misses to detect the "too fast..." event?

I'm gonna try to run the game a good amount of time and check if it happens without warning with OpenMSX and an emulated TurboR.

By Fish

Resident (46)

26-02-2020, 20:35

jltursan: if you need the agd file I'll be happy to sent it to you. It compiled without any errors.

By jltursan

Prophet (2619)

26-02-2020, 21:02

Yes please, I'll need it to recompile with some changes done in the engine.

It really hangs in OpenMSX after toggling freq to 60Hz in the TurboR and a lot of gameplay. I haven't been able to lock the game running over a National CF-3000 at native 60Hz, I don't have enough patience to achieve this
OpenMSX doesn't warns if it is or not a "too fast access.." and the "pause" led briefly flash and fades out.

There's a flag in the engine that can enable undelayed copy to vram routines but it's disabled by default and the big copy routines are always using the standard 27T wait except a routine that positively know that it'll be executed right after vertical retrace. Anyway, the VDP mode registers setup, in some places can be very tight with no more than 24T between OUT's and if this is a a problem it's strange that only this game crashes.
This game has a HEAVY use of PPI sound and all these bleeps and bloops are also very demanding, in fact, running over a MSX1 seems a bit slower than using the TR. I would try to disable all BEEPs first.
Also, if I'm not wrong, this conversion has no timers adapted and it runs as is in the MSX engine, twice as fast than the Spectrum original (the gameplay ends up being really frenzy!), that cause a little bit stress to the game logic as this game has a ot of sprite scripts.

By gdx

Enlighted (6438)

27-02-2020, 11:49

I tried to slow down access to the VDP but it didn't change anything. So I sorted out the interrupt routine a bit.

The game seems more stable now. I played about fifteen minutes without crash on an Japanese MSX1.

Download: https://mon-partage.fr/f/eSXs8vsS/

So finally I think this is the interrupt routine that must be improved.

Edit: Reuploaded! I modified the routine at 0B474h

LB474:  ld	hl,0b83bh
	set	7,(hl)
	res	6,(hl)
	ld	bc,0da1h    
	ld	hl,0b841h
LOOP:	out	(0a0h),a    
	outd
	ld	a,b          
	jr     nz,LOOP   
	ret

By jltursan

Prophet (2619)

27-02-2020, 21:03

I can't see any changes in the ISR in your ROM, only the ISR installer has some tweaks, what other changes have you done?. You can check the original sources in Github, routines "instisr" and "htimi".

The optimized routine is the ROUT ("psgrout" in my code) routine used by the PT3 & ayFX replayers, nice, thanks!, it's a bit faster this way. The first register accesed will always be equal to the value of STATFL, didn't checked it but I guess it would be always greater than a valid PSG register to avoid glitches.

By ray2day

Paladin (753)

11-03-2020, 20:16

@Juanmi and others .DSK version works fine with MFR, but you have to hold the 'D' key at (re)start/boot.

By gdx

Enlighted (6438)

12-03-2020, 09:22

@ray2day 'D' key at (re)start/boot remove the disks from other interfaces. The stability issue seems occur on MSX at 60Hz only. It's not because of the disks

By ray2day

Paladin (753)

16-03-2020, 16:49

@gdx I had the 'black screen' problem (on my 50hz NMS8245). And holding down D at restart worked.
Holding down D starting up MFR disables other disk interfaces to get more free RAM. (probably needed to get no black screen..)

By spl

Paragon (1470)

17-03-2020, 07:52

Great!!

By gdx

Enlighted (6438)

17-03-2020, 09:04

@ray2day I don't speak about 'black screen' problem but unstability (random crash). Terrahawks needs fix.

By Bodhi1969

Expert (96)

18-09-2020, 15:50

gdx wrote:

@ray2day I don't speak about 'black screen' problem but unstability (random crash). Terrahawks needs fix.

Is there any progress? I like playing this nice game, but randomly it kicks me out or just stops working.

By gdx

Enlighted (6438)

23-02-2023, 10:07

This weekend I looked in the program to see what is causing the crash. I found a LDIR that overwrite gradually the memory. So I replaced it by NOPs to see what changes. I didn't notice any change and it removes the crash. So here is the place to edit in the ROM version:

Replace ED B0 by 00 00 at 2B1Ah (AB1Ah in RAM).

And to remove the forced switch to 50Hz:

Replace F6 02 by 00 00 at 1D6Bh.

I played a few times for several minutes without crashing and without noticing any particular oddity. :)

I wonder what this LDIR was for. Maybe the dev can make a no-lag release now that the problem is located.

Share

Related content

Comments (40)