RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
i don't think there's anything more here either.
@Trebor might want to confirm what the road looks like at the very start of the rom being launched. If the road is dead center and the bike isn't accelerating, like in emulation, I suspect the road looks pretty much the same. The small road ripples in the road are probably there because the bike is supposed to be moving forward, and it's not possible to convey forward acceleration on a mathematically perfect and uniform road.
-
Just for context...
- pushing up on the joystick looks to the game like half of the buttons on the Top Rider controller are engaged. (all of the even bits in the 18-bit controller state are high)
- pushing down on the joystick looks to the game like the other half of the buttons on the Top Rider controller are engaged (all of the odd bits in the 18-bit controller state are high)
i'm sure some of those bits being engaged simultaneously are mutually exclusive (e.g. lean left+lean right) so we can't really expect to get anything resembling the actual control scheme using just a joystick.
-
2
-
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.
-
1
-
-
50 minutes ago, JagChris said:
Otherwise they wouldn't have statements about supporting publishing for it.
Would you say they're just keen to support homebrew, or keen to sell a bunch of shells they have as overstock?
-
1
-
-
3 hours ago, John Stamos Mullet said:
Well, as much as we all appreciate the time and effort quality homebrews take to get in the hands of users, they aren’t really wrong. They sold people a new product, professionally developed, marketed, and produced, using a fully established business. They paid taxes. They paid employees. They used real factories.
With the exception of paying employees, there are plenty of homebrews that tick all those boxes. That sizeable difference is mostly in your head.
3 hours ago, John Stamos Mullet said:as for the game - I liked it. It’s well made. Not my favorite game ever, but worth the $50 I paid for it at least. I can’t always say the same of homebrews I’ve purchased.
homebrews are like rock bands. Some are truly great, some are mildly entertaining. Many of them are… not.
Their game is good, so therefore it's not a homebrew? I take it you think every commercial 2600 and 7800 game is good then? Or maybe, just maybe, game quality can be independent of the homebrew/commercial category.
-
4
-
-
Generally this is about what is easier on balance for the developer, converting vs remaking.
In terms of non-arm-assist 2600 to 7800 conversions, 2600 games are typically so much smaller than 7800 games, that porting doesn't really save you a whole lot of time. 2600 games are also architected to save as many cycles as possible in the display kernel, and often that spills into other areas of the code, or even the whole architecture of the game. None of that is useful to convert over to the 7800, but you still need to understand it, and then remove it.
In terms of A8 to 7800 conversions, the conversion vs remake balance heavily depends on what unique hardware features the game uses. I think the only finished A8 to 7800 conversion at this point in time is Serpentine. Out of the dozens of A8 games I enjoyed greatly back in the day, I picked Serpentine to port because it didn't significantly use Player-Missile graphics, collision registers, or anything else deeply A8 flavoured. (Serpentine was itself a port from Apple II to A8, so that makes sense) Even then, i spent a few weeks disassembling the A8 release before even getting to the adaptation stage, so conversion isn't the easy slam dunk you might think it is.
The 7800 graphical strengths are somewhat opposed to the strengths of the 2600 and A8. Player-Missile graphics can easily be made tall, but being very wide is a decent challenge. 7800 display objects are easily made very wide, but creating very tall objects requires creating multiple stacked objects, which be hard on resources. Also, the cycle penalty for DMA tends to be heavier on the 7800 than on the A8, for comparable modes - I had to tune Serpentine timings to make it run faster on the 7800, just to keep pace with the A8 version.
When you're porting games from other platforms that don't have similar DMA penalties and improving graphics for the 7800 at the same time, you need to factor in that DMA cycle penalty even larger. Even though the C64 and PET run at a slower clock than the 7800, the fact that the 7800 port of Petscii Robots was pretty much all 160B (there are 314 160B sprites that make up the main display) meant it ran much slower than the other platforms at first. I had to dig really deep with algorithmic improvements to get things running at a correct speed.
While DMA, graphical strengths, lack of collision registers, etc. are a factor for any sort of port - conversion or remake - dealing with these issues in your own source from the outset is always going to be much easier than having to deal with them by refactoring someone else's source code.
Thanks for coming to my Ted Talk.
-
11
-
-
It's a feature for subscribers.
-
1
-
-
1 hour ago, SpiceWare said:
I think they don't consider what they're doing homebrew because they are professionals developers for the 2600 from back in the day. Along those lines would a professional athlete take kindly to being called amateur later on in their life? As such, I view it as a perceived slight where none was intended.
I think that's a poorly fitting analogy. But running with it... if the professional athlete is running in an amateur meet, I don't think he should say it was a professional win either.
Dropping analogies, they said CC wasn't homebrew not just because they were once professional programmers on the 2600, but rather, because it had a professional fit and finish, they didn't reuse carts, and homebrews are always made at home. (???)
I'm sure they didn't intend a slight, and they seem like nice guys. They just think they're better than homebrew. Whatever, no big deal.
-
6
-
-
5 hours ago, BrianC said:
Weren't David Crane and Garry Kitchen at Absolute at the time of the 7800? Wasn't Super Skateboardin' done by David Crane?
I wasn't aware. I stand corrected!
-
2 hours ago, selgus said:
I'm curious what the modified BIOS does that requires this reset, that the stock BIOS doesn't. Guess I could look into that.
The stock NTSC bios doesn't appear to run before the BBpro menu appears - there's no fuji, and therefore no encryption signature check on the cart, and more importantly, no lock on the console mode. Leaving the console unlocked appears to be integral to the operation of the cart, and whatever BBpro is doing to avoid that lock just doesn't work on modified BIOSes. 🤷
-
1
-
-
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.
-
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.
-
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.
-
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.
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.
-
3
-
-
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.)
-
1
-
-
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.
-
1
-
-
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.
-
Not presently, no - none of the 7800 emulators support nes controllers, and this controller is a bit weird. First, it has analog values spread over some of the bits, so I can't just substitute a gamepad for it. Second, it uses the NES Expansion Port rather than the regular NES controller ports.
-
Digging into the '89 SSCDLI.S source, the Top Rider device looks to be a clocked serial controller. At times the source code refers to the controller as a "motorcycle".
A slightly crazy thought... Top Rider is an NES motorcycle game that shipped in 1988 with an inflatable motorcycle controller, and NES controllers are clocked serial devices.
-
4
-
-
It looks to be a pull-up or pull-down on /WE, which is interesting. It's not in the AA 7800 schematic. @-^CrossBow^- is the other end of that resistor connected to +5v or ground?
-
58 minutes ago, darryl1970 said:
@RevEng Does "Hardcode" mean to set pokeysupport to $450 instead of just "on"?
Yep, correct.
-
1
-
-
4 hours ago, darryl1970 said:
Fred, when PentaGo goes to cartridge, will POKEY detection work on the HOKEY cart, or do I need to just manually default to POKEY and keep track of that in the game itself?
The recommended way forward for pokey support in 7800basic is to use hard-coded pokey addresses. It's also mentioned in the manual. The upcoming RMT functionality will only work with hard-coded pokey, and I'll likely put a compile warning in 7800basic if pokey autodetection is chosen. In the case of a game being put on specific hardware that is guaranteed to contain hokey/pokey, enabling autodetection doesn't get you anything, and it's just one more thing that can go wrong.
The 7800basic autodetection was developed at a time when XM was on the horizon and the only flash cart used bins without a78 headers, so a game needing to search for a pokey made sense. Our modern context is that every emulator and flash cart that can provide a pokey is reading and respecting a78 headers, and write-only pokey is a thing too; it just makes more sense now to tell the device where to put the pokey, rather than let devices put pokey somewhere and to try to search for it.
-
3
-
1
-
-
On 3/2/2023 at 1:01 PM, JagChris said:
Even though they say they have no interest in the 7800 i would imagine the 8 bit guy was likewise. Perhaps something similar could happen with Audacity.
David Murray owns a 7800 and has demonstrated it on his channel before, and mentioned the 7800 as a possible platform for Petscii Robots prior to mksmith and I starting the 7800 port. I don't think it's anywhere near his favourite console, but he genuinely does have a connection to it.
Activision served as publisher for a couple 7800 games, but did no coding in-house. I doubt that the Audacity guys want to learn another retro platform they have no personal history with. I also doubt they'd partner with established 7800 homebrew coders like David Murray did. At the risk of stoking a long dead controversy... from interviews, it was pretty clear to me that the Audacity guys did not want to be associated with the homebrew scene at all.
-
6
-
1
-
-
Seems to me it's a signal timing issue. Something (phi2, halt, rw, ...) has drifted out of spec, and it's occasionally causing DF to do the wrong thing, like a write instead of a read, or an action on an address that hasn't fully come up on the bus. Enabling pokey is probably giving you a weak pull-down on the signal in question, and it's enough to push it back in-spec.
-
1
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Super Stunt Cycle Source Code
in Atari 7800 Programming
Posted
Thanks for the investigation, and I agree.