1,537

(38 replies, posted in General Discussion)

Moriokun wrote:
nitro2k01 wrote:

The Nanoloop cartridge has an extra EEPROM chip instead of SRAM. This means it needs no battery and that you have to save your song before turning the power off.

Why don't cart markers just use this design? Or are you not able to flash custom roms and savs?

LSDj expects to have at least 32 kB of external RAM mapped directly, for the current project. You might be able to make a design which has 32 kB RAM for this purpose which is not battery-supported, and then save projects to EEPROM like NL. But then you would always have to save before turning off, and people would be annoyed. Simply put, it's not how you'd want to do things.

1,538

(38 replies, posted in General Discussion)

akira^8GB wrote:

But then it crashes and your work is gone.

Hmm, does Nanoloop actually crash in data-destroying ways? It shouldn't be as susceptible as the SRAM used by LSDj. That has nothing to do with the battery, but the fact that the CPU has to execute a series of commands in order to access the EEPROM.

1,539

(38 replies, posted in General Discussion)

The Nanoloop cartridge has an extra EEPROM chip instead of SRAM. This means it needs no battery and that you have to save your song before turning the power off. The main advantage, to be honest, seems to be piracy protection. The demo ROM is actually the full version, only that it can't save unless it's running on the appropriate hardware.

1,540

(38 replies, posted in General Discussion)

Re GBA carts: Mostly, commercial GBA games use EEPROM natively, So they read/write their save data in a very predictable way. The same is really true for most games, even GB. On GB however, the save data is stored in a SRAM chip, and is mapped directly onto the memory map, so you can read/write it without latency. And LSDj (ab)uses this to use SRAM as working memory for song data. In games, the memory is typically unprotected when you load or save the game only, whereas in LSDj, it's unprotected on every little edit, and also when you play the song. So to answer the question, no I think GBA flash carts only detect when you save the game. Trying to flush SRAM to an SD card is a bit hackish and would probably require relatively large capacitors to do reliably. Perhaps even approaching the size of a battery, which would defeat the purpose of getting rid of it in the first place.

1,541

(38 replies, posted in General Discussion)

Ok, the problems with GB flash cart design:
1) The size restriction. You only have a limited board area and only one side of the board is usable for components. (GG for a comparison has like the double board size available to it, and can also use both sides without problem.)
2) To a lesser degree power consumption of whatever you put on the board.
3) GB is 5 V whereas you'd need to go 3.3 V if you want a reliable stock of flash and RAM chips in reliable sizes. That means you need level shifters for the buses, or possibly a 5 V tolerant FPGA/CPLD as a bridge to the other chips. (Hard to come by these days...)
4) Games that use saving expect battery SRAM, which means you need a battery which takes up valuable board space, or more expensive FRAM or MRAM.

So far, there have been two designs around using USB.
1) The GBflasher design, used by Jose Torres and Smartboy. This design originally used a serial port programmer, but later added a USB serial chip and then moved it onto the cartridge board. It was a 5V design right through and worked well across all platforms. (Because of the FTDI drivers.) However, it was slightly overpriced for what it was and ultimately Jose Torres got caught with his pants down using this design, specifically not to be used commercially. So that cartridge won't be sold again, probably. Smartboy just disappeared from the surface of the earth.

2) The oh so beloved and hated EMS. EMS carts are using a custom flash controller, also used for some of EMS's other products like their N64 memory cards iirc. It's using a (I think) 5 V low-power FPGA, that they may have had to finalize the chip fab for themselves. (I looked into that long ago and as far as I remember, the producer of the FPGA sold this model of FPGA as wafers/dies.)

If it wasn't for its problems (power consumption, stuck page problem, proprietary drivers) it would be a decent cart. It's got enough memory to hold a lot of stuff and actually has multi-ROM capabilities. What this means is that each of the pages can be filled up to the memory size (with some limitations regarding ROM image alignment.) However, this has gotten a bit of a bad rap because it's known not to work well with LSDj in different ways. (LSDj is badly aligned by default and its SRAM management is not compatible with that of available menu ROMs.)

So, the future?
1) abrasive's drag'n'derp which features standard USB mass storage compatibility = works on all platforms. However, it keeps the creator is a heaps busy. Current status: The hardware design is mostly done but the software needs some touching up. Expected ETA: Early 2012.
2) krikzz' Everdrive GB. I asked him about this many months ago now and he said he hadn't started working on it. He may have started working on it now, but I haven't seen any sneak peeks or announcements about it. I'm suspecting he wants to leave it for last because of the difficulties mentioned above.

Title edited because of rule 12.

http://chipmusic.org/forums/topic/21/forum-rules/

1,543

(7 replies, posted in Software & Plug-ins)

Also, is it different fromwhen you listen from the speaker of the 'boy or headphones? Which kind of 'boy is it?

1,544

(7 replies, posted in Software & Plug-ins)

Better yet is not to use shitwave, so you don't fill up and clog the filter.

Seriously though, can I hear a recording where this happens?

1,545

(7 replies, posted in Software & Plug-ins)

Your soundcard probably has a shit filter. Shitwave sounds like shit, so it's only natural most of it would get filtered away.

Or nitpixling! yikes

I have more of a mathematical eye than an artistic one. My job is mostly nitpicking, not actually creating art. (Although I will keep the offer in mind.)

egr wrote:

Here's my contribution (couldn't decide how to "center" it):

egr: Sorry, but this logo has a couple of problems. (Call me a perfectionist if you will...)
Firstly, you didn't resize the original pixel logo by an even percentage, so the pixels aren't the same size. The third line from the bottom (the tongue of the G) is 11 pixels high but the other pixels are 10 pixels high. And different pixels are different widths. Resize both the width and height by integer values (500%, 600%, 1000%, but not 591% or something like that.)

The second problem is the jaggedness of the shadow which comes from the skew. The double pixels occur at every 6th or 7th pixel, which makes the shadow out of phase with the big pixel height. 45 degrees would obviously give a perfectly diagonal shadow. Of course, that's not what you want. But if you get the pixel ratio of the original logo right, you should be able to skew the shadow by exactly 41.99 degrees for a good result. (That gives you a ratio of 5/6 instead of 51/60 as it is now.)

Math is serious business!

Tinctu, what was their reason? That's ridiculous. Slovakia is in the EU now. You should be able to send inside the EU without problem. You should complain to someone!

Interesting project. A regular NES controller is read out by using a parallel in, serial out shift register. One button is read at a time. It also has support for 2-3 controllers on one port, each with a separate data line.There's a common clock line that clocks all the 2-3 controllers that may be connected to one port.

It seems from the chips on the board that this corresponding clock line is used to increment a 4017 decade counter. A decade counter is a type counter that sets one output pin high at a time, incrented by a clock signal. it can cycle through ten positions. Each position would then select a segment of the keyboard. This is what the 9 diodes are for. Each segment selector is connected to a segment of 8 keys. Those 8 keys are probably further broken down into 2 groups of 4, selectable by an output, so you're reading 4*9=36 keys at a time.

All of this might be possible to achieve using two controller ports on a NES. The NES controller port is a bit more crude than the Famicom one. Another option is to hook up the Famicom to an Arduino, and invent a serial communication protocol to be used over the NES controller port. Of course, this could expanded to work with a Gameboy or anything you like. BTW, if anyone wants to send me a Famicom keyboard for experimentation, I'd be happy to.

1,551

(9 replies, posted in Commodore Computers)

Yo!
http://gbdev.gg8.se/files/musictools/LSDj/Kits/

1,552

(12 replies, posted in General Discussion)

Shop's closed. Go make some music and come back next month.