nesdev.org

tokumaru wrote: It can't, really... it just has tools that help with copying/pasting square areas around. I still have to parse the images using my own scripts. First I recognize all the blocks in the image, generating a raw array for the map, then I encode that array to whatever format the game uses.

Oh ok. Basically it's just prototyping.

I personally wouldn't buy again from a company that never got back to me about a product I sent for repairs (not even to say they never got it). In this case, I'd get an Everdrive instead, it's cheaper and (as far as I can tell) just as good.

Of course I'd get another type of flash cart, not from RetroUSB which aren't reliable anymore (if they still exist at all).

You can manually type music data directly in the source, or use assembler macros to help you out with this.

That's what I do - use assembler macros.

What do you use then? I don't know of any chiptune-oriented programs that aren't tracker-based

PPMCK is not tracker based, but is not suited for games, as it uses too much RAM/CPU.

RetroUSB which aren't reliable anymore (if they still exist at all).

They're working on an 8-bit Christmas compilation cart with some features i'd describe best as deluxe. It seems a very active project with frequent updates. They updated about it 17 hours ago on facebook. Maybe your case dropped between things and they've forgotten to clean up unresolved tickets? I'd mail again.

FrankenGraphics, yes. I always forget to mention hex editor and hex calculators.

I use them on every project. Frequently.

I used a hex editor last week to...
1.trim some fat off the end of a DMC file, to save bytes
2.cut my CHR file in half, so I could assemble BG data in place of where CHR would be.

I used a hex calculator a few days ago to manually calculate the DMC start address.

($fa00 - $c000) >> 6 = $e8

(Edit, typed it wrong)

Quote:
I personally wouldn't buy again from a company that never got back to me about a product I sent for repairs (not even to say they never got it). In this case, I'd get an Everdrive instead, it's cheaper and (as far as I can tell) just as good.

Of course I'd get another type of flash cart, not from RetroUSB which aren't reliable anymore (if they still exist at all).

I have no complaints about my NES PowerPak, but the Everdrive N8 uses SD cards (vs compact flash for PowerPak), which will be easier / more convenient.

The N8 is also about $35 cheaper.

my main complaint about CF is that the swiss-army style external readers you can find in hardware stores and the like are so shoddy they virtually self destruct upon purchase

Notepad++, git, ca65, python (with PyQT), a bunch of tools I wrote using that python/PyQt combo, and FamiTracker. My artist uses Photoshop, and I use Paint.NET to rearrange things when they need to be. I sometimes try to convince her to use Paint.NET as well because Photoshop is kinda overkill, but meh. She's used to it. Haha

As for emulators I use FCEUX and Nestopia primarily, sometimes Nintendulator. Test on hardware with PowerPAK.

Bregalad wrote:

You can manually type music data directly in the source, or use assembler macros to help you out with this.

That's what I do - use assembler macros.

So basically like... a tracker?

I think this is a genuine way to make NES music, I'm sure a ton of original classic games had their music programmed like this, and you can customize the output to get around some of the limitations of existing engines using data converted from FT tracks. But I don't really see how this can be a more comfortable way to work with the music than Famitracker.

Sogona wrote:

Bregalad wrote:Actually I tired [FamiTracker] but didn't like it very much, the only advantage is that making "instruments" is simple and great, but making music is awful.

What do you use then? I don't know of any chiptune-oriented programs that aren't tracker-based

If you like LilyPond, PPMCK, or other MML tools, you'll love Pently. The score is written in an MML-like language that looks like this, though ft2pently is also available.

My main project is for the Game Boy, but is it alright if I chime in?

Computers: Mac Mini (desktop), Surface Book (laptop), MiST-based pseudo-"Amiga 3000" (since my real one bit the dust)
Keyboards: Unicomp Ultra Classic, Azio MK-Retro
OSes: NixOS, AmigaOS 2.1
Editor: Emacs (Linux), CygnusEd (Amiga)
Assembler: RGBDS (GBZ80), Devpac (68k)
C++ Compiler: GCC (Linux), SAS/C (Amiga)
Music: FamiTracker + command-line converter (C++)
Graphics: Custom Amiga editor (68k assembly), though I'm thinking of switching to DeluxePaint + converter
Level Editor: Custom Amiga editor (C)
Flash Cart: Everdrive GB
Game Boy: Fat DMG, modded with ProSound + backlight
Emulator/Debugger: BGB

??

You use a 68000 Amiga as a dev computer?

Ceased production in 1994. So, a 25 year old computer?

It's a FPGA clone

http://amigastore.eu/en/358-mist-13-plu ... puter.html

dougeff wrote:??

You use a 68000 Amiga as a dev computer?

Ceased production in 1994. So, a 25 year old computer?

It's only appropriate when developing for a 28 year old console!

Sometimes I wonder if the people here are a little bit genius, or a little bit mad.

Personally I would love to use my A4000 ( I just have the box and nothing else sadly ) for my C64/NES work. Its an 040 so, yeah it will be slower, but 64tass compiles on m68K so I don't need to change tools. Being able to draw something in DP-V on the one machine would make life easier. Seeing the images on a CRT while I draw them etc. Having the machine singular focus with no distractions would probably boost my productivity too. But sadly I wouldn't be able to run VICE to test with, but I could probably just put it on the Raspberry Pi and use the remote monitor to control it from the Amiga. I mean an 040 Amiga is probably overkill for such a task

Forget VICE, you could probably connect your Amiga to your C64