Jump to content
IGNORED

Dragon's Lair is sold out!


Tursi

Recommended Posts

Who knows, with some of the strange things I've seen on eBay over the years when in comes to limited editions on nearly anything, someone may post one up for $500.00 or something crazy like that. ;)

 

::strokes chin::

  • Like 4
Link to comment
Share on other sites

Who knows, with some of the strange things I've seen on eBay over the years when in comes to limited editions on nearly anything, someone may post one up for $500.00 or something crazy like that. ;)

Oh, I'm sure it'll appear on EBay. And I will certainly make a face in that direction, and question (as I did for the Skunkboard, Mr Chin, and Mario Bros) why I couldn't get that much for them when /I/ sold them. ;)

 

(Not that anyone should discourage anyone who does. If someone wants to make a fool out of some buyer, I guess that's free market ;) )

Link to comment
Share on other sites

I hope I am doing this correctly. I have read a number of these messages and have seen the module at work. My question is - how is this even possible on a TI 99/4a? A link to a post that might add insight to this would be appreciated.

the development thread here. videos are on YouTube under tursi's account.. Or his twitter .. Also his blog..

 

Sent from my LG-H872 using Tapatalk

Link to comment
Share on other sites

I hope I am doing this correctly. I have read a number of these messages and have seen the module at work. My question is - how is this even possible on a TI 99/4a? A link to a post that might add insight to this would be appreciated.

The TI-99/4A is working like an advanced yet low resolution videodisc player, but instead of using a disc it is using a 128MB Flash Memory, reading it and putting it to screen as fast as possible while feeding sound chip at same time.

 

As all the video data is inside the Flash Memory and the RAM is used only for a few variables and score then you don't need a memory expansion.

 

Of course this is an oversimplification as Tursi did something really amazing in the video and sound conversion and required calculations to keep everything in timing.

 

One question of mine: how many seconds takes to program the 128MB Flash?

  • Like 1
Link to comment
Share on other sites

You guys are pretty sweet. I did promise an overview of everything and I'll write that soon.

 

But to the basics, there were a few stages that led me to this, anyway.

 

First, I worked for a very long time converting stills to the TI. Eventually they got pretty good, and so I began to wonder about video. I actually wrote benchmarks years ago to figure out how fast you could push data on the TI from the cartridge port to the video chip, and the numbers made it seem feasible, at least for half the resolution of the bitmap screen.

 

A full bitmap screen takes two blocks of 6k (one for patterns, one for color). Splitting it in half gives 6k total. I'm not the only one who wondered about video - on the same day that I finally pushed out my first sample, the Spaceballs video, Rasmus also put out a full screen animation.

 

But in the end, video works by just pushing data to the screen as fast as possible. Even as fast as possible, and even only 6k, I still only manage about 9 fps. Since that's much slower than a video frame, I actually paint the screen in 4 bands. Doing this lets me push the pattern and color updates closer together in time, and minimizes the corruption.

 

I wrote an F18A GPU function to make that work better still, as the GPU can update both tables at the same time, but near the end of Dragon's Lair development I came up with a routine that compared a frame to the previous one, and adjusted the color table if it would help minimize the difference between them (without changing the final result). This made a huge improvement.

 

Audio was a bit of a challenge - like video I just blast data at the sound chip, but this was something I've played with on and off since the 80s. I experimented a lot which various conversions. The sound chip's volume control is a logarithmic curve, which means there's more detail available in the quiet part of the envelope than the loud part of it. A straight linear map is acceptable in many cases. A direct mapping to the closest logarithmic level sounds better, but only if your source audio is nicely centered in the range. I eventually came up with a hand-tuned scale for the 15 possible volumes that maximized the detail of the mid-to-louder parts of the envelope so that, in general, most audio could be heard fairly well.

 

There's always some distortion on audio, because there's a 48KHz carrier wave behind it, in addition to the low amount of control. At one point I thought it possible to get roughly 10 bits of audio resolution out of the sound chip by overlaying the channels (and, indeed, the MSX has done this and better with theirs). But I quickly found that because you can't control the start of the square wave, you can't control whether the channels are additive, subtractive, or (worse), offset from each other and adding harmonics. I still need to try using a manipulated noise channel with a custom rate, because this channel you CAN reset. It might be possible to eliminate the carrier wave.

 

Of course, a lot of this is thrown by the discovery that the sound chip is, by far, the slowest chip on the board, halting the CPU for roughly 28 cycles every write (over twice what a GROM read costs!) Fewer writes to sound, the better.

 

The audio is interleaved with the video at 1 byte every 4 video bytes, and the ultimate playback rate was determined more by observation than science, and then the video conversion scripts (a combination of ffmpeg, ImageMagick, SoX, and my own tools) just convert for that target frame rate. The playback code is, of course, all cycle counted and hand-tuned assembly. It's not perfect, but I got as close as I could.

 

Once that was working, I needed hardware. I reached out to a few people but like myself, everyone is busy. ;) In China I stumbled upon a large parallel flash chip, and found it's still a current part. With 128MB it was big enough for the game (and it seems there's a 256MB version coming ;) ). I selected a CPLD for level conversion and interfacing, and using my limited experience from the Jaguar Skunkboard, I learned VHDL for real and implemented the banking scheme we've been using for years, but on a much larger scale of 14 bits.

 

Then I was challenged to add GROM support for the v2.2 consoles, and I cursed that one out for like a month, but ultimately got a very small amount of GROM to work. The limitation there was mostly making it fit in the CPLD - with another 8 bits of address required, plus the logic to auto-increment, it was a tight fit in my little CPLD (and the next bigger CPLD was literally 3 times the cost.)

 

For the first 60 or so boards, I programmed the flash externally in an EPROM programmer and hand-soldered the boards. These chips take 10 minutes to erase, and the programmer took about another 20 minutes to program them. Then I tested them in a test cart, soldered them down, tested them again, put them in a shell, and tested them AGAIN. It was a pain. ;)

 

When I ran out of chips (due to defectives), I panicked and made a few changes to make in-circuit programming possible (with no idea how to do it), and ordered a bunch of pre-manufactured boards with newer chips. It took me about another month to come up with the CPLD logic and programming software, but that's working now. The TI can program a part in about 90 minutes (including the 10 minute erase), pulling the data from a Compact Flash card. The original pass at the program was 4 hours, but moving the main loops to zero-wait-state scratchpad improved that.

 

I also tried hacking one of my consoles to remove to wait states as per Theirry's page, but that isn't working and I haven't had a chance to diagnose it yet. Because my programming environment needs a couple of hacks to the console (in particular I replace the GROM line with another address select line to get direct access to the flash, and because the cart port is occupied, I dropped an Editor/Assembler GROM on the motherboard), I only have one machine running the programming (and a separate one to test ;) ).

 

I think that roughly covers it all... when I write it up I'll try to be more organized. ;)

  • Like 15
Link to comment
Share on other sites

Oh, I guess I can talk about the code. It's actually all available on Github (the video is not, though, sorry). To make the game itself, I interleaved joystick reading code throughout the video playback, replacing delays with the CRU setup and reads, and decode of the resulting data. By the end of that I had code that could play a fixed number of frames, and early-out when a specific direction (set by a mask) was detected. Simply put, it would play until it ran out of frames, or a valid input was read (and ignore invalid input).

 

Once I had that, playing a scene basically came down to a set of play commands. Each scene has the first frame to play, how many frames to play, and what joystick inputs are important. When the player returns, we check whether it was because of a joystick input or because we ran out of frames. Each possibility has a link to another sequence. If there are no more sequences, then the scene is finished and the code goes back to select the next scene. (There's also a flag that reports if it played a death scene, so it knows to count down the number of lives and add the scene to the replay stack).

 

Most of the game data fits in the 256 bytes of scratchpad memory. In fact the only thing that didn't was the scene queue.

 

The way the game works is that, regardless of mode, there are a few fixed sets of scenes to play. There's some randomness to the order, but the code basically queues these scenes up into a big list, which is stored in VDP RAM. When you die on a scene, it is added to the end of the list so that the game knows to make you replay it. The exact setup is hard coded and different for home and arcade modes, with slightly different rules for how long a set is and what it does when you die.

 

So I built the game backwards, basically:

 

First you have the video player, which plays a single clip and watches the joystick.

Which is called by a sequence player, which determines which clip to play next.

Which is called by a set player, which has a list of sequences to play.

Which is called by the core game engine, which tracks lives and cues up the appropriate set.

  • Like 12
Link to comment
Share on other sites

I do software for a living, but in the biz world, not the gaming and graphics world. @Tursi - that is an epic feat and I absolutely love the way you came at the problem! As an 11-12 yo kid I was doing XB on my TI-99/4A (and Basic on an Apple IIe at my school around that time). But the TI-99/4A was and is my first love (computer-wise, anyhow). I still remember the day my buddy Gene tells me I gotta go see this new game at the arcade, Dragon's Lair. The laser disc tech for a video game was so cutting edge, there was no way for him to describe it to me fully, so we hopped on our bicycles, I went, and I was amazed. In arcade terms, Dragon's Lair, and of course The Addams Family pinball are still all-time greats. I was too late on the draw on this one, though if you ever get the licensing to do a second round, I will happily shoot you the funds for this! And when you decide to mod the old TI Pinball game from back in the day to Addams Family, count me in. :)

 

I work full-time, do volunteer work, have a special needs kid, and am back for another Masters, so not much personal / fun programming time for me these days. But I intend to dig into assembly and/or GPL when I get free time and bang out some code on the machine of my first love. As a little kid I remember getting the Editor/Assembler package, and reading the brown Molesworth book on a greyhound bus b/t Detroit area and Grand Rapids after visiting a bud of mine. I got a little bogged down at that age with all the binary/hex conversion and never got back into it enough to code assembly, but it's been on my wish list for some years. Can't wait now that I'm again the proud owner of a TI. Anyhow, Tursi, thank you for your work and inspiration!

  • Like 4
Link to comment
Share on other sites

I do software for a living, but in the biz world, not the gaming and graphics world. @Tursi - that is an epic feat and I absolutely love the way you came at the problem! As an 11-12 yo kid I was doing XB on my TI-99/4A (and Basic on an Apple IIe at my school around that time). But the TI-99/4A was and is my first love (computer-wise, anyhow). I still remember the day my buddy Gene tells me I gotta go see this new game at the arcade, Dragon's Lair. The laser disc tech for a video game was so cutting edge, there was no way for him to describe it to me fully, so we hopped on our bicycles, I went, and I was amazed. In arcade terms, Dragon's Lair, and of course The Addams Family pinball are still all-time greats. I was too late on the draw on this one, though if you ever get the licensing to do a second round, I will happily shoot you the funds for this! And when you decide to mod the old TI Pinball game from back in the day to Addams Family, count me in. :)

 

I work full-time, do volunteer work, have a special needs kid, and am back for another Masters, so not much personal / fun programming time for me these days. But I intend to dig into assembly and/or GPL when I get free time and bang out some code on the machine of my first love. As a little kid I remember getting the Editor/Assembler package, and reading the brown Molesworth book on a greyhound bus b/t Detroit area and Grand Rapids after visiting a bud of mine. I got a little bogged down at that age with all the binary/hex conversion and never got back into it enough to code assembly, but it's been on my wish list for some years. Can't wait now that I'm again the proud owner of a TI. Anyhow, Tursi, thank you for your work and inspiration!

 

Thanks Patrick, those are kind words and I think we had a similar starting point. I had the TI at home, but I learned the Apples at school because I could do assembly there, but not on my bare bones TI at home. (This is why the Playground project Senior Falcon did fills me with wistfullness! Hehe.)

 

Dragon's Lair is a full on classic for good reason, though I rarely got a chance to play the real thing. Addam's Family is also a great pinball, but I'm more of a Twilight Zone guy myself. ;)

 

The trick with any software project is just breaking it into small enough pieces to accomplish. ;) I won't deny that when I started running out of scratchpad RAM near the end and had to balance the register usage between the various segments of code, it started getting tricky. Lots and lots of notes about what was where. Even with that, though, I look back and am a little surprised I did it all in assembly. I just kept each 'next piece' small enough that it didn't feel insurmountable. :)

Edited by Tursi
  • Like 4
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.

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

Loading...
  • Recently Browsing   0 members

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