From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: rec.games.programmer
Subject: Re: video game standard!?
Date: 7 Sep 92 03:55:40 GMT
X-Maildoor: WaflineMail 1.00r


     -=> Dreamweaver spoke of "Re: video game standard!?" <=-
    To All at 09-05-92  15:32
 Dr> As for the graphics/video, I'd opt for a vidRAM scheme that works at
 Dr> the one pixel/byte level (I've been doing EGA/VGA stuff for years ...
 Dr> did CGA stuff when it was in ... and have done Amiga at times ...{and
 Dr> I'm gettin' a bit tired of the calesthenics necessary to smooth scroll
 Dr> material through screen bytes ... hence I'm fond of the 256-color
 Dr> modes).

Are you suggesting the use of a VGA chipset?  {look out for
flames}  I like some of the features of the chipset but ... Thier
are several things that would make it next to impossible to use.
Bummer make it easier to design such a system.

 Dr> Also, it would be nice to work with a screen resolution that had a
 Dr> decent aspect ratio ... and additional memory on vid/RAM format for
 Dr> background pages without eating into the program space.  My example
 Dr> here is the Mode X and Mode Y stuff on VGA:  real nice, but not what
 Dr> hardware designers had in mind, or they would have made them legitimate
 Dr> video modes.

My thought of

Video
    RGB and NSTC output
    24bit pallete (16million colors to work with)
    256 colors

Graphics hardware
    320x200x256 resolution (is thier a need for higher?)
    panable display area (virtual screen)
    RMW (read modify write mode)
    functions
        copy    src,dest  (result to destination)
        and     src,dest  """
        or      src,dest  """
        xor     src,dest  """
        cut     src,dest  """   (if source is 0 no copy)
    rectangular moves on a per pixel basis (built in) in all RMW modes
    ?should graphics primitives be supported?
    16 bit access to all display planes
    display planes are memory mapped (for easy access {for once})
    each memory byte location is a FULL pixel (makes for easy
        ploting)
    ?split screen?
    ?display memory size?

Audio
    2 16 bit DAC's stereo or 2 seperate channels
    2 DMA channels for audio
    8/16 bit audio
    ?programable sound generator 16 channels?
    16 chanel audio mixer (stereo output)
    each channel may be panned (position effects)

storage
    cartridge - up to 8megs of ROM for game programs ?THAT's it?
        hehehe

    disk cartridge - optional 1.44 meg 3.5 disk drive and
        controller expandable up to 8megs of ram internally
        ?simms? no internal ROM needed consol will support a
        the drives (built in) all patches to the system should be
        on the disk
        ?should a 720k or 360k drive be used instead?
        programs can be loaded semi permanently (it' just another
        module) because DRAM refresh is continued even when the
        consol is off (but not unpluged)  base memory is
        recommended to be 512k

Operating system
    OSK - this is Os9 for 68k machines

    advantages
        romable
        modules are rommable
        VERY easy to patch for new hardware
        excelent embedded control
        multitasking
        multiprograming
        modular
        generic IO handling
        device access
        easy cross platform developement
        we can make it anything we like

    disadvantage
        ?cost?  - retails for $100 (embed cost???)
            My guess is it will probably cost about $5-$10 OEM
            per system, the reason is that it will not include
            any of the usual development tools etc.  Just the
            basic kernal. Everything else will be developed
            seperately by US so it should be cheap and make our
            life easier, I'll look into this I have microwares
            internet address

        not a popular OS - this is the main weakness this however
            is not really pertinent (explained later)

    custome

    advantage
        we can make it anything we like

    disadvantage
        It's a LOT of work that I would frankly like to skip!
        developement will be slow
        many patch headaches

    NONE
        This means sytems calls and everything is supported on
        the cartridge.

    advantage
        design will be simple and the programer can do anything
        they want period

    disadvantage
        developement will be very difficult and slow if not
        impossible.   Each cartridge will have it's own ?? and be
        a royal pain to work with.  The Disk cartridge will need
        it's own ROM for boot strapping etc.

developement hardware
    a simple special cartridge that plugs into the consol.  it
    allows debugging etc through a serial port to whatever
    platform you are using.

    OSK here would be GREAT it could handle a lot of the STUPID
    details most poeple shouldn't and therefore don't want to
    deal with.

    programs can be cmpiled and run within the confines of the
    cartridge without using host memory

    a simple "interface" protocol can be designed to allow the
    design of each platforms unique way of handling debuging and
    programing etc.

    a disk drive is optional (allow you to store your programs
    without wasting your valuable computer resources) SCSI and
    floppy should be available

developement software
    Compilors?
    at the risk of getting flammed I suggest C  it's easy to port
    popular and it's easy to make libraries for anything you
    want.

    C++ could be used as well (huh?) because Gnu C++ is available
    for Os9 based systems (minor mods needed for this system).
    It is none-the-less available (OOP makes game programing much
    easier).

cost
    the cost should be kept to a minimum so if anything is too
    expensive we will have to make a compromise.

That's about all I can think of for now. :)

        Stephen Cyberman@Toz.Buffalo.NY.US
        Scripted at Sun  09-06-1992  22:01:54

... Internal stack overflow - System halted.
--- Blue Wave/QWK v2.10
                
Newsgroups: rec.games.programmer