Jump to content
IGNORED

Remakes of old video games -- The TI-99/4A and PARSEC


Omega-TI

Recommended Posts

You need to add the bug (feature) where if you hold the joystick up while you're accelerating, you can wrap around. ;)

 

Nice one. Never knew of it. There seems to be 3 conditions for left and right boundary check to be logically “forgotten”.

 

1. Ship has to travel steadily at a speed (slow, fast, forward or backward).

2. The ship has to be at the upper limit (or get there before the left and right boundary check).

3. Joystick has to be in the up position.

 

:)

Link to comment
Share on other sites

Dont get me wrong, Ill take note of the features suggested.

 

Comparing with some of the major arcade games, Parsec obviously must have drawn inspiration from Scramble (1981) and Defender (1980). Scramble has the landscape, forced oneway scrolling, stages and levels. Defender has the grand explosion.

 

Funny thing about Defender being heavily based on Space Invaders (1978) and Asteroids (1979), allow for a wraparound world like Asteroids and turn Space Invaders 90 degrees. - Defender actually had asteroids added in development, but obviously they were later removed.

 

Ive looked in different directions, but now I think its time to actually add something. Besides moving in any direction, you can now fire the laser. You can use Ctrl, Q and Y to fire. I'll look into . (period) and tabulator (have to twist the KeyboardEvent or something).

 

:)

 

[media=544,416]http://sometimes.planet-99.net/parsec/p3.swf[/media]

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

I’ll take note of the features suggested.

 

I have one request. In the finished version, please do not overlook PAUSE. :)

While it's not a playability issue, a pause feature is one of the most important. Murphy's Law being what it is, one will be having the best game of their life, when a family member will walk in, want you to do something NOW, or demand your full attention!

 

T H A N K S !

  • Like 1
Link to comment
Share on other sites

I’m using the ISR VDP interrupt timer at >8379 to get frame by frame updates. Yes, LIMI 2 is good enough for Parsec.

 

Seeing the frames one by one, it looks as if the scroll area is updated in 4 chunks (from left to right). And that goes on in 4 out of 5 frames. The 5th frame is used for updating the stars.

 

Stars are turned off in the first bit position/last pixel (within a byte). Stars are at different positions (within a byte), so that’s how they do not turn off all at once.

 

Image below should be about 20 frames added.

 

:)

 

adding.frames.png

  • Like 1
Link to comment
Share on other sites

Stars added.

 

Controls

 

Y, Q, . (period), Ctrl and Tabulator fires the laser in your starship.
E, S, D, X and Arrowkeys moves your starship.
1, 2 and 3 changes the Lift which controls the speed of vertical movement of your starship.

:)

 

[media=544,416]http://sometimes.planet-99.net/parsec/p4.swf[/media]

Edited by sometimes99er
  • Like 4
Link to comment
Share on other sites

Hmm ... Here at my end, the Flash thing runs pretty smooth in Chrome and quite comparable with the TI-99/4A. It however appears jerky/choppy with Firefox, Explorer and Opera. Bummer.

 

I guess there’s a solution(s) somewhere since other stuff works fine (games with Facebook etc.). Wonder if it’s down to attempting to use hardware acceleration but then conflicting with this or that. I’ll experiment along the way.

 

:|

Link to comment
Share on other sites

CPU usage stays around 0% while only running the Parsec remake. Current Flash browser version is 11.8.800.94. Same as standalone (projector) version. All of which appear jerky. That includes my slightly older debug version. It being a debug version I didn’t take much notice of the jerkiness. Chrome however runs version 11.8.800.97, and it’s smooth. I guess I’ll stick with Chrome and see what happens.

 

:)

 

PS. The SWF file size (that's about what you're downloading) is still below 6K. Or 5,230 bytes - keeping it relatively TI retrotruespace.

Link to comment
Share on other sites

The SWF runs fine on my Firefox Nightly x64 build from yesterday. I just realized my Flash is a *little* behind...

You have version 11,7,700,224 installed

 

Whoops! It seems to run well on my TouchPad, too, which is something like Flash 10, I think.

 

(EDIT: all up-to-date... yeah, it's running a little jerky.)

  • Like 1
Link to comment
Share on other sites

Laser can now overheat. If you fire the laser continuously, the ship begins to flash. If the laser is fired for too long, your ship will explode.

 

Horizontal controls adjusted to be slower and less powerful (more like the original).

 

:)

 

[media=544,416]http://sometimes.planet-99.net/parsec/p6.swf[/media]

Edited by sometimes99er
  • Like 3
Link to comment
Share on other sites

I find it totally amazing how close you've been able to get this to the original. - EXCELLENT WORK YOU ARE DOING!

I have noticed that if you just press the fire button repeatedly, you can fire almost as fast as holding it down constantly, but you'll never explode.

 

Thanks.

 

Hope both the remake and the original behaves the same - regarding the fast fire.

 

At the moment I’m looking into the scroll area. The graphics in itself seems to take a good portion of the GROM - I’ll get back with more precise numbers there - eventually. Not even half through but it appears as if the graphics might be chunks of 30 by 64 pixels. Something’s bound to break that rule.

Link to comment
Share on other sites

I thought some of you might like to have a decent scan of the PARSEC manual. All the other scans I've seen so far are pretty 'rough' looking, so I figured I'd scan one in an upload it. Unfortunately the file is 11.7 megabytes (too big to upload here) so below is the link to download it.

 

https://www.wetransfer.com/downloads/a80f38a3db9b7c4734b4c5c8920c940c20130805191149/83d06aef750c35c3ddc174f0f0f6d64f20130805191149/1b0be5

 

ENJOY! ;-)

Link to comment
Share on other sites

This is the scroll chunks as they appear in GROM. The GROM is 18 KB and the chunks fill 7.5 KB. The first part of the first chunk (64 pixels wide) is repeated 4 times across when you start the Parsec game. The chunks (256 pixels wide) then come one after another. It seems as if the chunks always come in a particular order, like random but with a fixed seed. I observed parts 1(4), 6, 8, 7, 8, 8, 6, 6, 8, 1, 6, 8 etc. The tunnels of course come in when it’s necessary.

 

At Xona they’ve recently found that the tunnels share graphics. As you can see here, they share quite some even though they have they own parts in GROM. I’m surprised the developers/TI didn’t go for more unique tunnels when they had the memory. Maybe an element of surprise.

 

:)

 

scroll.chunks.png

  • Like 1
Link to comment
Share on other sites

Wonder how the graphics in general were drawn, and if mockups, drafts or anything has survived. One guy said he had the commented source code somewhere, - that would be interesting to see ...

 

I'd say they were almost certainly drawn on small graph-paper with pencil in someones notebook. That notebook is probably in a shoebox in the parents of the designers attic, long since forgotten!

  • Like 1
Link to comment
Share on other sites

On both accounts, I think, and hope, you're right ! ;)

 

When on holiday with no computers, or phones etc. (on purpose), I actually draw a bit of 9918 graphics on graph-paper, and do the 9900 shuffle. Hmm, other areas of retro-time-traveling gets to me. I think we (you and I) might share the music thing, though most certainly in different directions.

Edited by sometimes99er
Link to comment
Share on other sites

I would be interesting to know how many unique 8x8 characters and how many unique character transitions there are. Could the graphics be loaded into Magellan?

The area being scrolled is 30 pixels high and 32 columns wide.

 

The scroll area has the SIT and the CT preset and fixed. The PDT is where all the scrolling is done.

 

I not sure how it's done, but maybe it continuously fetches 2 bytes from GROM, shifts left into place (2 bytes becoming 1 byte) and basically streaming (auto-incrementing) to the VDP (cleverly having character codes stacked vertically). You could say it's almost true bitmap scrolling (though destination is not also source).

 

"Character transitions", if one could use the term here, is the complete area.

 

The scroll chunks in post #66 are in fact more like bitmaps, no indexing via characters or anything. Each has 30 bytes down and then the next column (32 columns). The chunks start in GROM at 5141, 8192, 9152, 10112, 11072, 12032, 12992 and 21660. Each chunk is 960 bytes (= 30 pixels high x 32 columns wide). I guess you could easily extract them to Magellan knowing these numbers.

 

Was it Jim who then started a Vanguard game for the TI, with full screen scrolling. I have the prototype somewhere.

 

Edit:

Yes, it was Jim Dramis with Paul Urbanus and Garth Dollahite. Jim and Paul also did Jungle Hunt with some clever scrolling. Paul and Garth did Pole Position. Vanguard, Jungle Hunt and Pole Position all for Atarisoft (target TI-99/4A of course).

 

:)

Edited by sometimes99er
Link to comment
Share on other sites

Yep, it gets a little speed boost for that.

 

I found the message here: http://tech.groups.yahoo.com/group/ti99-4a/message/62752

 

And to copy it:

 

This struck me as interesting, so I used Classic99 to see how true it

really is.

 

Parsec does indeed write and execute a small piece of scratchpad RAM

every frame, from 0x83E0. However, there's a lot of code executing in

the scratchpad, which does not get written repeatedly. Here's a function

at >8354:

 

65D0 bl @>8354

8354 movb @>8800,@>833c(R3)

835A inct R3

835C jlt >8354

835E b *R11

8360 mov @>833c(R4),R1

8364 src R1,0

8366 movb R1,@>8c00

836A inct R4

836C jlt >8360

836E b *R11

 

>8360 contains another subroutine:

 

6714 bl @>8360

8360 mov @>833c(R4),R1

8364 src R1,0

8366 movb R1,@>8c00

836A inct R4

836C jlt >8360

836E b *R11

 

Parsec does not appear to write the scroll routine to scratchpad every

frame. I tested this by adding code that would flag all executed bytes

in the scratchpad RAM, then emit debug if they were written to. After

the game was up and scrolling, I breakpointed the emulator and cleared

those flags, then resumed. There was no debug emitted. When I started

the game, that's when I saw the messages about data at >83Ex being

executed and written.

 

The code that ends up there, and thus gets rewritten, looks like this at

game start:

 

7F34 bl @>83e0

83E0 movb @>9000,R10

83E4 jmp >83e6

83E6 jmp >83e8

83E8 jmp >83ea

83EA b *R11

 

Note those three JMPs are NOPs, so all this does is a delay. Since it's

reading from >9000, this is probably just a little routine to safely get

the speech status without touching the 8-bit bus. This is the only code

that is written to scratchpad every frame, the rest lives there

permanently. It's only updated when it thinks it might be speaking.

 

By breakpointing on that code, it looks like Parsec has a 5-frame scroll

sequence, and it writes and calls this function for every frame. The

five frames seem to be:

 

-Scroll first quarter of scenery

-Scroll second quarter of scenery

-Scroll third quarter of scenery

-Scroll fourth quarter of scenery

-Scroll stars and animate ship flame

  • Like 1
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...