I'd like to share my new fantasy console, the F8!
DownloadSource+documentationI also have a
preview video for my upcoming game on the console, The World of Tim!
My first reaction at hearing the outdoor music of
The World of Tim:
"Gonna take a sentimental journey"
So it's a 6502 with a video/audio/input interface that you designed? Like some parallel universe NES?
rainwarrior wrote:
So it's a 6502 with a video/audio/input interface that you designed? Like some parallel universe NES?
Well, basically, yeah.
I checked the video and it seems interesting. What I would like to know is:
- what is the specs of this fantasy console other than the cpu
- how is it different from the nes
- Would it be made someday into some real console
- what is the future goal, people making real software for it or just educational fantasy console
I may have more questions later once I put a list together.
The specs are here:
https://github.com/FautenicOfficial/f8e ... r/spec.pdfAfter some reading, here's my quick summary:
Very "NES-like".
4:3 display of square pixels (256x192)
Has CHR and PRG concepts (though with built in bankswitching mechanisms, 3 "mapper" modes). CHR seems to be mapped into the CPU memory space (dual ported?). There's 16k of main RAM.
Background layer similar to NES, with 16x16 attribute regions, and 8x8 tiles. There are 4 backgrounds of 1k (32x32 tiles) and a separate 256b block of memory for the attributes.
64 sprites. Mostly like NES except 2 bits of "size" to select 8 or 16 pixels for each axis. Not quite sure if the priority "masking" works the same way.
Audio has 4 channels, 12-bit freq, 4-bit volume, 1-bit duty, each can be square/triangle/saw/noise.
(edit: corrected typo and omission)Not sure if per-scanline raster effects are possible, but there seems to be a 4-way split screen mechanism? It refers to them as "quadrants", not exactly sure how this works but it seemed like you can divide the screen in half twice and have a separate scroll position for each quarter?
Couldn't seem to find a spec for the CPU speed? Does it just run as many cycles as it needs until it tells you to display a frame?
Apparently there's a PDF with all the specs in the Github repository. It looks like an NES with a simplified architecture, that instead of having a separate VRAM bus, has everything is mapped in the CPU's addressing space.
It's cool to dream about such fantasy consoles, but this is so much like a real NES that I don't really see the point. The graphical limitations are almost the same, audio too, so I don't really see the appeal to go for this instead of making an actual NES game that can be run in a million different emulators on all platforms imaginable, including the real deal 80's console.
Quote:
4:3 display of square pixels (256x192)
How would this work on a TV? Extra-wide HBlank? Wrong aspect ratio? Out-of-spec scanline pitch?
EDIT: Ninja'd - now it sounds like I'm piling on... sorry...
rainwarrior wrote:
4:3 display of square pixels (256x192)
Yup.
rainwarrior wrote:
Has CHR and PRG concepts (though with built in bankswitching mechanisms, 3 "mapper" modes). CHR seems to be mapped into the CPU memory space (dual ported?). There's 16k of main RAM.
Yeah, there's no separate PPU memory like the NES.
rainwarrior wrote:
Background layer similar to NES, with 16x16 attribute regions, and 8x8 tiles. There are 4 backgrounds of 1k (32x32 tiles) and a separate 256b block of memory for the attributes.
BINGO! (Your FP is full!)
rainwarrior wrote:
64 sprites. Mostly like NES except 2 bits of "size" to select 8 or 16 pixels for each axis. Not quite sure if the priority "masking" works the same way.
Mhm. The priority bit determines if it's drawn in front of or behind the background. 1 is behind, 0 is in front.
rainwarrior wrote:
Audio has 4 channels, 12-bit freq, 2-bit volume, 2-bit duty, each can be square/triangle/noise.
Not sure if typo, but it's 4 bit volume and 1 bit duty. Oh, and there's a saw channel too.
rainwarrior wrote:
Not sure if per-scanline raster effects are possible, but there seems to be a 4-way split screen mechanism? It refers to them as "quadrants", not exactly sure how this works but it seemed like you can divide the screen in half twice and have a separate scroll position for each quarter?
Pretty much. This was done because I found it too difficult to render it at the scanline level, and also because I needed a way to do vertical splitting.
rainwarrior wrote:
Couldn't seem to find a spec for the CPU speed? Does it just run as many cycles as it needs until it tells you to display a frame?
It's fixed at 32768 cycles per frame.
tokumaru wrote:
Apparently there's a PDF with all the specs in the Github repository. It looks like an NES with a simplified architecture, that instead of having a separate VRAM bus, has everything is mapped in the CPU's addressing space.
It's cool to dream about such fantasy consoles, but this is so much like a real NES that I don't really see the point. The graphical limitations are almost the same, audio too, so I don't really see the appeal to go for this instead of making an actual NES game that can be run in a million different emulators on all platforms imaginable, including the real deal 80's console.
Hm, you do have a valid point. What do you suggest I do to make it stand out more?
@rainwarrior
Oh, I completely missed that ^^;; I checked the video and tried to find the main site hoping it would give a summary about it (the link with the zip file) but didn't think about checking the github files after seeing the 1 line README.md.
Thank you for pointing it out and for the summary.
Fautenic wrote:
rainwarrior wrote:
64 sprites. Mostly like NES except 2 bits of "size" to select 8 or 16 pixels for each axis. Not quite sure if the priority "masking" works the same way.
Mhm. The priority bit determines if it's drawn in front of or behind the background. 1 is behind, 0 is in front.
I was referring how on the NES if a "background" priority sprite has lower index than a foreground one, and of its behind-background pixels will end up cutting a hole out of the higher index foreground sprite. It's a very useful masking effect sometimes, but something that's not really intuitive behaviour.
Fautenic wrote:
Hm, you do have a valid point. What do you suggest I do to make it stand out more?
Maybe if it was more like the pseudo-consoles where modern retro-inspired games (e.g. Shovel Knight) run, it would make more sense for this day and age.
Modern displays are all widescreen, so it'd better to make proper use of the screen space. More background layers adds a ton of possibilities for effects and large objects. That combined with a window layer greatly reduces the need for raster effects. No need to be so stingy on the number of palettes either. In fact, doing away with the convoluted attribute system, which is one of the most hated aspects of the NES, would be a great idea. Using 2 bytes per tilemap entry would open up a lot of possibilities, like per-tile palette selection, more than 256 tiles for the background, tile flipping and more priority control, kinda like on the Master System or GBC, so still well within the realm of 8-bit consoles.
I would worry about improving the sprite system a bit too. The OAM could definitely be larger, also improving versatility. A few more bits per entry would really help in allowing access to more than 256 tiles, more palettes, and smooth scrolling at the top and left edges of the screen.
This would do away with most of the restrictions the NES has that annoy new artists and programmers, but still keep the feel of a real retro console, with period-accurate language and I/O systems.
Lots of palettes and a generous number of sprites could even satisfy those going for a look closer to that of 16-bit consoles, since it'd be possible to stack sprites and design backgrounds with less color repetition. A master palette better than the Master System's 6-bit RGB would really help too (maybe go with
RRGGBBII or RRGGBBSS if you want to keep it 8-bit).
Normally when you make a Fantasy console it is to fix issues.
To which I would
give it 8x8 colour attributes.
allow interleave VRAM access during frame time
bump to the clock to 8mhz or so
Give it at least 16K
Give it options to change the waveform per channel
This way its a NES that people can write a decent game for in C, and not suffer from "static background" syndrome, and have more freedom in music. But still have it feel as if they made a NES game
Oziphantom wrote:
allow interleave VRAM access during frame time
Give it at least 16K
Give it options to change the waveform per channel
It does do these 3 things.
my 'it' was in reference to "a Fantasy Console", not their fantasy console.
And I forgot a couple of things that I forgot a NES doesn't natively have...
Raster Interrupts
Timers
Fast mul/div registers
And stuff nothing has
FIFO hardware stack registers
It's always cool to invent machines that could have been there in the 80s.
Personally, if I had a fantasy console to make I'd make it store games on VHS tapes, and use them for CGI too, just like later CD-based consoles used CD for both storing the game and the music. Of course by todays standards it'd be shitty, but back then this would have made a CDi like-console, a great platform for shitty games. Or I'd use casettes for both game data and music, that'd be fun too.
Sharing RAM and VRAM among the same adress spaces simplifies programming, but it means halving the bandwith, so halving CPU processing power and PPU limiting graphics (for example in the C64 if you want colours, each pixels is repeated twice horizontally because of that). You could just say "well let's double the clock speed then", but then you have to have expensive fast RAM in each console shipped, and expensive fast ROMs in game cartridges (if that support is used). If insteads games are loaded from some magnetic support in RAM, then you need even more expensive RAM in the console.
Quote:
Mhm. The priority bit determines if it's drawn in front of or behind the background. 1 is behind, 0 is in front.
https://wiki.nesdev.com/w/index.php/Fil ... _quirk.pngrainwarrior mentioned it already, but here's a visualization from the nesdev wiki. This case was of course unintentional, but some of the utility of the effect is that it requires 0 cycles to mask sprites this way since it is hardware accelerated (virtual hardware in this case of course). If a system allows for more (all?) sprites to be shown on the same scanline, its utility would be maximized.
full article:
https://wiki.nesdev.com/w/index.php/PPU_sprite_priority
I'd say if you want a fantasy 8-bit console as a step up from the NES or the SMS, you could do a lot worse than a TurboGrafx-16.
- 7.16 MHz 65C02 CPU core, faster in some ways than even the Blast Processing of a Genesis
- Read and write video memory at any time using fast multi-byte copy instructions (similar to DMA)
- Pixel clock switchable between 5.37 MHz with 256x224 pixels and 7.16 MHz with 336x224 pixels. Ideal for supporting both 4:3 and 16:9 TVs with the same assets designed for 8:7 PAR.
- 16-pixel-wide sprites, 16 per line, for up to 75% coverage in widescreen
- Tiles have 4 bits per pixel
- Each 8x8 pixel background tile has one of 16 different 15-color background palettes, and each 8x8 pixel background tile has one of 16 different 15-color background palettes
- Palettes have 3 bits per channel, like the Genesis without its shadow/highlight modes
- Only one background layer (without the rare, Japan-only SuperGrafx revision) but the fast CPU and VRAM interface allows for practical generation of repeating background patterns in software (like Battletoads for NES and Prehistorik Man for Game Boy)
- Wavetable audio similar to Konami SCC, Namco 163, or Virtual Boy
Bregalad wrote:
Sharing RAM and VRAM among the same adress spaces simplifies programming, but it means halving the bandwith, so halving CPU processing power and PPU limiting graphics (for example in the C64 if you want colours, each pixels is repeated twice horizontally because of that). You could just say "well let's double the clock speed then", but then you have to have expensive fast RAM in each console shipped, and expensive fast ROMs in game cartridges (if that support is used). If insteads games are loaded from some magnetic support in RAM, then you need even more expensive RAM in the console.
There's no capability of raster synchronization in this design, so the specific timings of things don't seem to be important for this system*. Suspending the CPU at NMI to draw everything at once to a framebuffer is an option, they don't necessarily have to use the CPU bus in tandem. ...not that this would have worked for the NES, but it's probably how this thing is already implemented in effect anyway? On modern systems the GPU waits for the frame to finish drawing before displaying, that's a very natural paradigm once you have the buffer. At its minimum RAM requirement maybe NMI could just be a block transfer of ~16k of render data for the frame to the "PPU".
* I think even the audio channels lack phase reset, so even the potential for 4-bit PCM is stifled.
After looking at my existing specs, I realized that I have enough RAM to give each 8x8 tile its own palette, and double the size of OAM (though the latter would require I move the palette data back a bit to make OAM contiguous). I will make these changes, and double the clock speed to 65536 cycles per frame.
I'm still not clear on how 256x192 with square pixels is possible without wide black borders on all sides. Is this not an NTSC console?
93143 wrote:
I'm still not clear on how 256x192 with square pixels is possible without wide black borders on all sides. Is this not an NTSC console?
It's not NTSC, it runs on a PC.
That is a valid issue though, I guess you'd have to implement some 4:5 vertical scaling if your really wanted it to run on an NTSC TV.
rainwarrior wrote:
Bregalad wrote:
Sharing RAM and VRAM among the same adress spaces simplifies programming, but it means halving the bandwith, so halving CPU processing power and PPU limiting graphics (for example in the C64 if you want colours, each pixels is repeated twice horizontally because of that). You could just say "well let's double the clock speed then", but then you have to have expensive fast RAM in each console shipped, and expensive fast ROMs in game cartridges (if that support is used). If insteads games are loaded from some magnetic support in RAM, then you need even more expensive RAM in the console.
There's no capability of raster synchronization in this design, so the specific timings of things don't seem to be important for this system*. Suspending the CPU at NMI to draw everything at once to a framebuffer is an option, they don't necessarily have to use the CPU bus in tandem. ...not that this would have worked for the NES, but it's probably how this thing is already implemented in effect anyway? On modern systems the GPU waits for the frame to finish drawing before displaying, that's a very natural paradigm once you have the buffer. At its minimum RAM requirement maybe NMI could just be a block transfer of ~16k of render data for the frame to the "PPU".
* I think even the audio channels lack phase reset, so even the potential for 4-bit PCM is stifled.
As for when the framebuffer is drawn, it's drawn all at once, so you can write to "PPU" memory any time. A hardware version would just copy $4000-$7FFF to a local cache and then draw that.
As for phase reset, not sure what that is.
93143 wrote:
I'm still not clear on how 256x192 with square pixels is possible without wide black borders on all sides. Is this not an NTSC console?
I thought SDTV NTSC was 4:3
https://en.wikipedia.org/wiki/480i
Fautenic wrote:
[As for phase reset, not sure what that is.
It's being able to reset an oscillator to the beginning of its cycle. If the square signal started high, then goes low in the second half of the cycle, you could set the frequency low and keep resetting the phase to keep it always high. That'd make 4-bit CPU-driven PCM possible, but only if the CPU is uninterrupted across the frames. (The graphics buffering scheme would probably make that impossible.)
Fautenic wrote:
93143 wrote:
I'm still not clear on how 256x192 with square pixels is possible without wide black borders on all sides. Is this not an NTSC console?
I thought SDTV NTSC was 4:3
https://en.wikipedia.org/wiki/480iThat number "480" is important. NTSC does not have a variable number of lines. (The horizontal resolution can be varied a lot, however, as it's just an analogue signal anyway.)
You have 192 lines. Either you have 48 blank lines to fill out the rest of a
240p picture, or you have to do a vertical rescaling.
The glass is 4:3 (Or at least, has been since ... uh, late 1960s?)
Old glass CRTs didn't have a fixed number of pixels. By changing the specific rate at which a digital device emits pixels, the width of each pixel changes accordingly.
So the specific amount of image that's encoded in the signal (e.g. 640x480i that's overscanned so only ≈600x448 is visible) means that a 256x192 console with square pixels would be "windowboxed" like the C64.
Consoles like the Master System that drew 192-scanline-high video modes instead often stretched the pixels a little bit horizontally to make the display more nearly full-width; correspondingly the screen is letterboxed.
lidnariq wrote:
Consoles like the Master System that drew 192-scanline-high video modes instead often stretched the pixels a little bit horizontally to make the display more nearly full-width; correspondingly the screen is letterboxed.
I'd forgotten that the SMS did that!
Thinking more about the actual dimensions represented here, the letterboxing doesn't seem that bad... 24 lines at the top and bottom, partially cropped anyway so it's more like 16 visible blanks? The corresponding pillarboxes would be a little more prominent, but maybe not a huge problem. Also eliminates the "safe area" problem that we normally have with TVs.
Then again I grew up with an Atari ST which had a big empty colour-0 border around the screen at all times...
Updated the console, now it has a palette entry for each 8x8 tile, twice as much OAM, and twice the clock speed.
Send 240p pixels at 3.5 NES master clocks (7 edges) per pixel, and they'll be square. A 256x192 pixel screen at this dot clock rate will be exactly as big as 224x192 pixels on a ColecoVision, NES, or SMS, which is also conveniently the size of the 80% title safe area marked on Nintendo's background planning sheet. So yes, it'd be underscanned like a 1980s home computer.
Two more questions for you all:
Anyone at all interested in development for this console? Would porting to/from NES as far as homebrew is concerned be doable?
How commercially viable would a game built for this console be (something like Shovel Knight comes to mind)?
I think it's hard to beat the appeal of coding for one of the most famous consoles of all time that was part of so many people's childhoods. People don't like the NES because of its specs, they like it because of the great times they had with its games.
As for the average programmer, he's usually not after the authentic experience of coding for 80's technology, most would rather use modern engines/frameworks that greatly speed up the process of creating games. Learning assembly and doing everything from scratch probably isn't in the to-do list of anyone who wants to quickly release a game they designed.
The whole idea was to make a system that others could develop for, and make my own games for it as well. Not simply as a hobby though, but also as a means of income. I dedicated months to the design of the console and the development of the game which I thought was great, and people I knew also thought so. Only now, now that I'm trying to figure out a marketing strategy, has it really set in that maybe this design isn't a good idea, that it won't work.
I don't know whether I should modify the existing console design, make a new design, or ditch the idea of a fantasy console entirely. After all, there are platforms like Construct, RPG Maker, Scratch, Unreal Engine, Unity, Steam, etc.. So I know it can be done. The problem is, I've dedicated so much time to this concept, that I have no other ideas. I'm almost bone-dry.
I'm just so frustrated and stressed out at this point, and I don't know what to do.
Well, if it's good enough for your own games, that's already a win. But if you really want others to adopt your framework, I guess you'll have to decide who this product is really for (can't please everyone, unfortunately) and go ask them what their needs are. In 2018, assembly language is definitely a hobbyist thing... people trying to pump out commercial games quickly will look for something that increases productivity. Coding game engines from scratch is hardly commercially viable these days, because the typical number of sales of retro games doesn't cover the hours of work necessary to build something from the ground up.
It's hard to give advice in that case. If the main motivation was monetary then a proper market research before starting would have been a good idea.
Usually project like theses are based on passion and the main goal is not monetary but more a sense of personal accomplishment. Like mentioned by Tokumaru, people works on older consoles not because they are convenient but more out of childhoods memories they had about them. Myself included, I would have a hard time to create a project for your fantasy console since for now there is not much information about it, doesn't have a physical version (for me this is important) and already just for the nes I have not a complete project yet so it would make little sense to try something on it.
Before continuing on your project you need to define your target audience and get more information about it. Your friends will always support you and give a "rose tinted view" which may give you a false sense of everything is fine.
Your project is interesting and it's great that you made it that far. It is an accomplishment by itself. Now the next step is finding your audience.
Don't give up! Maybe just take a break from it, that's important too
You probably should have a look at the Pico8, as you are basically competing with it, and the C.H.I.P. also see the new Atari console.
To be commercially viable you need a store, and advertising. Porting something like Shovel Knight is pointless however, as I can run it on PC, 3DS, Vita or Switch?? already, what does me the person starting at the screen care that it is running on a emulated 6502? Its still on my PC screen just the same. Porting it NES is a different story as then I can to put a NES cart in to my NES and play with a REAL NES like I did when I was a little kid and that is different, although technically inferior to any of the above methods.
The improved graphics patches seems to be somewhat of a hit, so maybe being able to run improved graphic versions of NES games, might be something people go for, but again that can't be commercial. Steams being a great pile of garbage with a few gems in it, if you can make a point that you will have games and curate games of a certain style and quality you might be able to carve out a niche.
Maybe worth pointing out that the commercial success of pico-8 itself directly relies on the fact that all of its games are not commercial.
The real "fantasy consoles" that are used to make commercial games are just engines (RPG Maker, etc.) we just don't call them that because there's no pretense of this being some fictional machine, but it's more or less the same thing. Some sort of virtual system that has its own set of limitations and capabilities, and you use it to make a game.
Just saying, this thread remind me
that other thread I made just 2.5 years ago about making your own arcade games which basically means designing your own gaming system.