http://www.osnews.com/story.php?news_id=15223

I haven't read the whole thing yet but I've read enough to know that it 
may be of interest to a few folks around here.

-- 
Golan Klinger
Dark is the suede that mows like a harvest.

Golan Klinger wrote:

> http://www.osnews.com/story.php?news_id=15223

     Very nice article.

                                      Truly,
                                      Robert Bernardo
                                      Fresno Commodore User Group
                                      http://videocam.net.au/fcug

rbernardo@value.net wrote:
> Golan Klinger wrote:
>
> > http://www.osnews.com/story.php?news_id=15223
>
>      Very nice article.
>
>                                       Truly,
>                                       Robert Bernardo
>                                       Fresno Commodore User Group
>                                       http://videocam.net.au/fcug

It has a few inaccuracies.

"The one byte that represents the colour under one of the 8x8 pixel
characters is divided into two nybbles of 4-bits. Each of these nybbles
can store a number from 0-15, representing the 16 available colours,
and thus the Foreground and Background colours to use for the graphics
in that character square."

I'm not an expert on the C64's architecture, but I don't think this is
true.

"Programmers relied on 'fast-loaders', essentially decompression
software loaded into the disk drive's RAM & CPU, to speed things up
again."

Again, I'm not an expert here, but I don't think accelerators did
anything with decompression.

a7yvm109gf...@netzero.com wrote:
>
> It has a few inaccuracies.
>

In addition, it described the SID chip incorrectly as only having 2
"midi" type voices and 1 white noise.

*sigh*

However, 1 good thing about it was that I was able to find a version of
Geos Ensemble that I was able to download and try out. (
http://www.breadbox.com ). This is a PC-based version of Geos that's
evolved into more of a limited resource computing platform for
classrooms. The article goes into more detail on it in the 2nd or 3rd
to last pages.

I've run it for a little bit and it seems halfway decent for it's
evolution / focus. It would make a great Kiosk OS.

- Craig Taylor
http://www.ctalkobt.net/cbm

>>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:

a> "The one byte that represents the colour under one of the 8x8 pixel
a> characters is divided into two nybbles of 4-bits. Each of these
a> nybbles can store a number from 0-15, representing the 16 available
a> colours, and thus the Foreground and Background colours to use for
a> the graphics in that character square."

a> I'm not an expert on the C64's architecture, but I don't think this
a> is true.

Sounds like a perfectly accurate description of hires mode.

a> "Programmers relied on 'fast-loaders', essentially decompression
a> software loaded into the disk drive's RAM & CPU, to speed things up
a> again."

a> Again, I'm not an expert here, but I don't think accelerators did
a> anything with decompression.

Yeah, while there are loaders that do decompression on the fly to
speed things up, it's not the case with GEOS.

-- 
    ___          .     .  .         .       . +  .         .      o   
  _|___|_   +   .  +     .     +         .  Per Olofsson, arkadspelare
    o-o    .      .     .   o         +          MagerValp@cling.gu.se
     -       +            +    .     http://www.cling.gu.se/~cl3polof/

Yes, Geoworks Ensemble was an excellent OS overlay back in the day.  They 
aren't kidding, it works GREAT on old 386 machines.. and the printing 
ability of those things to any printer (including dot matrix) was impressive 
at the time.

Good to know it kept going.. too bad it didn't evolve very far, though..  It 
does look like they made a change to make it more 'current looking' with a 
Win95ish Start button style..

And it was one of the first systems that actually would multitask on a 
286....

I loved Geoworks......

"Craig Taylor" <ctalkobt@gmail.com> wrote in message 
news:1156561498.619039.192650@75g2000cwc.googlegroups.com...
>
> a7yvm109gf...@netzero.com wrote:
>>
>> It has a few inaccuracies.
>>
>
> In addition, it described the SID chip incorrectly as only having 2
> "midi" type voices and 1 white noise.
>
> *sigh*
>
> However, 1 good thing about it was that I was able to find a version of
> Geos Ensemble that I was able to download and try out. (
> http://www.breadbox.com ). This is a PC-based version of Geos that's
> evolved into more of a limited resource computing platform for
> classrooms. The article goes into more detail on it in the 2nd or 3rd
> to last pages.
>
> I've run it for a little bit and it seems halfway decent for it's
> evolution / focus. It would make a great Kiosk OS.
>
> - Craig Taylor
> http://www.ctalkobt.net/cbm
> 

MagerValp wrote:
> >>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:
>
> a> I'm not an expert on the C64's architecture, but I don't think this
> a> is true.
>
> Sounds like a perfectly accurate description of hires mode.

So the color RAM is actually made of bytes divided into two nybbles,
and each cell has independent foreground and background color?
Interesting. Don't know what color nybbles have to do with hires, looks
like I gotta crack open my PRG.

> a> Again, I'm not an expert here, but I don't think accelerators did
> a> anything with decompression.
>
> Yeah, while there are loaders that do decompression on the fly to
> speed things up, it's not the case with GEOS.
>

How would decompressing anything in the drive help transfer the
now-uncompressed software faster through the serial port? How could the
2K of RAM in the 1541 possibly support a program that decompresses all
the possible packed formats and why would it do that? As far as I know,
fast loaders simply change how the pins on the serial port are used and
manage to squeeze the information through there as fast as possible and
taking advantage of the disk format interleave and such.

On Sat, 26 Aug 2006 07:08:30 -0700, a7yvm109gf5d1 wrote:

> MagerValp wrote:
>> >>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:
>>
>> a> I'm not an expert on the C64's architecture, but I don't think this
>> a> is true.
>>
>> Sounds like a perfectly accurate description of hires mode.
> 
> So the color RAM is actually made of bytes divided into two nybbles,
> and each cell has independent foreground and background color?

Not the color RAM but the video RAM that is used in hires mode to store
the colors.

Ciao,
	Marc 'BlackJack' Rintsch

BlackJack wrote:
> On Sat, 26 Aug 2006 07:08:30 -0700, a7yvm109gf5d1 wrote:
>
> > MagerValp wrote:
> >> >>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:
> >>
> >> a> I'm not an expert on the C64's architecture, but I don't think this
> >> a> is true.
> >>
> >> Sounds like a perfectly accurate description of hires mode.
> >
> > So the color RAM is actually made of bytes divided into two nybbles,
> > and each cell has independent foreground and background color?
>
> Not the color RAM but the video RAM that is used in hires mode to store
> the colors.
>
> Ciao,
> 	Marc 'BlackJack' Rintsch

But that isn't what the article is saying as I read it. The video ram
doesn't store color. It just stores on or off states for pixels. The
article specifically and clearly states that

"The one byte that represents the colour under one of the 8x8 pixel
characters is divided into two nybbles of 4-bits."

Read it again. It is wrong. There is no "one byte that represents the
colour" for each 8x8 pixel cell. There is a nybble for each 8x8 cell.
The actual pixels in hires mode are just on or off, period. If they're
on, they take the color from the color RAM nybble. That's it, that's
all. There is no color byte for each 8x8 cell that also selects the
background color. The background color is set for the entire screen
AFAIK.

a7yvm109gf5d1@netzero.com wrote:
> BlackJack wrote:
>> On Sat, 26 Aug 2006 07:08:30 -0700, a7yvm109gf5d1 wrote:
>>
>>> MagerValp wrote:
>>>>>>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:
>>>> a> I'm not an expert on the C64's architecture, but I don't think this
>>>> a> is true.
>>>>
>>>> Sounds like a perfectly accurate description of hires mode.
>>> So the color RAM is actually made of bytes divided into two nybbles,
>>> and each cell has independent foreground and background color?
>> Not the color RAM but the video RAM that is used in hires mode to store
>> the colors.
> 
> But that isn't what the article is saying as I read it. The video ram
> doesn't store color. It just stores on or off states for pixels. The
> article specifically and clearly states that
> 
> "The one byte that represents the colour under one of the 8x8 pixel
> characters is divided into two nybbles of 4-bits."
> 
> Read it again. It is wrong.

No, it is correct.

> There is no "one byte that represents the
> colour" for each 8x8 pixel cell.
> There is a nybble for each 8x8 cell.
> The actual pixels in hires mode are just on or off, period. If they're
> on, they take the color from the color RAM nybble.

Not in hires mode which is used by GEOS. In hires mode the color memory 
(the nybbles at $D800-$DBFF) isn't used at all! Instead the colors for 
each 8x8 pixel cell are taken from video memory. The same video memory 
that is used in text mode for the so called "character pointers". So in 
hires mode 8000 bytes are needed for the bitmap and 1000 bytes (not 
nybbles!) memory for the color information.

> That's it, that's
> all. There is no color byte for each 8x8 cell that also selects the
> background color. The background color is set for the entire screen

In hires mode changing the background color has no visible effect, 
because all color information is taken from video memory. Note that in 
multi-color hires mode (which isn't used by GEOS) the background color 
is visible.

You don't have to take my word for this. You can look it up in the 
programmers reference manual. Or just use a hires paint program, like 
doodle or geoPaint, to see that every 8x8 pixel block can have two 
freely selectable colors.

On 2006-08-26, a7yvm109gf5d1@netzero.com <a7yvm109gf5d1@netzero.com> wrote:
> But that isn't what the article is saying as I read it. The video ram
> doesn't store color. It just stores on or off states for pixels. The
> article specifically and clearly states that

The 8000 bytes of bitmap memory stores the state of pixels.

In hires mode the 1000 video matrix bytes stores the foreground
and background colors for each 8x8-pixel area.

In multicolor mode the 1000 video matrix bytes stores two of
the colors, the 1000 nybbles of color memory stores the third color
for each 4x8-pixel area and the background color register stores the
fourth color that you can select with the two bits that comprise one
multicolor pixel.

> Read it again. It is wrong. There is no "one byte that represents the
> colour" for each 8x8 pixel cell.

Yes there is. (Sorry, could'n resist.)

> There is a nybble for each 8x8 cell.

There is a nybble of color memory for character mode color,
one byte for the character pointer which points to character
memory..

> The actual pixels in hires mode are just on or off, period. If they're
> on, they take the color from the color RAM nybble.

They take the color from video matrix bytes, not from color memory.
Look it up. Try it with the real machine.

> There is no color byte for each 8x8 cell that also selects the
> background color. The background color is set for the entire screen
> AFAIK.

In character modes and in multicolor bitmapped mode this is true.

-Pasi
-- 
"She's Minbari. You know, sometimes, I look at her and I know exactly
 what she's thinking. Sometimes, .. she's a mystery to me."
	-- Sheridan to Franklin in Babylon 5:"Sleeping in Light"

Pasi Ojala wrote:
>
> They take the color from video matrix bytes, not from color memory.
> Look it up. Try it with the real machine.

I guess I will have to...

Peter van Merkerk wrote:
> a7yvm109gf5d1@netzero.com wrote:
> > BlackJack wrote:
> >> On Sat, 26 Aug 2006 07:08:30 -0700, a7yvm109gf5d1 wrote:
> >>
> >>> MagerValp wrote:
> >>>>>>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:
> >>>> a> I'm not an expert on the C64's architecture, but I don't think this
> >>>> a> is true.
> >>>>
> >>>> Sounds like a perfectly accurate description of hires mode.
> >>> So the color RAM is actually made of bytes divided into two nybbles,
> >>> and each cell has independent foreground and background color?
> >> Not the color RAM but the video RAM that is used in hires mode to store
> >> the colors.
> >
> > But that isn't what the article is saying as I read it. The video ram
> > doesn't store color. It just stores on or off states for pixels. The
> > article specifically and clearly states that
> >
> > "The one byte that represents the colour under one of the 8x8 pixel
> > characters is divided into two nybbles of 4-bits."
> >
> > Read it again. It is wrong.
>
> No, it is correct.
>
> > There is no "one byte that represents the
> > colour" for each 8x8 pixel cell.
> > There is a nybble for each 8x8 cell.
> > The actual pixels in hires mode are just on or off, period. If they're
> > on, they take the color from the color RAM nybble.
>
> Not in hires mode which is used by GEOS. In hires mode the color memory
> (the nybbles at $D800-$DBFF) isn't used at all! Instead the colors for
> each 8x8 pixel cell are taken from video memory. The same video memory
> that is used in text mode for the so called "character pointers". So in
> hires mode 8000 bytes are needed for the bitmap and 1000 bytes (not
> nybbles!) memory for the color information.
>
> > That's it, that's
> > all. There is no color byte for each 8x8 cell that also selects the
> > background color. The background color is set for the entire screen
>
> In hires mode changing the background color has no visible effect,
> because all color information is taken from video memory. Note that in
> multi-color hires mode (which isn't used by GEOS) the background color
> is visible.
>
> You don't have to take my word for this. You can look it up in the
> programmers reference manual. Or just use a hires paint program, like
> doodle or geoPaint, to see that every 8x8 pixel block can have two
> freely selectable colors.

You're right. I went off on a brain lock-up there. I think I'll stick
to PICs for now. I was convinced that the color RAM was used the way I
thought. In my defense, I haven't touched a 64 in decades. I have a 128
I use in 128 mode, that's it.

>>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:

a> How would decompressing anything in the drive help transfer the
a> now-uncompressed software faster through the serial port? How could
a> the 2K of RAM in the 1541 possibly support a program that
a> decompresses all the possible packed formats and why would it do
a> that? As far as I know, fast loaders simply change how the pins on
a> the serial port are used and manage to squeeze the information
a> through there as fast as possible and taking advantage of the disk
a> format interleave and such.

Even with a really fast loader (2-bit xfer, interleave independent)
the C64 will spend half the time just waiting for the 1541 to read in
the next sector. The trick is to spend that time decompressing the
previous sector, so that when the last sector transfers, the file is
almost done decompressing. As I wrote it's not a common technique, but
it has been done, and it can speed up loading significantly.

-- 
    ___          .     .  .         .       . +  .         .      o   
  _|___|_   +   .  +     .     +         .  Per Olofsson, arkadspelare
    o-o    .      .     .   o         +          MagerValp@cling.gu.se
     -       +            +    .     http://www.cling.gu.se/~cl3polof/

MagerValp wrote:
> >>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:
>
> a> How would decompressing anything in the drive help transfer the
> a> now-uncompressed software faster through the serial port? How could
> a> the 2K of RAM in the 1541 possibly support a program that
> a> decompresses all the possible packed formats and why would it do
> a> that? As far as I know, fast loaders simply change how the pins on
> a> the serial port are used and manage to squeeze the information
> a> through there as fast as possible and taking advantage of the disk
> a> format interleave and such.
>
> Even with a really fast loader (2-bit xfer, interleave independent)
> the C64 will spend half the time just waiting for the 1541 to read in
> the next sector. The trick is to spend that time decompressing the
> previous sector, so that when the last sector transfers, the file is
> almost done decompressing. As I wrote it's not a common technique, but
> it has been done, and it can speed up loading significantly.
>
> --

I guess I don't understand what you mean by "decompressing". Decoding
the GCR?

a7yvm109gf5d1@netzero.com wrote:
> MagerValp wrote:
>> Even with a really fast loader (2-bit xfer, interleave independent)
>> the C64 will spend half the time just waiting for the 1541 to read in
>> the next sector. The trick is to spend that time decompressing the
>> previous sector, so that when the last sector transfers, the file is
>> almost done decompressing. As I wrote it's not a common technique, but
>> it has been done, and it can speed up loading significantly.
>>
>> --
>
> I guess I don't understand what you mean by "decompressing". Decoding
> the GCR?

The thread has veered off what GEOS does, but...

Notice the relative roles MagerValp has assigned to the C64 and 1541 (in
this non-GEOS technique that utilises compression).  In order for the
nonstandard buss transfer to work, there has to be fastloader software
running in both the computer and the drive.

So, the floppy has compressed data stored on it.  The 1541 reads in a sector
(does the physical track/sector location, GCR decoding... all that) and
quickly transfers the data to the computer.  But, the fastloader system can
transfer the data from drive to computer faster than the drive can read
sectors off the disc.  During the "downtime", while the computer is waiting
for the next sector's data to be delivered, it decompresses the current
data.

The original article *was* wrong -- GEOS doesn't do anything like that, and
it definitely doesn't "load software into the disk drive's CPU" (at least,
not more than one instruction at a time!).

Brian
-- 

<a7yvm109gf5d1@netzero.com> wrote in message 
news:1156601310.033211.124250@i3g2000cwc.googlegroups.com...
> MagerValp wrote:
>> >>>>> "a" == a7yvm109gf5d1  <a7yvm109gf5d1@netzero.com> writes:
>>
>> a> I'm not an expert on the C64's architecture, but I don't think this
>> a> is true.
>>
>> Sounds like a perfectly accurate description of hires mode.
>
> So the color RAM is actually made of bytes divided into two nybbles,
> and each cell has independent foreground and background color?
> Interesting. Don't know what color nybbles have to do with hires, looks
> like I gotta crack open my PRG.

Not exactly. It depends on whether you are using Multicolor bitmap or Hires 
bitmap. Color RAM is only available in a multicolor based bitmap mode. It 
contains two of the 3 foreground colors. The Screen RAM contains the 3rd 
foreground color and the background color for the attribute cell. However, 
it is explained a little differently but depending on right conditions, the 
background color is either the value in the cell or the value set for the 
screen background color. Usually, hence there is 8000 bitmap bytes, 1000 
color ram bytes and 1000 screen ram bytes and 1 byte that sets the 
screenbackground color WHICH can be different depending whether or not the 
background color in the screenram is set. Most of my current reading is in 
hires modes and I personally haven't spent as much time reading about the 
multicolor bitmap mode in a detailed fashion.

Hires however is typically 8000 bitmap bytes and 1000 bytes of screenram and 
may also contain a 1 byte for screen background color for default background 
color. Of course you can only have 2 colors in an 8x8 area (unless use of 
FLI ). Multicolor will only allow 3 colors in an attribute area. Of course, 
you are not limited to just one background color and thus you can change 
that for the attribute area. Hence the ScreenRAM, it can give you either the 
default background color or a chosen background color for the specific 8x8 
cell.

What FLI is? Is a trick that changes the screenRAM pointer (effectively 
changing which screenRAM you are using - thus allowing upto 8 screenRAMs as 
there is only 8 rasterlines per char cell (attribute area). It therefore, 
adds 8x amount of data then normal in screenRAM. Hence, 8000 + 8000 + 1 
bytes in hires FLI bitmap. There is 8000+1000+8000+1 bytes for Multicolor 
FLI bitmap. Don't ask if you can do the same with color RAM, it is kinda 
fixed to one location, you can't move it around. Why it has not been done.

In case of C-128s (including all 128d models), the VDC bitmap is hires but 
different than hires on C64. There is no cell by cell change of the 
background color without another advance trick. The attribute memory (2KB - 
due to 80 columns versus 40) contains a whole byte but one nybble of the 
byte determines the foreground colors (though assigned in terms of RGBI 
bits), the other nybble determines other attribute info such as flashing 
(blink), underline, reverse video and alternate character set on a cell by 
cell basis). However, I suppose a cell by cell controlling of background can 
be achieved through constant changing of the background color with some sort 
of interrupt but it will take some thinking to get that going right. Line 
and point plotting works with constant adjusting of the foreground colors, 
so there is a means to it. Like you do on the background color register 
manually. Constant changing of R26 bits 0-3.... there needs to be some 
interrupt....

Tricky it may be.....

Screen RAM is also the same RAM used to store your text when in character 
mode.

You misread it. What you are talking about is the Bitmap memory.

Screen RAM is 1000 bytes (its default starting location is decimal 1024 or 
in hex $0400.) Don't confuse it with character memory in text mode. 
Character memory but it is nothing more than the font patterns for the 
character set)

When the VIC-II is set into bitmap mode, the screen memory which normally is 
used where you see the text on the screen in hires bitmap mode, is used to 
store the information for foreground and background color for the given 
character cell. The bitmap memory is where all the on and off bits are.

In hires mode, it is pretty simple. If a bit for defining the 8x8 cell is 
set to 1 then the pixel in which that bit is corresponding to is set to the 
foreground color defined in the screen ram for that character (cell) 
position. Lets say we are in the top-left corner 8x8 cell. So imagine on the 
first pixel in the first raster row of the top-left character cell of the 
screen is intended to be foreground color - then the bit 7 of byte 0 in 
bitmap memory must be set to one.

Typical bitmap cell layout (same as programmable characters)

* = 1, O = 0

  7 6 5 4 3 2 1 0
0 * O O O O O O O
1 O O O O O O O O
2 O O O O O O O O
3 O O O O O O O O
4 O O O O O O O O
5 O O O O O O O O
6 O O O O O O O O
7 O O O O O O O O

Row 0 is byte 0
Row 1 is byte 1
Row 7 is byte 7

So, here we go, by plugging a value of $FE (dec. 127) in first byte of the 
8000 byte bitmap, you turned the left most pixel of the first raster row of 
the top-left character cell to foreground color.

In screen RAM, each byte represents the foreground or background color of 
each 8x8 cell. 8x8 = 64 px. 8 bytes per 64 px. or char. 1000 bytes thus 
would represents 64,000 px. which coincides with the size of 320x200 px. 
64,000 divided by 8 would be 8000 which corresponds well with the bitmap 
memory.

Each bytes in screenram represents the foreground and background color of 
each 8 bytes of bitmap memory. This is descriptive of a typical hires 
bitmap. Multicolor bitmap is similar as well. 8000 / 8 = 1000. Coincides 
well. Doesn't it?

If you think of it. You'll get it. The language used by the reporter had got 
things garbled up.

There is a default background color typically but the video mode allows for 
cell by cell changing. Why do you think you can have a background of blue, a 
foreground color of a cell in red with a yellow background for that cell.

Think of a Red plus sign on a yellow background within an 8x8 area and that 
in front of a blue screen background.PERFECTLY legal in hires bitmap mode. 
Even so in Multicolor bitmap. Text modes may apply other limits unless you 
use "Extended Background Color" mode for text. Example from C64PRG: A blue 
character on a yellow background on a white screen.

PERFECT!

<a7yvm109gf5d1@netzero.com> wrote in message 
news:1156604993.067831.5560@75g2000cwc.googlegroups.com...

> But that isn't what the article is saying as I read it. The video ram
> doesn't store color. It just stores on or off states for pixels. The
> article specifically and clearly states that
>
> "The one byte that represents the colour under one of the 8x8 pixel
> characters is divided into two nybbles of 4-bits."
>
> Read it again. It is wrong. There is no "one byte that represents the
> colour" for each 8x8 pixel cell. There is a nybble for each 8x8 cell.
> The actual pixels in hires mode are just on or off, period. If they're
> on, they take the color from the color RAM nybble. That's it, that's
> all. There is no color byte for each 8x8 cell that also selects the
> background color. The background color is set for the entire screen
> AFAIK.
> 

Yes, EACH and every byte in screen memory represents both a foreground and a 
background color. (For A7yvm) 4 bits of that byte represents foreground and 
the other 4 bits represents background.

Color memory is a little bit awkward but 3 or 4 bits are used of it.


(Divergence)
Though, that upper 4 bits can be used if the VIC-II was modified to support 
256 colors and thusly, those 4 bits could then be used to represent which 16 
color constrain palette to use in cell. (Ultimately also effecting the color 
given from screenRAM as well.) That would be a thoeretical way of enhancing 
the C64.

Nice to test in an emulator. Modify VICE (for eg. or another emu) to have 
256 colors but only one 16 color constrained palette can be used per 
attribute area and that would also effect the colors derived from screen RAM 
as the color values from that would derive from that palette value. That can 
be cool to see in an emu or even on a C-1.

"Pasi Ojala" <albert@pikkukorppi.cs.tut.fi> wrote in message 
news:slrnef1cuq.rp2.albert@pikkukorppi.cs.tut.fi...
> On 2006-08-26, a7yvm109gf5d1@netzero.com <a7yvm109gf5d1@netzero.com> 
> wrote:
>> But that isn't what the article is saying as I read it. The video ram
>> doesn't store color. It just stores on or off states for pixels. The
>> article specifically and clearly states that
>
> The 8000 bytes of bitmap memory stores the state of pixels.
>
> In hires mode the 1000 video matrix bytes stores the foreground
> and background colors for each 8x8-pixel area.
>
> In multicolor mode the 1000 video matrix bytes stores two of
> the colors, the 1000 nybbles of color memory stores the third color
> for each 4x8-pixel area and the background color register stores the
> fourth color that you can select with the two bits that comprise one
> multicolor pixel.
>
>> Read it again. It is wrong. There is no "one byte that represents the
>> colour" for each 8x8 pixel cell.
>
> Yes there is. (Sorry, could'n resist.)
>
>> There is a nybble for each 8x8 cell.
>
> There is a nybble of color memory for character mode color,
> one byte for the character pointer which points to character
> memory..
>
>> The actual pixels in hires mode are just on or off, period. If they're
>> on, they take the color from the color RAM nybble.
>
> They take the color from video matrix bytes, not from color memory.
> Look it up. Try it with the real machine.
>
>> There is no color byte for each 8x8 cell that also selects the
>> background color. The background color is set for the entire screen
>> AFAIK.
>
> In character modes and in multicolor bitmapped mode this is true.
>
> -Pasi
> -- 
> "She's Minbari. You know, sometimes, I look at her and I know exactly
> what she's thinking. Sometimes, .. she's a mystery to me."
> -- Sheridan to Franklin in Babylon 5:"Sleeping in Light" 

Rick Balkins <nospam.rickbalkins@nospam.wavestarinteractive.com> wrote:

> So, here we go, by plugging a value of $FE

wrong

> (dec. 127)

wrong

> you turned the left most pixel of the first
> raster row of the top-left character cell to foreground color.

wrong

Cool explanation.

-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-

well, must of got the numbers wrong. Add the correction to those parts to 
make sure it is correct.

Maybe the 64PRG guide got is confusing.... Let me check it again.
F*** me, I got the wrong hex value. It should be $80 and that should be 
decimal 128 not 127.

In that case, were I put $FE - it should read $80. $FE is 254 in decimal.
BAD hex calculating in my head and off by 1 in decimal.


"iAN CooG" <iancoog@despammed.com> wrote in message 
news:77LIg.86174$_J1.774895@twister2.libero.it...
> Rick Balkins <nospam.rickbalkins@nospam.wavestarinteractive.com> wrote:
>
>> So, here we go, by plugging a value of $FE
>
> wrong
>
>> (dec. 127)
>
> wrong
>
>> you turned the left most pixel of the first
>> raster row of the top-left character cell to foreground color.
>
> wrong
>
> Cool explanation.
>
> -- 
> -=[]=--- iAN CooG/HokutoForce ---=[]=-
>
> 

Thank iAN, what a narly F*** up in hex. My decimal was close (off by 1)

Now, to think of it, the Programmable Character Worksheet (as called briefly 
in the C64PRG is another wordage for character cells and bitmap mode is 
entirely based on these programmable characters... Oh well... I should now 
remember to use the calculator and NOT try to do decimal 2 hex conversion in 
my head, for awhile.

"iAN CooG" <iancoog@despammed.com> wrote in message 
news:77LIg.86174$_J1.774895@twister2.libero.it...
> Rick Balkins <nospam.rickbalkins@nospam.wavestarinteractive.com> wrote:
>
>> So, here we go, by plugging a value of $FE
>
> wrong
>
>> (dec. 127)
>
> wrong
>
>> you turned the left most pixel of the first
>> raster row of the top-left character cell to foreground color.
>
> wrong
>
> Cool explanation.
>
> -- 
> -=[]=--- iAN CooG/HokutoForce ---=[]=-
>
> 

Hello,

Brian Ketterling wrote:

> The original article *was* wrong -- GEOS [...] definitely doesn't
> "load software into the disk drive's CPU" (at least, not more than one
> instruction at a time!).

Well, loading the speeder routines into the drive RAM is "loading
software into the disk drive's CPU", at least, if you take the phrase
"CPU" a little broader.

Notice that people grown up with microprocessors tend to say CPU
("Central Processing Unit") = MPU ("Micro Processing Unit", the
microprocessor). Anyway, anyone grown with "bigger systems" would
consider a MPU together with RAM and ROM as "CPU". "Back in they days",
there were people considering the whole computer (for example, the C64)
as "CPU" to distinguish that from the peripherals (floppy, etc.)

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

"Spiro Trikaliotis" wrote ...
>
> Well, loading the speeder routines into the drive RAM is "loading
> software into the disk drive's CPU", at least, if you take the phrase
> "CPU" a little broader.
>
> Notice that people grown up with microprocessors tend to say CPU
> ("Central Processing Unit") = MPU ("Micro Processing Unit", the
> microprocessor). Anyway, anyone grown with "bigger systems" would
> consider a MPU together with RAM and ROM as "CPU". "Back in they days",
> there were people considering the whole computer (for example, the C64)
> as "CPU" to distinguish that from the peripherals (floppy, etc.)

Looking back the PeeCee had drives mounted in the "CPU" and a separate
keyboard.  Commodore 8-bits had a separate disk drive and the keyboard
mounted in the "CPU"

I remember a cousin thinking my 1541 was the computer and that my Plus/4 was
only a keyboard.
-- 
Best regards,

Sam Gillett

Change is inevitable,
except from vending machines!

Sam Gillett wrote:
> I remember a cousin thinking my 1541 was the computer and that my Plus/4 was
> only a keyboard.


He was right.

christianlott1 wrote:

>>I remember a cousin thinking my 1541 was the computer and that my Plus/4 was
>>only a keyboard.
> 
> He was right.
> 

You scored a point ;-)

silverdr wrote:
> christianlott1 wrote:
>
> >>I remember a cousin thinking my 1541 was the computer and that my Plus/4 was
> >>only a keyboard.
> > 
> > He was right.
> > 
> 
> You scored a point ;-)

:o

Spiro Trikaliotis wrote:
> Well, loading the speeder routines into the drive RAM is "loading
> software into the disk drive's CPU", at least, if you take the phrase
> "CPU" a little broader.

That's true... I was using the current colloquial sense, which isn't really
proper.

> Notice that people grown up with microprocessors tend to say CPU
> ("Central Processing Unit") = MPU ("Micro Processing Unit", the
> microprocessor). Anyway, anyone grown with "bigger systems" would
> consider a MPU together with RAM and ROM as "CPU". "Back in they days",
> there were people considering the whole computer (for example, the C64)
> as "CPU" to distinguish that from the peripherals (floppy, etc.)

You could really go back to "the day", and refer to RAM as "scratchpad
memory" :) .
(Or forget finding ways to hook up flash RAM to a 64, and install some
ferrite core memory instead.)

Brian
-- 

In article <slrnef8tji.6lr.news-200605@news.trikaliotis.net>, Spiro
Trikaliotis <news-200605@trikaliotis.net> wrote:

 little broader.
> 
> Notice that people grown up with microprocessors tend to say CPU
> ("Central Processing Unit") = MPU ("Micro Processing Unit", the
> microprocessor). Anyway, anyone grown with "bigger systems" would
> consider a MPU together with RAM and ROM as "CPU". "Back in they days",
> there were people considering the whole computer (for example, the C64)
> as "CPU" to distinguish that from the peripherals (floppy, etc.)
> 
> Regards,
>    Spiro.

Hello, and at the risk of showing my age and digressing further OT, I
remember taking some undergrad computer courses at Virginia Tech where the
the term "CPU" was not even used in describing computer architecture. 
There was a "control unit" and an "arithmetic and logic unit."  The first
time I ever encountered the term "Central Processing Unit" was the front
panel label on the main console of an IBM series 370.  Wonder if IBM
coined the term.  Sincerely,

John Wood (Code 5550)        e-mail: wood@itd.nrl.navy.mil                     
Naval Research Laboratory
4555 Overlook Avenue, SW
Washington, DC 20375-5337

CPU is a term derived from mainframe computing where the CPU is the unit 
that controlled processing. Because the whole computer encompassed several 
large 'cabinets' housings. There was two memory units. Short term memory 
units (essentially, your RAM) and the long term memory units (the 
reel-to-reel units).

Since then, a single microprocessor chip contained everything that was and 
is needed for processing instructions. In fact, MPU is MicroProcessing Unit. 
A single computer may contain more than one MPU but only the main MPU that 
controls or is essentially the master to all the other MPUs and other chips 
is the "CPU". To some extent, other chips on cards or on the motherboard may 
contain processing units within itself (Essentially any microcontroller) and 
therefore may have multiple processors.

There is subsequent situations in which there is multiple CPUs, like a 
parallel processing units. This is because the bank of CPUs are equal to 
each other in the heiarchy. However, networks are exceptions to the rule but 
are typically an interconnection of complete computers. So.... well doesn't 
matter.

IBM did essentially call the main unit the CPU because they were utilizing 
mainframe-era terminology and applied it to their personal computers. 
However, a typical IBM PC would contain a short term, long term and CPU all 
in one unit. Making it a little silly but eventually the CPU had been 
narrowed down the microprocessor that controls the computer as the CPU in 
today's common use. Thus keeping more true to the mainframe-era context in 
the first place.

These days, MCU (Micro Controller Unit) can essentially be a self-contained 
computer... look at the 65c265 and it is. It does have some internal 
embedded RAM. ANyway, old mainframe era terms live on.

"J. B. Wood" <wood@itd.nrl.navy.mil> wrote in message 
news:wood-3008060709130001@jbw-mac.itd.nrl.navy.mil...
> In article <slrnef8tji.6lr.news-200605@news.trikaliotis.net>, Spiro
> Trikaliotis <news-200605@trikaliotis.net> wrote:
>
> little broader.
>>
>> Notice that people grown up with microprocessors tend to say CPU
>> ("Central Processing Unit") = MPU ("Micro Processing Unit", the
>> microprocessor). Anyway, anyone grown with "bigger systems" would
>> consider a MPU together with RAM and ROM as "CPU". "Back in they days",
>> there were people considering the whole computer (for example, the C64)
>> as "CPU" to distinguish that from the peripherals (floppy, etc.)
>>
>> Regards,
>>    Spiro.
>
> Hello, and at the risk of showing my age and digressing further OT, I
> remember taking some undergrad computer courses at Virginia Tech where the
> the term "CPU" was not even used in describing computer architecture.
> There was a "control unit" and an "arithmetic and logic unit."  The first
> time I ever encountered the term "Central Processing Unit" was the front
> panel label on the main console of an IBM series 370.  Wonder if IBM
> coined the term.  Sincerely,
>
> John Wood (Code 5550)        e-mail: wood@itd.nrl.navy.mil
> Naval Research Laboratory
> 4555 Overlook Avenue, SW
> Washington, DC 20375-5337 

On 2006-08-28, Rick Balkins <nospam.rickbalkins@nospam.wavestarinteractive.com> wrote:
> Color RAM is only available in a multicolor based bitmap mode. It 
> contains two of the 3 foreground colors.

No, the color RAM still contains only one nybble, thus only one color.

> The Screen RAM contains the 3rd foreground color and the background
> color for the attribute cell.

The screen RAM (video matrix) contains two colors in both hires and
multicolor graphics mode and characters pointers in character mode.
*There is no attribute cell.*

And actually, multicolor mode has two foreground and two background
colors. This comes to play when you have sprites:
1) if a sprite is "under graphics", it is still above both
   background colors
2) sprite-graphics collisions only check collisions with foreground
   colors.

The fourth color in multicolor graphics mode (background color 00)
comes from the background color register.

> that for the attribute area. Hence the ScreenRAM, it can give you either the 
> default background color or a chosen background color for the specific 8x8 
> cell.

Wrong. It gives two colors in both hires and multicolor graphics modes.
In hires graphics mode the background color register is not used.

> Tricky it may be.....

Yes. You still have to read about it a couple of more times it seems..

-Pasi
-- 
"It's like hypnotism. People follow him to see what's going to happen
 next. They tell themselves that they're just going along with it for
 a while and can stop any time they want to, but they never want to.
 It's damn magic."	-- Vimes about Carrot in Discworld:"Jingo"

Brian Ketterling wrote:.
> (Or forget finding ways to hook up flash RAM to a 64, and install some
> ferrite core memory instead.)

If you do find a way to hook some up - I'd be interested in seeing it.

While completely pointless it'd be cool just from the coolness factor.
(Say, a 8 out of 10 - hooking it up to a TI calculator or PalmPilot
would prob. go 10/10). 

- Craig Taylor
http://www.ctalkobt.net/cbm