Jump to content

Photo

My Channel F Web pages are up


67 replies to this topic

#51 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Wed Nov 21, 2007 3:04 PM

I unfortunately lost my picture drawing code (all that wasn't posted here) and sat tonight and rebuilt some of it.

Tried the code Kurt produced from the converter software and it unfortunately looks awful...
It's supposed to be like this: green 00, red 01, blue 10, background 11


Posted Imagechan0061.png

International_Karate___ChannelF.gif chan0062.png


Reading the first line of the IK+ picture, data in your post says 00000000 - which means green, but turns white with B&W palette... it should have been 11 - background colored. Looking further in the picture the blue water is background colored - grey instead. Which means what should have been 10 is 11 instead...

Snippet from the IK+ data
gfx.multicolor.data:                .byte % 00000000, % 00000000, % 00000000, % 00000000, % 00000000, % 00000000, % 00000000                .byte % 00000000, % 00000000, % 00000000, % 00000000, % 00000000, % 00000000, % 00000000                .byte % 00000000, % 00000000, % 00000000, % 00000000, % 00000000, % 00000100, % 01000000                .byte % 00000001, % 00000000, % 00000000, % 00000000, % 00001110, % 11101110, % 11100110

Patterns look right, but colors are not.


Translation:

IS   SHOULD BE
00   11
11   10
10   00

Then everything should be OK.

Edited by e5frog, Wed Nov 21, 2007 4:07 PM.


#52 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Wed Nov 21, 2007 3:59 PM

I translated the bitmap data according to the translating table above (note that Red was coded correctly ;-) )

The result was a lot better:

chan0063.png

Edited by e5frog, Wed Nov 21, 2007 4:00 PM.


#53 Kurt_Woloch OFFLINE  

Kurt_Woloch

    Dragonstomper

  • 987 posts

Posted Thu Nov 22, 2007 10:10 AM

Oh... sorry. There was an error in my program, and I think I found it now.

Just to explain what happened: The program computes each line of date in two passes:
1. Figure out the best pallette for that line
2. Figure out the best matching dots for that given line.

Now, when I first wrote that program (that is, adapted another program to give Channel F data), I didn't care too much about the actual resolution or pallettes of the Channel F, thus the mapping of the colors were wrong, as described above.
When I corrected the program to put out actual Channel F data, however, I did a mistake...

To check which pallette is best, the program first assigns each possible pallette to the 4 available color slots and then tests how well this pallette is suited to give the best representation of the line to display. After all 4 pallettes have been tried and the best one has been determined, the color numbers for that pallette are again assigned to the 4 color slots in order to generate the final appearance of the line. Unfortunately, when reworking that assignment to the actual color scheme used in the Channel F, I only changed the colors used for determining the best pallette, but not the ones used for actually forming the line, which resulted in wrong color numbers used (although the result looked alright visually shown in my program).

So... I hope I've got it correct with the following table:
[codebox]
color code
Pallette code
00 01 10 11
00 white white white black
01 green red blue gray
10 green red blue l.blue
11 green red blue l.green
[/codebox]

Also, I'd like to know if I picked the correct RGB values for the Channel F's colors:
black: 0/0/0
white: 255/255/255
green: 0/255/0
red: 255/0/0
blue: 0/0/255
gray: 191/191/191
light green: 191/255/191
light blue: 191/191/255

Edited by Kurt_Woloch, Thu Nov 22, 2007 10:13 AM.


#54 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Thu Nov 22, 2007 8:11 PM

Also, I'd like to know if I picked the correct RGB values for the Channel F's colors:
black: 0/0/0
white: 255/255/255
green: 0/255/0
red: 255/0/0
blue: 0/0/255
gray: 191/191/191
light green: 191/255/191
light blue: 191/191/255



You did an excellent job, now it works wonderfully!

The original MESS colors differs a lot from what a real unit produces on screen, using the modified MESS (modified by Sean Riddle, which also has improved sound) - being download-able from http://veswiki.com there's the ability to set a palette file. It's called chfpal.dat, and is simply a binary file of 3x8 bytes. By measuring color values from screenshots made with a video capture card and comparing to a few different tv-sets I have come to the conclusion that a second generation Channel F has approximately this palette:
black: 16/16/16
white: 252/252/252
green: 2/204/93
red: 255/49/83
blue: 75/63/243
gray: 224/224/224
light green: 145/255/166
light blue: 206/208/255

A first generation console differs a bit as far as I have seen, main differences is that the blue is a little darker and the red is more orange. Picture on a first generation unit are usually sharper as well but that's beside the point. ;-)


I made these wonderful pictures today:
chan0071.png
chan0069.png
chan0068.png

These are snapshots from MESS, as you can see they use the palette above.


Great work Kurt!!

#55 Bill Loguidice OFFLINE  

Bill Loguidice

    River Patroller

  • 2,522 posts
  • Armchair Arcade Managing Director
  • Location:Central New Jersey, USA

Posted Fri Nov 23, 2007 6:51 AM

Speaking of the Channel F... I've learned that there also was a home computer in the late 70's based on the F8 CPU, called the VideoBrain. It's described on AtariProtos.com. Does anyone know how to program that thing? From what I get from the screenshots, it seems to be a character-based system showing 10 lines x 18 columns, where each character can have one of 16 foreground colors, but the whole screen has the same background color. The characters probably have a matrix of 8x16 pixels or something like that, and at least 16 of them are redefinable. There is one program shown where you can draw on the screen, but the actual drawable resolution here seems to be 32x32 because the image is mirrored horizontally as well as vertically. The whole system only has 1K of RAM, which is less than the Channel F has! But there's no info on how exactly the graphics work and how to program it...


The problem with the VideoBrain is that it has no built-in programming language, and the one language available on cartridge, APL/S, is exceedingly rare. Also, the one option that would allow for saves, the Expander 1 unit, which essentially gave the computer the ports it would need, is probably even rarer. In short, there are two serious problems that need to be overcome in regards to the VideoBrain before anyone can even begin to make programming for the thing practical. Nevertheless, I'd be up for new product for either the VideoBrain or the Channel F, but considering the availability of the latter, my money would be on twenty things for the console before even one for the computer...

#56 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Fri Nov 23, 2007 11:14 PM

Speaking of the Channel F... I've learned that there also was a home computer in the late 70's based on the F8 CPU, called the VideoBrain. It's described on AtariProtos.com. Does anyone know how to program that thing? From what I get from the screenshots, it seems to be a character-based system showing 10 lines x 18 columns, where each character can have one of 16 foreground colors, but the whole screen has the same background color. The characters probably have a matrix of 8x16 pixels or something like that, and at least 16 of them are redefinable. There is one program shown where you can draw on the screen, but the actual drawable resolution here seems to be 32x32 because the image is mirrored horizontally as well as vertically. The whole system only has 1K of RAM, which is less than the Channel F has! But there's no info on how exactly the graphics work and how to program it...


The problem with the VideoBrain is that it has no built-in programming language, and the one language available on cartridge, APL/S, is exceedingly rare. Also, the one option that would allow for saves, the Expander 1 unit, which essentially gave the computer the ports it would need, is probably even rarer. In short, there are two serious problems that need to be overcome in regards to the VideoBrain before anyone can even begin to make programming for the thing practical. Nevertheless, I'd be up for new product for either the VideoBrain or the Channel F, but considering the availability of the latter, my money would be on twenty things for the console before even one for the computer...



Channel F has only 64 bytes of RAM, the other 2 kB is VRAM and is used to store what shows up on the screen, I'm not even sure it can be read again after being written to... Neither does Channel F have any built in programming language. But with DASM and a modified cart homebrews are a fact. Making software for VideoBrain should work as for the Channel F, start by dumping software, disassemble (f8tool on veswiki.com will probably work) study the code to figure out how to use graphics and such.... Seems to be more of a challenge than Channel F - oh yes.

Unless VideoBrain has a 3853 SMI in the unit the cartridges are most likely the same type of PSU:s as for Channel F - I know Sean Riddle knows how to dump these, if it does have one - the carts are plain roms can be dumped quite easily.

It would be interesting to see what's under the hood of one of those.

#57 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Wed Dec 5, 2007 7:29 AM

Now that I've gotten my own eprom programmer I could try some things out on the real unit, I took photos of the TV displaying some Christmas related full screen pictures, and the smaller pictures are the corresponding MESS snapshots. Note that I have a PAL system. The tv-set photos got a little dark and has those curved distortions from top to bottom, but it gives an idea how it looks on a real unit. The original picture is to the far right...


Hpim2817.jpg chan0076.png christmas_1135239757.png christma...35239757.png]
Hpim2818.jpg chan0077.png julkort_2002.png julkort_2002.png]
Hpim2819.jpg chan0078.png bild_jul.png bild_jul.png]
Hpim2816.jpg chan0080.png stj_rtlapp.png stj_rtlapp.png]


I'm guessing we should make our own thread instead of using FND's about his new Channel F page... ;-)

Edited by e5frog, Wed Dec 5, 2007 7:41 AM.


#58 Kurt_Woloch OFFLINE  

Kurt_Woloch

    Dragonstomper

  • 987 posts

Posted Wed Dec 5, 2007 4:14 PM

Now that I've gotten my own eprom programmer I could try some things out on the real unit, I took photos of the TV displaying some Christmas related full screen pictures, and the smaller pictures are the corresponding MESS snapshots. Note that I have a PAL system. The tv-set photos got a little dark and has those curved distortions from top to bottom, but it gives an idea how it looks on a real unit. The original picture is to the far right...

(...)


Now that's interesting... on your PAL TV, there seem to be about 55 lines visible.

By the way, did you get my recent message with the new converter version attached? I didn't get any reply to that one yet...

#59 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Wed Dec 5, 2007 4:51 PM

Now that's interesting... on your PAL TV, there seem to be about 55 lines visible.

By the way, did you get my recent message with the new converter version attached? I didn't get any reply to that one yet...



Yes, there is about 55 - on that particular TV - with that unit... ;-)

What shows in MESS is something of a maximum display, but even there some TV:s (unit combinations) display outside the MESS display also, not more than a row or so.


I got the message, have only tested it briefly - noticed that the hex output is only nine bytes wide instead of the 20 that was before. It saves a little vertical space, but not as much as before. ;-)

I'm getting an NTSC console this week, I'll hook it up and take a look at what differs on the displays.

#60 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Wed Jun 18, 2008 7:44 AM

Just wanted to let everybody know in this thread also that I've made a converter program that converts 1-bit color bitmap files to a blitGraphic object.

Simply drag and drop your bmp-file on the exe-icon or run from command prompt. If run from command prompt there's a switch called -i that can be used after the filename (which then has to be specified) which inverts the output in case original picture had the colors swapped.

If no filename is supplied it will try and read the file bitmap.bmp, output file is always called blitgraphic.data.txt.

Maximum size is 128 x 64 (same size as VRAM of the VES).


Any questions, do ask, feedback is most welcome.

Can be found in the http://veswiki.com here: http://veswiki.com/Homebrew:BMP2Blit

It makes graphics real easy!

All you need to do after copy and paste it into your code is to dci blitgraphic.bmp.parameters and then call blitGraphic with pi blitGraphic which you of course also have copied as a subroutine into your code.


Just go ahead and do some animation, with small enough graphics there's a lot of room!

#61 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Wed Jul 16, 2008 2:38 PM

Thought I should mention in this thread also that I've updated the graphics converter to MultiBlitGraphics as well - which means you can make four-color-blit objects as easy as two-colored! A test-picture is included to set the palette right for all your future Channel F graphics.

It's in the same place as the previous version on http://veswiki.com


The main reason for writing the converter was this:
http://w5.nuinternet...annelf/test.bin
Try it out in MESS and let me know what you think!

I got tired of calculating all the graphics data "by hand" I hope someone more will benefit from my work.

Edited by e5frog, Wed Jul 16, 2008 2:40 PM.


#62 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Thu Jul 17, 2008 10:27 AM

Perhaps the previous bin-file isn't that interesting if you don't have a real Channel F controller connected to your PC and can easily try all moves... So here's a non controllable demo-version also:

http://w5.nuinternet...f/test_demo.bin

#63 yuppicide OFFLINE  

yuppicide

    I am the Black Knight. Give me your money!

  • 6,933 posts
  • Location:New Jersey

Posted Sun Jul 20, 2008 9:12 PM

Nice page. On your timelime, though you have a spelling error:

"SCHLUMBERGER
Acquires Fairchild
Camers & Instrument
Corporation"

Camera.

#64 FND OFFLINE  

FND

    Stargunner

  • Topic Starter
  • 1,155 posts
  • Location:Cal. Bay area

Posted Sun Jul 20, 2008 9:45 PM

Nice page. On your timelime, though you have a spelling error:

"SCHLUMBERGER
Acquires Fairchild
Camers & Instrument
Corporation"

Camera.



Thanks for the heads up, I appreciate the help. Funny how many times
you can look at something and never see the mistake.

#65 Kurt_Woloch OFFLINE  

Kurt_Woloch

    Dragonstomper

  • 987 posts

Posted Thu Apr 5, 2012 4:07 AM

Seems to be more of a challenge than Channel F - oh yes.

Unless VideoBrain has a 3853 SMI in the unit the cartridges are most likely the same type of PSU:s as for Channel F - I know Sean Riddle knows how to dump these, if it does have one - the carts are plain roms can be dumped quite easily.

It would be interesting to see what's under the hood of one of those.


OK, it seems that this thread has been dead for a long time, but I don't know where else to put this, so here it goes...

I've been reading up on the Videobrain internals on Sean Riddle's site. Actually, it looks pretty interesting. I read through the patent at http://www.google.co...tents?q=4232374 which describes the video hardware in detail. They actually tried to put up some sprite system, but with some severe limitations, which makes the system be "neither fish nor flesh", meaning it's neither suitable very well as a computer nor as a game console...

There are 16 sprites which can theoretically be any size as long as the horizontal size is dividable by 8. But there are a few catches... as usual, sprites can be one of 32 colors (8 colors in 4 intensities each) against the background which shares the same color scheme. But then sprites cannot overlap, and there's also nothing else displayable other than the sprites! There's also no "tile" or "character" mode... so when the Videobrain displays some lines of text, there are two possibilities to achieve this:
1. Each whole line is a sprite (as Sean Riddle claims) or
2. Each character is a sprite, and after displaying the line, the sprites get re-used (which is what the patent states as being possible).
I suppose they rather used method 2 than method 1, because for using method 1, you'd have to copy the whole bitmap content of the line into RAM, which either takes 128 bytes to display one line and then have the CPU copy in the data for the next line, or takes 896 bytes for all 7 lines at once, which uses up nearly all of the available RAM.
So my guess would be that they rather used method 2, where each character is a sprite. In this case, the pattern for each sprite (character) gets read directly from ROM, and in RAM there's only the pointers to where each character starts in ROM. For the next line, these pointers are getting updated. That's what happens during the scanlines between the displayed lines. According to the patent, the CPU actually has to do much work in every frame to update the sprite list.

And as if this wasn't bad enough, the sprite list has to contain the sprites in the order they start to get displayed. So if during a game, a sprite that was a scanline higher than another moves below that other sprite, they have to swap places in the list in order to be displayed correctly. This is shown in the listing of the Tennis cartridge which is contained in the patent, where basically for each frame, the list gets re-sorted, and there are additional measures taken to avoid any objects on screen overlapping each other.

There are a few tricks you can do, such as having a sprite repeated horizontally by using the Xcopy bit, or magnifying the sprites in X and Y direction, although I'm not sure if you can do this for each sprite individually or only globally for all sprites.

So making games for this console would be quite difficult, I suppose, and many types of game would even be impossible to implement correctly. I think Space Invaders should be possible though, or other games where the moving objects never overlap with the background or each other like Carnival or even Gyruss. You might get a Frogger clone with a bit of trickery, but I'm not so sure about Pac Man.

#66 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Thu Apr 5, 2012 6:14 AM

... and the VideoBrain has plain roms in the cartridges since it uses a newer combined CPU and memory interface circuit.
If I ever get one I'll try some programming for it.

#67 e5frog OFFLINE  

e5frog

    Dragonstomper

  • 517 posts
  • Good.
  • Location:Sweden

Posted Mon May 19, 2014 7:50 AM

I got one (a prototype apparently), haven't tried programming it yet though.



#68 Keatah OFFLINE  

Keatah

    Quadrunner

  • 7,833 posts

Posted Mon May 19, 2014 1:55 PM

Don't forget to put in F8 of Nations, the world's smallest game. It makes those 256 byte DOS games seem massive in comparsion. icon_shades.gif

 

Ridiculous! The game uses BIOS routines - which by default is code no matter what you call it.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users