80s-90s styled game engine for PC?

[Tsutarja]

Not sure if this is the best sub-forum to post...
This is only an idea and I need some opinions on whether you think this would be a good thing or not.

What's the purpose?

The purpose of this is to have people be able to create 80s-90s styled games without having to worry about copyrights and such. The engine will be kinda like an emulator, but it will emulate a console that never existed. One of the big reasons I wanted to do this is how you program things with assembly language and how things behave when you are giving instructions directly to the processor. Sometimes I'm feeling that the PC's operating system is limiting your programming possibilities.

What will this 'console' be like?

This is only a rough plan, but here is what I have planned out so far

Processor

8 bit processor
4kb of RAM
~3.50 MHz clock rate
16 bit program counter
supports bank switching

Graphics

256x240 resolution
2 background layers (background/foreground)
4 tilemaps (nametables) 2 for background and 2 for foreground
tilemap mirroring setting.
12 palettes; 4 for sprites, 4 for background and 4 for foreground
each palette has 7 colors + alpha channel
color is defined by LLSS HHHH
H = hue
S = saturation (saturation 0 gives always grayscale regardless of hue)
L = lightness (or brightness)
Horizontal blank counter that can generate interrupts (similar to scanline interrupt found on some memory mappers on NES games)
256 different 8x8 sprites in memory at once
256 different 8x8 tiles in memory at once (shared for background and foreground)
CHR RAM
max 64 8x8 sprites on screen at once
no colors/sprites per scanline limitations
sprites can be layered either below, between or on top of the tilemaps

Audio

8 channels
4 generators and 2 sample players and 2 waveshape players
generators can produce sine, pulse, saw or noise
different 'timbre' settings (sine and saw gets inverted, while pulse has pulse width and noise has either white or "gate" noise)
note periods are read from built in lookup table (coarse pitch)
fine pitch is given to a second register as a signed value
sample players can play samples as 1 - 4 bit delta samples depending on the channel settings
samples can be pitched from -7 to +8 semitones
waveshape players play a custom waveshape
waveshape can be either 8, 16, 24 or 32 units long

Instruction set

The instruction set is mostly based around the 6502 instruction set. Some new instructions that will be added are here:

Code: Select all

SSB        ; Store set bits. Stores only set bits of the value in accumulator to the given memory address
             ; e.g. A = #%1010 0110
             ; $005E = #%1001 1100
          ; SSB $5E = #%1011 1110
          ; useful for setting bit flags in variables/registers
SCB       ; Store clear bits. Works with the same idea as SSB, but stores only cleared bits.
             ; e.g. A = #%1010 0110
             ; $005E = #%1001 1100
          ; SCB $5E = #%1000 0110
PHX/PHY             ; Push X/Y register
PLX/PLY             ; Pull X/Y register
TXY/TYX            ; Transfer X to Y/Y to X
WAI                 ; Wait for interrupt
SWI                 ; Software interrupt (replaces BRK as it seems to generate interrupt)

There's probably going to be a lot more instructions as the 6502 set has a lot of 'unofficial/illegal' instructions which are the ones begin replaced.

What do you think of this whole project? I'm trying to make the engine to be somewhere between the 8 bit and 16 bit consoles in terms of processing power and functions and such. On this early stage of the whole project, feedback is really important. Are there anything you think I should add, remove or modify a bit?

[dougeff]

If this is just emulated (ie, no hardware) why impose a CPU speed limit?

Also, I suggest you use the Atari 7800 color palette... 16 hues and 16 brightness. As long as there's at least 1 good red and 1 good yellow, and more than 4 grays, I'll be happy.

Also, include (indirect), x - opcodes.

[freem]

When I saw the thread title, I immediately thought of Super Play, though your idea seems to have a different goal.

If you're using a 6502-like instruction set, why not start from the 65C02 as a base? It already implements PHX,PHY,PLX,PLY, and WAI.

[mikejmoffitt]

I might have you covered with sound stuff - I worked on this library with a friend:

https://github.com/TravisWhitaker/LibPOLY

Later, I made my own simpler wavetable generator (think TurboGrafx16):

https://github.com/Mikejmoffitt/LibChip

[lazigamer]

Funny enough, I programmed my own fictional 8 bit console that I called Arcadia (at the time not knowing Emerson beat me to the name). Envisioned to be a system that could have come out in the mid 1980s. It has similar specs to what Tsutarja proposed, I even ported SMB to it as a proof of concept.

Controls:
X- A button
Z- B button
Arrow keys- D pad
Enter- Start Button
Right Shift- Select Button

NOTE: I didn't finish the audio on the port of SMB; the audio will be hard to listen to, so you might want to keep the volume down.

Here it is, source and all.

[Joe]

no colors/sprites per scanline limitations

This would be an interesting problem for hardware implementations. Loading 64 sprites worth of data during hblank probably wouldn't be possible, but I don't know what alternatives exist.

[lidnariq]

I think you should seriously compare what you have here to the PC Engine = Turbografx's or the Supergrafx's capabilities.

[Sik]

For the record, since you mention HHHHLLSS for the palette format (I'd suggest hue first for this): once I had considered this, with hues 0 to 14 being meaningful hues (in steps of 30º) and hue 15 being grayscale (being 1111LLLL). This also means that when hue is not grayscale, that neither LL nor SS reach 0% nor 100% (because you can get those with the "gray hue" instead). But that was for lossy encoding of colors, not for something I'd get on retro hardware (fake or not).

A more likely alternative I came up with is RRGGGBBB, with the last B also being the last R (i.e. red and blue share the LSB). Note that this one is also very easy to do as a hardware circuit if you don't go through composite (and it's a pretty decent master palette).

[Bregalad]

I don't understand why you would limit to a 8-bit CPU instead of using the PC directly for programming. Also, I don't want why you'd want to have BGs at all, just support enough sprites of large size, and it will be trivial to simulate a BG with sprites.

[rainwarrior]

The only person who will deal with how your program is made is you. Users of a program only get to see its output. You can pick whatever arbitrary standards you want when making your art and sound, and you can easily make something that looks and sounds NES / SNES / TG16 / etc. in any capable 2D engine. You don't need to create a whole new engine just to do some narrow subset of things.

If the engine is a fun project for you, then by all means go ahead and build it, but all you really need to accomplish the right output for a game is art direction and standards.

[psycopathicteen]

I don't understand why you would limit to a 8-bit CPU instead of using the PC directly for programming. Also, I don't want why you'd want to have BGs at all, just support enough sprites of large size, and it will be trivial to simulate a BG with sprites.

At least it doesn't have to be as limiting as the 6502. I think it should be pretty easy to design an efficient 8-bit/16-bit CPU with 16-bit addressing.