I am an experienced software engineer with some 6502 experience, and I recently completed an Atari VCS game of Dodgeball, which can be found here: http://github.com/tschak909/dodgeball/ .. Have been a member of AtariAge since 2006 (and the Stella mailing lists since 1998), but this is my first venture into the NES homebrew community.

I initially was going to try doing WoW for the ColecoVision, but it turned out that Opcode had beaten me to the punch .. So... Didn't see one for the NES...and thought, why not?

I will be writing the primary game code in CC65, but for now, my concentration is on trying to make the graphics as accurate as possible. This is a challenge for me, as the original Astrocade based display runs at a different color clock, and therefore aspect ratio. (352x240) (As it happens, there are +2 more pixels in the horizontal direction, basically. so things need to be squeezed..also since I am targeting this for NTSC, there is less vertical space available.)

I've managed to take enough of a pass at the graphics to start laying out nametables so I can get an idea of scale (these static nametables won't be used as such, but hopefully will be generated programmatically).

I have been proceeding glacially at this for the last few weeks, but I am trying to be slow, patient, and precise. So i'll be working on the graphics for a while, until I can balance out accuracy for constraints... once I'm sure I can get everything squeezed in well enough, I'll start coding.

The target for this guy is an NROM-256. If I can do it smaller...great. I don't see a need to do a mapper.

Anyway, back to it. I hope all the American users have a good 4th of July.

-Thom

(edit: images were obnoxiously large due to my hi-dpi display. Turned them into URLs to be polite.)

Last edited by tschak909 on Mon Jul 10, 2017 10:18 am, edited 1 time in total.

Hey and welcome, that's cool. I like that game, I always play it whenever I find it somewhere. Something is neat about games on that old Bally hardware, I might have ported Space Zap if I hadn't had so many projects already. And that one is a lot simpler than Wizard of Wor.

I was just looking at the sample set from MAME, I don't know how deep into the audio you'd want to get, but it looks like that entire sample set, if it was encoded as DPCM @ ~22khz should fit into one of my GTROM boards. That's the basic-level board I make instead of NROM. I also have made a phoneme-based speech synth, that fits in 16kB. Anyways I'm just rambling, I'm just as fine seeing it ported in any form.

Last year I was working on a song in Famitracker and part of it reminded me of Wizard of Wor, so at the time I went ahead and did a little version of it. Attached it here just for fun.

Hey and welcome, that's cool. I like that game, I always play it whenever I find it somewhere. Something is neat about games on that old Bally hardware, I might have ported Space Zap if I hadn't had so many projects already. And that one is a lot simpler than Wizard of Wor.

I was just looking at the sample set from MAME, I don't know how deep into the audio you'd want to get, but it looks like that entire sample set, if it was encoded as DPCM @ ~22khz should fit into one of my GTROM boards. That's the basic-level board I make instead of NROM. I also have made a phoneme-based speech synth, that fits in 16kB. Anyways I'm just rambling, I'm just as fine seeing it ported in any form.

Last year I was working on a song in Famitracker and part of it reminded me of Wizard of Wor, so at the time I went ahead and did a little version of it. Attached it here just for fun.

Wow, The music is awesome!

As for the PCB, what's the big difference between the NROM and GTROM? I do intend completely to do the voice bits..given that the votrax SC-01 sounds have very limited spectra, you could get away with a ridiculously low sample rate and it be intelligible.

Nukey Shay over at AtariAge pointed me to this blog, which has everything from the theory of operation manual, to level layouts (the theory of operation describes the level structure as an 11x6 grid of squares with 4 possible openings (that'll make the level data structure REALLY easy, I think) so I can hopefully do the levels programmatically.

I am currently trying to figure out whether I can actually fit the original level structures into the slightly smaller screen on the NES, versus the Astrocade hardware.

The levels in Wizard of Wor are actually created from a symmetrical pattern that is based on a grid of 11 horizontal squares, and 6 vertical squares, of which there can either be a wall or an opening on either side. I can represent this just fine with a data structure, and with the 2x3 metasprites I am using (to be as true to the game as possible) I can't make this fit...

Does anyone see a way, from these pictures or my description that I could make something that could fit? or should I just make my own level patterns?

(would anyone really give a #%()#@ if I used different maze patterns? I'd rather not, because I want to be as accurate as possible, but I do understand when brick walls are hit.)

Each dungeon consists of an eleven by six matrix of squares, with a wall or opening on the sides of each square. The maze is symmetrical around the center vertical axis. Every maze has a side escape door located four squares up from the bottom, and on each side of the maze.

Based on the screenshots on the game's KLOV page, the original game's cells are 24x24 pixels. It runs on a board whose pixel clock appears to be 7.16 MHz according to MAME's astrocde driver. This makes its pixel aspect ratio 6:7, which is narrower than the 8:7 of an NES. A PAR-accurate scaling to ColecoVision/NES pixels would result in 18x24 pixel cells, or 2 1/4 by 3 tiles per cell.

Here are your practical options to make it fit:

Each cell is 16x24 pixels or 2x3 tiles, and the 11x6-cell playfield is 176 by 144 pixels.

Each cell is 20x24 pixels or 2.5x3 tiles, and the 11x6-cell playfield is 220 by 144 pixels.This requires separate tiles for walls being in the left or right half of each cell. It also pushes the column of figures to the left and right side of the playfield into the overscan area, but it's fine if you're willing to move the figures below the playfield, as is done in CBS's Atari 2600 port of WOW.

And you might end up needing to draw new level maps anyway, as level maps and sprite graphics are the first thing that copyright lawyers would seize on.

I'm working on illustrations of what 16x24 and 20x24 pixel cels would look like inside the 256x240 pixel picture.

Nice arena…though it doesn't fit the original constraint of "horizontally symmetrical", alas.

18x24 is still doable, it just costs twice the CHR space of that 20 [or uses different circuitry; might be interesting to see a board HW-render the maze fed to it instead of using actual tile-layout logic…no, that'd still be extra, thanks to the 8-pixel buffer in the renderer. Of course, you don't want to use a mapper, so this is academic.]

Also, isn't it correct that on NTSC PPU's the bottom two rows in the name table won't be visible (making what would be a 240 pixel output, essentially 224 pixels?) ... that makes the NES very much like traditional arcade hardware.

The NTSC NES PPU outputs all 240 scanlines. Some just get cut off by the TV because of overscan.

In an arcade game, the arcade operator enters service mode, which displays various test patterns on the display, and adjusts the monitor's size and position controls to make the picture exactly fill the monitor. But in a game for a console, the developer has to put up with the picture size that the TV actually displays, and this varies from one SDTV to another. You can't change how much is cut off, but you can use scrolling to determine whether it's cut off at the top or bottom or a little of both.

There are various "safe area" definitions that approximate upper and lower bounds on the overscan size for typical TVs. See "Overscan" on the wiki for these.

Seems like the 2x3 tile size may not allow for players going the vertical directions (in the arcade game, the player and enemy blitter objects are simply flipped center-axis)...

Still experimenting... no matter what, I should have enough CHR-ROM space to have tile variations...

...i think.

(I do know I will have enough sprites, there are no more than 6 enemies active per whole dungeon, 36 sprites total, 48 sprites with the two active player sprites, leaving 16 sprites.. I can definitely get away with using tiles for the phasor cannon.)....

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum