nesdev.com

Thought I'd split this from the compo thread:

I looked at the POST screens of Award and AMI BIOS and came up with this mockup of an NES POST screen.

• I added color fringes using snes_ntsc to prove that my 4x8 pixel font remains readable on a TV.
• CPU and PPU will be filled in from TV system detection.
• RAM will be either 2K or 10K; VRAM will be either 10K or 34K.
• Controller detection based on this.

And now the question: Anyone know the part numbers in a Dendy, or whether the RGB PPU has any behaviors that allow it to be distinguished from the NTSC one?

Will there also be a memory test on every cold boot?

And, if there is, will there be a way to skip the memory test? (One of my old computers runs a memory test that takes about a minute every time it cold-boots. It cannot be skipped.)

There are many parts, not all of them actually had numbers. This list is incomplete:

2A03 direct replacements: UA6527P, TA-03NP1 (the same, additionally marked 6527P)
PPU direct replacements: UM6538
Dendy-On-Chip (not a gloptop): UM6561A
2K SRAM: UM6516

Thanks. I'll use the "direct replacement" set in my POST simulator. Now what should I list as the manufacturer instead of Ricoh?

Joe: It won't take anywhere near a whole minute to test the small amount of RAM the NES has. It'd be shorter than the Mega Man X intro. Mostly it's an excuse to display the copyright notice, detected region, and detected controllers, and to give the player some time to start serial boot. Think of it as analogous to the intro animation on a Game Boy Color or Game Boy Advance system, which gives the player a chance to change the constant color of a monochrome game (GBC) or enter serial boot (GBA).

The chips with the part number starting from U are labeled as UMC (a picture). The TA-marked chips does not have any manufacturer logo.

Well, heck! Why not take it all the way? Make this a "BIOS" like the Intellivision with handy routines. Make it so NBIOS binaries can simply be appended to the NBIOS.NES ROM and automatically launch them after the self test.

I could discuss adding an actual BIOS inspired by Monitor (Apple II), KERNAL (Commodore 64), Executive (Intellivision), BIOS (IBM PC), BIOS (ColecoVision), and BIOS (FDS). But I'm reluctant to do that at the moment for at least two reasons:

• I anticipate a crapton of bikeshedding when discussing what to include. For example, for decompression alone, should it include PackBits RLE? GBA-style RLE? PCX-style RLE? DAN0 (RLE feeding LRU)? Some LZ77 variant? BPE? Huffword (which is especially efficient for RPG dialogue)? Pixel-level Markov coding a la Codemasters? Should the decompressors decompress directly to $2007, to a fixed RAM location, or to an arbitrary destination in RAM? And what kind of sound engine would be included?
• Adding a BIOS would involve reserving a bunch of ROM and RAM for the BIOS's use, much as parts of RAM have predefined uses in the Apple II. That'll become easier once INL gets that FDS-style board with SPI flash and a bunch of RAM working.

Which leaves open the question of how to detect RGB PPUs (PlayChoice, FC Titler, Sharp TV, RGB-modded NES) programmatically.

What is the technical advantage of a NES BIOS over a statically-linked library (with function-level linking, so you only pay for what you all)? For a multi-cart, it might reduce the ROM size slightly, but a smart compressor could probably find the common occurrences of any shared routines among entries. That's all I come up with. The disadvantages just write themselves: effort in designing it, API stability, routines not used for a particular cart, efficiency, rigid use of resources (globals, ROM location), little benefit over static linking, copyright issues, bugs and different versions, lack of customization. And on and on.

Are you really going to name chips? With the multitude of famiclones out there you are bound to state untruths in your POST screen. Maybe if you added "(or compatible)" after the chip names it wouldn't feel so wrong.

The same goes for frequencies. Can you reliably measure the CPU frequency with code or will you display wrong information to the people who have overclocked their consoles?

You could replace the "CPU" and "PPU" lines with "System Type" or something like that. Also, for input devices, you could add a line for the Famicom expansion port, even if the compo menu doesn't support all input devices, it would be a thing to include in such a screen. (Some devices act same as on the second NES port. Such things can be listed on the second port, and the line for the expansion port displayed if it is something that isn't acting the same as the second NES port; for example, the Family BASIC Keyboard.)

You probably do not need an actual BIOS, or to reserve any RAM for it. However, some functions might be useful to have in such a BIOS simply for the serial boot feature; such as, to load CHR RAM, and to load serial data, and to display text (all of which would already be used by the POST screen); in such case as that, you might be reserving RAM, only for programs that use the BIOS, though. You shouldn't include too many things, though.

You can omit any BIOS functions which aren't used by the POST screen.

_________________
.

A cart with SPI flash needs a BIOS (or at least some sort of IPL) for the same reason the FDS and PowerPak do: the CPU doesn't know how to read it by itself.

I can't measure the CPU frequency precisely without a separate reference oscillator on the cart (such as NSF's 1.00 MHz oscillator feeding a PIT). But I do know that the PPU is generating about 15700 lines per second, or TVs can't sync to it. This means I can approximate the CPU speed to within plus or minus a percent by counting cycles from 9 sprites on line 0 to sprite 0 hit on line 239. Measuring vblank and post-render (count from NMI to 9 sprites and next NMI respectively) identifies the TV system class (NTSC, PAL NES, or Dendy).

"Or compatible" is to be assumed. If I'm emulating, say, an original IBM PC on my laptop, it'll say it's running on an 8088 when it's actually an Atom N450. Or if I'm emulating an NES on a Game Boy Advance, it'll say it's running on a 2A03 when it's actually an ARM7TDMI SoC. I doubt that anyone who OCs an NES will get annoyed by "lies" any more than the Mega Man X intro "lies" about the Super NES's hardware.

I'd include the Famicom expansion port if I could test it. But all I have is my NES. Yeah, yeah, I can't test OC'd NES, PAL NES, or PAL famiclones either. But at least I can test that the basic assumptions lead to correct results on my NTSC NES, and I feel more confident in mature emulators' handling of PAL NES and PAL famiclone timing than in their handling of the open bus edge cases needed to reliably detect controllers.

Is this a homebrew?
If so how can I use it?
I am looking for a homebrew that shows console info such as cpu speed and region and other info about the console.
Thanks in advance.

I won't do any more work on this until April. I have another project due by the end of March.

I'm not sure how useful this would be for the NES and its software currently, but it would make a neato possible computer permutation using NES hardware.

_________________
Be whatever the situation demands.

I think the boot up screen looks nice for the first screen in the coming up volume of action 53, and the stats displayed are interesting. I agree on avoiding providing BIOS calls to user programs.