Image Map Image Map
Page 11 of 11 FirstFirst ... 7891011
Results 101 to 104 of 104

Thread: Osi c4p

  1. #101
    Join Date
    Jan 2011
    Location
    Vancouver, BC
    Posts
    4,853
    Blog Entries
    3

    Default


    Mists clearing?
    The airport is still fogged in Dave, although I think I see the tower in the distance.

    Btw, I got this from the creator of WinOSI over on the osiweb forum:

    Earlier versions of WinOSI initialized the memory with 0's on start. This differs from the real OSI which did not initialize color memory on reset, so you got the color of whatever the 2114 static memory happened to power up with. I've found some static RAM maintain a good percentage of bits, even when powered off for a while. Turning on an OSI that did not power-on reset could give you a screen you could half read with stuff left over from it's last use. Other systems seem to initialize with almost the same bit pattern (mostly 0's) every time.

    Later versions of OS65D or Plot Basic do initialize color video RAM on bootup. My current WinOSI version does initialize RAM with random values, and it's damn annoying as the screen is almost impossible to read when color is enabled.

    I think the 540 board could do black as suggested when using a custom RGB interface, but the composite color interface is as you have seen.
    So it appears the behavior of my 540B board on initialization might well be normal, both the random checkerboard background and the visible color background around each character.

    Also I had made a mistake with Terry's in assuming his machine initialized with a solid orange background. I was confused because he was doing the same 'blue X' test program from the manual. When I entered the program, I got an X, and a blue square somewhere else onscreen, and no solid orange background. However, I discovered a few things.. #1, there's a few different variants of the manual, #2 they are all riddled with errors. Terry was using a later version of the program that actually painted the entire screen orange *first* and then put the blue X up. And even his had one of the poke statements wrong, which he thankfully corrected. The version of the program I attempted was the earlier one - it was a four liner that basically just poked an X and then tried to poke a blue tint to the same point in the screen. But the poke statement is in error and pokes the blue a line or two away from the X.

    Anyway, it seems like things are working as they should. I guess there wouldn't be a way to force the color memory to go to '0' on initialization?

  2. #102

    Default

    Unlikely - it's something you'll have to live with.

    Now, since it seems to be fully working, you are now in a position to do whatever it was you had in mind when you bought it.

  3. #103
    Join Date
    Jan 2011
    Location
    Vancouver, BC
    Posts
    4,853
    Blog Entries
    3

    Default

    I'm trying to learn programming and was advised it was best to refresh on BASIC before going to something a bit more complex like assembly.

    I'm trying to program a simple tank shooter game for the OSI to start.

    One thing I'm trying to figure out is, if I want to draw stuff onscreen (like boundaries, etc) - how to not go crosseyed trying to draw things square by square with poke statements. I'm wondering if there's a way to create a 'draw' program that lets you 'freehand' it a bit and then translates it into the required POKEs. Sort of what like Ken Williams did with Sierra's early adventure games.

  4. #104
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,551

    Default

    The best way is to learn to clear the screen (video and colour memory) and setup colour mode. Write your own subroutine and call that at the start of your program.

    The next thing to do is to learn to plot a point (at an X, Y location defined by these variables) as another subroutine. This can be as simple as setting the specified X,Y screen location to either a <SPACE> character for OFF/BLACK or a <SOLID BLOCK> character for ON/WHITE - or more advanced, by taking note that you can divide each character cell up into four separately addressable 'quadrants'.

    Having got a subroutine to plot a single point (by specified X, Y and Colour) you can move on to drawing a line using Bresenham's line algorithm (see https://en.wikipedia.org/wiki/Bresen...line_algorithm) - but ignore the maths and go straight for the pseudo code!

    Having developed a subroutine for plotting a line from X1, Y1 to X2, Y2 in colour C - you can develop a subroutine for drawing a box - comprising of four lines.

    Bresenham also came up with a circle algorithm from points as well - and this can be extended to an ellipse if desired.

    You can then build your graphics primitives up from there.

    You would want a subroutine for printing text at a given X, Y point also.

    You then develop your 'game' (or whatever) by stringing this all together.

    I have developed my own graphics library in Java for my own use - and it is amazing the effects you can get by using a very simple low-level 'plot a point' function. It may not be the quickest library in town - but porting it to another hardware platform is simple!

    Dave

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •