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
Some art from my old Sonic project
Moderator: Moderators
Re: Some art from my old Sonic project
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: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.
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).tepples wrote:Defensive programming likely ruled out non-equal in the first place.
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).
Er, think about this: how would you connect the FDS into the VCR-style cartridge slot?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.
Re: Some art from my old Sonic project
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.Sik wrote: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: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.
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.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).
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.Er, think about this: how would you connect the FDS into the VCR-style cartridge slot?
Re: Some art from my old Sonic project
I meant more like "did carry mean less than or greater than", stuff like that. Not everybody has such a good memory =Ptepples 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.
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.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.
Re: Some art from my old Sonic project
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.Sik wrote:I meant more like "did carry mean less than or greater than", stuff like that. Not everybody has such a good memory =Ptepples 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.
Re: Some art from my old Sonic project
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.
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.