Super Stunt Cycle Source Code

[Tempest]

9 hours ago, RevEng said:

Clocked serial communication with the console isn't just a quick hack job. It would be much closer to implementing the thing properly, and this device doesn't seem to be fully documented.

 

Anyway, I tried trowing random values into the 9 different memory locations the serial data gets stuffed into as it's read ($C2-$CA) and also the "latch" locations that seem to also get the data stored in them. ($CB-$D3)

In the 4-14-89 version, it just replaces the 03-03-03-03-03-03-03-03-03 text with my random values. (03 would be the all-high value from the serial read, and is an expected result without a device attached)

In the 5-26-89 version it just briefly displays the text "123456789ABCDEF".

 

I don't think the controls have been implemented in these protos, beyond the displayed values result. This is the sort of thing I'd write first for a new controller, rather than trying to hook it up to a game engine right away. It was in fact, the first thing I wrote to test the 7800basic snes2atari controller driver.

Ok so those numbers that get displayed in the 4-14-89 version are values being read from the serial read?  Can you explain a bit what you mean by that and how it relates to the 7800?  Sounds like there was a lot of work done behind the scenes that isn't visible.

 

5-26-89 just crashes right away.  Someone will have to look into why.  Maybe it's trying to read something and crashes when it isn't there (like the mythical controller)?  That or it just wasn't complied right.

 

8 hours ago, Mitch said:

The more interesting question to me is if the final game (Motor Psycho) has the serial code.

 

At this point, I wonder how much of SSC is in Motor Psycho or if they're even related.  The reason I assumed that SSC was an early version of Motor Psycho was that SSC was originally assigned Motor Psycho's part number and then crossed out and Motor Psycho written in.  This could either mean that the game was renamed or that Motor Psycho was a completely different game that was put into SSC's slot after it was cancelled.  I think the first explanation is more likely since it wouldn't be surprising that they changed the name from SSC to something a little more 'hip' and that if they needed a part number for a different game, there were plenty of unassigned ones.  Unless for some reason they specifically needed a motorcycle game for that part number that is.

 

I know that Motor Psycho was done by Blue Sky Software, but I don't know all the employees they had so I can't tell if the people mentioned in the SSC demos are Blue Sky Software employees.   They also did several other 7800 and XE games including the unreleased 7800 Klax, XE Xenophobe, and XE Mat Mania which I know exists but has never been dumped (last I heard Bruce at B&C had it).

[RevEng]

1 hour ago, Tempest said:

Ok so those numbers that get displayed in the 4-14-89 version are values being read from the serial read?  Can you explain a bit what you mean by that and how it relates to the 7800?  Sounds like there was a lot of work done behind the scenes that isn't visible.

Correct. 

 

From a high level, the 7800 driver is pulling 18 bits worth of data out of the controller. Each of these 18 bits is representing some different bit of state of the controller. The drive gets those 18 bits by pulling 2-bits of data from the controller 9 times.

 

Getting a bit more into the weeds, the device is wired into the second joystick port, and the low 2 bits (b0,b1) of the second joystick port are used for transmitting serial data from the controller to the 7800. The other two joystick lines are (b2,b3) are used for signalling from the 7800 to the device. (b2=reset, b3=clock)

 

The 7800 driver is written to only pull one set of the two bits every frame, and the two bits are immediate stuffed into one of 9 memory locations. The reason why we see a bunch of "03" values, is those two bits are always high without a device connected. i.e. binary 11 = decimal 03 = hex 03.

 

TBH that "always high" might be a quirk of a7800 emulation, and perhaps on real hardware the display will be 00-00-00-00-00-00-00-00-00.

 

1 hour ago, Tempest said:

5-26-89 just crashes right away.  Someone will have to look into why.  Maybe it's trying to read something and crashes when it isn't there (like the mythical controller)?  That or it just wasn't complied right.

It works in emulation, on a7800. It doesn't have a text display like the earlier version, but it does have a running loop, even if it seems to do nothing much on-screen. Or maybe you mean it's crashing on real hardware? 

 

9 hours ago, Mitch said:

The more interesting question to me is if the final game (Motor Psycho) has the serial code.

I trapped on RIOT access in the a7800 debugger, and I'm seeing nothing like the serial driver in the game's active code.

 

I also searched for a short hex sequence from the Top Rider driver (one that I'd expect to remain constant) and I came up empty.

 

[Tempest]

17 minutes ago, RevEng said:

It works in emulation, on a7800. It doesn't have a text display like the earlier version, but it does have a running loop, even if it seems to do nothing much on-screen. Or maybe you mean it's crashing on real hardware?

 

Really I'm using a7800 5.2 on my Linux box and all I see if the screen with two garbled looking characters on the left.  It does briefly flash 123456789ABCDEF though when it starts.  I assumed this was because it was crashing but maybe it's just not displaying anything because it wants the special controller.  Sounds like we're not going to see much without it.

 

Hopefully someone can compile that 5/26 version. 

[RevEng]

4 hours ago, Tempest said:

Really I'm using a7800 5.2 on my Linux box and all I see if the screen with two garbled looking characters on the left.  It does briefly flash 123456789ABCDEF though when it starts.  I assumed this was because it was crashing but maybe it's just not displaying anything because it wants the special controller.  Sounds like we're not going to see much without it.

Yeah, it's running. If you run a7800 with the "-debug" argument, hit F5 in the debugger window, you can see it happily executing instructions. If I send random data into that serial controller buffer then the 123456789ABCDEF flashes again.

 

Even with the actual Top Rider controller hooked up, I'm pretty sure nothing much is going to happen with these roms. Sending random data into that buffer should be equivalent to randomly engaging all of the controls on the motorcycle, but nothing is happening. (except the 123456789ABCDEF text.)

[Tempest]

3 hours ago, RevEng said:

Yeah, it's running. If you run a7800 with the "-debug" argument, hit F5 in the debugger window, you can see it happily executing instructions. If I send random data into that serial controller buffer then the 123456789ABCDEF flashes again.

 

Even with the actual Top Rider controller hooked up, I'm pretty sure nothing much is going to happen with these roms. Sending random data into that buffer should be equivalent to randomly engaging all of the controls on the motorcycle, but nothing is happening. (except the 123456789ABCDEF text.)

Something must be happening that we can't see though.  I mean 5 months is a long time for game development much less a demo.

[RevEng]

I don't think we have the right runtime context for this rom. If I remove the first half of the rom, which is empty anyway, and change the header to linear/flat rom, the mountains are back.

 

Spr Stunt 5-26-89-short.a78

 

The proto is also trying to write to addresses in the $Fxxx range. It's not trying to do anything exotic like self-modifying code, but rather it's just using ad-hoc allocation of memory here and there between subroutines. This sort of allocation is pretty common on ram-based 8-bit computers, and no doubt it''s popping up here because the proto was being developed on a ram cart.

 

 

[Tempest]

23 minutes ago, RevEng said:

I don't think we have the right runtime context for this rom. If I remove the first half of the rom, which is empty anyway, and change the header to linear/flat rom, the mountains are back.

 

Spr Stunt 5-26-89-short.a78 32.13 kB · 0 downloads

 

The proto is also trying to write to addresses in the $Fxxx range. It's not trying to do anything exotic like self-modifying code, but rather it's just using ad-hoc allocation of memory here and there between subroutines. This sort of allocation is pretty common on ram-based 8-bit computers, and no doubt it''s popping up here because the proto was being developed on a ram cart.

 

 

 So these prototypes most likely need an ST development board to run?  I actually do have one, but no ST to load it.  Or do you think they were using some other sort of development system?

[+Trebor]

Here is what we have courtesy of @CPUWIZ MCP Dev Cart (Thanks @RevEng for the idea):

Control Notes: 
Controller 1 - No response.  

 

Controller 2 - Pressing Up, results in the animation scroll with "123456 C EF" shown at the bottom.  Pressing Down, results in the animation scroll with "8 A" shown at the bottom.  Left, Right, and buttons have no impact.

[Tempest]

40 minutes ago, Trebor said:

Here is what we have courtesy of @CPUWIZ MCP Dev Cart (Thanks @RevEng for the idea):

Control Notes: 
Controller 1 - No response.  

 

Controller 2 - Pressing Up, results in the animation scroll with "123456 C EF" shown at the bottom.  Pressing Down, results in the animation scroll with "8 A" shown at the bottom.  Left, Right, and buttons have no impact.

Progress!  Which version is this or do they both do the same thing?

 

Has anyone compiled that last version yet?

[+Mitch]

Should we try chopping them all down to 32K?

 

Mitch

[RevEng]

1 hour ago, Mitch said:

Should we try chopping them all down to 32K?

 

Mitch

Yeah, they should all be 32k, and linear/flat. (currently they're 64k supergame). I already did both of the '89 ones...

Spr Stunt 4-14-89-short.a78 Spr Stunt 4-14-89-short.bin (new)

Spr Stunt 5-26-89-short.bin Spr Stunt 5-26-89-short.a78 (this is the one I posted earlier, that Trebor tested out)

 

23 hours ago, Tempest said:

 So these prototypes most likely need an ST development board to run?  I actually do have one, but no ST to load it.  Or do you think they were using some other sort of development system?

Any ram cart or equivalent should work. Trebor used CPUWIZ's NVRAM based MCP cart.

 

2 hours ago, Tempest said:

Has anyone compiled that last version yet?

Isn't the "5-26-89" version that we've been progressing here the last version?

 

3 hours ago, Trebor said:

Controller 2 - Pressing Up, results in the animation scroll with "123456 C EF" shown at the bottom.  Pressing Down, results in the animation scroll with "8 A" shown at the bottom.  Left, Right, and buttons have no impact.

 UP=bit_0 and DOWN=bit_1 of the RIOT port, which are the serial data bits of the motorcycle controller. So essentially you've managed to simulate some combination of motorcycle buttons/sensors being pressed simulaneously.

 

[Tempest]

1 hour ago, RevEng said:

Yeah, they should all be 32k, and linear/flat. (currently they're 64k supergame). I already did both of the '89 ones...

Spr Stunt 4-14-89-short.a78 Spr Stunt 4-14-89-short.bin (new)

Spr Stunt 5-26-89-short.bin Spr Stunt 5-26-89-short.a78 (this is the one I posted earlier, that Trebor tested out)

 

Any ram cart or equivalent should work. Trebor used CPUWIZ's NVRAM based MCP cart.

 

Isn't the "5-26-89" version that we've been progressing here the last version?

 

 UP=bit_0 and DOWN=bit_1 of the RIOT port, which are the serial data bits of the motorcycle controller. So essentially you've managed to simulate some combination of motorcycle buttons/sensors being pressed simulaneously.

 

Oh you're right, I guess the one I was thinking of is an earlier version.  There's still 10/14/88 and 11/18/88.  
 

Will this work with a7800?  How about the Concerto?

[+Mitch]

So setting them as 32K ROM + 16K RAM in the header won't work? Or is it treating the ROM as writable?

 

Mitch

[RevEng]

1 hour ago, Tempest said:

Will this work with a7800?  How about the Concerto?

They'll run in a7800, but not correctly. a7800 doesn't have a ram cart mapper. For some mappers with some address ranges, Concerto allows writes to happen to "rom", but I think for 32k it doesn't. I have my 7800 packed away at the moment, so I can't confirm that.

 

1 hour ago, Mitch said:

So setting them as 32K ROM + 16K RAM in the header won't work? Or is it treating the ROM as writable?

The writes happen throughout the cart, including the top-most addresses, so it would all need to be writable. There isn't a header setting for all-ram-cart, and even if there was, there's no support for it in emulators or flash carts.

[Tempest]

7 hours ago, RevEng said:

They'll run in a7800, but not correctly. a7800 doesn't have a ram cart mapper.

Is there a 7800 emulator that does?  Makes it hard to review a game without an emulator that can handle it. 

[+Trebor]

1 hour ago, Tempest said:

Is there a 7800 emulator that does?  Makes it hard to review a game without an emulator that can handle it. 

8 hours ago, RevEng said:

There isn't a header setting for all-ram-cart, and even if there was, there's no support for it in emulators or flash carts.

[Tempest]

56 minutes ago, Trebor said:

I'm old and don't understand those circle face things.  Can you turn that into a sentence please?  I assume an emulator that works with this exists then?

[RevEng]

2 hours ago, Tempest said:

Is there a 7800 emulator that does?  Makes it hard to review a game without an emulator that can handle it. 

I'm not aware of any 7800 emulator or flash cart that does.

 

You won't be able to review it in emulation and get anything better than Trebor's video, unless someone does an implementation of the Top Rider controller *and* a ram cart target. Alternatively, maybe someone else can hack the rom to only use cart-ram, disable the Top Rider driver, and insert a routine that reads some other multi-button controller and populates the 18-bits... I don't have the cycles to do that, and don't foresee being able to do it soon.

[Tempest]

1 hour ago, RevEng said:

I'm not aware of any 7800 emulator or flash cart that does.

 

You won't be able to review it in emulation and get anything better than Trebor's video, unless someone does an implementation of the Top Rider controller *and* a ram cart target. Alternatively, maybe someone else can hack the rom to only use cart-ram, disable the Top Rider driver, and insert a routine that reads some other multi-button controller and populates the 18-bits... I don't have the cycles to do that, and don't foresee being able to do it soon.

My problem with the video is there's a lot of moire effect going on there and I can't see what's really happening.  I assume that's moire effect anyway, unless the ground is stripped like that?

[Tempest]

Anyone look further into this?  Also does anyone have a cleaner video of the screen moving?

[alex_79]

I guess those would run on the old "DevOS" by Eckhard Stolberg, using any of the ramcart types supported.

That is, if you have a PC with a parallel port that can run the old software, maybe in a virtual machine.

[+Trebor]

16 hours ago, Tempest said:

Anyone look further into this?  Also does anyone have a cleaner video of the screen moving?

Here is a higher quality version - @1920x1080 60p available. 

 

The "Auto" setting should set the right resolution based on screen view size.

 

Nonetheless, for the default below sized window, the video should be configured as "360p" to minimize moiré.

 

Viewing fullscreen on a native 1920x1080 display, the video configuration should be set to "1080p60" to minimize moiré.

 

Setting "1080p60" at the below size window will increase moiré drastically.

[Tempest]

57 minutes ago, Trebor said:

Here is a higher quality version - @1920x1080 60p available. 

 

The "Auto" setting should set the right resolution based on screen view size.

 

Nonetheless, for the default below sized window, the video should be configured as "360p" to minimize moiré.

 

Viewing fullscreen on a native 1920x1080 display, the video configuration should be set to "1080p60" to minimize moiré.

 

Setting "1080p60" at the below size window will increase moiré drastically.

Oh I see. That's not moire effect, that's just how the road is then after you start going off to the left or right?

 

I'm really thinking that this game has nothing to do with Motorpsycho now.  I think they scrapped this engine completely and made a completely different game.  Is there any code from this in Motorpsycho?

[RevEng]

5 hours ago, Tempest said:

I'm really thinking that this game has nothing to do with Motorpsycho now.  I think they scrapped this engine completely and made a completely different game.  Is there any code from this in Motorpsycho?

Mostorpsycho and the last SSC rom don't share any significantly amount of code.

 

I base that statement on compressablity testing i did with a dictionary type compression. (Lempel-Ziv coding) If you sum the compressed size of each rom, it's about the same size as both roms concatenated and compressed. (just 0.5% difference) Had there been any shared routines in both roms, the difference would be greater.

[Tempest]

4 hours ago, RevEng said:

Mostorpsycho and the last SSC rom don't share any significantly amount of code.

 

I base that statement on compressablity testing i did with a dictionary type compression. (Lempel-Ziv coding) If you sum the compressed size of each rom, it's about the same size as both roms concatenated and compressed. (just 0.5% difference) Had there been any shared routines in both roms, the difference would be greater.

I guess I'll split them into two pages then.

 

Has anyone taken a look at the code for 10/14/88 or 11/18/88?  I think those were in the archive as well.