Recently I've been reading
Agner Fog's message board where he and others discuss creating an open source instruction set. It's interesting stuff, so if you have 30 minutes you might want to check it out.
Anyway, this got me thinking:
What would it look like if NesDev designed an imaginary 8-bit video game system? We could come up with our own design for a CPU, PPU, and APU, and have fun discussing the options.
So let's try it!
Let's start out with some basic specs:
- 4KB RAM
- 8-bit CPU
- 16-bit address space
For the PPU, I'm thinking a window size of 256x224 with nametables of size 256x240 would be good. This gives 16 extra VBLANK scanlines vs the NES, and allows 4-way scrolling to hide tile updates in the off-screen section.
For the CPU's instruction set, I think it's important that it be compatible with C, as that would make the system much more accessible. I don't know what the ISA should look like, however.
What do you think?
Three words:
Turbo
Grafx
Sixteen
I had a design for PPU that had its own instructions that it could execute during hblank/vblank (and the program always restarts from the beginning during each vblank), and then the PPU is clock-interleaved with the CPU, so that they can share memory without conflicting.
My ideas for another computer it had the "video instruction set" as follows:
- 0: JMP: Jump to the operand's address. (If the operand is immediate, treats it as an instruction.)
- 1: WAI: Same as JMP but wait for the next hblank before continuing.
- 2: ROL: Rotate left operand value through carry, and store result in A.
- 3: ROR: Rotate right operand value through carry, and store result in A.
- 4: ADC: Add operand value with carry to A.
- 5: CMC: Complement carry flag; operand is read but ignored.
- 6: SBC: Subtract operand value with carry from A.
- 7: CMP: Subtract operand value from A (without carry); update carry flag but do not update A.
- 8: AND: Bitwise AND operand with A and store in A.
- 9: ORA: Bitwise OR operand with A and store in A.
- 10: EOR: Bitwise XOR operand with A and store in A.
- 11: SAR: Write value from A into video register specified by operand. (This includes the playfield address, palette, modes, and other stuff.)
- 12: LDA: Load operand value into A.
- 13: LDB: Load operand value into B.
- 14: STA: Store A into operand. (You can write to an immediate value.)
- 15: STB: Store B into operand.
The video instruction set also has one flag (carry), two 8-bit accumulator registers (A and B), and each instruction also has an addressing mode (A, B, 8-bit immediate, or 16-bit absolute), and a condition code (never, if carry clear, if carry set, or always). Note also that this enables tile height to be any number, because it is programmed by software.
Note that the CPU would have its own instruction set, not the above.
For audio, there is some kind of ideas. You could have different channels that act differently, and maybe even some like SID, some like GameBoy, etc. One idea I had is you could have a "IDFX" channel. There are four 4-bit numbers, called I, D, F, X (in addition to the period, which is separate). If the phase is p, and output volume is v (0 to 15), then (as a C code):
v=(((p&I)^(p<D?15:0))&F)^XYou could also have additional RAM in the cartridge if 4K is insufficient, like it can be on NES/Famicom.
I also think there should be both keyboard and game controls, and possibly even Forth built-in that can be executed when no cartridge is present (you may then save the program on a tape, if you want to keep it; usually you would use ROM cartridges though; the Forth is just something extra).
You may vary these things; all of the above are just ideas, and you can do differently if you want to do.
... Good for C? On an 8-bitter? Er.
Just how much cheating is allowed?
Can I choose a 16-bit machine that's contemporary? (CP1600) Can I choose an 8-ish-bit machine that's substantially later? (AVR;1996) How about a 16-bit ISA that's older than the AVR? (MSP430;1993) ... How about a 32-bit ISA that's substantially older? (MIPS or ARM; 1985, both with prototypes back to 1980)
Honestly, if I wanted to make something "Like the NES, but less bad for C" I'd end up very close to the SMS.
I've been doing this in my head for ages. So many silly ideas, so little time. I even wrote an emulator for my APU design, the FRA1, though I'm still not convinced it would actually work in period-accurate silicon.
@zzo38: This is an interesting idea!
lidnariq wrote:
Can I choose a 16-bit machine that's contemporary? (CP1600) Can I choose an 8-ish-bit machine that's substantially later? (AVR;1996) How about a 16-bit ISA that's older than the AVR? (MSP430;1993) ... How about a 32-bit ISA that's substantially older? (MIPS or ARM; 1985, both with prototypes back to 1980)
The three guidelines are:
- Possible to be manufactured using 1985 fabrication methods
- Fit what people imagine when they think "1985 game console"
- Be decently cost effective
IMO 32-bit CPUs are out of the question because that's not how gamers remember the era.
You can use modern instruction sets if they're not
too complicated, though honestly, when I started this thread I was hoping people would come up with their own wacky instruction sets instead of using existing ones - not because they would be better, but because I think it's fun to start from scratch
Quote:
I've been doing this in my head for ages. So many silly ideas, so little time. I even wrote an emulator for my APU design, the FRA1, though I'm still not convinced it would actually work in period-accurate silicon.
Have you published anything about it?
Writing a C backend is not for the faint of heart. Something like LLVM is designed for 32bit machines with a bunch of identical registers, no flags, automatic sign/zero extension, flat addressing space and [register+offset] addressing and so forth.
Is there a limit on number of registers? That's pretty detrimental to the whole C thing important in terms of making the CPU C-friendly, for better wording.
nicklausw wrote:
Is there a limit on number of registers? That's pretty detrimental to the whole C thing.
It depends on how registers are accessed. In 1985, arcade games had started using FM chips like the OPM and OPN and OPL, and those have over 200 bytes of registers which is pretty massive for the time. This is because they're all large shift registers that are always accessed in the same sequence and constantly get refreshed, which makes them very efficient to implement. (this is also why the tg16's audio chip works the way it does)
50Mhz 4510 CPU
128K-512K RAM
Graphics chip with sprites, bitmap and char mode. Should be 256 colours per each, so 256 colour sprites, 256 colour chars
1080p graphics with modern output HDMI/DP etc
DMA engine
Blitter
so basically just a MEGA65
http://c65gs.blogspot.com.au/http://mega65.org/
pubby wrote:
Have you published anything about it?
Not yet. It's a 4-bit wavetable chip similar to the N163 or PCE, but designed to stream samples from external memory by stealing a few bytes from each scanline of the PPU's fetch pattern. Other than what's involved in doing that, avoiding aliasing and a neat little sample compression trick, there's not really much to it.
Here's a demo rendering, using my crappy homemade samples and a random MIDI. 6 MHz host clock, 6 channels and 128-byte samples (I think only 4 of them are actually used in this clip, so that's 512 bytes total).
I love the 6502, but if I could improve anything about it, I'd expand the support for addressing modes (indirect addressing using the X register, for example), and maybe add another index and possibly even another accumulator. I don't really care about C, coding in assembly is more fun!
pubby wrote:
nametables of size 256x240
Oh, come on! Why can't we go for nice power-of-2 dimensions to make scrolling easier? Getting the attribute tables out of the way already helps a lot with vertical scrolling even if name tables are 240 pixels tall, but 256 pixels would make things much cleaner overall, and even provide some extra room for the scroll seam (useful for 32x32-pixel metatiles maybe?).
Other than that, I find the idea of 3bpp graphics really interesting, that combined with a decent number of palettes (maybe 8, shared between sprites and the background) could produce really nice graphics. A larger, more consistent master palette than what the NES has would be very welcome. Other PPU features I'd want are more sprites per scanline (16 would probably be OK, but the more the better) and a built-in scanline counter. Background attributes such as tile flipping and priority (in front or behind sprites) would be cool too.
tokumaru wrote:
Other than that, I find the idea of 3bpp graphics really interesting, that combined with a decent number of palettes (maybe 8, shared between sprites and the background) could produce really nice graphics.
I was thinking about having only a single pattern table with 4bpp. This allows 15 colors per sprite, but you can also combine two 2bpp tiles into one 4bpp tile, or four 1bpp tiles into one, etc.
Quote:
Oh, come on! Why can't we go for nice power-of-2 dimensions to make scrolling easier?
I like this idea but you need to come up with how attributes/tile colors exist in memory.
16GB RAM
64-bit CPU
48-bit address space
tokumaru wrote:
name tables [ that are ] 256 pixels would make things much cleaner overall, and even provide some extra room for the scroll seam
It'd also be nice to not treat PAL consoles as second class. Supporting a 256x256 mode would be awfully close to full screen...
Quote:
Other than that, I find the idea of 3bpp graphics really interesting, that combined with a decent number of palettes (maybe 8, shared between sprites and the background) could produce really nice graphics. A larger, more consistent master palette than what the NES has would be very welcome. Other PPU features I'd want are more sprites per scanline (16 would probably be OK, but the more the better) and a built-in scanline counter. Background attributes such as tile flipping and priority (in front or behind sprites) would be cool too.
And that's basically what I meant by "I'd end up with the SMS". Fix the obvious awkwardnesses of the NES (e.g. 8.5 bits per nametable entry obviously becomes 16 bits; increase bit depth of both sprites and backgrounds from 2bpp to 4bpp, enlarge the source palette from 56 colors to 64), switch to a more-nearly-C-friendly ISA (Z80 is better than 6502 for that),
I mean, not that the SMS is flawless. There's plenty things I'd take from the NES side of the equation, too (such as the ability to do any interesting raster effects at all, the external PPU data bus, a sound IC that doesn't hurt to listen to), but ... all things said, it'd be closer to the SMS.
lidnariq wrote:
switch to a more-nearly-C-friendly ISA (Z80 is better than 6502 for that),
Eww, gross.
Come on, this topic has already been discussed over and over
here and
here. But because I'm stupid I'll state my opinion once more on the matter ^^
- Either 3BP graphics with multiple palettes, or 4BP with a dual BG/sprite palette (SMS-style)
- Resolution would probably be the same as the NES but with overscan properly hidable. Either that or 320 px horizontally.
- One non-scrollable high priority BG layer for status bars, one scrollable BG layer for levels. Either it's 256x256 pixels, or even 512x512 (or parametrable).
- Either that or we have enough sprites so that the scrollable BG layer is not necessary at all (Neo-geo style), in that case, the "dual palette" idea won't work
- I don't think the CPU really matters because it just comes down to personal preference eventually
- At least two interrupt sources for vertical retrace and arbitrary timing.
- Either wavetable synth or FM, I think wavetable is easier to use, for example 4-bit samples with either 32 or 64 samples and 4-bit volume control would be cool. It could be abused to paly actual samples by playing a "FFFFFF" sample and using IRQs and rewriting the volume constantly during playback
pubby wrote:
Quote:
Oh, come on! Why can't we go for nice power-of-2 dimensions to make scrolling easier?
I like this idea but you need to come up with how attributes/tile colors exist in memory.
The obvious thing to do would be to extend NT entries to 16-bit, like lidnariq said. That'd give us enough bits to address 512 tiles, select 1 of 8 palettes, flip tiles horizontally and vertically, and control priority.
With 16KB of VRAM (what the Master System had), we could have 512 3bpp tiles (12KB) and 2 256x256-pixel name tables (4KB). It would be cool if there was an option for this memory to be on the cartridge, like is the case with the NES, so that tiles could be bankswitched.
Personally I'd just drop the concept of "nametables" (as far as I know unique to the NES) and have a nice extended tilemap instead. Makes it much easier for scrolling to have a single larger tilemap rather than multiple smaller tilemaps. The only "advantage" of nametables is if we have a status bar and want to keep it somewhere fixed (Battletoads-style), however if we have more than 1 BG layer or enough sprites this stops being an advantage.
Hardware decompression and video codec. Similar to how PS1 had MJPEG in hardware, this hypothetical console could embed VP9.
...what? Who says proper FMVs wouldn't fit an 8-bit game?
calima wrote:
Hardware decompression and video codec. Similar to how PS1 had MJPEG in hardware, this hypothetical console could embed VP9.
...what? Who says proper FMVs wouldn't fit an 8-bit game?
What about this then, the console is basically an ehanced VHS player, and games are distributed as VHS tapes. Part of the tape contains the program, and part can contain FMVs. The software running in RAM can control the VHS in order to seek anywhere to either load new data into RAM or play a FMV.
This would be the only way to conciliate FMVs with authentic, 8-bit hardware I can think of, and it actually sounds like it would have been cool back in the day. Sort of a 3DO before it's time
There is a VHS adapter for the C64, it is used in lieu of the Datacassette, so plausible... They also made a CD version, so you can get a pile ( 30? ) Codemasters games on a CD for the C64.
And yeah if you making a new console, ditch nametables, and just have tilemaps...
I really love this idea, but instead of thinking strictly consoles, why not go for a configuration that could work with everything onboard on a single PCB for a plug-n-play solution just like arcade JAMMA boards, or those plug-in consoles with built in games?
I don't know a lot about electronics, but I would love it if it were possible to design a simple complete "open source console" that could easily be set up on a breadboard with just a couple of FPGAs and a bunch of easily available ICs, along with hopefully a minimum of extra components or complex wiring.
Would that be possible?
There doesn't seem to be a lot out there in the sense of open source FPGA based video chips, and the few there are, all seemed to be based on modern 3D rendering, etc.
I absolutely agree though, not making nametable screens 256x256 would just be repeating the same mistakes the NES did. It would be pretty cool to have at least two background layers to work with, too.
see
Mega65
C-One
MiST FGPA
Chameleon
Quote:
it were possible to design a simple complete "open source console" that could easily be set up on a breadboard
This has already been done.
Quote:
that could easily be set up on a breadboard with just a couple of FPGA
FPGAs are anything but "easily set up".
It was my impression that if you're working with a predetermined configuration and have the necessary tools, programming an FPGA is no more complex than writing to an EPROM. But I guess I was wrong.
Programming the FPGA is as easy as EPROM, connect a cable and press "program" button on the PC side... just making the stuff that gets programmed isn't anything along the lines of easy
Oh fudge it, just make a GBA. And if you're dissatisfied with that, make a NDS. And if you're dissatisfied with that, go full Tegra X1.
2 cents:
-uniqueness is more important than capacity. If we want something that's a middle step between nes and snes, there's turbo-grafx or mega drive; they also have a larger user base than a completely new console.
-thus, what would be interesting is a set of features and limitations which feel, look and sound unique.
-assembly is hard, but fun (for the 65xx family). BASIC is ineffective and limiting, but accessible and fun. Is C fun?
For audio:
555 timers, thermal noise with a simple but rather sharp BP filter, and a couple of simple vactrol (optocoupler) envelopes. OH YES. Not only would the vactrols make for a distinct sound - it would be a bliss from a score/music engine perspective. They can take an impulse, a prolonged "on" or a variable voltage, anything goes, everything sounds musical, you don't need to store or process envelopes to make nice sounds. The circuit can be as simple as anything gets, they can even be passive if they must, sans programmable logic. But they could also feed back to modulate the timers for percussive punches. If an impulse is sent while a lower voltage is being fed continously, it sounds like two instruments on one channel. It would be pretty effective. It's a very cheap and small circuit to have them select between gating amplitude only or both amplitude and low pass filtering. The latter is generally more musical, but sometimes you may want the bright edge of amplitude gating only.
Wavetable or FM would be more versatile than a simple set of 555 timers, of course.
Maybe even add a mix tap to a bucket brigade delay to make things even easier for the music engine.
I've always used the terms "name table" and "tile map" interchangeably.
tokumaru wrote:
I've always used the terms "name table" and "tile map" interchangeably.
It's a semantic thing, isn't it? A very large name table could potentially hold a level.
Bregalad wrote:
Personally I'd just drop the concept of "nametables" (as far as I know unique to the NES)
Are you referring to the segmentation of tilemaps wider than 32 tiles into 32xsomething-tile chunks? The Super NES, Game Boy Advance, and Nintendo DS 2D hardware retain this quirk outside rot/scale backgrounds.
TmEE wrote:
Programming the FPGA is as easy as EPROM, connect a cable and press "program" button on the PC side... just making the stuff that gets programmed isn't anything along the lines of easy
That's where the whole "open source" thing gets in. I'd assume in relation to this whole thread's topic, FPGAs are unavoidable in the first place.
I agree that "TurboGrafx" pretty much fills the void for the need for well designed console hardware placed somewhere between the 8bit and 16bit generations, and SD card adapters are even pretty cheap if you wanna start making homebrew for it. That's why I brought up the arcade-style "everything on one PCB" concept - being able to easily (and relatively cheap) reproduce the necessary hardware would be huge in my book. Reproducing a PC-Engine isn't that simple.
From what I can see, Mega65 is the closest to what I was thinking of, but it also seems like it's designed with a more PC-like configuration in mind - or more exactly, replicating the C64, OS and all. Also, it's seems it's still in development. You can download a bitstream to use, but there doesn't seem to be any complete hardware design, so it's unclear to me how "complex" the physical hardware profile is gonna be.
tepples wrote:
Are you referring to the segmentation of tilemaps wider than 32 tiles into 32xsomething-tile chunks? The Super NES, Game Boy Advance, and Nintendo DS 2D hardware retain this quirk outside rot/scale backgrounds.
Yes I refer to that precisely. I didn't know that Nintendo kept that in their later consoles, which sucks, because it's a terrible idea.
My thoughts.
-256 color choices (vs current 50ish), 8 or 16 per palette
-per tile palette selection, and BG tile flipping
Larger sprites (16x16) and more per line
More RAM...32k
Music, 8 pulse channels, finer volume control
-1 full PCM audio channel
Faster processor. 65c02. They make 14 Mhz today, that's
8x faster than NES.
As for pulse generators, dedicate at least a byte for PWM per channel. Besides finer granularity (making sweeps and a bunch of timbres possible), you can get octave-like overtones this way. Example waveform: --__-_-_
Another cheap application is to use flip-flops to get frequency division, and thus get suboctaves. you'd need active control of the sum/mixer to make it versatile.
I'm thinking lots of 8-bit registers that can be combined to form 16-bit registers. But to keep that from being literally the Z80, I guess they could also combine in certain combinations to form 24-bit, 32-bit...
Honestly my ideal old console processor is a fast Z80. Not gonna lie. 65xx is more fun but Z80 makes way more sense to me.
I say make the whole thing out of 7400 series logic parts and EPROM tables.
tepples wrote:
Three words:
Turbo
Grafx
Sixteen
Actually, I really like the 9-bit color palette of 512 choices. Blows NES out of the water.
And it has much bigger sprites, 16 per line.
There doesn't seem to be a homebrew scene for TG16/PCE. It's a shame. I know almost nothing about the system. Never saw one in my life.
nicklausw wrote:
I'm thinking lots of 8-bit registers that can be combined to form 16-bit registers. But to keep that from being literally the Z80, I guess they could also combine in certain combinations to form 24-bit, 32-bit...
Honestly my ideal old console processor is a fast Z80. Not gonna lie. 65xx is more fun but Z80 makes way more sense to me.
There's the
eZ80 which has 24-bit registers, a 3-stage pipeline, and which ditches the z80's 4-bit ALU for a 24-bit one, so it's pretty much a suped-up fast z80 in every way. Would be cool to see that in something that's not an embedded system with fixed code; the closest I've seen are some of TI's newer calculators.
NovaSquirrel wrote:
There's the
eZ80 which has 24-bit registers, a 3-stage pipeline, and which ditches the z80's 4-bit ALU for a 24-bit one, so it's pretty much a suped-up fast z80 in every way. Would be cool to see that in something that's not an embedded system with fixed code; the closest I've seen are some of TI's newer calculators.
Man, they stole my idea almost a decade before I came up with it!
[/sarcasm]
Bregalad wrote:
Come on, this topic has already been discussed over and over
here and
here.
Where and where?
There was also that FamiCube thing.
I came up with some specifications for a slightly improved NES-like PPU.
-up to 64kB of VRAM or VROM, accessed through the cartridge
-8kB of VRAM inside the system that is controlled by the cartridge (the way the NES does it)
-CPU is allowed to access 4kB of the VRAM/VROM at once
-6 byte FIFO, allowing the CPU to write up to 6 bytes per scan lines
-up to 1024 sprite patterns at once
-up to 1024 BG patterns at once
-56 colors at once (same limits as GBC)
-2 selectable 64x32 tile nametables (more can be used with on-cart VRAM)
-sprites and backgrounds can both be flipped and have priority
-64 8x8 or 8x16 sprites
-16 sprites per line
I haven't decided on what kind of palette it would have, but I have an interesting idea. Use an NTSC/PAL palette, but use a color index ROM to prevent out of gamut colors.
dougeff wrote:
There doesn't seem to be a homebrew scene for TG16/PCE. It's a shame. I know almost nothing about the system. Never saw one in my life.
There
are some actually, just not really active (Frozen Utopia even had several commercial releases such as a
RPG, though their homepage is currently "down until some big announcements").
Also, Chris Covell's
demos.
There is a very small community of programmers,I also just started with TG-16 development.
http://www.youtube.com/watch?v=or3oS-zd2gY
nicklausw wrote:
NovaSquirrel wrote:
There's the
eZ80 which has 24-bit registers, a 3-stage pipeline, and which ditches the z80's 4-bit ALU for a 24-bit one, so it's pretty much a suped-up fast z80 in every way. Would be cool to see that in something that's not an embedded system with fixed code; the closest I've seen are some of TI's newer calculators.
Man, they stole my idea almost a decade before I came up with it!
[/sarcasm]24bit registers buts it still 8bit ....
The 65CE02/new 4510 cpu fixes some of these issue in the 6502, it lets you do 24 and 32bit indirect indexed It would be interesting to see what a 50Mhz eZ80 vs a 50Mhz 4510 could do...
Also there is a 6502.orgs 65Org16, although not sure it is still "8bit"
Other ideas I've been musing with is What could you achieve with reworked motherboards, take components of the day but rework them. Say you have a PPU and then add another chip that does sprites, a TMS something
then put another 6502 are higher clock, so you have a GPU cpu and an game CPU, more of an arcade machine design. The C128 offers a lot of potential in this area.
the eZ80 @ 50mhz is apparently stated to be equivalent to a z80 clocked to 150mhz when used with fast enough memory. eZ80 comes in various variations (ROMless, flash, sram, 20/50mhz). The price is normally 8-7, occasionally up to 12 EUR (for 50mhz variants) and down to 4,5 EUR (for 20mhz) when ordered by the hundreds.
The 4510 has those two fancy CIA:s. Mouser and digi-key doesn't seem to have them in stock.
dougeff wrote:
There doesn't seem to be a homebrew scene for TG16/PCE. It's a shame. I know almost nothing about the system. Never saw one in my life.
That's a shame. PC Engine is literally my favourite console system of all time. There's so much great stuff on it, especially its arcade ports. It's like a proto-Saturn, but I like it a lot more.
It's sad that a lot of people still perceive the system as "obscure". In Japan it was bigger than Sega.
FrankenGraphics wrote:
the eZ80 @ 50mhz is apparently stated to be equivalent to a z80 clocked to 150mhz when used with fast enough memory. eZ80 comes in various variations (ROMless, flash, sram, 20/50mhz). The price is normally 8-7, occasionally up to 12 EUR (for 50mhz variants) and down to 4,5 EUR (for 20mhz) when ordered by the hundreds.
The 4510 has those two fancy CIA:s. Mouser and digi-key doesn't seem to have them in stock.
Yeah but I'm talking about this version which is a open source FPGA core
http://c65gs.blogspot.com.au/2016/04/ov ... today.html he had to pull back on the 192Mhz version as people complained it wasn't 8bit feel still. 1Mhz 6502 is basically near to 3Mhz Z80, so a 48Mhz 4502/10 and a 150Mhz Z80 would be "Game On"
Sumez wrote:
It's sad that a lot of people still perceive the system as "obscure".
I think it's about at the level of obscurity as the Neo Geo. "Obscure" is the CPS changer:
http://www.nintendolife.com/news/2015/0 ... me_console
I've never seen the CPS Changer,thanks for the link Espozo.
Sumez wrote:
dougeff wrote:
There doesn't seem to be a homebrew scene for TG16/PCE. It's a shame. I know almost nothing about the system. Never saw one in my life.
That's a shame. PC Engine is literally my favourite console system of all time
I owned one and so did friends in high school,great system.
As I understand it, one of the main bottlenecks of the day was memory. How fast were RAM/ROM chips from circa 1985, and what does that translate to in terms of clock speeds?
For example, the NES PPU reads one byte every two pixels. Was that purely to save on pins, or does it have to hold the address lines steady for the entire two clocks for the memory to keep up?
If the latter, the only way to get more than 2bpp on a 256x240 BG layer would be to do like the SMS, and use a 16-bit data bus, in which case 3bpp (which I'm something of a fan of) doesn't make a whole lot of sense... unless you use 16-pixel-wide tiles, I guess. Or interleave the first two planes and simply ignore half of every third-plane read, using 3bpp solely to cut down on pattern memory.
I'm rambling again, sorry.
Rahsennor wrote:
As I understand it, one of the main bottlenecks of the day was memory. How fast were RAM/ROM chips from circa 1985, and what does that translate to in terms of clock speeds?
For example, the NES PPU reads one byte every two pixels. Was that purely to save on pins, or does it have to hold the address lines steady for the entire two clocks for the memory to keep up?
If the latter, the only way to get more than 2bpp on a 256x240 BG layer would be to do like the SMS, and use a 16-bit data bus, in which case 3bpp (which I'm something of a fan of) doesn't make a whole lot of sense... unless you use 16-pixel-wide tiles, I guess. Or interleave the first two planes and simply ignore half of every third-plane read, using 3bpp solely to cut down on pattern memory.
I'm rambling again, sorry.
Maybe it could have a 2bpp background, but a choice between 2bpp 3bpp or 4bpp sprites.
It might be worth just recap'ing what the OneBus VT03's capabilities were, for comparison:
* Integral MMC3 with outer banks (comparable to the COOLBOY cart)
* choice of 16px wide 2bpp sprites or 8px wide 4bpp sprites (or 8px wide 2bpp sprites) - but regardless limited to 8 per scanline
* option for 4bpp backgrounds
* option to switch from NES-normal 4+0+2 bit HSL to 4+4+4 bit HSL color specification
* full X,Y lightpen support in hardware
* One extra whole APU - but no second functioning DPCM DMA unit
* Integral asynchrous serial port
Another alternative for video rather than the common way or the video instruction set is something involving the 6845 CRTC (which is what was used on PC), which allows the tile height to be controlled by software, as well as how many tiles per scanline, and other stuff (including lightpen support). (The 6845 CRTC works horizontally entirely in tiles and not in pixels. You must add external hardware to implement pixels.)
Still, I think having a video instruction set might help better (it is a kind of display list, like ANTIC has, although my idea is more capable, although still simple). You will still have to decide what video registers you want though; you could use a superset of the 6845 registers I suppose.
The background could be made as whatever bpp you want depending how many clock cycles are available; you could have 4bpp perhaps, and video registers will specify the base address of the tiles for each plane (which have to be a multiple of 256), and then the display program can alter these per scanline to display taller tiles. This would enable background tiles to be flipped vertically, although not horizontally.
Myask wrote:
Bregalad wrote:
Come on, this topic has already been discussed over and over
here and
here.
Where and where?
Sorry, I messed up when editing the PHP links. I edited them (including in the quote just above) so now they're fixed and points to the two topics where extremely similar matters were being debated (and those are both recent topics).
I decided to make a PPU register map for this fictional PPU
Code:
$xx00
bits 0-7 write: IRQ fire position
bits 0-7 read: scanline position
$xx01:
write
bit 0: grayscale
bit 1: color de-emphasis cyan
bit 2: color de-emphasis magenta
bit 3: color de-emphasis yellow
bit 4: BG enable
bit 5: sprites enable
bit 6: IRQ enable
bit 7: NMI enable
read
bit 0: scanline position MSB
bit 6: in H-blank
bit 7: in V-blank
note: reading this register clears IRQ and NMI signals, but not IRQ and NMI enable
$xx02
bits 0-7: x position
$xx03
bit 0: x position MSB
bit 1: ???
bit 2: sprite height (not sure if needed)
bit 3: left-most 8 pixels mask enable
bits 4-5: BG patterns table select
bits 6-7: sprite patterns table select
$xx04
bits 0-7: y position
$xx05:
bits 0-1: PPU memory
00: VRAM increment by 1
01: VRAM increment by 64
10: Color RAM
11: Sprite RAM
bits 2-3: ??
bits 4-7: name table select
$xx06/07
bits 0-15: PPU address bus port
$xx08:
bits 0-7: PPU data bus port
Should grayscale bit to disable the colour burst signal?
Probably not? Some televisions will stop chroma decoding altogether (edit) for the remaining scanlines of the current field if they can't get a chroma lock on one scanline.
When it comes to interrupts do you really need to clear the interrupt, or can you just have a short pulse that lasts only a few cycles? How long does the interrupt signal need to be?
Depends.
If the CPU is in a state such that it is ready to handle an interrupt, you should only need to assert /IRQ for 9 cycles or so.
On the other hand, that's only suitable for tasks that happen at fixed timing relative to an NMI or another IRQ; if an IRQ could happen during any time (edit)that interrupts are temporarily disabled you'd need to assert it until the CPU is ready.
I have an insane idea. Double the PPU bus width, but keep only one 2bpp background, so you can have 96 sprites per scanline, and still have some CPU to PPU bandwidth left over.
It's not that insane considering the existence of the Neo Geo.
Alternatively, this could make good non-flickering bullet hell shooters though.
In that case, shared subpalettes between sprites and background becomes a bit more important. If you can have 96 sprites per scanline, using some of them as trimmings to the decor would come in handy.
Should you use clock interleave for video so that the picture can be programmed during rendering? It would have to see the rest possibly, to see if it is good or not, since other considerations might affect it too.
Two changes to the 2C02 would allow adding write-during-display behavior analogous to that in the TMS9918, 315-5124/5246, and HuC6270:
- Retrieve new attribute byte only when the attribute address has changed. This breaks MMC5 ExGrafix but frees up about 32 slots: 24 during background fetches in active picture and 8 during sprite fetches in hblank.
- Second dedicated VRAM address port for use with write FIFO.
Updating CHR RAM $1000-$1FFF through this mechanism would, however, confuse MMC3 and other interval timers that count stretches of PA12 low. And if a write lands at the very end of a scanline, a timer counting stretches of PA13 high, such as that of the MMC5, might also get confused.
I thought a little more about the specs and I came up with this.
By default there will be 40 16x16 or 16x32 sprites onscreen with no flicker, but it will have 2 sets of 40 sprites that can be switched per scanline, and can be used for sprite multiplexing.
tepples wrote:
Updating CHR RAM $1000-$1FFF through this mechanism would, however, confuse MMC3 and other interval timers that count stretches of PA12 low. And if a write lands at the very end of a scanline, a timer counting stretches of PA13 high, such as that of the MMC5, might also get confused.
When you're doing a modified incompatible version of the 2C02 anyway you can throw in a native scanline interrupt and any theoretical games for that platform would use the native one instead. It's a bit different from the 15-sprites-per-scanline thing where regular NES games use the upgrade without trying.
tepples wrote:
Updating CHR RAM $1000-$1FFF through this mechanism would, however, confuse MMC3 and other interval timers that count stretches of PA12 low.
Wait, weren't we talking about an all-new console? I didn't think we were considering any sort of backwards compatibility...
Earlier, lidnariq
mentioned VT03, which is mostly back-compatible.
If we're making a digital NTSC encoder, I just had an idea for it.
A problem with NTSC if having a black pixel surrounded by saturated primary colors is chroma bleeding making the blacks not looking black enough. So I had the idea of making de-saturated pixels wider by having a fast slope towards greys, but a slower slope towards saturated colors.
I made an algorithm for it:
a = u^2 + v^2
U(n) = u + 2a(U(n-1) - u)
V(n) = v + 2a(V(n-1) - v)
This might be used in combination with more typical luma/chroma filtering.
dougeff wrote:
There doesn't seem to be a homebrew scene for TG16/PCE. It's a shame. I know almost nothing about the system. Never saw one in my life.
i agree, and it's strange because if you take this forum for exemple, there are many people who know how to code for 65xxx, and the PCE is really a simple, straightforward and powerful system,and nobody tried to code for it .
Although the love for the PC Engine is typically strong, the user base is naturally a lot more limited than the NES which is one of the most famous video game systems ever, and in the recent years it has been regaining a very strong presence based on nostalgia as well.
I love the PC Engine myself, but I'm more interested in making a game that other people would have a genuine interest in as well. Also, the limitations of the NES is a part of what draws me to it.
I've seen some Kickstarter projects of games with a proposed PCE release though:
https://www.kickstarter.com/projects/sa ... 6-pc-steamhttps://www.kickstarter.com/projects/sa ... video-game
If you look at the total units sold for given retro-consoles, the relative infrequency of PCE homebrew doesn't seem very suprising to me?
- Game Boy: 118 million
- NES: 62 million
- SNES: 49 million
- Genesis: 30 million
- 2600: 30 million
- SMS: 20 million?
- Game Gear: 11 million
- PCE: 6 million
- Lynx: 3 million
* Very quick list cobbled together from vgchartz/wikipedia
Yeah, the infrequency of SNES homebrew is a lot more unsettling. But we already have an entire thread dedicated to that
Wasn't PCE sold mainly in Japan, being expensive and rare outside? Thus the devs and audience would be Japanese, and mostly unknown to us who don't speak moon runes.
calima wrote:
Wasn't PCE sold mainly in Japan
Mainly, but USA and France weren't neglible markets either. It got in maybe a little too late on Spain and the UK (market introduction 1990), because it was discontinued internationally in 1993, and 1994 in japan (5 years of market life).
Had it had an earlier international release, it might've fared much better. But markets back in the day seemed to be pretty slow moving back then.
It might be worth to note that unlike Japan and the US, Europe was a patchwork of natinal markets at the time (i kind of imagine the rest of the world was like this, too, but i know too little). The spectrum didn't reach much at all outside the UK as Sinclair had no interest in that market, but aside purebred consoles like the NES and SMS, it was a turf war between amstrad, MSX, c64 (less dominant than in the US), and local offerings like ABC80/800. And on the east side of the iron curtain, home computers were mostly of the DIY variety and built out of discrete off-the-shelf components and virtually every game was homebrew/bedroom coded.
Despite the PCE having a very charming/attractive feature set right on a sweet spot between simplicity and wonder, i think MSX might actually have the upper hand as a potential homebrew platform. Besides getting an original unit, you can build a perfect MSX clone today. It's just that the price isn't very attractive for most people at this point (a bit like c65, i think? except c65 never saw an original release at all and has no original software as a result).
Anyway, it seems the NES, the spectrum (surprising as it is rare outside the UK, or maybe speccy homebrew gets extra attention because of
retro gamer the magazine), and c64 are the most popular homebrew options. Then maybe Sega Mega Drive or Game Boy?
Back on topic. I notice when people talk about designing a console, people tend to not like the idea of having multiple graphics modes like the SNES, but honestly, I think it was a good idea at the time because if every BG layer was 4bpp there would only be 2 layers of parallax with it's access speed of 5.37Mhz. I think a couple modes might need to be changed a bit though, such as making everything packed pixel.
Yeah, typically you don't need too many colours in the rearmost layer (if it depicts something distant), nor in a close-up layer if it's backlighted or "out of focus".
Honestly, if Nintendo just used the best available components in everything, the NES would be SOOOO much better.
8 times faster processor.
8 channels of audio
1 palette per BG tile
32k RAM
256 color choices
Enough VRAM for 4 nametables.
And if the Genesis were as powerful as the Neo Geo, it would have been so much better. But the Genesis beat the Neo Geo AES by being a heck of a lot cheaper. Good enough sells.
Worse is better.
dougeff wrote:
Honestly, if Nintendo just used the best available components in everything, the NES would be SOOOO much better.
8 times faster processor.
8 channels of audio
1 palette per BG tile
32k RAM
256 color choices
Enough VRAM for 4 nametables.
Pretty much all systems had to be under $200 back then.
psycopathicteen wrote:
Pretty much all systems had to be under $200 back then.
That corresponds to about $500 now, given inflation.
Yes, but we're talking about* a hypothetical retro system, with modern components.
I'm suggesting that if it functioned identical to my description of "if Nintendo had just used the top-of-the line parts"... it would feel like a super-charged NES.
Edit * at least we WERE talking about it, in June.
Well, we can design something like a console version of the GBA, but with a higher resolution and better sound chip.
psycopathicteen wrote:
better sound chip.
You mean
a sound chip?
Well, there always is the GB sound hardware, but it sounds jarring next to the GBA graphics. The resolution is horrible though; literally only half the pixels of 320x240, which I can't think of it being used by any 2D system, except the best designed 2D system ever made: the legendary Irem M92.
Quote:
The resolution is horrible though; literally only half the pixels of 320x240
Exactly what I had in mind.
I don't see the point of 320x240 on an NTSC console. Unlike an arcade monitor, the TV connected to a console isn't designed for easy width and height adjustment by the owner to match the picture width (in microseconds) and height (in scanlines) from a particular source. Instead, a TV is fixed at 52.148 microseconds wide and 240 lines per field tall, with a few percent on each side hidden by the bezel. So if you're keeping a square pixel aspect ratio, and you don't want to waste PPU cycles on making pixels the player will never see, you end up with a 6.14 MHz dot clock and 288x224 pixels, much like Namco arcade PCBs. Each scanline then contains 288 pixels, 32 pixels of side border, and 70 pixels of blanking. But this is still an improvement compared to the GBA's 240x160.
Like the Super NES S-PPU, a GBA clone PPU takes four master cycles to produce each dot. So to get square pixels, you'd need to feed it 270/11 = 24.545 MHz, which is 46% faster than the GBA's master clock. Then multiply this crystal by 7/48 to get the NTSC subcarrier frequency.
But the GBA uses the same nametable arrangement as the Super NES, with the map broken up into 32x32-tile (256x256-pixel) chunks. This makes a display 240 pixels wide is more convenient to program than something exceeding 256 pixels wide. A GBA text background on a 240-pixel-wide display can be set to single-screen mirroring without artifacts, while a background on a display 250 pixels wide or wider (such as that of the Nintendo DS, which extends the GBA PPU architecture) requires horizontal arrangement (vertical mirroring) with the nametable split into two halves.
If you're targetting CRT diplays, there's no real reason to go for square pixels though...
Most game systems leave about 25% of a scanline for H-blank, so you might as well clock it at 27Mhz.
I've been researching stuff about the GBA, and is it true that the GBA can DMA up to 80kB to VRAM during V-blank?
Sumez wrote:
If you're targetting CRT diplays, there's no real reason to go for square pixels though...
Why would anyone target CRT displays in 2017? Sure we keep them around for the old stuff, but it's only a matter of time until it becomes impossible to find a working CRT.
Sumez wrote:
If you're targetting CRT diplays, there's no real reason to go for square pixels though...
Unlike unassisted* fourth-generation consoles, the GBA can rotate sprites. Rotation is slightly more practical with square pixels, especially for sprites such as Sonic the Hedgehog that appear unrotated most of the time and rotated occasionally. It's especially more practical in 90-degree situations.
The Super Game Boy doesn't compensate for the host PPU's 8:7 PAR, but the Game Boy Player does compensate for the 10:11 PAR that the GameCube's native 27 MHz video output would entail.
* The Super FX GSU2 in Yoshi's Island is assistance.
If you're designing a system made for an HDTV, then you can divide the 148.5 Mhz dot clock by 5, and get a dot clock of 29.7 Mhz, and take 5 scanlines to draw a row of 5x5 pixels. It could draw 1 BG layer per scanline and draw sprites on the last.
On the other hand if you're going analog route, doesn't Sega Saturn have a GBA-style VDP where it's clocked 4x the pixel rate?
tokumaru wrote:
Sumez wrote:
If you're targetting CRT diplays, there's no real reason to go for square pixels though...
Why would anyone target CRT displays in 2017? Sure we keep them around for the old stuff, but it's only a matter of time until it becomes impossible to find a working CRT.
I agree, my statement was based on tepples' assumption pertaining to overscan.
The rotation argument is a pretty decent rebuttal, though. Dealing with 360 degree direction vectors in an uneven coordinate system can be pretty complicated, too. I never thought about it before, but that must have been a pretty relevant issue for Cave's shooters on the PGM system. PGM has
an absurdly large "horizontal" resolution.
At least the pixels are mostly 2:1, the CPS2 has a more awkward horizontal resolution, considering it's still running on 4:3 monitors:
tokumaru wrote:
Sure we keep them around for the old stuff, but it's only a matter of time until it becomes impossible to find a working CRT.
Oh please, this stuff lasts forever.
tepples wrote:
Unlike unassisted* fourth-generation consoles, the GBA can rotate sprites.
You forget about Mode 7 though; I don't think I've ever seen a game on the SNES where a spinning background takes the 8:7 PAR into account (even if all the sprite graphics do). Most all games I've played on any 2D system don't take into account the PAR for object speed either; you'll play overhead games where ovals are shrunk/stretched to be circles, but the player will still move faster across one axis. I personally wouldn't even bother about the 8:7 PAR on the SNES if I were designing a game (not just an engine); it causes more of a headache (and even a possible performance hit; it's more difficult to do sub pixel movement) than it improves the visuals, especially considering that most people would probably play it on an emulator in 8:7 anyway.
I only really pay attention to aspect ratios, if I am using a circular object. If it's a character animation, good luck with that. I do wonder if Capcom's development set used computers with their weird PAR.
I heard they used Sharp X68000s through at least the CPS1's lifetime. It must have been a real pain to draw the graphics if that's actually the case.
Sumez wrote:
The rotation argument is a pretty decent rebuttal, though. Dealing with 360 degree direction vectors in an uneven coordinate system can be pretty complicated, too. I never thought about it before, but that must have been a pretty relevant issue for Cave's shooters on the PGM system. PGM has
an absurdly large "horizontal" resolution. At least the pixels are mostly 2:1
What exactly is the dot clock rate on a Cave CV1000? The
MAME driver lists crystal X1 as 12.8 MHz, but the precise video timing hasn't been measured. If the 448x224-pixel video output is at this same rate, then it'd be awfully narrow through a SuperGun (JAMMA to NTSC converter). My
dot clock rate list describes how each system would appear on a standard 4:3 TV through a SuperGun, though the PAR in practice may differ because of nonstandard active picture periods that many arcade PCBs use and for which an arcade technician is expected to adjust the display.
Sumez wrote:
the CPS2 has a more awkward horizontal resolution, considering it's still running on 4:3 monitors:
psycopathicteen wrote:
I do wonder if Capcom's development set used computers with their weird PAR.
Incidentally, the pixel aspect ratio of CPS and CPS2 is very close to the 3:4 PAR of the Commodore 64 and Apple IIGS super hires.
For X68000's monitor,
Wikipedia's article claims 15 kHz, 24 kHz, and 31 kHz modes, one of which has 640x480 square pixels. In this case, zooming by 3x4 would theoretically fit 213x120 pixels of a sprite sheet on the screen at essentially correct PAR.
CV1000 games run at a fairly "normal" resolution (I think it's actually perfectly 4:3), I was referring to the game they made for the PGM system (Daioujou, Espgaluda and Ketsui), though other shooters for PGM obviously have the same issue - not sure if there are any except from Bee Storm.
I don't understand what you are asking though? I've run some PGM games through a supergun, and they show up fine on my consumer TV, with the expected overscan. My supergun doesn't convert JAMMA to NTSC though, not sure why you'd want them to do that. Sounds like a horrible thing to do.
tokumaru wrote:
Why would anyone target CRT displays in 2017? Sure we keep them around for the old stuff, but it's only a matter of time until it becomes impossible to find a working CRT.
By this reasoning, it's only a matter of time until it becomes impossible to find any working digital device or anyhting that uses electricity to function...
What do you mean? People are throwing away CRTs all the time and I don't think I've seen a newly produced CRT TV in years. It's still easy to find a PAL-only CRT TV, but the good ones with NTSC support are more rare.
The point isn't if devices break or not. The point(s) are these:
-Electronics break with age and use, so older equipment may be sooner to break.
+counterpoint: but older equipment was often made with made-to-last components, designs and techniques, unlike the designed for the dump philosophy of today
+and when something break, it's often the matter of replacement of a single or a few components. If they're not smd/smt; easy peasy provided you can identify the problem.
-But it doesn't matter. When something breaks, most people drive it to the dump, not for repairs.
-Most of all, people drive their crt:s to the dump anyway, functioning or not, because they aren't used anymore and/or because they want something newer. What we see is a rapid diminishing of the existence of CRT screens.
EDIT: Pokun beat me to it.
Maybe NESdev shouldn't be designing a new console, but a new retro gaming monitor
I'm absolutely certain we will see new production runs of CRT monitors in the future - targeting collectors, fans of retro electronics, retro arcades, etc.
They will most likely be very good quality, but also extremely expensive due to a lack of mass production. Just like how new dot matrix displays are more expensive nowadays than a much higher resolution full color LCD screen.
I'm not.
Look at how much difficulty the people who have gotten into making just all-new-parts nixie tubes have. CRTs are all that complexity, plus needing leaded glass (which is simply unlawful in the EU) and toxic chemicals (the phosphors) and the complexity of building a functional aperture grille.
Building a mechanically scanned laser raster display will be cheaper.
lidnariq wrote:
leaded glass (which is simply unlawful in the EU)
When did that come into effect? Last I checked,
the counterpart to RoHS in the (U.S.) State of California exempted leaded glass in CRTs because the EU RoHS exempted leaded glass in CRTs.
EXAMPLE: The EU RoHS Directive exempts lead in cathode ray tubes (CRTs). If a particular CRT television contains lead in the glass of the CRT above the 0.1% maximum concentration value (MCV) for lead, and if the lead in the CRT glass is the only substance that exceeds the MCV, both the EU and California would allow the sale of that television.
You're right. I'm not certain how I'd gotten that impression.
RoHS compliance or not, maybe a new CRT is impractical given its special parts.
I think these general criteria would make sense, for starters:
-Be able to build from off the shelf components to a high degree.
-Everything outside the PSU box should be operable at non-fatal voltage levels
-May be offered as a final product, DIY kit, bare PCB + BOM. One hobbyist may commision another who's more confident with a soldering iron to populate a board and/or assemble the whole thing.
So the challenge then becomes coming up with a non-crt screen that:
-renders correctly as far as the eyeball is concerned
-without delays or interleaves
-will work with a light gun
Then, perhaps:
-More or less modular approach:
--External PSU
--External sound
--You pick which "shield"/"hat" suits your need the best for a reciever/decoder; and perhaps a sound module or remote control reciever if you want that. Third parties may offer their own designs or you can stripboard one yourself.
Pins may be an initial extra hardware cost, but you gain the freedom of adding in whatever you want and may omit the rest. RF, composite, scart...
I don't think you need to worry that much about a CRT because most HDTVs support composite and component anyway. Plus you can just make it HDMI in the first place. The question is to either use HDMI timing and convert it to composite/component, or vice versa.
psycopathicteen wrote:
I don't think you need to worry that much about a CRT because most HDTVs support composite and component anyway.
Not well enough. They'll upconvert (and deinterlace, even if it's supposed to be 240p) but the image quality is terrible, and more importantly the lag is really really bad.
Last Christmas holiday, I played a game of Mario Golf with my brother, my sister, and my brother's wife. I was the only one who picked a non-straight shooter (Mario, because he has one of the longest drives). This screwed me when my mom decided to take a nap in the next room and we had to move upstairs and plug the N64 into an HDTV. I couldn't hit the fairway to save my life; the timing was off by at least a tenth of the swing bar. My brother ended up beating me with Plum.
If we'd been playing Duck Hunt we'd have had to quit.
Not to mention vertical scroll-staggering and strobe effect problems.
Not forgetting the lack of light gun and light pen compatibility.
Sumez wrote:
I'm absolutely certain we will see new production runs of CRT monitors in the future - targeting collectors, fans of retro electronics, retro arcades, etc.
They will most likely be very good quality, but also extremely expensive due to a lack of mass production. Just like how new dot matrix displays are more expensive nowadays than a much higher resolution full color LCD screen.
There
are companies still making CRTs but most of them are actually of very
low quality. Between that, and the current availability and relatively low price of good quality used CRTs, I can't imagine someone being able to make a good business out of artisanal CRTs in the next decade at least.
You see the same thing with other niche electronics, like floppy disks: they're still being made and the quality levels are horrible.
Sumez wrote:
Although the love for the PC Engine is typically strong, the user base is naturally a lot more limited than the NES which is one of the most famous video game systems ever, and in the recent years it has been regaining a very strong presence based on nostalgia as well.
I love the PC Engine myself, but I'm more interested in making a game that other people would have a genuine interest in as well. Also, the limitations of the NES is a part of what draws me to it.
I've seen some Kickstarter projects of games with a proposed PCE release though:
https://www.kickstarter.com/projects/sa ... 6-pc-steamhttps://www.kickstarter.com/projects/sa ... video-gameYes in general you want to code for your childhood's system,and it's normal, but it's strange that not even one guy here tried to do it .
Those kickstarter projects was started by some pcenginefx folks .
Well we are a number of people on the forum that have coded for the PC Engine. I've read through the dev docs but I still don't fully understand how everything works to the point that I would be able to make a game (I'm not sure how to do a main loop considering vblank etc). I've made simple programs that detects hardware, displays text and played around with the PSG sound channels though.
Lots of homebrew are made using HuC (CC65 still isn't up for it), but Chris Covell started making a great
beginner guide for people that wanna start out with PC Engine assembly.
Bregalad wrote:
tokumaru wrote:
Why would anyone target CRT displays in 2017? Sure we keep them around for the old stuff, but it's only a matter of time until it becomes impossible to find a working CRT.
By this reasoning, it's only a matter of time until it becomes impossible to find any working digital device or anyhting that uses electricity to function...
93143 wrote:
Not well enough. They'll upconvert (and deinterlace, even if it's supposed to be 240p) but the image quality is terrible, and more importantly the lag is really really bad.
This times a million. Although the quality and lag vary considerably (the TV in my living room has a whole quarter second of lag, while the TV in the living room at my friend's house has almost no lag), you're just much better off with a CRT.
It looks ridiculous, but this is actually the setup I have in my room. (Notice the non pissed-on SNES.
) Unfortunately, my N64 and Genesis are at my father's house, and the Switch is such a POS that it can't pick up the WiFi from my room.
Attachment:
Two TVs.png [ 192.18 KiB | Viewed 1455 times ]
rainwarrior wrote:
There are companies still making CRTs but most of them are actually of very low quality. Between that, and the current availability and relatively low price of good quality used CRTs, I can't imagine someone being able to make a good business out of artisanal CRTs in the next decade at least.
Would it just make more sense at this point to make an OLED TV with an actually good analog to digital converter if you were to target the "retro" market? From my understanding, CRTs have had digital TVs beat for the longest time in that they can display both pure black and pure white next to each other, but now that OLED is a thing, digital TVs can do the same.
I'm slowly working on something along the lines of an universal CRT driver board, to get most out of existing tubes and allow them to be used with moden inputs etc.... All the larger screens have decent enough dot pitch to show 1280x960 with not a whole lot of loss, and you can feed them higher resolutions and it would still look usable, free subpixel scaling helps a bit lol. I'm still learning about the power supply side of things and I have not yet tested how far can non monitor deflection coils be pushed, but the rest is mostly figured out and will need prototype to be actually built. I will not be making any futher fuzz about it until there's actually something working going on.
...But my motivations will run really low once OLED stuff is affordable (and there isn't any retarded image processing things going on with their inputs but hopes are low on that regard though). One can only hope a monitor doesn't have any unnecessary things in it though, but for now, monitors cost even more than the TVs do... In theory it would be possible to scan an OLED panel like a CRT, getting light gun/pen compatibility and whatnot, but that requires the electronics in the panel to allow updating individual pixels rather than entire rows or columns, i.e passive matrix style rather than active matrix similar to how plasma screens work (which are now no longer manufactured).
Another future project is pretty much an universal digital panel driver, to fix up the image processing aspect, but it won't happen anytime soon either lol.
Quote:
Although the quality and lag vary considerably (the TV in my living room has a whole quarter second of lag, while the TV in the living room at my friend's house has almost no lag), you're just much better off with a CRT.
You should probably enable some "gaming mode" in order to reduce input lag, all modern TVs have this. You should also enable some kind of bluring filter to make image from old consoles acceptable, as they contain high-frequenties which are supposed to be filtered out by the TV. (In NES's case this is due to color bust being made of square waves instead of sine waves I think).
Quote:
It looks ridiculous, but this is actually the setup I have in my room. (Notice the non pissed-on SNES.
)
You have an american SNES. Japanese Super Famicoms and european SNES tend to look like piss colour.
Bregalad wrote:
all modern TVs have this.
The one in my living room actually doesn't, and it's from 2015.
Bregalad wrote:
You should also enable some kind of bluring filter to make image from old consoles acceptable
The problem is that it blurs it too much. It looks noticeably sharper on my CRT, which I prefer. Not to mention it's only 30fps instead of 60fps.
Bregalad wrote:
You have an american SNES. Japanese Super Famicoms and european SNES tend to look like piss colour.
There are lots of yellow American SNESs as well:
I have no idea why it seems to affect some and not others.
Espozo wrote:
I have no idea why it seems to affect some and not others.
They weren't consistent with the ingredients when they mixed the plastic.
rainwarrior wrote:
Between that, and the current availability and relatively low price of good quality used CRTs, I can't imagine someone being able to make a good business out of artisanal CRTs in the next decade at least.
Oh it'll definitely be more than ten years in the future. Especially for arcade games though, the amount of consumer tubes you can use as decent replacements are extremely limited.
TOUKO wrote:
Yes in general you want to code for your childhood's system,and it's normal, but it's strange that not even one guy here tried to do it .
Those kickstarter projects was started by some pcenginefx folks .
Well... this is a NES development community.
Is OLED the only new technology available to potentially act like a CRT scan would?
I don't even think OLED is great; similarity to a CRT raster requires a comparatively short (hundreds of microseconds) luminosity lifetime. Otherwise lightpens and other consoles' lightguns won't work.
(In turn, that means that the light emitter has to emit most of its energy in a short period of time, which requires higher peak power for the same net brightness)