Jump to content

Transylvania, a new version using TMS5220 synthetizer


Recommended Posts

Finally, here's some speech data for the stump scene... first a howling wolf (well, me howling like a wolf, actually), then the location text gets read (also my voice). The attached MP3 file approximates how it might sound (simulated by my encoder, not by emulation or on the actual machine). This is for the TMS5200, the speech synthesizer for the TI-99.

Stump_Scene_LPC.mp3 LPC_TMS5200_Stump_Scene.zip

  • Like 2
Link to comment
Share on other sites

Another thing about this game... as I already mentioned, at least the originally released versions don't load the graphics from disk as bitmaps, but as a series of line, fill and other draw commands which get executed to form the picture on screen. The way the pictures are drawn, this is a big memory saver. I did a bit more research and found out that the pictures have been drawn with "Graphics Magician" by Penguin Software (the same company which also originally released Transylvania), which also had the property that you could port graphics you drew on the Apple II to other machines (Atari 800, C-64) very easily. Graphics Magician also could use the special capabilities of each computer like setting interrupts on the Atari machines to set 4 different colors for every 2 lines and using the color RAM on the C-64, though this hasn't been done for Transylvania as it seems. The graphics still do look different on each system the game was ported to, for instance, the stump scene has a reddish road on the Amiga and Atari ST, but it's brown on the Apple II, yellow-ish on the Atari 8-bit and light green on the C-64, which tells me that the colors don't really have to look exactly like any other version because they look a bit differently in each version anyway.


What's more, Graphics Magician saves the pictures as SPC files which then can be loaded by the main game, and at least the C-64 disk of Transsylvania actually contains the SPC files for each individual room which indeed can be loaded and dissected with Graphics Magician. I'm pretty sure that a variant of this was also used on the other versions even on machines Graphics Magician wasn't released for. The manual of Graphics Magician also mentions an "interpret" command which would save the binary SPC files in a readable format, but I couldn't find that command in the C-64 version.


Now I thought how this could be used on the TI-99... the TI graphics chip has no "multicolor mode" where each pixel is defined by multiple pixels, but rather that strange bitmap mode with its 8x1 zones. So the pictures would have to be adapted a bit because any vertical or diagonal lines separating differently colored areas create a "clash" if they don't fall on a boundary of an 8x1 pixel field. So I think one could adapt to this by converting most of the dithered areas to solid colors and then drawing them in a way that works on the TMS9918A. To explain this, the "fills" are done by starting at a specific point and extending that color (or pattern) to the left and right until an "edge" gets reached. The way this could be done on the TI-99 is by implementing that logic as follows:

We're filling the bitmap as stated above, line-by-line, and in steps of our 8x1 pixel blocks. If a pixel block is empty (the color to be filled), it's turned to the new color in its entirety. However, if it's only partially empty, there are multiple cases:

1. If the block contains all pixels of a different color, it won't be changed at all, and the fill will stop before reaching it.

2. If the block has one or multiple pictures in a different color and then pixels of the background color to be filled, from the direction the fill is coming from, first the background pixels and then the pixels in the different color turn to the new color, and the pixels in the background color beyond that don't change.

3. If the block, seen from the direction the fill is coming from, has the background color and then one or more pixels in a different color, but nothing beyond that, the background pixels will become the new color, but the different color pixels will remain the same color.

There are also other commands like boxes and lines, and those will probably turn the foreground color of each block they touch into the current foreground color. Since in the SPC files, usually first all lines get drawn, and then the gaps between them get filled, this should work fairly well.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 2 years later...
On 9/23/2012 at 9:12 PM, jespol said:

We have found sources of a modern encoder for LPC string, and we will try to adapt the output (and the algorithm) for TMS5220... I hope this new converter will enhance human and non human samples.

Does anyone know of a windows program that converts to tms5220, 200 samples per 25ms frame?
I used QBoxPro (on my really old XP netbook) for the speech in my port of Astro Blaster, but can't get any sense out of it now (DOSBox).
Video captured from my BBC Micro using its TMS5220, best viewed at 720p50 most of the speech is supposed to sound robotic!
If anyone has a working qboxpro.ini and procedure that isn't the video linked, I would appreciate it although I am using the same ini from astro blaster and my notes from the time :(

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...