e5frog

I've contacted Namco Bandai about releasing Pac-man for VES/Channel F .... so it might be a gaming publication eventually. Sorry for making the thread into Channel F homebrew. Kurtan is a Swedish nickname for Kurt - I'll send you a message and you can e-mail the converter-.exe if you like. / Freddan

Saba Videoplay is not very rare, $100 is too much, about $50 is more reasonable, even if they are boxed. $50 Saba Videoplay system boxed If all have booklets $500 for all: from $5 to $30 (1, 16 and 20) Saba Videoplay carts 1-20 boxed $70 Nordmende Teleplay system w/mail-order style box $110 for all, $8 rising to $35 if in good condition and has their respective booklet: Nordmende Teleplay carts 1,2,3,4,9,10,12,14 boxed I'm interested in two of the SABA ones and most of the Nordmende Teleplay carts if you want to sell. LetMeKnow / fredriC

That's great Kurt, I'll try it out (I also mentioned about garbled code when using the % sign close to the digits, I'm guessing it reads a ascii code binary or something? Like /%235 or similar. Are you willing to share you converter program? Could be used for smaller gfx as well, like multicolored monsters in Pac-man for instance - or other games. Sorry about the palette, I couldn't see very well what color I should be using on the bubble inkjet printout of the small .jpg-picture you had added, the palette is easily changed as described before. Use DASM and MESS to try your code out, use the multiblit routine since that's the fastest. We may have a problem removing the delay when compiling for old version VES, but removing delay in blit routine works for MESS (hence not accurate emulation) and it also works on the Channel F II and late version consoles of other brands that has the VLSI chip instead of all the logic circuitry... VERY VERY VERY nice work! Do Interkarate+ as well, I'm thinking of making it into a VES-game... Playing on a few different consoles on a few different tv-sets I have come to the conclusion we need to update graphics one pixel extra around the 102x58-field, some tv:s are set wrong and shows like the upper left part of the screen, some shows the right and left edges to far out etc etc... Graphics from now on are a square of 104x60 pixels instead, the inner square of 102x58 pixels is what we count on being visible on a modern tv, I'm guessing a square of 98x56 pixels is safe area to use for any normal TV - keep important things inside that box. I had been thinking about doing a simple rasterscroll, like on the C64 - colorful lines that was plottet over the whole screen - even in the border - and then move them in sinus wave patterns... Should be doable, only need to change two bits to change the color of a background horisontal bar, you change a whole byte at once and you have changed four in that short time... Kurt, it's a wiki - add the link yourself. Blackbird (Tim) tried different patterns of plotting the dots, and that was the best way he could solve it, if you show a picture with a new suggestion we can maybe do that instead. If you look again you'll notice that blue ghosts have no eyes, we're meaning to change them into multicolored monsters if it doesn't slow things down too much. I'm aware af the weak AI, we need to work a little more on that, but we can't use the same method as in the original code since that playfield is made from a series of squares that are compared and such in ways that don't fit our x, y coordinate type of approach to it. If Tim or I had read about the original code before making Pac-man it might have followed that same concept - perhaps Tim starts from the beginning and do a complete rewrite when he's "warm in his clothes" as we say in Sweden - when has started programming again and gotten used to it (he's only 16 years old (exactly HALF my own age) so he ought to have a lot of spare time). That collision is still an x,y issue, we check coordinates for monsters and Pac-man, and if they are too close - it's a hit, but we could perhaps "loosen" it a little... and decrease the "collision-circle" but that will probably affect the other items as well - we'll see... Thanks, we beat the machine that beat our machine. Great input Kurt, thanks a lot! I hope Tim reads these threads as well, I think he has been here at AA, longer than I have... Speed increases by the end since we have less and less dots to redraw, as it is written now, all dots not yet eaten are plottet after each moving object has been updated - it takes shorter time to plot less dots (and powerpills).

... and these are probably under the metal shell next to the LED.... I was thinking if I need to correct the impedance (efter cutting the load of the RF-circuit), it's supposed to be 50 ohms, right? Don't know how I go about that. On the portable NES I'm building for a dear friend the French constructor tipped that a resistor had to be replaced with a 50 ohm resistor to get better picture when drawing composite video directly from the board after removing the RF modulator. Yesterday I saw the exact same type of machine a NESp, in a wooden shell! Mine is built from the NES-shell, looks extremely NES-ish. I might have to sit down and do some actual work on that, good that I found my Electric and electronics schoolbooks today... *sigh* I might just emulate it in some program instead... any tips? Fredric

If ITT... bought Ingelen in 1967 and the Telematch was released ten years later in the Ingelen brand name, why the heck did they change the name to ITT on the unit instead, exact same exterior except for removing the Ingelen logo on the right side and putting an ITT-logo on the left side instead? Perhaps Ingelen systems were sold only in Austria, and the ITT was sold in non-Austrich countries?? Then maybe there are a few more Ingelen machines to get hold of. A fellow collector here in Sweden who has or have had most items known to videogame collectors have of course had an Ingelen machine as well for a little while... It's my belief that the Telematch brand of the Fairchild System is the best one to have except for the hand controllers (same type as SABA Videoplay (not Vidoplay - right, Jens? ) 2, but big rectangular knobs (one blue one red) instead of small square almost cubic knobs... The triangular know is the best in my opinion to get a good grip for twisting. I've swapped controllers on my Telematch machine, and stored the original (fragile) controller in a safe place. The "fins" that hold the whole stick up are very thin and break easily - making a nice maracas but not good to play videogames with. And also the spiral springs were replased with rubber tubes instead - gives softer feel but also a bit wobbly... Rubber will probably also wear out quicker than springs, and age... Best thing about the Telematch machine is the built in antenna switch, it automatically switches the antenna to the game when turned on. Sound on the TV, small footprint (smalles there is). No eject button, you just hook it into place and a goog looking 80's brushed metal front. One thing I've thought about a few times is that all text on the front of the panel are in English except for the ON button - it says "NETZ". I also think the PAL machines runs faster than the NTSC version, cause the crystal is a 4.433619 MHz instead of the 3.something that NTSC has. I noticed it the first time I ran Pac-man on my ITT, music was a little faster than in MESS - not as true to the original as it ought to be. Any downsides then? Well, the antenna output and input are both female, so you have to have a gender changer in the output to connect a normal TV RF-cable (that has one male and one female connector). And the connectors are "hardwired", or really mounted in the shell, since there are connectors on the inside.

Jens... I'm looking forward to receiving a good quality pdf with the complete manual scanned in color in the next few days... Check my post on how to get composite video, I've redrawn the first sheet of the schematic as well, crystal clear now! ... pleeeease? Remember that the is online again! / fredriC

First page done! I'll give away free System Fairchild Luxor stuff to the first person who redraws the second page - it took quite a while! I recommend printing it in poster mode 3x3 pages on yellow paper - and then frame it and hang on a free wall. Went from a 2MB jpg to a 300kB gif... phew. Many thanks to Jasc Paint Shop Pro 7 for starting (and closing) a lot faster than the competing Adobe product I won't mention by name.

Studying the PCB-schematics for the FVE 100 as it is called on the schematics I noticed where the VIDEO input to the RF part was... VIDEO INPUT SHT 2 it says... so I looked at sheet 2 and find this: As you can see by the discreet arrow I added - there's a LED inside the unit by the RF-box, and after that there's a resistor where the VIDEO is connected to the RF-circuit, three resistors meet in that node, so although I don't have those coordinates along the edge of the PCB in my Luxor V.E.S I managed to find it pretty easy - no components at all are marked out by the way: I decided to try it using my defective spare unit connected to a C= 1084S-II monitor: Nice! But quite weak picture, trying it on my working unit there was no difference in quality really - I had to turn the picture very very bright - black is almost the same color as the background: When trying to connect it to a plain TV, I got no picture at all until I connected it via a VHS-machine, just putting the signal through - looks awful: I'd like some help to modify it so that I get a proper signal - the picture is excellent - well worth running on a big screen at the next "local" convention here in Sweden Retrogathering 2007 weekend October 6th (my birthday BTW). But then I thought, why stop there - we might get RGB right away from here (yes it says BLUE in the middle): But there I'm certain I need some sort of amplifier - I know I've seen an RGB mod for another console where such an amplifier was built... I'd like to get the best picture possible: RGB, S-Video (Y/C) or Composite HELP. Here are the complete schematics (it says there are supposed to be 3 sheets, but I only got 2). I am in the making of redrawn schematics without all that black dotty crap in the picture. It's nice to be able to understand why you have to do certain things while programming, using ports for controller input and such: I also noticed that the current build of Pac-man doesn't run on the old version of this console - the delay when plotting graphics need to be longer. It works fine in the second version of the unit, with the VLSI chip instead of all those TTL circuits, I'll see if I can make an RGB/S-Video/Composite mod for that as well, but unfortunately I have no schematics for that one... Thanks for your interest.

Hur går det då?

Jag har ju hållit till här ett tag också - mest System Fairchild relaterade saker då förstås.

The Emerson Machine was sold from Italy, so we can assume it was sold there somtime, the other stuff looks good. Jepp, but someone could also be sitting on a batch oh those programmamble carts and making them into something fake-offical which we so happily drewl over and pay shit loads of money for! I bet some old geezer sits at home with a whole box he has stolen from the company when he worked there and portions them out very slow for most cash and least risk of discovery! Here I am building a double cart, just adding a swich to that type of cart and you can swap between Slot and Checkers as many times as you want to...

Here's the inside of a Democart 2: It has a 8316A "2kB General Purpose Mask Programmable ROM" IS THIS A RE-PROGRAMMABLE CARTRIDGE!? Or was it only one-time-programmable (OTP)? There's at least 2 of these!! This one was bought from Umeå i Northern Sweden in 2005 for only $40 - postage included to Germany...

Oh... and the Ingelen Telematch (released before ITT bought Ingelen), there is also Emerson: There we also have the alternative multi language instruction booklet from SABA. Luxor also have variations on the booklets, Swedish, multi lingual and a blue/white version in German only. Luxor also relabeled a few SABA carts, just small white labels in the corner of box and label - and an instruction sheet. But I'm guessing you're satisfied with a complete cart collection? Luxor has two version cart-labels as well, just an extra black label with white text on the lower part of the original Farichild labels and their own blue/white version. I don't know much about Barco, Dumont and Emerson, I have basically only seen pictures of them. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewI...em=320087391262 Looks like it says Emerson Videoplay System.

Wow! I just tried this out and i must say it's darn impressive!!! I wouldn't have thought the channel-f could do such an accurate port of pac-man (considering it's technical limitations)! Many thanks! Check out the you too!

I usually write in wordpad, and compile with dasm. Testing in MESS with debugger, I've left the link to a Channel F improved version (external palette-file, System 2 sound). There is a very good Development package at the Direct-link: http://www.bingbangboom.us/productions/ves.../3/3a/Devel.zip

Last change (I think) of the picture program was to improve the palette drawing. I defined it as a blitGraphic object, 2 pixels wide and 58 pixels tall to be plotted at the palette columns 121 and 122. Only 23 bytes is needed for all the palette data ( .word is 2 bytes - 16 bits (adress)) instead of setting coordinates and plot one dot at a time. Binary data in the gfx.palette.data: 00 gives black background row 01 lt. gray/grey 10 lt. blue 11 lt. green ; full screen picture demo by e5frog, original picture painted by Kurt_Woloch processor f8 ;=========================================================================== ; VES Header ;=========================================================================== include "ves.h" ;=========================================================================== ; Configuration ;=========================================================================== game_size = 4 ; game size in kilobytes ;=========================================================================== ; Program Entry ;=========================================================================== ;--------------------------------------------------------------------------- ; Cartridge Initalization ;--------------------------------------------------------------------------- org $800 cartridge.init: ; initalize the system CARTRIDGE_START CARTRIDGE_INIT ;--------------------------------------------------------------------------- ; Main Program ;--------------------------------------------------------------------------- main: ; clear to B&W li $21 lr 3, A pi clrscrn ; plot picture blue dci gfx.blue.parameters pi blitGraphic ; plot picture red dci gfx.red.parameters pi blitGraphic ; plot picture green dci gfx.green.parameters pi blitGraphic ; set palette dci gfx.palette.parameters pi blitGraphic ; wait for hand controller input pi wait.4.controller.input ; clear to B&W li $21 lr 3, A pi clrscrn ; now draw multiblit version dci gfx.multicolor.parameters pi multiblitGraphic ; set palette dci gfx.palette.parameters pi blitGraphic ; wait for hand controller input pi wait.4.controller.input jmp 0 ; restart wait.4.controller.input: ; see if one of the hand controllers has moved clr outs 0 outs 1 ; check right hand controller ins 1 com bnz wait.4.controller.input.end ; check the other controller clr outs 4 ; check left hand controller ins 4 com bnz wait.4.controller.input.end br wait.4.controller.input wait.4.controller.input.end: pop ;--------------------------------------------------------------------------- ; gfx drawing routines include "drawing.inc" include "multiblit.inc" ; graphics data include "picture-palette.inc" include "blue.inc" include "red.inc" include "green.inc" include "multicolor.inc" ;=========================================================================== ; Signature ;=========================================================================== ; signature org [$800 + [game_size * $400] -$10] signature: .byte " e5frog 2007 " Remember that the is up again! Edit: Ooops... forgot to upload the new binary: picture.bin textfile_010_bitmap_data_to_asm_bytes.exe.bin

Now when VESwiki is back I manged to test the MultiBlitGraphic routine that young Blackbird has written. In this new binary the three segment picture is drawn first as before, then it waits for input from one of the hand controllers (press anything). Screen clears to black again (as it did before the picture was the first time). MultiBlit-picture is drawn - significantly faster, I'm guessing >25% or something like that. Graphics data is ofcourse also shorter - 1/3 shorter. Machine waits for new hand controller input and then restarts program Conclusion - large multicolor pictures on Channel F is best drawn with the MultiBlitGraphic-routine! http://www.bingbangboom.us/productions/ves...ippet:Multiblit picture.bin

Now there's help! VESwiki is now UP! http://www.bingbangboom.us/productions/ves...title=Main_Page

VESwiki is now UP! http://www.bingbangboom.us/productions/ves...title=Main_Page

VESwiki is now UP! http://www.bingbangboom.us/productions/ves...title=Main_Page

VESwiki is now UP! http://www.bingbangboom.us/productions/ves...title=Main_Page

I've got one of those, in near mint condition - unfortunately it came without the box: The twists are connected to the POT Y and POT X connectors on the Atari/VIC interface, but I don't know what happens if you ground the POT pin since they're usually connected to +5V through a variable resistor. To fire you press down (which makes it useless for speed-shooters), the pull up function is not connected to any wire.

I made a copy of the Instruction set table of the "Polhoff"-book Attached here as a Word-document: F8_instruction_set_table.doc

the table says that reg0 -reg31 are general purpose so are these what I have at my disposal for everything else That's only the table used in that version of Pac-man, these aren't used to store information during the gameplay, but rather as temporary registers for storing temporary data. The 16 registers 0- 15 can be used directly, r9 - r15 also have alternate names ( J, HU, HL, KU, KL, QU and QL). H, K and Q can be used as 16 bit registers when handling addresses and such, H is made up of HU and HL and the other two uses the same principle. So, instead of doing this: lisu 0 lisl 7 lr A, S You can transfer contents of register 7 directly lr A, 7 Which saves both code and processing time. So instead of doing a lot of work on the registers, changing ISAR and so on, you can transfer what you need to work with to these lower 15 registers. Like the plot routine, you transfer the correct values into the lower registers and then it goes to work. Then you can also save time by using consecutive registers, doing that you only need to set a start register in ISAR and then increase or decrease it at the same time as you "Load Register" . Copy register 'o'20-22 to registers 2-4: lisu 2 ; load upper value of ISAR 'o'2 lisl 0 ; load lower value of ISAR 'o'0 lr A, I ; copy register 'o'20 into A and increase ISAR (now 'o'21) lr 2, A ; copy A into register 2 lr A, I ; copy register 'o'21 into A and increase ISAR (now set to 'o'22) lr 3, A ; copy A into r3 lr A, D ; copy register 'o'22 into A and decrease ISAR (now set to 'o'21) lr A, D ; same again, just to set ISAR back to 20 - as we started with. You'll figure it out if you check the pdf:s.

Octal is a number system that has eight values only: 0-7, decimal has 10: 0-9 and hexadecimal has 16: 0-F. You have registers 0 - 63 to play with, the lower registers can be addressed and played with without the need to go via the ISAR. These lower registers are usually used in different routines, as they can be used quicker (not having to deal with ISAR). Examples are the plot, blit, delay etc. etc. Here's the table we use in Pac-man to permanently store information about the ghosts, octal numbers written with three digits (all start with 0) and the decimal equivalence after #: GHOST_0_X_REG = 040 ; #32 GHOST_0_Y_REG = 041 ; #33 GHOST_0_DIR_REG = 042 ; #34 GHOST_0_ANIM_REG = 043 ; #35 GHOST_1_X_REG = 044 ; #36 GHOST_1_Y_REG = 045 ; #37 GHOST_1_DIR_REG = 046 ; #38 GHOST_1_ANIM_REG = 047 ; #39 GHOST_2_X_REG = 050 ; #40 GHOST_2_Y_REG = 051 ; #41 GHOST_2_DIR_REG = 052 ; #42 GHOST_2_ANIM_REG = 053 ; #43 GHOST_3_X_REG = 054 ; #44 GHOST_3_Y_REG = 055 ; #45 GHOST_3_DIR_REG = 056 ; #46 GHOST_3_ANIM_REG = 057 ; #47 There's also a temporary register to hold the values of the current ghost being manipulated: GHOST_TMP_X_REG = 034; #28 GHOST_TMP_Y_REG = 035; #29 GHOST_TMP_DIR_REG = 036; #30 GHOST_TMP_ANIM_REG = 037; #31 Then we have a cycle that copies ghost 0 information to the temporary registers, change that accordingly, copies it back, copies next ghost, change, copies back etc... That way we can use the same routine for all the ghosts, I don't know if this is the best way, but that's how Blackbird solved it - if looking for speed it's probably better to have one routine for each ghost, not copying back and forth between a temporary register. You should really take a look at these pdf:s if you haven't already, I uploaded all of them into my personal webspace except for the circuit schematics of the Fairchild unit: Best one: http://w5.nuinternet.com/s660100106/files/...Programming.pdf Others: http://w5.nuinternet.com/s660100106/files/channelf/f3850.pdf http://w5.nuinternet.com/s660100106/files/...lf/f3851_56.pdf http://w5.nuinternet.com/s660100106/files/...lf/f3852_53.pdf http://w5.nuinternet.com/s660100106/files/...eneral_info.pdf http://w5.nuinternet.com/s660100106/files/...hoff_(1979).pdf I recommend printing the F8_Guide_to_Programming.pdf and definately the instruction-table from f8_info_'16_bit_%B5P_architecture',_Terry_Polhoff_(1979).pdf to more easily see what commands are available, what they do and how slow they are. As you can see in that table a PI takes 6.5 cycles to complete, so if you're using a routine a lot you'll save time if you are able to reach it without using a subroutine call. Happy programming!