136 replies to this topic

[Bruce Tomlin]

It was pointed out to me that I got the branches off by one in my own assembler. I also fixed up a few other things (in particular, adding the S, I, and D, register indirect modes) and will release a new version in the next couple of days.

In the meantime, you can change both instances of "EvalBranch(2)" to "EvalBranch(1)".

Basically, at the time I didn't have the Fairchild docs, and didn't have any real binary code to look at. Now I've got the docs, downloaded all of GoodChaF, and hacked F8 into my own disassembler so that I could look at some of the code.

Here's a couple things about Channel F cartridges:

The BIOS goes from $0000-$07FF.

Cartridges start at $0800 and are mostly 2K, 3K, and 4K. There is one 6K game, Schach/SABA-20.

The first byte of a cartridge must be $55. The entry point of a cartridge is $0802. All scratchpad registers are cleared except for register 59 ($3B), which is loaded with $28.

[Bruce Tomlin]

Okay, I downloaded lights.asm. First of all, he uses that "(IS)" thingy which isn't standard F8 syntax, but I got it working. Then he does the ORG directive in column 1, which is also non-standard, and just plain a bad idea anyhow. But if you fix that, it assembles just fine.

[~llama]

The new F8-enabled DASM is working, and you can get it from the [channelf] list and start using it for Channel F stuff, and also Bruce's assembler and now f8tool is publicly available too... so we now have lots of options.

I'm getting started on some simple demo stuff, so... should be fun

[Blackbird]

Sounds great! I'll have to try out DASM in the morning, hope what I've written so far works fine with it...

[Andrew Davie]

~llama said:

Stay tuned for a probably public release of DASM/F8 and then lots of cool Channel F stuff

Yes indeed. Thomas's changes are now installed into my latest DASM code-base. Only a day or two of testing to go, and I'll release an official F8 update of DASM. The release DASM can always be found on www.atari2600.org/dasm -- look for the official update there, soon. Many thanks to Thomas for his fine work on this one!

Cheers
A

[Andrew Davie]

~llama said:

is there any documentation available about the Channel F, for homebrewing purposes? I'm sick, I know, but... perhaps there is some homebrew potential in the Channel F

For those interested, DASM now supports the Fairchild F8 processor (as used by the Channel F). Version 2.20.10 is available from http://www.atari2600.org/dasm

Cheers
A

[~llama]

Andrew Davie said:

~llama said:

is there any documentation available about the Channel F, for homebrewing purposes? I'm sick, I know, but... perhaps there is some homebrew potential in the Channel F

For those interested, DASM now supports the Fairchild F8 processor (as used by the Channel F). Version 2.20.10 is available from http://www.atari2600.org/dasm

Cheers
A

I definitely posted something about this in the Programming section while you were posting this in this forum, simultaneously. Weird.

[Ferris]

The important thing with the 3200 is not to get it confused with the 3600, I see that quite often. The 3600 was merely the working title of the 7800 before they renamed it. The 3200 was supposed to take over for the 2600 sometime in 1980. (I think this was project Sylvia) The unit was really sleek looking and was designed by Roy Nishi. The 3200 would have been reverse compatible with the 2600 and would feature "arcade-style graphics" similiar to the 7800. Word is, the unit was developed to be just too far ahead of its time and started getting quite expensive really fast and they ran into some major hurdles with programming as many of the software engineers who were so used to the 2600 and 400/800 said the 3200 was just too darn hard to program. I've been told this was to be a "10-Bit System" but that sounds rather strange. I didn't even know that was possible to have a "10-Bit System" but that may well have been part of the reason this thing was so hard to code for. Either way, they scrapped the 3200 and started over and had to patch together a quick solution to the "next gen" system ordeal and hacked the 400/800 down into the 5200 and the rest is history.

Even if there was sufficient documentation the 3200 would most likely be too hard to program for. I'd still love to see some good info come out about this. I know Curt has *some* info but I'm not sure how much.

...damnit why does everything always have to be such a mystery? I always end up feeling like Fox Mulder on a conspiracy theory.

[Cootster]

Ferris said:

I've been told this was to be a "10-Bit System" but that sounds rather strange. I didn't even know that was possible to have a "10-Bit System" but that may well have been part of the reason this thing was so hard to code for.

Doesn't the INTV use some form of 10-bit addressing?

[Blackbird]

Sorta... which is why it's so hard to make an intellivison cartridge. Wikipedia says:

Quote

The Intellivision was the first 16-bit game console, though people have often mistakenly referred to it as a 10-bit system because many of the CPU's commands are 10 bits in length.

The 3200 seems like it was actually a 10-bit console, though...

[Ferris]

Blackbird said:

The 3200 seems like it was actually a 10-bit console, though...

Agreed. I do not have any documentation on this myself but I have spoken with those that do and those that were there. To most of these guys this was just another exciting job in the Valley from 25 years ago so some things they dont remember as well as others. However almost everyone Ive spoken with about the 3200 who would have any kind of knowledge believes it was based on 10-Bit architecture and thus was too difficult to program for at that time. The working name at the time was "Super Stella" or "Sylvia" The unit really has the quintessential "Atari that never was" feel to it. Seems as if every home would have had one of these things for Christmas 1981. Woulda made Coleco think twice before entering the market.

Sidenote : To make a correction with regards to my last posting, the 3200 was worked on mostly in 1981, not 1980.



Here are some pictures of the 3200's designs:

Attached Thumbnails

• 

[Bryan]

Looks cool, but sorta like an 80's answering machine.

-Bry

[Ferris]

I think it's beautiful. I've tried to track down one of the prototypes but Roy Nishi doesnt have any of his anymore =(

[~llama]

i think the angled top looks great, and looks good mirrored, too... but the buttons bother me intensely... they don't fit... I'm not sure what they could have done to make them look any better but they would have had to do something...

[SeanRiddle]

I thought I had posted the source to my menu program, but I hadn't, so I just added it to http://members.cox.n.../chanfinfo.html. In it is some code I stole from the Football cart to play songs. It only works well on System II hardware (or MESS). In System I it sounds pretty harsh. The cart 17 disassembly shows how to make the 3 built-in beeps.
Sean

[Blackbird]

In the interest of Channel F programming, I've set up a Channel F Programming Wiki that is open to the public. It can be found at:

http://www.bingbangb...ojects/veswiki/

Over time I and hopefully several others will be adding info related to programming the VES, including programming reference, code snippets, tutorials, and disassemblies. Feel free to browse through the wiki, or to add more content yourself!

[supercat]

SeanRiddle, on Sun Oct 24, 2004 11:37 PM, said:

OK, here's a page with links to a bunch of info:

Interesting stuff there, including the (somewhat hard to read) schematic. It's interesting that while the Channel F is regarded as having 64 bytes of RAM, it actually had 2 whole kbytes of video memory. I don't know what restrictions where were on processor access to VRAM, but it would seem the Channel F could probably do a lot of things the 2600 and Intellivision could not. A decent Missle Command knockoff would seem entirely feasible.

I don't really see much point in homebrewing for the Channel F, though, given that the audience is much smaller than the audience for e.g. Atari 2600 games. It would appear, though, that it should have been possible to produce some decent games for that system.

BTW, I wonder if it would be practical to design a homebrew cartridge system using logic quite different from (and simpler than) what the F8 designers had in mind. For example, since the ROM data bus is going to be 16 bits wide even though only 10 bits are needed by the F8, the other 6 bits could be used to assist in address calculation.

Alternatively, one could probably code an entire game mechanic in something like a PIC and just have it feed the F8 instructions to draw what needed to be drawn and kick back information about the controllers, etc.

[Bruce Tomlin]

supercat, on Wed Jul 20, 2005 6:36 PM, said:

BTW, I wonder if it would be practical to design a homebrew cartridge system using logic quite different from (and simpler than) what the F8 designers had in mind.  For example, since the ROM data bus is going to be 16 bits wide even though only 10 bits are needed by the F8, the other 6 bits could be used to assist in address calculation.

Uhhhh... that's the Intellivision you're thinking of there. While both of them have relatively complicated bus protocols, I think that the F8 bus interface is actually more complicated.

[supercat]

Bruce Tomlin, on Wed Jul 20, 2005 7:22 PM, said:

While both of them have relatively complicated bus protocols, I think that the F8 bus interface is actually more complicated.

I know the F8 is horrendously more complicated, but I thought both used ten-bit instruction words. Maybe I'm misremembering.

In any event, my recollection was that one of the complications of the F8 addressing device was the need for an ALU to compute branch addresses. Having branch addresses partially-precomputed in the excess words of an instruction would seem to greatly simplify the addressing logic (among other things, doing the Nth bit of an ALU in a PLD requires 2^N minterms; this quickly becomes impractical as N gets big. If one had six extra bits which could hold precalculated intermediate carries, one could split the ALU into smaller pieces, vastly reducing the number of minterms required for each.

[Bruce Tomlin]

The F8 data bus is strictly 8-bit. There are no "extra bits".

I suggest that if you don't want to use a PLD more complicated than GAL chips, at least for getting the initial design right, it might be helpful to make the ALU out of plain TTL chips. That way you could concentrate on getting the bus protocol right first, then worry about implementing the adder later.

[djmips]

I'd like to have a custom chip to replicate of the features in the Saba Cart 20 (the German Chess game) which allows standard ROMs as well as 2K of RAM. If you recall from Sean Riddle Chan F info, the chess cart uses a 3853 which converts the F8 control signals into a "full blown address bus" and allowed him to more easily create a multi cart.

I finally snagged a Channel F!

I'd like to build a downloader cart myself but I don't hold out too much hope on getting Saba Cart 20...

[Luigi301]

Isn't the Channel F a year older than the 2600?

[Rob Mitchell]

Luigi301, on Mon Jul 25, 2005 3:59 AM, said:

Isn't the Channel F a year older than the 2600?

yup! 1976.

Rob Mitchell, Atlanta, GA

[~llama]

supercat, on Wed Jul 20, 2005 8:12 PM, said:

In any event, my recollection was that one of the complications of the F8 addressing device was the need for an ALU to compute branch addresses.  Having branch addresses partially-precomputed in the excess words of an instruction would seem to greatly simplify the addressing logic (among other things, doing the Nth bit of an ALU in a PLD requires 2^N minterms; this quickly becomes impractical as N gets big.  If one had six extra bits which could hold precalculated intermediate carries, one could split the ALU into smaller pieces, vastly reducing the number of minterms required for each.

I have the F8 Reference Manual/User Manual in front of me, and it would appear that you're right about all this ALU nonsense. Yet another thing that makes me really not like the F8 all that much. The [channelf] list really kind of died off... I would love to get it going again, but I never really learned F8 well enough to do anything meaningful in it. A good experiment, I guess... and DASM has F8 support now I got a VIC-20 and got kind of sidetracked from Atari and Channel F. I'm turning into a bit of a Commodore fanboy

[djmips]

A little Batari Basic would jumpstart things... As in a port to the Channel F. And then we port Ooze or Solar Plexus.