Search options (Page 2 of 4)

Y'all, I need to just do an update where you can edit them like normal tiles in a game. Best to wait for that than do something convoluted...

No, unfortunately it's not just a CHR change at the moment. The format is a little odd. I could at least put them in a more normal format so you can hack them with standard NES romhacking tools. I could also extend the shape selection to allow more banks of four shapes. I'll have to take a look at making this more customizable.

BTW, thanks for putting new shapes in. It shows that I need to be sure to release source for things because it does help.

Oh yeah, about the shapes, you should avoid having much go in the left two and right three columns. If you run on a NES, anything on those edge columns will have glitches due to the way it generates so many colors. It's OK if a shape has a little sharp corner that pokes in a bit, but try to keep within the box of the standard square shape.

I finally put the full source code up for the NES and SNES versions of litewall (they share most of the same files, thankfully).

Yeah, the PC cable works fine on a PAL NES, and fortunately I have one for testing. I've been using it for years. As arfink said, it's just an adjustment to the timing loops, since the PAL CPU runs slightly slower than the NTSC one. Ideally the cart would have a Ciclone chip in it, so that it would work on NTSC or PAL NES, but we probably won't put that in the first version, which will be NTSC/PAL depending on the original cart we start with. The alternative is to use a NES with the CIC disabled by cutting a pin, or the redesigned one which I hear doesn't even have a CIC.

As I understand it, this is a device which connects to the NES controller port, and doesn't require anything special on the NES side; it's all in software. So anything can make full use of it, be it a program running on PowerPak, a cart with EPROM in it, etc. It's just a software protocol you use to communicate with it.

And being synchronous as I understand it, it doesn't require any cycle-timed code, and can run quite fast. If the hardware can keep up, the NES can read bits from the controller port at a maximum rate of 447 kilobits per second. More realistically, if it's actually saving the data somewhere, around 150 kilobits per second. And if I understand it right, the protocol makes it trivial software-wise, just a few instructions to read a bit.

Well, 25 kbps is slower than the 57.6 kbps can easily do in software on the NES, but the big advantage is that you get buffering, critical for music players and such. Is this interface synchronous, where the Arduino is clocked by the controller strobe rather than requiring cycle-timed NES code when reading? You can PM me if my questions are cluttering up your thread, BTW.

I prefer taking things a step at a time, so right now the phase is "build a prototype and see how it works". I'm pretty optimistic, but I've never used these Flash chips before, so there might be some snags. I don't want to make any big promises. Heh, I'm in a US-Central time zone, I just have an odd sleep schedule right now.