ROTRO

ROTRON?

Purpose

The ROTRO (or ROTRON?) is designed to fill an ever-growing void. If you want to program a 2D pixel art game nowadays, it's done with lots of layers between you and the final output (like libraries on top of OpenGL). You need to understand a bunch of strange systems / dependencies and end up doing things very indirectly. There have been attempts at making platforms to encourage people to learn programming, but I think ASM or C + Libraries, or WYSIWYG building block things are hard to get started with (I failed even though I already know how to program to some degree).

I'd like to promote the idea of a BASIC syntax language which is scalable into direct hardware access and fancy OOP. You can later gravitate towards the inline asm and skip the OOP, or go the other way, or learn how to use both to their respective advantages. I'd base it off BlitzMax which is a BASIC/OOP hybrid I'm using a lot. Here's what I'd probably understand if I was new to programming:

// Open a screen and draw the first 16 colors as filled rectangles.
// (Opening a main screen automatically sets scaling and centering.)

Open main screen with id 0, sized 320, 256, using palette offset 0

Set palette index 0 to 42, 127, 255	// Set background color to sky blue.	

For c = 0 to 15
	Use color index c 		
	Draw filled rectangle at c*32, 0 sized 32, 48
Next c

Update display	// Tell video chip to generate a new frame image.

Delay 6 seconds
End program

This could be scaled back to a shorter format (it's just word replacement for the compiler), allowing a the learning programmer to write faster and more compact. In strict mode the compiler is more nitpicky, variables will have to be declared, etc. The programmer can also be more detailed to get around the sometimes unwanted assumptions made by the easy-to-use functions.

StrictMode
Global int DWidth = DisplayWidth()	// Monitor rez.
Global int DHeight = DisplayHeight()
Const SCREEN_WIDTH = 320, SCREEN_HEIGHT = 256

// Figure out maximum scale-up to use on current monitor.
Global byte FScale = Min (DWidth / SCREEN_WIDTH, DHeight / SCREEN_HEIGHT)

SetFinalScale FScale, FScale // Scale onto HD monitor.

FlushAllGfx()		// Tabula rasa, clear all sweepers.
RegGfx 		0, SCREEN_WIDTH,SCREEN_HEIGHT
SetPalOffset 	0, 0 	// No palette offset.
SetGfxPos 	0, 0,0 	// Place in top left corner of 8-bit buffer.
SetGfxScale 	0, 1,1 	// No scaling on 8-bit buffer.
SelectGfx	0	// Select for drawing output.
Global ptr MyScreen = GfxAddress(0)	// For poking and peeking later on!

SetPal 0, 42,127,255	

For local byte c=0 to 15
	UseCol c 		
	DrawFRect c*32,0, 32,48
Next

Sweep(0)	

Delay 6000
End

Compiling this could output text files with assembler and "Readable Assembler" (where MOV r0,r1 is written Copy r1 into r0 or something like that). The programmer can then look at these files and go: Aha! that's what's happening at the lower level! Maybe even copy-paste some asm, optimize it as an inline function replacement. The programmer can either use Readable Assembler or regular assembler inline. It would help if comments were retained (or even created by the compiler), offering reference points.

Now, there are languages out there which does output asm text files (BlitzMax for example), but when it comes to graphics there's the whole layer of mystery added because of the libraries being used. On my platform, changing a pixel ("Plot Color,XPos,YPos") would simply be a memory operation like "Poke Address,Value" or "STR r0,Address". Scrolling would also be a simple memory operation as the video chip uses screen pointers. In a way, this makes the language quite low level.

System Components

VIDEO CHIP "Zebranky"

Each video frame update this chip constructs an internal "HD" 24-bit image and DVI out signal by using several "memory sweepers", each consisting of:

A pointer to somewhere in main memory. Each byte in memory is a pixel - a reference to a palette index. When using multiple pointers/sweepers then bitwise operation and mask values can be used to create complex overlapping effects (such as searchlights and parallax planes). Scrolling is handled by simply moving the pointer.
A pointer to an offset in a 256 color 8*3-bit RGB palette (used when generating the internal 24-bit image).
X and Y bounds for the sweep, setting size (X limit being linefeed on the internal image... the sweep itself is linear through the memory).
X and Y can be swapped and inverted, allowing for simple rotation/flipping.
Origin displacement (so a smaller screen can be centered on a 16:9 WUXGA display, or displaced to allow for split-screen effects).
Integer X and Y scaling (so a high resolution LCD display can show 160*256 "wide-pixels").

One or more sweepers could be used to display a screen. "Sprites" could be done either by activating more sweepers, or by manipulating image regions of memory. The video chip, once told to do a frame update, will probably lock up the RAM, limiting the CPU to internal activities while it waits for the video update complete signal. Hmm... maybe Zebranky is a FPGA? Maybe not, because it doesn't benefit from parallelism.

I don't quite know how the image buffer should work (or anything about DVI signals). If the sweepers cake things directly on a 24-bit image, then 8-bit palette bitwise operation won't make sense as that information is discarded during 24-bitization. Maybe there needs to be an intermediate 8-bit buffer which can be scaled onto the final 24-bit image. This way multiple layers can be caked onto a smaller 8-bit image buffer quite quickly, then scaled up all at once. There can only be a single global 256 color palette (which is no big loss as it's plenty enough). The palette pointer for a sweeper could simply be an index offset so a pixel region with byte values 0-7 has, say, a +32 offset using the "night time" 8 color palette.

I suppose the video chip could also do a post-8-bit pass where it grabs 3-byte chunks in a 24-bit sweep mode.

1Ghz "Orz" CPU

The CPU can be fairly modern. I see no point in keeping the specs down just to be retro or something. Retro graphics however have real utility as they are very easy to deal with, and whether they look great is up to the artist more than any palette restriction.

"Syreen" AUDIO CHIP

Enough channels and stuff. I don't know a lot about audio.

512MB "Mmrnmhrm" RAM

Half a gig should be sufficient. Maybe a regular (mini) memory slot to allow for upgrades?

SD card reader

Using a SD card as a main "drive" works pretty well on my Raspberry Pi. It's nice to easily be able to swap out the card. Sort of like Workbench floppies.

Connections

4 x USB (e.g. keyboard, mouse, joy, thumbdrive).
Ethernet port.
3.5mm Audio jack.
AV video out.
HDMI out.
Power in.
14 x digital GPIO + 5V & GND.

Also!

Power-on wheel.
Turbo switch.
HDMI/AV switch.

Firmware and Software

BIOS: Minibench 0

OS: Minibench 1.0 - the OS where all of the GUI elements are just little images and you can also redraw the mouse cursors in an editor and draw tiles and tile maps for the desktop, and edit icons, and it's all saved in the same simple 8-bit image format in some folder somewhere. No memory protection. Cooperative multitasking. Compilable BASIC-ASM with IDE. CLI commands can be full english words/sentences and also suggest what you might have done wrong (e.g. partial path errors). Pre-installed games, if any, are not shit. Runs in whatever resolution the display is, but has a 64/256 color system palette for icon/GUI consistency (and theme colors to play around with in a palette editor).

Art by Arne Niklas Jansson

AndroidArts.com