nesdev.org

One of the really great things about your Sonic art is how natural it seems to fit the system. It doesn't look like a game trying to be something it's not. It could pass for an original NES title.

I know your engine isn't finished, but it would be so great to be able to see the visuals on a ROM through the real hardware with the PPU's unique filter. Just a taste is all I ask, just a taste... lol

tepples wrote:Unless it's a counter derived from 10 Hz. Animations of walking characters in Thwaite and RHDE are based on a variable counting from 0 to 5 on NTSC or 0 to 4 on PAL. So is missile spawning and cooldown. Clocking a 10 Hz animation on a particular value or clocking a 20 Hz animation on 0 and 3 or 1 and 4 can produce good results.

That would rule out just about every animation that has to update every frame (e.g. moving things and such). That could be made up for by having destination values being multiples of 30, but sadly these systems prefer powers of two way too much to make that an option.

tepples wrote:Defensive programming likely ruled out non-equal in the first place.

Unless you keep forgetting what "carry"/"not carry" translate to, in which case you'll go for "equal"/"not equal" whenever you can (not an issue for me since I program on the 68000, but a huge issue on 8-bit CPUs - I keep having this issue on the Z80 all the time, and I don't recall the 6502 being any better).

Also there are times where you want things to happen only at a specific spot and nowhere else without having to stop the counter, which is where "equal" is ideal. Sadly you don't have a guarantee that it'll work anymore, so you have to resort to doing a "less/greater than or equal" comparison and keeping around flags to keep track of events.

Also if some stuff is fast enough to trigger 1 event per frame in NTSC, now you have multiple events going off in the same frame in PAL and you need to account for that... yeah. I think you're underestimating all the effort that goes under this, unless you want games to ditch vblank altogether and use some other hardware timer (maybe even include one in the cartridge).

OneCrudeDude wrote:A good guess would be that Nintendo was planning on putting the FDS out for the United States, but saw literally no reason for it since cartridges superseded the only advantage the diskettes had. So Nintendo likely had the audio lines cut out so that they could be re-connected just for the FDS, and not for anyone else. It sounds kind of odd putting it that way, but considering Nintendo was very controlling of their console, it wouldn't be surprising that Nintendo did that so that they could maximize their cartridge profits.

Er, think about this: how would you connect the FDS into the VCR-style cartridge slot?

Sik wrote:

tepples wrote:Unless it's a counter derived from 10 Hz. Animations of walking characters in Thwaite and RHDE are based on a variable counting from 0 to 5 on NTSC or 0 to 4 on PAL. So is missile spawning and cooldown. Clocking a 10 Hz animation on a particular value or clocking a 20 Hz animation on 0 and 3 or 1 and 4 can produce good results.

That would rule out just about every animation that has to update every frame (e.g. moving things and such). That could be made up for by having destination values being multiples of 30, but sadly these systems prefer powers of two way too much to make that an option.

For things that happen every frame, having the speed be a few percent off is probably acceptable. Thwaite has a bunch of 13/16 and 19/16 factors applied to various values.

Unless you keep forgetting what "carry"/"not carry" translate to, in which case you'll go for "equal"/"not equal" whenever you can (not an issue for me since I program on the 68000, but a huge issue on 8-bit CPUs - I keep having this issue on the Z80 all the time, and I don't recall the 6502 being any better).

MOS Technology was founded by Motorola alumni, and I'm pretty sure 6502 and 68000 share carry semantics. I know ARM's carry matches that of 6502. Z80 and x86 are a different story because the Intel 8080 has the opposite convention for borrow from the 6502.

Er, think about this: how would you connect the FDS into the VCR-style cartridge slot?

The system card for the NES version of FDS would be shaped like an ordinary NES Game Pak, with the disk signals routed through the expansion pins.

tepples wrote:MOS Technology was founded by Motorola alumni, and I'm pretty sure 6502 and 68000 share carry semantics. I know ARM's carry matches that of 6502. Z80 and x86 are a different story because the Intel 8080 has the opposite convention for borrow from the 6502.

I meant more like "did carry mean less than or greater than", stuff like that. Not everybody has such a good memory =P

tepples wrote:The system card for the NES version of FDS would be shaped like an ordinary NES Game Pak, with the disk signals routed through the expansion pins.

Point stands, some part of the hardware would have to stay away from the cartridge slot or it'd be impossible to connect. May put the audio lines there as well, especially if it would have helped designing or manufacturing the hardware.

Sik wrote:

tepples wrote:MOS Technology was founded by Motorola alumni, and I'm pretty sure 6502 and 68000 share carry semantics. I know ARM's carry matches that of 6502. Z80 and x86 are a different story because the Intel 8080 has the opposite convention for borrow from the 6502.

I meant more like "did carry mean less than or greater than", stuff like that. Not everybody has such a good memory =P

What I'm trying to say is that whatever carry means, it means the same across 6502, 68K, and ARM. So if you do manage to memorize it on one, you've memorized it for all three.

Given that they put the audio mix on the NES's expansion connector, and they only reserved 10 pads, and the cable from the FDS base to the drive itself is 11 conductors, two of which are power and ground... I guess they could have done it that way. (q.v. electronics junkers' RE'd schematic: http://green.ap.teacup.com/junker/119.html )

Seems a little weird to me to have deliberately decided to route audio through the expansion connector twice, but it's pointless to second-guess now.