e5frog

Reducing the size of the graphics will increase speed, yes... it also means rewriting a lot of the code unfortunately. When moving I erase only the parts that are not overplotted by the next frame with small rectangles of green, that reduces flicker and also improves speed - not having to erase the entire block of graphics every time. I was thinking today, on the bus on my way to work, that it would be fun to do a minature game and try to reduce the size as much as possible by reducing the size of the graphics, perhaps small enough to compete in http://minigamecomp.org.uk/ I'll keep working on it...

I've added some more collisions, but for now you can only hit the default frame (stand still)... I also managed to speed up the MultiBlitGraphic-routine quite a lot, when output:ing color there was this code: clr .multiblitGetColor: ds 0 bnc .multiblitGetColorEnd ai $40 ; multiply color number by $40 br .multiblitGetColor .multiblitGetColorEnd: This takes at least 6 cycles and at most 37.5 cycles (times four for machine cycles). Length of binary code is also shorter, 4 bytes instead of 8! But as the color data is the two lowest bits all that is needed is to shift them six steps to the left... This way it only takes four cycles every time: lr A, 0 sl 1 sl 1 sl 4 outs 1 Increase in game speed was very noticeable... between 2 and 33.5 cycles faster for each pixel! The updated binary is placed on the same link as above, I recommend the MESS 0.80.1 that is available for download at http://veswiki.com - it has more correct colors, even the ability to set the palette yourself and also updated sound - sounds like a Channel F II, and also the debugger is available - but not turned on by default. I'm going to add more collisions, try and optimize and then fill up the memory with soundeffects... if there's any left. It's a balance act choosing between fast code and short code... MESS screenshot stretched to correct geometry (almost):

I've come this far: http://w5.nuinternet.com/s660100106/files/channelf/test3.bin Movements work on both players, no collision detection yet. It's a bit slow, but as a PAL unit runs faster than MESS and NTSC units I hope it will be playable on one of those. If anyone like to check the code and help out it would be appreciated. Let me know.

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

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.

I've completed a MultiBlitGraphic converter as well and joined the two programs into one converter. It takes a 1 bit color (2 colors) or 4 bit color (16 colors) .bmp and converts a two-color bitmap to blitGraphic-data and 16 color bitmap to MultiBlitGraphic-data as described on veswiki.com. Maximum size is still 128x64, note however that a blit- or MultiBlitGraphic object of that size will write in the background color encoding columns at column 125 and 126... Maximum visible size in MESS is 102x58 which is usually a little more than on a real system and TV. An example picture is included to show which palette the 16 color bitmap is supposed to have to make your MultiBlitGraphic object look the same on the Channel F as on your bitmap picture. I'll upload it to veswiki.com very soon...

OK, it (and a whole lot more) can be found on the veswiki. I recently finished a blitgraphic converter, which converts a two-color bitmap to blitgraphic formatted data, it too can be found on the veswiki. Yesterday I finished a MultiBlitGraphic converter - it takes a 16 color bitmap and converts it into MultiBlitGraphic data, I'm planning to combine the two into one program. It uses a fixed color table instead of checking and comparing the colors of the bitmap to what the Channel F can produce. I haven't decided exactly how it's going to look in the final version, probably black (bkg), blue, red, green, lt. green (bkg), lt.grey (bkg), lt blue (bkg), white (interpreted as blue which displays as white on a b/w row) and the other eight colors interpreted as background. I'll add an example picture with the program so the "correct" palette can be used when drawing your own MultiBlit-objects. Making graphics is now pretty easy!

What's the bump about? The veswiki.com is up and working...

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!

Just wanted to let everybody know 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!

That's how I understood it as well, $10 discount when you trade in your System I unit ( which cost about $170 ? ) and by a System II - which is the same apart from a sound upgrade, not only does it have sound on the TV but the hardware is changed a little to allow playing other frequencies of sound other than the three original beeps. That type of sound sounds pretty awful on a System I unit. If they had released the keypad that was planned to be connected to one of the controller ports it would be a pretty good idea to upgrade - to be able to play the K-1, K-2 etc games - but that never happened unfortunately. BUT I apparently misread - it's even worse - it's a measly $10 off a reconditioned System I! If you want to repair your System I you could send it in and pay $49.50 for the repair, shipping and handling... Edit: Spleling Erorr

I just use Fairchild so I also get to look at all the old Morgan Fairchild photos & the Gen 13 Fairchild drawings FND And all those planes and models... doesn't it fill your mailbox every day?

First thing that I do on old systems are to reseat the socketed circuits, pull them out and put them back in the sockets, perhaps even a few times, this will remove some of the oxidation that builds up over time. It could be the RAM that's defective, there are four of them and they are socketed and easily removed, you could try swapping places and see if you get other patterns on screen... If you do, it would indicate one or more of the RAMs are defective. I don't know if they are hard to find new ones... You should also check that you have 5V and 12V from the power supply part of the unit. If one of them isn't working changing the 7805 (5 volts) or 7812 (12 volts) might solve the problem. If you're unlucky - the VLSI circuit is busted, if I remember correctly it's a 40 pin circuit with no text on it. This is a single circuit replacement for almost all the logic chips that the FVE100 has. Best thing to do is to get another unit and try and swap them, if you get hold of a cheap one this might be your best option, it could be an option in the other cases as well. Good luck!

You have cleverly avoided to use the word "videocart" anywhere in the description, which means my auto-search didn't get it... I was glad to find it here but unfortunately I can't afford that dear old #19 right now, if it's unsold perhaps we can work out a deal? Edit: I noticed I haven't used "channel f" as search words for some reason, I added it right away.

Nice scans, always interesting to get authentic information. I think it was a bit cheap offering only $10 to trade in your FVE100 for a FVE300.

Very nice investigation there FND, now I know what to look for when I get a System II... it must be the Fairchild release of course!

No, there are 8 colors, in color mode - three foreground colors: red, blue, green and backgroundcolors grey, lt.blue or lt.green. In B&W mode all foreground colors turn white and the background is black. 3+3+1+1 = 8 The palette can be set for each row, any combination is possible. If you'd like to see screenshots of games, my gallery is available: http://go.to/channelf Here's an example of where the combination of B&W rows and color make a pretty nice picture: http://www.veswiki.com/Homebrew:Fullscreenpicture It doesn't look that good on a 32" TV though..

Unfortunately with black background color the three foreground colors all turn white. Grey is not available since it's a background color. It looks very nice, why not start programming for use in MESS to start with?

I have both a PAL and an NTSC system, they look the same, so answer is - yes. The problem with writing a 3853 Static Memory Interface replacement is that it's not very well documented, if you check out the documents (pdf:s) at http://www.veswiki.com there are ROM states that aren't 100% clear what to do. I'd welcome anyone to try and do it, but I understand that it will be hard to do without a system to test on. It would be nice to be able to build carts without having to slaughter another. Other late cartridges have a 3853 and rom but in the form of chips directly mounted to the PCB, one of those could be used as well, but as these are pretty rare as well (usually cart 18 and up) you might not want to do that anyway. Buying a batch of 3853 is one way to go as well, they exist but are quite expensive, it can be found at many circuit-brokers... A friend of mine is thinking of using a PIC32, if they're fast enough it might be possible, I haven't heard anything about it for some time now, he might be busy with other things. Maybe we should summon up some prize money to get people interested.

Very nice graphics, a note though is that the pixels are approximately 3:4, three times wide, four times high. I'm feeling a bit of an urge to start programming...

What about having multiple bytes of ROM associated with each address? Every type the F8 asks for a byte of memory, fetch four bytes from the EPROM. Those bytes could then hold the modified PC value or whatever else was needed. Can you elaborate on that I don't quite get what you mean. Thanks.

I have a spare cart to modify, it all depends on how much you're willing to pay for it, it's a lot of work. Send me a message and we can discuss it.

I can solve two of them right away: Luxor 19 and 20 was never released as far as we (other Swedish collectors) know, not that surprisning since they are rare finds for Fairchild/Zircon as well...

Usually the wires break right where they exit the hand controller, but it seems unlikely that all those wires would break at about the same time, perhaps the ground wire has been damaged... I'd check the wiring first anyway.

Yes.