I started making my own OS at about 10 yesterday.Its kinda hard to get started, you have no text routines, no input, nothing.Most everything I started with dealt with the ports like sleep, direct input keychecking, and copying a buffer in ram to the lcd.From there i added some basic functions.Right now, the routines used by my os include...



its not much, but its getting there for the first day

Sounds good to me. Do you have any high-level goals for this project?

An excellent question. I'm also curious if you wrote all those routines from scratch, cannibalized them from a previous project of yours, or borrowed them from others' code.

with the exception of sleep, getcsc, drawrectangle, and the line routines are borrowed from other people, Checkkey and DirectIn is really just my Checkey routine divided into 2 parts. The rest were handwritten on the spot.

I dont really have much of a plan, but I'm focusing on adding the basic things first.I am thinking about setting up 4 buffers for drawing is perspective to TIOS's 2.The 4 are all used when in grayscale mode and in mono thats another 768*2 bytes of saferam Its pretty cool i think.One of the things i also plan to do is to align my saferam consecutively.I though it sucked that when you may need 1000bytes you have 1 768 byte buffer and 1 256 byte one Might jjust add a layering and oam system similar to the gba's instead though.

Good stuff regarding the routines. I'm quite curious where you got the line-drawing routine, actually, considering how notoriously hard-to-write line-drawing routines are. I'm confused why you need four buffers for grayscale; can you explain?

the line routines were borrow from the decompiled MOS line routines in the DCS source (you can tell there decompiled by the way they're labelled) 4 lvl grayscale takes 2 buffers to use, so having 4 buffers gives you a backup one. (of course, someone could also get smart and add a 8 lvl grayscale routing >_>)

I'd agree that line clipping can be rather tricky, but line drawing is quite straightforwards. Bresenham's line algorithm makes light work of it, certainly.

Except that 8-level grayscale should only take 3 buffers if done properly. And although the line drawing routines were original disassembled from MOS, they have been heavily, heavily modified since then. I don't suppose you happened to read the license ( http://www.cemetech.net/doorscs/docs/source6/license.txt ) that was attached to that code that you borrowed?

thats a fairly interesting page >_> i saved it to my flash.Might give a looksy later and possibly make my own line routines from scratch

Kerm i assumed they where from MOS, and under the MOS license

I'll be honest, it's a bit of an uncomfortable gray area, because on the one hand I am using bits of code in those line-drawing routines that are not originally mine, but on the other hand I've heavily modified them to improve bugs and shortcomings in the originals as well as some needs for those routines specific to Doors CS. I'm not sure exactly where that stands, and since MOS doesn't come with an explicit source code license (or indeed any explicit license) I guess I need to err on the side of caution and say that those line drawing routines (as you took them from the Doors CS 6 source; the DCS7 source has overhauled MOS-compatible line routines) are still mostly at the whim of the original MOS license.

I love gray areas.

Anyway, OAM-Wise I'm looking towards the OAM constisting of 1024 bytes.That means the user can have up to 128 8x8 black and white images or 64 8x8 4lvl grayscale images.This would be equated to the value OAM_Data.Then there'll be a table call OAM_Flags set up like this...

Code:

So that'll be 3 bytes for each entry.Since you can change the sprite number, you can use the same images multiple times.For example, you can have 1 picture of a monster in the OAM_Data and have 3 of the OAM_Flags pointing at it to have 3 of the same monster.You can tell whether or not to display a grayscale pic with bit 'gray', hide the sprite by resetting bit vis, and flip with bits hflip and vflip. There are 2 bits used for the rotation, 00=no rotation, 01=rotate90, 10=rotate 180, 11=rotate 270. You can change the priority of the sprite with the prio bits whereas there are 4 layers, layer0, layer1 layer2 and layer3

Can you specify what OAM stands for? This is a new concept on me.

OAM stands for object attribute memory and is basically a very organized and advanced way of diplaying sprites in sytems such as the GB, GBC, GBA, and NDS

OAM's usually constist of 2 parts.The first is all the sprite images lined consecutively,

Code:


the second part tells where and how to display the images on the screen.

That makes perfect sense, thanks. It sounds to me like you're interested in creating a gaming-centric OS, then, correct?

Not entirely game based, just a few things that make life easier

Plus, the more organized the system is, the greater chance someone might create a gamemaker and all hell will break loose X) Imagine games coming out left and right for the TI simply cuz people dont have to learn ASM X) Of course, I'm gonna make an edittor for programs myself

A similar system was employed in the popular TMS9918, where it was called the Sprite Attribute Table (SAT), and I'm sure the same goes for many other video display processors. As these chips had hardware support for sprites using a table in video memory was indeed a good way to organise them, but on a system where you're drawing sprites in software I can't help but feel it would be painfully inefficient (in comparison to the user calling a sprite drawing function, as is the conventional wisdom).

ah, noooo.For 1, the table isnt going to be required to use, its optional. For 2, the speed would depend solely on how many sprites the person wants to display.The first step before even attempting to display a sprite is to check if the visibility flag is set.If not it just skip.It'd be wayyyy slower to render all the sprites by hand than to have an organized table like the OAM do it for you

A table of sprite attributes wouldn't magically make anything faster; you're still having to go through every item in the table, check if it's visible or not, then draw it if so (plus sorting). However, when working on a specific program you can make particular assumptions (for example, that you don't need to sort most of the sprites) which a generic solution may not be able to make.

If you still make the underlying sprite-drawing routines publicly accessible then there's no problem, and I'm sure that a generic table-based solution may be sufficient for a lot of projects.

I didnt say it'd make anything faster, i just said it'd be faster than drawing the images by hand.No sorting is needed, the routine to update the OAM will use a var call OAM_Layer. When called, is draws only the sprites with the priority=layer, OAM_Layer is incremented and done.This way, the higher priority images are on top of the lower, and the time needed to draw the sprites is only 1 run through the table

When are there going to need to be multiple layers, though? The majority of games that I've seen for the calculator use a single layer of sprites, like a tilemap.