I Made a Sudoku Thing

http://www.smspower.org/forums/15481-Sudoku

Once again it's for the SMS. There's only like 5 puzzles in the game right now, but I plan on writing a program to generate somewhere around 700 of them.

Enjoy.

I didn't know you were a SMS guy. The system seems pretty cool to me and it has the advantage of having an R-Type port (not that it matters anymore though with MAME) but sprites not having flip bits and no vertical line per line scrolling kind of dampens it. Also, doesn't the SMS use vram? I imagine in several situations, the tile data would about be halved for flipped versions of existing graphics. I guess you could blast more tiles in, but I don't know how much bandwidth there is. Sorry about my random discussion.

I'm gonna take your little chunk one piece at a time. (Gonna ignore the MAME part, cuz I know nothing about that).


It's pretty much my main console. XD


Yup, I suppose so. At least mapped tiles can be flipped.



Yup, in fact the whole display is just a certain part of vram being "transposed" to the screen. Yes, flipped tiles means less space taken up, and thankfully the SMS supports them (just not with sprites).

It's just an emulator for arcade games. R-Type was originally an arcade game that utilized hardware from 1987, so it's going to look better than the SMS version, even though they play just about the same from what I've seen.


Aye. I didn't know a fourteen year old would be interested in something slightly obscure like that. (I'm not trying to be mean or anything.) Generally when people think of "8-bit consoles," they think about the NES, unless you had a SMS growing up from one of your relatives like I did for the SNES and Genesis. (The SNES was the only one I actually got though, and the same one is the one I play today. That's, not the case with the Genesis, as that got sold years ago...)


Yup, I suppose so. At least mapped tiles can be flipped.[/quote]
Interesting... Is the reason sprites can't be flipped because limited space in OAM? (Or sprite ram. basically whatever you want to call it.)
I assume it isn't so much to do with the video hardware not having enough power to do so. (I really don't have a clue how consoles handle sprite flipping.)


Yup, in fact the whole display is just a certain part of vram being "transposed" to the screen. Yes, flipped tiles means less space taken up, and thankfully the SMS supports them (just not with sprites).[/quote]
How fast can tiles be uploaded and replaced though?

The speed of tiles being copied into VRAM depends on how compressed they are. When uncompressed, it's very fast. You don't have to change the actual tile to flip it, though. Explanation is further below.

Now, I wasn't ever big on Sega until I tried getting into assembly programming. I found tutorials on the SMS before the NES, so I just rolled with it. Now I have an SMS and plan on saving up for a homebrew cart.

The reason sprites can't be flipped is because there isn't a byte in sprite ram to hold it, whereas on the display each tile has a modifier byte that lets you flip the tile, use the sprite palette, so on.

Actually, there is... it just goes unused. (the sprite table has a gap in the middle for no apparent reason) And even then there's the byte that has the "early clock" flag (I think it applies in mode 4?).

But yeah, sprites can't be flipped, background tiles can. This is the exact opposite of how the NES handles it. (this also meant that many Master System games preferred to render more stuff with background tiles)

This is usually not a problem for the main character, which normally has its patterns updated for each animation frame anyway, but this can be annoying for enemies.

On the NES it's possible to design a mapper with extended tile map attributes (à la MMC5) that can flip background tiles. That would be a fun feature in a homebrew mapper.

One of the biggest advantages the SMS has over the NES are the 16-color tiles, so graphics can look more colorful overall, even comparable to Genesis games, given a good artist (Deep Duck Trouble and Astérix and the Great Rescue for example are leagues ahead of anything the NES ever saw, in terms of graphics).

Another nice advantage the SMS has is priority control on the background tiles, not on the sprites. It may not allow for the complex masking tricks that are possible on the NES (which are limited anyway, because of the low sprites-per-scanline limit), it makes drawing foreground level elements much more practical.

Priority only on background tiles bites the SMS when the life bar drops behind the lava at 11:58.

Update, 0.2 is out. Now there's 127 puzzles, along with some other changes. Check the link in the first post or in my description to get it.

No, it's the exact opposite, because it means either the player sprites are stored twice (big problem because it makes the ROM bigger and you can't even afford to compress these sprites, and the player usually has many more unique sprites than enemies) or they have to be flipped on the fly before uploading (big problem because that eats a significant amount of precious CPU time). For enemies there isn't much of a problem, especially if you can afford to have frames where they don't have to be flipped.

Well, the player not being able to flip greatly affects rom, but not vram, unlike what enemies could if they stay in vram. It seems games like shmups would be best suited to the SMS's abilities, because there isn't nearly as much sprite flipping as their would be in just about any other type of game.

Flipping is one table lookup per byte. And if you're using real-time sprite scaling, you get flipping for free because you can bake flipping into a second set of scaling tables. Or is that sort of lookup hard on Z80?

You just make the artistic choice of having each angle looking different, like player is left handed and gun stays in that hand. That is something I do regardless of hardware so lack of sprite flipping never bothers me.

https://github.com/NicklausW/sudoku-sms

This post is fairly late, but I felt like pointing out that Sudoku is now also on GitHub, cuz why not.

I've been wanting to experiment with the NES, and have a small dev environment set up with asm6 but man, this is WAY different from what I'm used to. Something this is teaching me, however, is that when someone tells you it takes one assembly language to learn another (easily, that is,) they aren't lying.

Anyway, I've kinda figured out the differences between NESASM (I called it nesdev on accident XD) and asm6 syntax, so guess it's time to start on the (self-translated?) Nerdy Nights tutorials. Woot woot...

Man! We need more SNES people, dang it! I agree on learning another assembly language is a pain. I've tried to learn ARM, (but quickly quit... (I didn't like it at all.)) pre bulls*t x86, and MIPS (which doesn't look fun either...) and I have to say that I like 65xx assembly the best. I've never had much interest in the Z80 because nothing I've ever wanted to program for uses it and I hear it's slow as molasses. I can appreciate a processor that doesn't need a very high clock speed to get stuff done.

Z80 needs twice as many cycles as 6502, but it was also usually clocked twice as fast. The VTech CreatiVision had a 2 MHz 6502. The ColecoVision and Sega SG-1000 had a 3.6 MHz Z80 but were otherwise identical in specs to the CreatiVision, down to the same amount of RAM and the same video chip. The successor to the SG-1000, the Sega Master System, had the same 3.6 MHz Z80, which was comparable to the 1.8 MHz 6502 in the NES.

If you want to get technical, you can see why clock speed doesn't matter. The NES and Super NES both run at 21.5 MHz. They just have a divider in front of the CPU core. The original Super Game Boy also runs at 21.5 MHz, with a different divider on its CPU core to produce 4.3 MHz for the Z80-like Game Boy CPU.

I thought they were generally custom made?


Why?

You know, I've noticed that both the Z80 and the 68000 are both twice as slow for the given the same frequency as their 65xx counterparts. Were the 65xx series of processors abnormally good in this regard, or where the Z80 and the 68000 just bad? Another thing: I heard that in order to change clock speed, you need a higher frequency crystal or something. Now I don't know what that means and it kind of reminds me of the crystal in a light saber, but does it cost the same amount to make a 6502 faster as a Z80 in terms of clock speed?

Heat is usually a major limiting factor in choosing a CPU clock speed. I would imagine that they eventually managed to revise the chip to dissipate less heat at higher frequencies.

Another limiting factor is the delays inherent in how the circuitry works, though I think this has traditionally been a smaller factor than heat. It takes time for a transistor to switch from off to on. This can also be improved with progressively refined engineering.

I've never found the Master System to have a slow CPU, especially because of how big an interrupt routine you can fit into one frame. Speed isn't something I think you'd want to look for in 8-bit machines, anyway.

The thing doesn't generate one degree of heat! I always thought it was a cost problem. Why don't Sega arcade boards with multiple 12MHz 68000s have to worry about heat? If it's just heat, couldn't the Sega Genesis have ran faster, seeing that there were already a ton of other things with 12MHz 68000s that came out at the same time? The SNES's CPU doesn't even have a heat sink, and they're worrying about heat? I would have loved to see stronger PPUs.


I had always assumed the Z80 to be more than twice as slow as the 6502. I guess not.

As I said, that could be true, but it doesn't cause any problems or noticeable lack of speed, so.

Texas Instruments made a TI-99/4a computer. Later it made the computer's video display controller (TMS9918) available separately, and several other computers and video game consoles adopted it, including MSX, CreatiVision, ColecoVision, and SG-1000. The Master System uses a custom extended TMS9918, and we've discussed before how the NES PPU's architecture was inspired by the TMS9918's ability to run pixel-perfect Donkey Kong.


Because transistors don't switch instantly, especially when there are lots of them that switch based on the output of other transistors. Transistors that switch faster cost more; compare the price of modern Intel CPUs rated for different speeds. A divide by 12 circuit allows a core rated for 2 MHz operation to work with the 945/44 = 21.5 MHz crystal that the PPU's color generator needs.


Not "good" or "bad", just a different microarchitecture.


See Crystal oscillator on Wikipedia.

That is patently false. All CPUs generate heat.

The use of a heat sink is an engineering problem. Whether it's appropriate depends on how much difference it makes, how do you anchor it to the CPU, what's the added cost, etc. There's lots of situations where no practical heat sink is going to dissipate heat fast enough to make a worthwhile difference. You can't just add heat sinks until it's cool enough; it's not that simple.


People have overclocked all of these systems at some point. Look this up if you want to see how much faster they could adjust the clock speed before it reaches failure. It could be tempterature, it could be switching speed, or it could be other factors, but what you'll find invariably is that it can't really go that much faster, and is usually very limited by an overheating problem. They didn't just arbitrarily restrict the speed on you, they made it as fast as they practically could, always leaving an overhead to try to ensure it would be as reliable on a hot summer day as a cold winter night.

The exception to this rule is if a new revision of the CPU rated for higher speeds eventually becomes cheaper, later revisions of the unit might use these but be stuck at the original specified speed. (See the progression of the Nintendo DS for the opposite example of letting the specification be revised to keep up with technology.)

You did get to see stronger PPUs, you just had to wait for them to become practical. PS1 had a stronger one than SNES. XBox 360 had a stronger one than PS1. There's been progress in the technology. Why do you think we didn't have a PS4 in 1985? Do you really think it's just because somebody arbitrarily decided to run a CPU at 1/100th of the speed it was capable?

As further evidence, game-tech.us took a bunch of thermal camera pictures of the toploader many years ago:
http://www.game-tech.us/pmwiki/pmwiki.p ... ES-101Heat
TL;DR: The CPU and PPU will easily get to a 10-40F rise over ambient temperature.

That's really neat, lidnariq.

Well, I was talking about the console itself. One reason I guess it doesn't seem nearly as hot as things nowadays if you put your hand near the vents on it is that there's no fan to blow out the hot air. Of course, it doesn't get hot enough to need a fan. (I'm sure a fan would be pretty pricey too.)


From what I heard a little ago, that's what I thought. It didn't really make sense to me initially.

After some efforts I finally got a little skeleton file of my own, obviously based off of tokumaru's. I would use his but eh, for originality's sake. Or at least the sake of "disguised plagiarism"...eh, who cares.

Gotta say though, part of what was keeping me from the NES was the fact that I never could figure out what a CHR-ROM is. Now I know, but still, thought it was this random huge file you had to generate somehow.

Anyway, woot.

(Well, it's not on the SNES... CHR rom is tremendously more useful though. It's actually what the Neo Geo uses.)

Can you compress it, though? Uncompressed tiles on the Master System are a nightmare...dunno what the NES people have to deal with if they can't compress.

Throw more memory at it. If you're not planning on making this into a real life cartridge, the sky is the limit. And of course on the Neo Geo, they weren't concerned about memory in the slightest...



You can't always decompress graphics too, unless you want slowdown. One thing I wonder though: has there ever been a cartridge system that used vram that could be expanded in the cartridge? I know the NES has an ounce of VRAM, but it only really holds the pattern table? I just think CHR is the better option in terms of, basically anything but cost, (that's basically why every 80's-90's arcade board uses it, including the Neo Geo) and vram is only good for cost effective reasons. Again, vram wouldn't be a problem if you could expand it in any of these systems. I've talked about before how it seems that the SNES was originally supposed to have 128KB of vram, but I don't know if that's true or not.

You can use CHR-RAM instead, and it will be exactly like on the Master System. =)

Some emulators don't like mapper 0 ROMs to use CHR-RAM though, so you may have to go with mapper 2 (UNROM) or 34 (BNROM), even if you don't need more than 32KB of PRG-ROM.

Honestly though, CHR-ROM is easier to use most of the time. The tiles are just there for you to use, no need to copy/decompress them from PRG-ROM to VRAM.

You don't have to worry about finding slots for the objects (or sprites, in psychopathicteen and I's case) which takes away CPU time. You could always just animate the player by updating vram and nothing else, but then you wouldn't be able to store that much animation. Another thing that stinks about vram (on the SNES, at least) is that you can't update much every frame, only about 2.5 64x64 sprites due to bandwidth restrictions. I would much rather be able to change character positions for sprites than finding empty space in vram, uploading it, and then changing the character bits anyway.

But you can load multiple frames of an animation into video memory if needed...

Videomation and RacerMate Challenge II have more than 8K of CHR RAM.


There are plenty of effects that work best with CHR RAM. How would you do, say, a variable width font engine with CHR ROM?


Game description page from Action 53 prototype

Or stack more sprites than your video memory bandwidth normally allows, as in Hatris?



Or align game objects to areas smaller than one tile, as in Qix that ultimately runs on a 2x2 grid?


Qix, #67 in IGN's top 100 NES games

Or draw lines at arbitrary angles like in Elite?



Port Star Fox to Neo Geo and then tell me what Nintendon't. If the Super FX is cheating, port Wolfenstein 3D, Jurassic Park (for Super NES), or FaceBall 2000 (which runs on a Game Boy of all things).

(I might as well start a topic under NESDev called "nicklausw's stupid questions")

Uh, this might make me sound like an idiot, but I honestly can't figure out how .orgs work in asm6.

See, when I see ".org $c000", I expect to open up a hex editor and see the following data under $c000. It doesn't seem to work that way, though. At the beginning of the ROM I see:



Basically the ines header along with all my .org'ed code. And when I go to what's presumably $fffa (the end of the file,) I see stuff I had put there too, but at a very different location than $fffa.


In general, I don't really understand this. Is it just a NES-specific thing that asm6 simply works with? Or am I going insane?



Edit: later on you'll find I figured this out, but I'll post on this one what I didn't get.

In WLA, .org means to go to this point in ROM, minus the slot. With asm6 the first .org just does the equivalent of setting the slot in WLA. The location of the code output is the same.

But it's slow... Like I've said before, you're not going to see anything like this: (If you have enough CHR ROM, than it's fine. The problem then was that it cost too much, but that doesn't really matter now.)

(What the heck is going on with the picture? It was fine when I found it...)


That affect is way more limited than more overdraw though. You only have one palette and on the SNES, it has to fit in a 256x128 box. Again, there's not enough bandwidth either.


Well, you could make it using 65536 tiles.


I was actually thinking of something like the SNES having more vram through the cart. I don't know why they didn't set up the system to have something like that, but I guess you'd have to add another bus or something to go to the cartridge.


Well, you got me there... I don't really have a problem with vram, as long as there's a good amount of bandwidth, and the SNES doesn't really have that.

One thing I wonder though: How can sprites and tiles on the NES even take advantage of more tiles in CHR ROM if they don't have that many bits to select tiles?

That's because the NES maps the cartridge ROM at $8000-$FFFF (the upper half of the address space), so file offsets (what the hex editor shows you) don't match 1:1 with the CPU's address space.

Adding to that, there's the NES header, which changes the offset by 16 bytes.

Since the CPU sees the program at $8000, but in the file it starts at $10 (i.e. after the header), you have to add/subtract $7FF0 when converting between CPU space and file space. So if you want to see what will show up at CPU position $FFFA, look at offset $800A in the hex editor.

There's hardly any reason to do this though... it would be better to use FCEUX's built-in hex editor, which will show you the memory as the CPU sees it, so you don't have to convert addresses. It can also show other addressing spaces, such as the PPU, and even the ROM file, like an external hex editor would.

I can see where your confusion comes from, since the Master System maps cartridges starting from $0000 and ROM files have no headers. It's just a happy coincidence that file offsets match the CPU addresses though, since this choice was made because the Z80 has interrupt vectors at the beginning of the addressing space, while the 6502 has its vectors at the end.

You can composite to the background, which is what Hatris, Zoop, RHDE, and the Action 53 menu do. There's more than enough background memory for the whole screen even in 8bpp mode, so long as not everything moves every frame. In Hatris and Zoop, the field changes only when pieces are added or removed. In Action 53 and RHDE, only one line of text changes in each frame.


Bank switching. A mapper circuit on the cartridge controls the CHR ROM's upper address lines based on values selected by the CPU.

For example, the FME-7, a mapper chip used in later Sunsoft games, divides CHR ROM into 1024 byte banks, and it divides the pattern table address space into 1024-byte windows ($0000-$03FF, $0400-$07FF, ..., $1C00-$1FFF). The mapper lets the CPU select a bank of ROM for each window. When the PPU reads the pattern table, looks at PPU A12-A10 to see which window is being read, and it looks up the appropriate bank number to output on CHR ROM A17-A10.

Example with actual numbers: FME-7 register 5 is the CHR ROM bank number for PPU $1400-$17FF. Bank 19 of CHR ROM is $04C00-$04FFF. The CPU writes a value of 19 to register 5. Then whenever the mapper detects that the PPU is accessing $1400-$17FF (PPU A13-A10 = 0101), the FME-7 outputs 19 (CHR ROM A17-A10 = 00010011), thereby redirecting the access to CHR ROM bank 19.

PRG ROM in excess of 32 KiB needs to be bankswitched as well. The NES, SMS, or Game Boy CPU writes to a mapper register to control upper address lines of the PRG ROM, which makes different parts of the program appear to the CPU.

So you can only use one bank per frame? You can't do something like fill the entire screen with unique tiles?

About the 8bpp frame buffer thing, I generally wanted to use the whole screen because I wanted multiple layers of parallax and a bunch of sprites. I've learned that what I had in mind wasn't possible without it running at 20fps and letterboxing it a ton. (I'd also need a good expansion chip for plotting the pixels.) I wouldn't mid the SNES's capabilities if it had more overdraw. I've never been pleased with BG 3 either, but I have to understand that it's a console that was released in 1990/1991 and was developed in 1986.

Thanks, that makes sense. And you're right, I'm used to handling ROMs that are basically exact copies of what'd be on the cartridge (no rom header) and mapped right at the origin.

Older mappers swap the entire 8KB of CHR-ROM as a single block, but newer mappers divide that space in areas as small as 1KB (64 tiles), so you have 8 banks mapped at any given time.


You can if you use scanline IRQs to bankswitch mid-screen.

Smash TV uses the MMC1 mapper. Its title screen uses several banks of CHR ROM, switching banks between one scanline and the next.

Super Mario Bros. 3 uses the MMC3 mapper. It switches CHR banks between the playfield and the status bar. Cosmic Epsilon also uses the MMC3 mapper. It switches banks after every scanline to draw a texture-mapped 3D road.

Pirates and Marble Madness switch banks mid-scanline using very precisely timed code. Mike Tyson's Punch-Out!!, Fire Emblem, and Famicom Wars use the MMC2 and MMC4 mappers, which treat the pattern table addresses associated with "magic" tile numbers $FD and $FE as triggers to perform mid-scanline bank switches.

Um no, it's the exact opposite since you load it once during loading time then leave it there. The problem is that it eats up more memory than needed (which also tends to result in dumbed down animations to compensate), so it's a matter of whether you have enough spare memory to keep the graphics around.

Well, it is a problem if you're constantly updating the graphics because they won't all fit in vram like DKC.

Okay, one more question: in this case, does asm6 have a default base targeting the NES mapper?

I'm not sure I understand the question, but ASM6 is completely unaware of NES mappers. It's your responsibility to arrange the banks and .org/.base the addresses correctly for the mapper you're using. Are you having some trouble with that?

Cuz I mean, you say that the NES is mapped so that $c000 is right after the header at the beginning (a nes thing) yet asm6 is compatible with anything 6502.

Since the header is just metadata prepended to the ROM file, it's not really part of the addressing space in any way. Back when I got started with NES development people didn't even define the header in the source code, they just merged a 16-byte binary file created in an hex editor with the ROM after assembly.

Now it's more common to define the header in the source code, but the assembler doesn't really know what that data is, it just puts the bytes you tell it to in the beginning of the file.


Yes.

From what I understand, ASM6 will start outputting data to the file as soon as it finds commands that generate output, and the first .ORG or .BASE will set the program counter so that the addresses of labels can be calculated. Subsequent .ORGs will output filler bytes until the specified address is reached, since the current address is known. Subsequent .BASEs will simply redefine the PC, without generating output, which is useful for creating new banks, because you want to continue appending data to the file but the PC has to be changed back to what it should be at the beginning of a bank.

If you're unsure about how to generate ROMs with a certain structure, let me know exactly what you're trying to do and I'll see if I can help. Are you targeting a mapper other than NROM? What exactly isn't working as you expected?

...oh my god, it makes sense. I think.

So unlike WLA DX, .org doesn't go to a certain area in the source, it's just for address calculation? FINALLY I get it.