Help me design an early-80s microcomputer from an alternate universe

I'm building a simulated late-70s/early-80s style microcomputer, called Mini Micro.



It's built atop MiniScript, and will ultimately be available on the web as well as installable on various platforms. The web version, at least, will be free; probably the platform versions too.

The point of this project is to recapture some of the magic of those early days, when your computer booted up to a blinking cursor, just waiting for you to give it some commands. The "shell" uses the exact same language as the programming environment, and in fact supports interactive, immediate-mode commands that can interact with the display and program state just like program code. This makes it (I believe) a great environment for learning programming.

But unlike the real computers in those days, this is using a modern language, has a decent GUI code editor, and will have fairly powerful graphics and sound capabilities. I'm thinking of 8 display layers, any of which can be set to (1) solid color, (2) text, (3) pixel buffer, (4) sprite layer, and maybe even (5) 3D graphics. The screen shot above shows a text layer on top of a pixel buffer, into which the code shown has done some drawing. All this makes it a fun environment for programming.

I'm really pleased with how all the underlying technology has come together, and now it's time for a carefully thought-out API for the end user. This needs to support all the different graphics and text operations, plus sound, file I/O, and keyboard/controller input. And I'd love to have more brains than my own on this.

Is there anyone else here who gets nostalgic for those days? Want to help design the home computer environment from some alternate, slightly more advanced dimension?

 

To make it more specific... here are the general areas we need to cover. It's a lot, but it's finite.

Display Modes
Set each of the 8 layers of the display to off, solid color, text, pixels, or sprites. (And possibly in a future version, 3D graphics.)

Text Display
Output text to any position in the 25x68 character screen, with any foreground and background color (and inverse mode).

Pixel Display
Draw or fill boxes, ellipses, polygons; draw lines; maybe (in the future?) create/move/destroy “live pixels”. Also, draw images loaded from disk.

Sprite Display
Create and destroy sprites; change their position, rotation, scale, layering, and color tint.

Keyboard Input
Get full text input with standard line-editing; get a single character input; check whether a gettable key has been pressed; check whether any specific key is down (including modifier keys). (Controller input will be just a special case of that last function.)

Sound Output
Play a sound (one-shot or looping) in any of 8 (16?) audio output channels. Set the pitch, pan, and volume of any of those. Check whether any channel is busy, and get/set the playhead of its sound.

File I/O
Get/set the current working directory; get a list of files in a directory; create/delete files or folders; read and write text files, sound files, and image files (JPEG or PNG).

Utilities
Built-in modules for helping with colors, and probably other stuff we'll think of while fleshing out the above.

 

What do you mean by layer? You mean like how you are displaying the text on top of the image?

 

Yes, exactly.

 

Nope. I'm not a relic.

Never actually used an 8bit computer... can't imagine I'd be that impressed.

 

Neat project!

What about networking? Even if it's rudimentary and inefficient. Someone might want to implement a simple MUD on it.

A simple NetHack would be a good test application for it, too.

Constraints are good. It might be neat to limit it to a 256-color palette, or even fewer colors. And I think 3D would be taking it too far. I'd rather see more focus on the core features rather than unbounded feature creep.

 

Hmm, that's an interesting notion. I did exactly that in Python back in the day; maybe it'd be a good fit here too. (Or maybe that would be better suited to the command-line version of MiniScript... but I could still see wanting to make a multiplayer MiniMicro game using sprites or whatever.)

That's a great idea. I'm dreaming of writing a book or two on game development with it, where most chapters would simply walk you through creating a particular type of game. (The book practically writes itself!) This would be a good one to include.

You are probably right about the 3D. And certainly right about unbounded feature creep. I don't see the need to impose artificial constraints, though. The pixel layers are simply a PixelSurface, which is a 32-bit color buffer; no reason to go out of my way to reduce that.

 

In case anybody's interested... here's the API I've come up with so far. I think it's off to a decent start.