nesdev.com

That is my Question?

Basically are people happy with an FDS release, I presume nobody can actually put the data on a disc to play on the console? But emulators support it fine?

I'm making a port of Squid Jump for the C64 and I figured I would port it to the NES as a "Hi", I originally though the port would be easy, the NES would make the issues I have on the C64 "go away" but looking at the NES it going to be a lot harder to pull off. I even though of janking it and going SNES but the game is too simple for the SNES. The FDS has some nice properties which would aid the port I feel, but is it going to annoy people that its on a FDS and there is no hardware support?

What does the FDS offer that a cartridge with CHR RAM doesn't?

PRG RAM and 32K of it

There is nothing stopping you from putting 32k of RAM on a cart.

The FDS is something pretty much only collectors would have.

Is the game you're porting the one that's a minigame in Splatoon? If so, I don't see what you need 32KB of RAM for, since the levels aren't destructible...

Yes the Splatoon one.

Well the water does destroy. So having the map in RAM and just letting the water march over makes life easy, not the only way, not necessary. But that is not the issue.

VBlank is tight(especially on NTSC). And I have to do the white octopus platforms in chars, so each ones has 5 chars that need to be updated, and then 3-12 + 1 erase positions on the Screen every 8th pixel they move. Of which there maybe 3 on screen at a time. Then the water needs to animate so there is another couple of chars to copy, then you have the conveyor belt type platforms which also need to animate, they can be done in 1 char. There is 2 directions so that is 2 chars to update. Plus adding 1 or 2 rows for the scroll with possibly also 2 rows to plot for the water depending on how fast it is going. Plus update OAM and I starting to get the impression I'm going to be
HI VBLANK... BYE VBLANK... COME BACKKKKKK

So that is 15+2+2 chars, and then 39+48+48 screen positions(main level width is probably going to be 24 chars wide), and then 4 sprites to update potentially.
Each pickup is 4 chars, and if you collect one of those then it will add another 4 screen positions to update.

To which speed code generators will help me ease the VBlank pressure. But Speed Code eat RAM.
Also coding in RAM is nicer than coding in ROM.

I could be worrying over nothing, I've not got to the point of putting it into code to see just how much I can pump through in VBlank, but what I have been reading on this forum is not filling me with much hope I'm just evaluating options at the moment

Side note N8/Everdrive does support FDS roms ^_^

If there is destruction but not scrolling, the built-in RAM should be enough. RHDE: Furniture Fight has a 28x24-cell playfield, to which it devotes $300-$5FF.

I think homebrewing for FDS is fine. Using on real hardware should be possibly with Tape Dump. Even if it's not it can run with flash carts on real hardware. However I'd still add a cartridge version. SOROM and SXROM supports 16k and 32k of WRAM respectively, but it's bankswitched.

The levels are very tall, 32 screens +

You're thinking like a C64 programmer and that is blinding you to the best ways of doing things on the NES. The C64 and the NES are both 6502 machines with sprite-and-tilemap graphics, but they have very different strengths and limitations which lead to different programming approaches.

The pickups would be better done as sprites rather than painting them onto the BG. You've got 64 sprites to play with, might as well use more than 4 of them.

The best way to do the rising water would be to stick it in the second nametable (using vertical or one-screen mirroring). Every frame, check whether the surface of the water is onscreen and if it is, set up a sprite 0 hit or a raster IRQ to switch over at the appropriate scanline. Look at some commercial NES games with an "outrun the rising water" gimmick (e.g. Super Mario Bros 3, Castlevania 3) and see how they do it.

Animating the water, conveyor belts and moving platforms can be done via CHR ROM bank flipping. Then you only have to update the ends of each moving platform in the nametable when its position reaches a multiple of 8 pixels.

You can and people do it all the time. I advice against it though, because home-written disks usually only work on the disk drive you wrote it on.

But FDS homebrew is no problem nowdays when there's the FDSStick and similar devices. You only need the RAM Adapter and the FDSStick and then you can play the disk image on the console like it was a real disk.

@AWJ
Sprites will also be used for the fixed HUD on the side, of which 2 for player + 6 for Score = 8. So that basically pushes me into using chars for the pick-ups. On the C64 they are spites as are the octopus platforms HUD too In my original idea having 64 sprites should make this easy silly me...

I though about keeping the HUD in chars and doing the shifts and plots to keep it stable allowing me to keep pick-ups and moving platforms in sprites, but as the moving platforms can't be done in sprites and have to be chars, it makes sense to me to switch the HUD to sprites and put the pick-ups into chars while I'm at it. As then their scrolling will be "for free"

Doing a split for the water is probably how I will end up doing it, but if possible it would be nice to get the chars plotting in so the water can slowly eat the char rather than having the fixed cut off where what is behind doesn't show through.

Doing the CHR-ROM flips means every single platform has to be on the same X offset, or at least you have the X offset going left and X offset going right, which means you can't really have platforms that move at different speeds, well you can, but they you are using silly amounts of ROM. Then you can't have fast platforms and slow conveyor platforms. There is probably a 24 or so levels of flipping that could be worked out to hold all the possible combinations a screen needs in the ROM, but they are what 4K a bank? 96K of CHR ROM for the chars??? Although doing it this way would mean I can store the HUD chars at the 8 Y scroll offsets, getting more sprites back for the pick-ups,moving platform caps etc but then I have to plot the HUD chars as I move up and down which would probably eat more time in VBlank then removing the pick-ups when collected. But some mappers have 1K granularity right? That might make it more practical... hmm
edit another thought, is I should be able to fit all the chars with shifts into 1 set ( Table being the NES name? ) to which if I go the IRQ split and negate the pixel perfect water, would drop the problem to Screen map transfers only.

Thank you for the input, if you have more, or I've missed the boat, please share

So the big hang up is putting the score at far right. Pogo Cats (topic; video) avoided all this by putting the score at the top.

Doing a score, timer, lives, level + hi at the top of the screen. While not "original" doesn't really solve much. Ok I get the pick-ups into sprites rather than chars(worth noting the pick-ups don't animate in anyway or move), so on that very rare occurrence I don't have to update 4 screen positions, but I have to shift their sprites Y every time, its a neither here nor there issue. Pickups are not that common in the game there might be 10 per level max.

The main issue is getting enough char updates and screen updates to cover a rapid scrolling screen + 3 moving platforms + 2 animating chars for other platforms + animating and moving water. Where the vertical movement of the water could as pointed out by AWJ be a raster split.

I'm not sure what "animating and moving water" would take. But assuming the "2 animated tiles" can update at 30 fps, the rest is 6 transactions copying 92 bytes:

• 32-byte copy: Vertical scroll seam at 8 px/frame (2 screen heights per second)
• 8-byte copy: Attributes for said seam
• 3 x 12-byte copy: 3 moving platforms
• 16-byte copy: 1 of 2 animated tiles, alternating

The fastest variant of the Popslide blitter uses 3 bytes and an estimated 50 cycles per copy transaction, plus 1 byte and 8 cycles per copied byte. Thus it'd take 92+3*6 = 110 bytes of page $01 and 8*92+50*6 = 1036 cycles to update VRAM. Add 526 cycles to copy the sprite list to OAM, and you're still well within 2270 cycles of NTSC vblank.

A raster split with highly variable vertical position is doable but tricky on a discrete mapper, particularly if you need the DMC free for sampled drums or bass. Without an interval timer to interrupt the CPU at the split point, you end up estimating the worst-case execution time in scanlines of every subroutine, running those that fit before the wait for sprite 0, and running everything else afterward.

Verdict: It can be done without FDS.