e5frog Posted November 21, 2007 Share Posted November 21, 2007 (edited) 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 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 November 21, 2007 by e5frog Quote Link to comment Share on other sites More sharing options...
e5frog Posted November 21, 2007 Share Posted November 21, 2007 (edited) I translated the bitmap data according to the translating table above (note that Red was coded correctly ) The result was a lot better: Edited November 21, 2007 by e5frog Quote Link to comment Share on other sites More sharing options...
Kurt_Woloch Posted November 22, 2007 Share Posted November 22, 2007 (edited) 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: 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 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 November 22, 2007 by Kurt_Woloch Quote Link to comment Share on other sites More sharing options...
e5frog Posted November 23, 2007 Share Posted November 23, 2007 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: These are snapshots from MESS, as you can see they use the palette above. Great work Kurt!! Quote Link to comment Share on other sites More sharing options...
Bill Loguidice Posted November 23, 2007 Share Posted November 23, 2007 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... Quote Link to comment Share on other sites More sharing options...
e5frog Posted November 24, 2007 Share Posted November 24, 2007 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. Quote Link to comment Share on other sites More sharing options...
e5frog Posted December 5, 2007 Share Posted December 5, 2007 (edited) 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... I'm guessing we should make our own thread instead of using FND's about his new Channel F page... Edited December 5, 2007 by e5frog Quote Link to comment Share on other sites More sharing options...
Kurt_Woloch Posted December 5, 2007 Share Posted December 5, 2007 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... Quote Link to comment Share on other sites More sharing options...
e5frog Posted December 5, 2007 Share Posted December 5, 2007 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. Quote Link to comment Share on other sites More sharing options...
e5frog Posted June 18, 2008 Share Posted June 18, 2008 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! Quote Link to comment Share on other sites More sharing options...
e5frog Posted July 16, 2008 Share Posted July 16, 2008 (edited) 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.com/s660100106/files/channelf/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 July 16, 2008 by e5frog Quote Link to comment Share on other sites More sharing options...
e5frog Posted July 17, 2008 Share Posted July 17, 2008 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.com/s660100106/files/...f/test_demo.bin Quote Link to comment Share on other sites More sharing options...
yuppicide Posted July 21, 2008 Share Posted July 21, 2008 Nice page. On your timelime, though you have a spelling error: "SCHLUMBERGER Acquires Fairchild Camers & Instrument Corporation" Camera. Quote Link to comment Share on other sites More sharing options...
FND Posted July 21, 2008 Author Share Posted July 21, 2008 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. Quote Link to comment Share on other sites More sharing options...
Kurt_Woloch Posted April 5, 2012 Share Posted April 5, 2012 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.com/patents?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. Quote Link to comment Share on other sites More sharing options...
e5frog Posted April 5, 2012 Share Posted April 5, 2012 ... 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. Quote Link to comment Share on other sites More sharing options...
e5frog Posted May 19, 2014 Share Posted May 19, 2014 I got one (a prototype apparently), haven't tried programming it yet though. Quote Link to comment Share on other sites More sharing options...
Keatah Posted May 19, 2014 Share Posted May 19, 2014 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. Ridiculous! The game uses BIOS routines - which by default is code no matter what you call it. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.