Jump to content
IGNORED

TI Scramble - Scramble clone


Asmusr

Recommended Posts

I repeat what I said about your earlier demo: Why, in the name of all that is holy, did we not have games of this calibre back in the day! Your work *proves* that the hardware is capable of it; it just needs the applied talents of an inspired programmer.

People used to believe that it was impossible for a human to run a 4-minute mile until Roger Bannister did it. Now the *slowest* runner in a 1-mile race comes in at under 4 minutes. It comes down to perception. TI set the "standard" for the 9918A with one color blocky graphics, and people simply accepted it. The 99/4A never really attracted the "gamer" crowd either, so the games suffered. Parsec was deemed the pinnacle of 9918A capability and no one ever challenged it.

 

Konami on the MSX1 proved the 9918A was capable of *much* more, but by then it was too late for the 99/4A anyway. Now Rasmus has proven that the way Parsec did scrolling was not the best or only way to pixel scroll. Improvements like this come from simply not accepting what already exists and rolling your own, which is completely viable on a limited system like a classic computer or "golden age" coin-op. Or you might simply not know the current "limits", so you have no preconceived notions to hold you back.

Edited by matthew180
  • Like 1
Link to comment
Share on other sites

Matthew, from your experience fixing coin-op games, do you know which VDP Scramble was using? All I have been able to find is this page where it's described as 'Scramble hardware':

http://www.system16.com/hardware.php?id=554

 

And do you know if any coin-up games were using the 9918A?

 

I know Baby Pac Man used the 9928 (same VDP with component output) for the game screen, and Cliff Hanger (a LaserDisc game) used the 9918 for the computer text overlay. I'm not sure what else may have... is the MAME database searchable? :)

Link to comment
Share on other sites

Matthew, from your experience fixing coin-op games, do you know which VDP Scramble was using? All I have been able to find is this page where it's described as 'Scramble hardware':

http://www.system16.com/hardware.php?id=554

Hmm, interesting. I didn't know there were so many games made on that board set. Scramble, like more coin-ops back then, does not have a "VDP" that is a single IC. The arcade systems use discrete logic to implement a video subsystem, so each one is unique and custom. IMO they are very cool and interesting and it is amazing what they achieve with discrete logic.

 

Ironically I've been working on describing classic coin-op boards into FPGAs and I was looking at the Scramble schematic last night. Give me a little time and I'll give you a detailed summary of the system's capabilities.

 

I can tell you though, that most classic coin-op video systems have a sprite subsystem that are typically called "objects", a tile layer, and background. Some coin-ops support hardware scrolling of the tiles, some don't. For example, the Williams boards set used for Joust, Defender, Bubbles, etc. does not have any scrolling capability! It is a 384x256 pixel bitmap with 4-bits (16 colors) per pixel and required 48K of VRAM using the same DRAMs found in the 99/4A! What that board set did have though, was a custom blitter that could push a lot of pixels really fast. But, the Defender board did not have the blitter so all the scrolling and animation was done by the one 6809 CPU!!

 

Anyway, Scramble has one Z80 CPU for the game, one Z80 for sound, and dedicated hardware to rasterize the tiles and sprites (objects). The CPU would update certain memory and the objects and sprites would move or update. Similar to the 9918A's "name table" or "sprite attribute table", etc. Typically the graphics in a coin-op are in ROM so the patterns could not be changed. Most coin-ops do have a programmable palette though, so they were still limited in the number of colors but they could change them.

 

Typically in the coin-ops any shared RAM access would be multiplexed between the main CPU and the video subsystem, so the CPU had full speed access to any RAM. But, the RAM was typically just table updates and not patterns (with exceptions like the Williams board I mentioned, etc.) PAC-MAN, for example, only has 1K of RAM. The CPU would usually be running between 1MHz and 4MHz, with 3.5MHz being typical for the early 80's era systems.

 

And do you know if any coin-up games were using the 9918A?

Tursi already mentioned the only one I knew of: Baby PacMan, and I almost got to test the F18A in one in March, but alas it did not happen.

Link to comment
Share on other sites

http://www.youtube.com/watch?v=c8lYSiHB5nY&feature=player_embedded

 

Tomy Tutor uses the 9995 (same microprocessor found in the Geneve) and the 9918. Barry Boone ported some of the games to the Geneve years ago.

 

Quite intriguing how sluggish and ugly this Scramble looks compared to Rasmus's 9918 version running on a slower 9900!! Amazing!

 

(the guys comments about the poor use of sound are spot on)

Link to comment
Share on other sites

 

(the guys comments about the poor use of sound are spot on)

 

I have a question about sound in TI games. I know the ability and program exist to record samples and convert them into something the TI can use, but would digitized sounds be too big or difficult to utilize effectively? Would it slow things down too much? I can just imagine actual explosions in a remake of some future game. That would be awesome!

 

My problem is I'm just so blown away with all the knowledge and talent of the guys on here like Tursi, Rasmus and Mathew, that I keep forgetting about the actual hardware limitations. These guys have proven time and time again that nothing is impossible, which is why I always expect to see them give these limitations the figurative bird once again and come out with something else that is new and improved to blow my mind yet again.

 

Damn, if only these guy were around in the mid 80's to 90's things would have been a whole lot different.

Edited by Kevan
Link to comment
Share on other sites

 

 

Damn, if only these guy were around in the mid 80's to 90's things would have been a whole lot different.

 

Ahhh... many of the folks here were and have been around since the 80s and 90s :) I feel that the advent of emulation, faster PCs, better communication, and a host of tools has contributed to the further advancement of the TI and other computers. I know I find it much quicker and easier to program with emulators and a few tools open on my PC than using the real hardware, though I always bounce back to real hardware because it just..feels..right. :)

  • Like 1
Link to comment
Share on other sites

People used to believe that it was impossible for a human to run a 4-minute mile until Roger Bannister did it. Now the *slowest* runner in a 1-mile race comes in at under 4 minutes. It comes down to perception. TI set the "standard" for the 9918A with one color blocky graphics, and people simply accepted it. The 99/4A never really attracted the "gamer" crowd either, so the games suffered.

 

Yes.

 

Parsec was deemed the pinnacle of 9918A capability and no one ever challenged it.

 

Perhaps. It depends on your criteria. I could list dozens of officially released games (mostly not by TI) using one or another approach to pixel scrolling. Can't say I remember anyone using both speech and scrolling though. But then the 99/4A soon went out of business.

 

Konami on the MSX1 proved the 9918A was capable of *much* more, but by then it was too late for the 99/4A anyway.

 

Yes. Konami was however not the only one.

 

I think the 99/4A suffered big time from not having stock MC availability and this then kinda includes more than 256 bytes of RAM. Most of the notable competitors, in that time frame, had stock access to execution of machine languages programs loaded/entered into RAM.

 

I guess at least 90% of people did not have 32K RAM Expansion (and perhaps a cartridge being able to take advantage of this). I guess many "would be" game programmers quickly realized this one limitation and moved on to more "open" machines. TI shutting down the 99/4A surely didn't help, while the arcades inspired along the way (Konami and MSX1).

 

Now Rasmus has proven that the way Parsec did scrolling was not the best or only way to pixel scroll. Improvements like this come from simply not accepting what already exists and rolling your own, which is completely viable on a limited system like a classic computer or "golden age" coin-op. Or you might simply not know the current "limits", so you have no preconceived notions to hold you back.

 

It (the technique used throughout) has been proven a few times in projects like War Zone II.

 

;)

Link to comment
Share on other sites

Check out Penetrator, for the ZX Spectrum. Like the TI, the Speccy has no hardware scrolling. It also has no hardware sprites. Nevertheless, this guy got pixel scrolling, and animated pixel sprites from the hardware.

 

In 1983.

 

http://www.youtube.com/watch?v=LdPaT8m9Oc4

 

With the ZX Spectrum (Timex in the US) in mind, this is not the only example, but certainly one of the earlier ones. Only proves, to me, that a more "open" stock home computer with nothing more than a standard cassette recorder, would inspire more imagination and creativity. Yes, you'd probably need a book and maybe some kind of Assembler, but then you're capable of pushing the machine. If it hadn't been for the Mini Memory Module, I guess I wouldn't have rediscovered the TI. Again, the MMM turned out not to be greatly supported.

 

This one is 1987.

 

  • Like 1
Link to comment
Share on other sites

I played Penetrator when young in a Sinclair Timex 2068, and this remembers me a recent PDF book http://bizzley.com/

 

It describes how the author made R-Type for Sinclair Spectrum, but the important thing is where he talks about scrolling, he says that in order to get a good speed he only scrolled the non-zero blocks because Spectrum lacked power to move complete screen. I've tested the game (just to see) and it is an amazing work.

  • Like 1
Link to comment
Share on other sites

I played Penetrator when young in a Sinclair Timex 2068, and this remembers me a recent PDF book http://bizzley.com/

 

It describes how the author made R-Type for Sinclair Spectrum, but the important thing is where he talks about scrolling, he says that in order to get a good speed he only scrolled the non-zero blocks because Spectrum lacked power to move complete screen. I've tested the game (just to see) and it is an amazing work.

 

Hey ! Looks like I'm going to enjoy that book which I just downloaded and quickly browsed a few random pages. Nice !

Edited by sometimes99er
Link to comment
Share on other sites

A number of people from that time era that I talked to always wanted to try programming on the TI, but the cost barrier was way too high. Even when the console itself got cheap, to do anything high end required a PEB and 32k and disk and Editor/Assembler. They could get a C64 for the price of any of those, and so they did.

 

Regarding digitized sound, there's not much available that I've found yet for hardware support, and no way to feed audio from a co-processor from the cartridge slot, meaning the 9900 needs to do a lot of work. I don't think it's impossible - years ago I did a demo that had moving sprites while playing 1-bit sound and it wasn't TOO awful, but I haven't experimented further to see how much you can get away with that concept (playing digitized audio interrupted at 60hz for gameplay). Of course, it DOES take a lot of memory, but we have lots of memory on cart these days. ;)

Link to comment
Share on other sites

I haven't experimented further to see how much you can get away with that concept (playing digitized audio interrupted at 60hz for gameplay). Of course, it DOES take a lot of memory, but we have lots of memory on cart these days. ;)

 

Yeah, I kind of thought the bottle neck would be sound interrupting the free-flow execution of a program. Not being an programmer like you guys it was just a guess. About the only program remember I seeing anything even close to this was Parsec, with it's built-in speech. I'm assuming embedding explosion sounds would be done the same way as speech, correct?

Link to comment
Share on other sites

 

Yeah, I kind of thought the bottle neck would be sound interrupting the free-flow execution of a program. Not being an programmer like you guys it was just a guess. About the only program remember I seeing anything even close to this was Parsec, with it's built-in speech. I'm assuming embedding explosion sounds would be done the same way as speech, correct?

 

Parsec does its speech through the Speech Synthesizer, which is actually a compressed audio decoder (the compression is highly optimized for reproducing speech, is all, but all it knows is that it is playing back tones and noises). This device /does/ work independent of the 9900, for the duration of it's FIFO buffer, and so Parsec takes advantage of this by feeding it 60 times a second, and trusting that it will work on its own for at least that long (1/60th of a second).

 

In theory the synthesizer can reproduce many sounds with varying degrees of accuracy, but creating the compressed data is difficult. The tools are highly optimized for human voice and don't work well on other sounds. There was an example of a game somewhere (here or the list?) that used it for sound effects on a different platform, though.

 

It's possible to play back digitized sounds using the 9900 and the sound chip, which is what I thought you were asking about, but the system needs to work hard at it. 8Khz-11Khz seems to be the best quality most people achieve, which is middling-to-acceptable for music (comparable to telephone quality for voice, although we have only 4 bits of volume compared to 8 bits for telephone. For comparison, CD quality is 44Khz at 16 bit). So that said, if you decided to run at 10Khz and 4 bit, you have two problems to overcome. First is CPU - the 9900 must send new data to the sound chip 10,000 times a second, with fairly good accuracy (time slips will be audible - the ear is very sensitive to audio errors!) So that means every 100 microseconds, which is only 30 cycles on the CPU. Since most instructions take more than 10 cycles, you can see you won't be doing much more than moving data to the sound chip. The second issue is memory storage. At 10Khz/4-bit you eat 5k for every second of audio. A stock cartridge has 8k, the expanded system has 32k RAM. So you will quickly consume a lot of space for digitized audio. (And this is why TI's speech synthesis chip was such a revolution in 1979 - suddenly you could have plenty of speech for very little ROM - on the order of tens of bytes. That said, the compression was tricky enough that TI got away with charging (I've heard) thousands of dollars /per word/ to make the LPC data). But, you can also see it's not impossible.

 

Besides Barry Boone's Sound F/X which played back VOC files from the PC, the only commercial title on the TI I know that played digitized audio without a speech synth was Perfect Push, which announced "Golden Games presents Perfect Push" on the title page. It used 1-bit audio and played it back by toggling the cassette audio gate (for a 'tick' each time) rather than using the sound chip. I released a Teenage Mutant Ninja Turtles game to the BBS's which used the Missing Link and had a brief sample from the title song of the cartoon, I also used 1-bit audio but I played back with the sound chip. (The only reason mine was 1-bit was the only way I had to digitize the sound was via the cassette port, and that's all it can do. ;) ). I don't know what their sample rate was, but ISTR mine ended up around 6khz. Both both mine and Perfect Push's approach use the CPU exclusively, and nothing else happens while it's playing.

 

It was later that I tested the same audio digitizer (which I released to the Ottawa BBS, I think, I don't know if those files still exist) from normal Extended BASIC and left interrupts enabled, so sprites moved while it was playing. I remember thinking it didn't sound much worse. ;) Probably be a fun concept to revisit.

Link to comment
Share on other sites

Matthew, from your experience fixing coin-op games, do you know which VDP Scramble was using?

After looking around in MAME, reading the schematics, and a few other places, this seems to be the basic hardware capabilities:

 

Main CPU:

Z80@3MHz

2K CPU RAM

16K CPU ROM

 

Sound CPU:

Z80@1.8MHz

1K SOUND CPU RAM

6K SOUND CPU ROM

 

2K VIDEO RAM

2K OBJECT RAM

4K OBJECT / TILE ROM

 

Hardware generated starfield

 

8x8 tiles, 2-bits per pixel

16x16 sprites, 2-bits per pixel

 

256 x 224 pixels (32x28 tiles)

 

The tile layer seems to have hardware scroll support but I have not totally worked out the details yet. I also think the "background" can have priority over the tile layer for any tiles with a "name" less than 3, but I'm not sure.

Link to comment
Share on other sites

I did notice a horizontal line moving downwards over the screen, typically this indicates that you're not syncing to vertical refresh, could this be the case or am I looking at a MESS artifact?

That sounds strange, and I don't see it in my MESS (0149b). Even if MESS emulated scan line rendering I don't think my program would have this problem since all screen updates are done with double buffering.

Link to comment
Share on other sites

After looking around in MAME, reading the schematics, and a few other places, this seems to be the basic hardware capabilities:

 

Main CPU:

Z80@3MHz

2K CPU RAM

16K CPU ROM

 

Sound CPU:

Z80@1.8MHz

1K SOUND CPU RAM

6K SOUND CPU ROM

 

2K VIDEO RAM

2K OBJECT RAM

4K OBJECT / TILE ROM

 

Hardware generated starfield

 

8x8 tiles, 2-bits per pixel

16x16 sprites, 2-bits per pixel

 

256 x 224 pixels (32x28 tiles)

 

The tile layer seems to have hardware scroll support but I have not totally worked out the details yet. I also think the "background" can have priority over the tile layer for any tiles with a "name" less than 3, but I'm not sure.

Thanks. It's not a lot of video RAM, but there are actually not that many tiles or sprites in the game which is why it works so well on the TI. The hardware generated starfield explains why it's visible even through the buildings. I guess from studying the game that they also had a limitation to the number of sprites per row.

Link to comment
Share on other sites

Sure. There is a finite amount of time to collect the data and shift it out. The sprites use a line buffer, so the next line is probably being buffered while the current line is being drawn... maybe. Centipede used the horizontal blanking to get the sprite data and could support up to 16 total sprites. I think I read that the Scramble hardware object RAM supports up to 64 sprites, but certainly not all of those would be visible on a single scan line.

 

As for the amount of RAM, remember that the pattern data (which is typically color data as well) is in ROM. The actual object and tile tables are not very big. An exception would be a system like the Williams set I described previously, which only has a bitmap and thus a lot of Video RAM.

Link to comment
Share on other sites

That sounds strange, and I don't see it in my MESS (0149b). Even if MESS emulated scan line rendering I don't think my program would have this problem since all screen updates are done with double buffering.

Same version here, maybe it's a problem with my MESS install on my Mac. However, double-buffering alone is not enough, if you flip the buffer mid-scan you will still see tearing effects. So if you're not waiting for vsync, there is a real risk that you will see vertical tearing. And of course, this is much more obvious with horizontal scrolling than vertical scrolling.

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