e5frog, on Fri Nov 23, 2007 11:14 PM, said:
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.
3
)
Like us on Facebook
Follow us on Twitter
Watch us on YouTube