List of CGE Homebrews in RETRO (magazine)

[Atari Charles]

If someone wants to share their homebrews here in the forums, I'm unaware of anything stopping them from doing so.

 

http://www.atari2600homebrew.com/

 

is an excellent site and actually has the storylines, cart scans/pictures, screenshots, manuals, and many of the roms(if publicly released). I think the webmaster is in the process of updating the site. Anyway, I think is the go to site for information on homebrews, hacks, reproductions, demos, and non-game releases.

Edited January 31, 2015 by Atari Charles

[Greg Zumwalt]

As you insist upon making a fool of yourself and trolling this post, this is the last time I will respond as I grow ever sickend by having to show the public your arrogance and "prove myself to you".

 

For future reference, don't ever post again to any of my posts if all you plan to do is troll.

You've already tarnished the good news of my games being released and I don't appreciate it.

 

If you don't have anything good to say, don't post.

 

Here's your program output.

This is YOUR own software showing MY work is NOT the same as others.

Does it make you happy, proud, satisfied?

Don't bother to answer as I know nothing will.

 

[Thomas Jentzsch]

Whether the game is done in Assembly, Batari Basic, Hackomatic, Bit Hacker or using Borg technology from the 23rd century, I have seen some awesome releases by many different people carried by many different companies. When I see new or newer releases making it on the Flashback, I am really happy to see new games making it so mainstream.

I am happy for the same reason.

[+Nathan Strum]

 

http://www.atari2600homebrew.com/

 

is an excellent site and actually has the storylines, cart scans/pictures, screenshots, manuals, and many of the roms(if publicly released). I think the webmaster is in the process of updating the site. Anyway, I think is the go to site for information on homebrews, hacks, reproductions, demos, and non-game releases.

 

I'll reiterate my suggestion for adding gameplay videos. Screenshots say nothing of the gameplay, which is of far more importance than cart scans and storylines. Of the first 12 games I looked at on that site, 10 had no ROMs available, and one page had a broken link (404).

[Greg Zumwalt]

Please people....

I do feel bad about this, it really does sicken me too.

I have games posted on dozens of other sites but it is only on AA I get attacked and accused and it has always been the same troll.

No matter his contributions, you have no idea how much trouble he has stirred up.

I could post some emails that would clearly show the viewers just what is being done and why so many programmers are being driven away, but that would only feed the trolls and damage a very delicate situation that Albert is working hard to amend.

It is a shame that trolls still strive to undo it.

 

This is why I don't like comming to places where trolls just rune all the joy.

To that end, I will not be posting again any time soon and I will leave matters to my publicists to address.

[Atari Charles]

 

I'll reiterate my suggestion for adding gameplay videos. Screenshots say nothing of the gameplay, which is of far more importance than cart scans and storylines. Of the first 12 games I looked at on that site, 10 had no ROMs available, and one page had a broken link (404).

 

I agree and will mention it. I think the site needs to be updated, but I am not the webmaster. From the info I have, some roms are posted, some have not been but will be, and some are not released to the public.

[LS_Dracon]

Take it easy Greg, nobody here is bashing your works.

 

I know what you feel, I already have a bad start in other community long time ago.

And lost much time with trolls and flame wars, and they aren't nothing.

They don't represent the whole community.

Edited January 31, 2015 by LS_Dracon

[Thomas Jentzsch]

Here's your program output. This is YOUR own software showing MY work is NOT the same as others.

Thanks for checking again. I wonder why Demon Attack from CCE is not related to the other versions. There seems to be a bug hiding in my old code. Can you post the clones.txt file? That should help fixing it.

 

Anyway, judging from your screen shot you are right and I stand corrected: The Shaman is not a hack of Demon Attack.

 

Sorry, that my wrong assumption made you upset.

[+Nathan Strum]

Regarding trolls: this forum has a nice feature allowing you to block posts from people you don't want to read. Go under your settings to where it says "Ignore Settings" and then type in the first few characters of their name. Auto-complete will bring up a list to choose from. I just tried it, and it works.

Edited February 1, 2015 by Nathan Strum

[Mr SQL]

I do feel bad about this, it really does sicken me too.

I have games posted on dozens of other sites but it is only on AA I get attacked and accused and it has always been the same troll.

No matter his contributions, you have no idea how much trouble he has stirred up.

I could post some emails that would clearly show the viewers just what is being done and why so many programmers are being driven away, but that would only feed the trolls and damage a very delicate situation that Albert is working hard to amend.

It is a shame that trolls still strive to undo it.

 

This is why I don't like comming to places where trolls just rune all the joy.

To that end, I will not be posting again any time soon and I will leave matters to my publicists to address.

Hi Greg,

are you the same programmer who wrote those awesome CoCo games bitd? I was on the scene with Saint John Gallery Software in the Rainbow and at the 80's expos - awesome to see you on the forum either way but even cooler if you are indeed that legendary developer!

 

You have a fair point and I've seen some awesome old school programmers from the 80's getting driven off the forum but there are plenty of gamers and collectors with great attitudes enthusiastic about joining in the retro fun; and plenty of fantastic developers from yesterday and today

 

[Greg Zumwalt]

Regarding trolls: this forum has a nice feature allowing you to block posts from people you don't want to read. Go under your settings to where it says "Ignore Settings" and then type in the first few characters of their name. Auto-complete will bring up a list to choose from. I just tried it, and it works.

Thanks. I was not aware of that feature.

[Greg Zumwalt]

TronSmiles.jpg

Hi Greg,

are you the same programmer who wrote those awesome CoCo games bitd? I was on the scene with Saint John Gallery Software in the Rainbow and at the 80's expos - awesome to see you on the forum either way but even cooler if you are indeed that legendary developer!

 

You have a fair point and I've seen some awesome old school programmers from the 80's getting driven off the forum but there are plenty of gamers and collectors with great attitudes enthusiastic about joining in the retro fun; and plenty of fantastic developers from yesterday and today

 

 

Ah, now you've gone and done it.

Do you mean,

Am I the person who co-developed the 68B09E2 CPU, created the SP2000 chip, co-created the E.A.R.S. Project; created the CoCo4 prototype; co-designer of the MMU 1Mb expansion;

Member of the Holy Trio;

Designer of the Oblique Triad, programmer of the A D J S DOS's;

Co-programmer of the TRS-DOS, OS9 LV1, OS9 LV2 (lets hear it for Lear and Pike!), RGB-DOS and HD-DOS operating systems;

Creator of more than 300 games and dozens of utilities carried by Data East, Sundog, Tandy, Owl-ware, ZCT Systems, DieCom, Activision and others;

Co-programmer of Jeff Vavasour's DOS CoCo emulator (registration #0095C);

Creator of the Win8 CoCo emulator;

Owner of the Snow White BBS (now the Wild Side), largest CoCo 3 repository in the world;

Creator of many DeskMate works of art, RAT to GIF converter, 256 colour display code;

Creator of the MIR SatTrack uplink and element reader;

Featured guest in CoCo Friends, TRS80, Turn of the Screw, Nine Times, Rainbow and other zines;

Having been interviewed by Rick Cooper, Nickolas Marentes, John Kowalski, Mike Snyder and spotlighted entry in CoCoNUTS?

Sorry mate, don't know who you could be thinking of on an Atari forum

But if I were, mayhap we met at Penfest.

[Mr SQL]

 

 

Ah, now you've gone and done it.

Do you mean,

Am I the person who co-developed the 68B09E2 CPU, created the SP2000 chip, co-created the E.A.R.S. Project; created the CoCo4 prototype; co-designer of the MMU 1Mb expansion;

Member of the Holy Trio;

Designer of the Oblique Triad, programmer of the A D J S DOS's;

Co-programmer of the TRS-DOS, OS9 LV1, OS9 LV2 (lets hear it for Lear and Pike!), RGB-DOS and HD-DOS operating systems;

Creator of more than 300 games and dozens of utilities carried by Data East, Sundog, Tandy, Owl-ware, ZCT Systems, DieCom, Activision and others;

Co-programmer of Jeff Vavasour's DOS CoCo emulator (registration #0095C);

Creator of the Win8 CoCo emulator;

Owner of the Snow White BBS (now the Wild Side), largest CoCo 3 repository in the world;

Creator of many DeskMate works of art, RAT to GIF converter, 256 colour display code;

Creator of the MIR SatTrack uplink and element reader;

Featured guest in CoCo Friends, TRS80, Turn of the Screw, Nine Times, Rainbow and other zines;

Having been interviewed by Rick Cooper, Nickolas Marentes, John Kowalski, Mike Snyder and spotlighted entry in CoCoNUTS?

Sorry mate, don't know who you could be thinking of on an Atari forum

But if I were, mayhap we met at Penfest.

 

Wow that's awesome Greg! I enjoyed your fantastic games and your work inspired me bitd!!

 

It's a pleasure to meet you on an Atari forum, or anywhere else for that matter. Wish I had met you in the 80's, we certainly talked about you enough in the computer clubs - many programmers found your work equally inspiring!

 

I was never at the PennFest, only the Princeton expo's in the booth with the beautiful artwork (The Saint John Gallery was my Fathers art company before it became a software company). SunDog had some nice art in their ads as well that I remember seeing in the Rainbow.

 

Isn't the VCS fun and refreshing to code on for a CoCo programmer with it's unique accelerator hardware? Twin oscillators that keep outputting that phat sound and high res hardware sprites over semi-graphics with so many colours all racing the beam The 4-switch models even leak chroma like A CoCo - I've been having fun artifacting on the Atari!

 

You actually built accelerator hardware for the CoCo for processor independant sound and your CoCo4 prototype was over the top! I really missed the higher res semigraphics modes of the 6847 that Pickett dropped from the GIME design; they had awesome game potential I was focusing on at the time.

[Greg Zumwalt]

Wow that's awesome Greg! I enjoyed your fantastic games and your work inspired me bitd!!

 

It's a pleasure to meet you on an Atari forum, or anywhere else for that matter. Wish I had met you in the 80's, we certainly talked about you enough in the computer clubs - many programmers found your work equally inspiring!

 

I was never at the PennFest, only the Princeton expo's in the booth with the beautiful artwork (The Saint John Gallery was my Fathers art company before it became a software company). SunDog had some nice art in their ads as well that I remember seeing in the Rainbow.

 

Isn't the VCS fun and refreshing to code on for a CoCo programmer with it's unique accelerator hardware? Twin oscillators that keep outputting that phat sound and high res hardware sprites over semi-graphics with so many colours all racing the beam The 4-switch models even leak chroma like A CoCo - I've been having fun artifacting on the Atari!

 

You actually built accelerator hardware for the CoCo for processor independant sound and your CoCo4 prototype was over the top! I really missed the higher res semigraphics modes of the 6847 that Pickett dropped from the GIME design; they had awesome game potential I was focusing on at the time.

 

Oh, now you're showing my age

And now that this cat has slipped the bag...

 

Those really were the days when we walked the world like Titans in the dawn of modern computers, and the CoCo was years ahead of its time.

And we didn't just make the games, we built the machines to run our OS's to play our games!

With a UNIX like OS and all that power! We were unstoppable!

Been a long time though, and I contributed my work to the CoCo community years back.

I still keep in touch on occasion, as here, but I usually try to keep my work seperated.

 

Still have some magazines and manuals laying about though. Found a box full of Rainbows

One of the best things about that system was all its undocumented abilities. Conversely, it was also the worse with so many circuits removed and misdocumented from its prior version.

When I software coded the system to reenable the 256 colour display, it changed gaming. NES wouldn't even be released until late 1985 (and didn't get popular until 1987 once it reached Europe) and by then I had already released a slew of games with graphics just as good by a system years older.

In fact, it is that same concept I used years later to get so many colours on the Atari. A PitA to program the 650x but at least its documented well.

 

Next thing you know someone's going to start on about the games I've made for Intellivision, Colleco, NES, Playstation, PC or even boardgames (you know, those things people played before electronic entertainment) for GURPS, Paladium, Brain Games, White Wolf, Marvel and last but certainly not least, TSR.

Have I ever mentioned on my more than a decade with Atari Age that I have made a few games in the past?

 

My other work aside though, on the CoCo I still love Rogue for LVII, with the 512K patches of course A few years back I even ported it to Win8 just to add to my large Rogue-Like collection. I've also made a 2600 version. Not as elaborate. Unfortunately, due to the ENORMOUS 64Kb size and having used a TigerChip in coding it, the cost is too prohibative to produce in quantity and sell. Once I catch up on my latest projects I may go back and recode it for a less expensive Atari chip.

 

 

You might get a kick out of these images.

A 256 colour display on the CoCo;

my old system;

and, whoa, who are those guys and what are we doing hiding inside your computer?

Oh yeah, we were there long before the NSA got inside everyones system

[Mr SQL]

 

Oh, now you're showing my age

And now that this cat has slipped the bag...

 

Those really were the days when we walked the world like Titans in the dawn of modern computers, and the CoCo was years ahead of its time.

And we didn't just make the games, we built the machines to run our OS's to play our games!

With a UNIX like OS and all that power! We were unstoppable!

Been a long time though, and I contributed my work to the CoCo community years back.

I still keep in touch on occasion, as here, but I usually try to keep my work seperated.

 

Still have some magazines and manuals laying about though. Found a box full of Rainbows

One of the best things about that system was all its undocumented abilities. Conversely, it was also the worse with so many circuits removed and misdocumented from its prior version.

When I software coded the system to reenable the 256 colour display, it changed gaming. NES wouldn't even be released until late 1985 (and didn't get popular until 1987 once it reached Europe) and by then I had already released a slew of games with graphics just as good by a system years older.

In fact, it is that same concept I used years later to get so many colours on the Atari. A PitA to program the 650x but at least its documented well.

 

Next thing you know someone's going to start on about the games I've made for Intellivision, Colleco, NES, Playstation, PC or even boardgames (you know, those things people played before electronic entertainment) for GURPS, Paladium, Brain Games, White Wolf, Marvel and last but certainly not least, TSR.

Have I ever mentioned on my more than a decade with Atari Age that I have made a few games in the past?

 

My other work aside though, on the CoCo I still love Rogue for LVII, with the 512K patches of course A few years back I even ported it to Win8 just to add to my large Rogue-Like collection. I've also made a 2600 version. Not as elaborate. Unfortunately, due to the ENORMOUS 64Kb size and having used a TigerChip in coding it, the cost is too prohibative to produce in quantity and sell. Once I catch up on my latest projects I may go back and recode it for a less expensive Atari chip.

 

 

You might get a kick out of these images.

A 256 colour display on the CoCo;

my old system;

and, whoa, who are those guys and what are we doing hiding inside your computer?

Oh yeah, we were there long before the NSA got inside everyones system

Those were magical times

Awesome you made games for TSR! Had a blast playing their D&D genre with the 20 sided die when I was a teenager

 

And very cool you got the 256 colour mode to work on the CoCo3, I'd heard of it but thought it was a fable no one could find! How did you do it!?

Rogue is awesome! Is the Tiger chip running code like the ARM on the Harmony?

[Greg Zumwalt]

Those were magical times

Awesome you made games for TSR! Had a blast playing their D&D genre with the 20 sided die when I was a teenager

 

And very cool you got the 256 colour mode to work on the CoCo3, I'd heard of it but thought it was a fable no one could find! How did you do it!?

Rogue is awesome! Is the Tiger chip running code like the ARM on the Harmony?

 

I did some work with SSI on Eye of the Beholder but only as a consultant.

I also co-owned a Power House Comic so I had access to all the gaming materials and before the public.

 

I know very little about the internal workings of the Tiger Chip or the Harmony cart. Never seen a TC and as I've only one HC I don't feel like ripping it appart to examine it. I'm sure others on this forum could help with answering those questions. The TC does use additional accumlators and banking that differs from the standard chips. Makes programming easier but costs a lot more to make.

 

The 256 colour mode was no fable. Most thought it is was just a typo in the flyer, but it in fact exists, depending on your chip version, and how much code you want to apply.

 

Here is a bit of conversation and info about the subject from a few years back.

I'll put it here, but then if you want to keep the topic going I think we should go private as it really isn't on topic, not even the right forum

 

 

 

 

CoCo Team: OMG! I finally found you after nearly 3 years of searching!!!

I am so delighted to have been able to track you down

Spent ages going through old forum and email posting, dead email

Addresses, hundreds of gaming sites, et c.

I am Tiger and I run the CoCo archives out of Australia. Some developers and I have been trying to modify a CoCo3 by adding back the hardware you researched and recoded back in 1984. I would really, really, love it if you could help us. We are trying to find schematics, code tables and any software related to producing 256 colors along with anything else you can share on the matter.

Hopefully u still have something about stuff u found in the Gime chip with luck. Or u got a technical document from tandy that only u software designers got listing what the gime could do and listing things that can be done but not approved by Tandy.

See a group of us have been doing research on the Inner workings of the Gime and noting them down.

So far we have found some really nifty things which are useable.

Also you have inner knowledge about any hidden modes tandy did not disclose. The Major one is the so called 256 color mode in CMP and RGB modes myth that Mark Seigel said existed and that he was the only person to ever activate it on a production run coco 3. You might be able to finally end this debate with a YES or NO comment. That way people can get back to hacking the gime and use modes that exist and make them better.

GZ: Do you mean for OS9 or RS? I can send both files.

No, not the OS9 one. The other machine code one for games.

GZ: Correct and agreed.

The CoCo was far ahead of its time.

Then again, it was made for military use, satellite tracking, in the

Series of Dragons.

And it supports a *NIX OS, with a 4 way serial bus and hardware

Expandable address port.

All this in a $25 gaming computer?

LMAO!

Damn, those were the days!

You'd have loved to see my modified 6-Gun running 256 Full height

Drives all lined up on one wall, an 85Mb SCSI drive, my 300 baud

Coupler modem (don't sneeze!), my Oblique Triad and Quolla Pad drawing

Board, CM-10 monitor, Digital scanner, Gorilla Banana 7-pin Dot Matrix

CHAINSAW, 1-Mb expansion the size of a modern laptop (2Mb coming along

After I was moving onto an 80386-DX2 overclocked to 75 MHz), shelves

Of books, walls covered in paper and my D&D/SHadowrun gaming table.

Memories.

Yes, it sounds like you are on the right path. Hope some of my old

Notes helped.

Helpped? They have advanced our project years and rediscovered code and gaming methods lost to the CoCo community for decades!

GZ: Give this a try.

Ok. What you described is the Page flipping technique if I am understanding right its what sockmaster and Roger Taylor used for their respective hi color displays.

My technique uses 2 screens one is the 320x225x16 mode then the next screen is shifted down one row and it uses the reserved lines per field bits which is a 320x210x16 mode.

And when both screens are running you get a 320x480x? Color display we found that the color depth was more then 16colors and it was running at 30fps which is normal as it uses two modes.

So the technique you used for your cold hack, did you have to set it in the last 256bytes area called Fexx and you could only get out of it using the reset button because it was locked in and needed a cold reset to get back to basic.

As Seigel says that this 256 color rgb mode was a real 1byte/pixel mode hidden by Tandy.

GZ: Oh, I know what you mean now. The one I sent you is the one that works best in games as it is small and fast. Try this one instead. I think it is what you seek. The thing is though, it is large and not game friendly.

While I was browsing through my unravelled series. Had a strange thought about the IRQ routines FeF7-FeF8 I am thinking of setting my hack to use the third Irq just too see what happens as I have only ever used Fef8 in my handler never thought about the last one.

Been getting the urge to hack the Gime again and implement the little info you remember in my hack.

If only the Gime Diagram actually said what the unnamed register that by-passes the palette ram was called would help find any other secrets hidden in the Gime.

OMG! YES. YES! YYEESS!!!! That is it. THAT is the missing code!

They look really good and they work in Mess as well. I was expecting a viewer program to view them. Are you using 3 screens to create the images? And the viewer program is built into the 30granule files?

GZ: yes, the viewer is stored with the image data, no external program required

Ok. Its way more clearer and less flickering. Your viewer technique is more efficient then any others I have seen.

GZ: Images are taken from 320x200x8bit reduced photos. As to your code causing a lot of flickering, you are using too many scanlines. I've long lost touch with Jeff but hope you are right.

 

Steve Bjork and I did some technical works together years back, but

Separately from one another.

 

I very much doubt I'll be able to help you much more on the CoCo as

I've forgotten more than most people will ever know on the system.

However, I suggest you contact Prickett, as he was an R&D engineer for

The chip. You could also try Lear, Hawkins, Scott,

Even Pike if any of them can be found. They developed all the

Software for MicroWare which Tandy used to run the system. They'd

Know more about the code addressing than anyone alive and likely more

Than what was ever documented.

 

I'm including a couple R&D notes and schamatics. Nothing new. All

Released around 1986. Very rare then but I'm certain common now. One

Of Hawkin's own notes clearly indicates 256 colour mode

 

I'm trying to dig up a copy of my old computer room. If I find it,

I'll pass it along.

 

PS I think the CoCo3 maxed somewhere around 250 just to be

safe.

Also, I seem to recall having to send a small array of data to map out

the RGB 3 bit 8x8x8 mode in order to set up the display, though I do

not recall what data nor where it was sent. Once the data was sent,

then a new state was ready and a new PMode using 3 screens cycles

could be used. This was how 256 colour GIFs were achieved.

Gidday Greg.

Reading what you sent me is fascinating for sure! Because if my limited hardware skills are correct.

You could do a 256 mode in a stock coco 3 without needing the 1 or 2 meg boards all you need to know is the time for signals on E Clock falling and rising edge to display the 3 screens on separate scanlines.

So Mr X's or Mark Siegel said he did it on a stock coco 3 which needed a hardware reset to get out of it and only could happen in Fexx and needed the Timer reg and Mmu which is exactly what your info says.

This method would also increase resolution depth and color even if the memory bandwidth could not do a 320x200x256 colors normally as it is doing 3 screens using one color each of R, G,B at the one time on seperate screens.

Also my hack increased the vertical line count which your method should also create interlaced and possibly overscan too.

What would make it hard is doing double buffering for say a game for smooth animation.

I can see why Tandy did not want this knowledge ever to get out back in the day it would be too much competition too their T-1000 line up.

Oh yes your little tidbits does help greatly and it seens to correspond with what my hack does except your method was more graceful while mine is like being hit over the head with a sledge hammer. :-)

Because for my hack to work i used a Lsbr wait which seems to send the irq into la la land and traps it in the Fexx area which only effects the reserved mode bits in FF98 and FF99 all other modes and bits work as normal so i suspect that somehow my Lsbr is similiar to doing a double duty cpu cycle pause type trick.

Yeah would be a treat seeing your old setup from the past :-)

GZ: I made most of my games and artwork demos prior to modifying for 1Mb and my code was designed for a stock 128K system. I'm glad some of my ancient knowledge is still of use.

Well the more I set the coco 1,2 bits in the video mode register to coco 1,2 lines per row the more it shows the scrolling is faster when you use less lines per scanline using the unused vres 210 mode.

Why Tandy even had these lines per row settings for is a waste of space especially when using coco 3 modes.

Well I know what your doing in these pics is not the method everyone knows for 256 color display using multiple screens which causes flickering, your method is essentially flicker free. You are using the technique that Mr X's(Mark Seigel) told Nick Marentas years ago. Your using a Timer based IRQ and other stuff only vastly improved.

And it only allows 1 page so as u mentioned in a previous email it cannot be used for animation as there is no way to do double buffering. But it may be possible to do a graphics adventure.

Greg just this other tidbits has helped me figure out why I got video flicker in the bottom border region as I and another person pushed the overscan way past 250 lines we were displaying graphics upto about line 260 roughly.

So if i reduce the graphics to around 240 it should reduce video flicker. And be more static. Thanks for the tips. All my images are now very clear!

GZ: Here's a detailed schematic of the CoCo3.

This was gold back in the 80's.

Sure they are common now.

I once had one that had a bunch of circuit modes in my own handwriting;

MMU expansions, keyboard buffer bosts, stabler SALT, and a lot

More...I'm sure someone has all this around... my copy was stolen a

Few years back and sold on eBay.

Long story, don't ask.

I have several CoCo schematics but I have never seen one that detailed! Too bad about the one with all your notes on it being stolen.

Thanks very muchly for all the info. I know others who might be able to use the extra info and piece it together and unlock this method you guys designed as the more we read your stuff the more likely Mark Seigel used one of your demos to activate it and Roach saw it and told him to never disclose what he saw. Hence why his conversation with Nick and Socks sounded like someone who never designed the code but only knew bits and pieces about how it worked.

With the new flash drive type devices now in use on the coco 3. Storage is no problem. But yes 58g per image is a lot of disk space. But imagine the graphic adventures done using your tweaked code method and how many screens you could have on a 2gig flash card.

You could essentially create a game that encompasses all the coco's beginning and end :-)

Btw that Elf pic looks super on the CoCo!

GZ: Here are some of my old emails from Marty and Dale on the subject of the GIME.

Date-Received: Tue, 18-Nov-86 23:43:12 EST

Sender: daleske@cbdkc1.UUCP

Organization: AT&T Bell Laboratories, Columbus

 

 

 

COCO3 GIME chip specs.

 

[Generally, I try to avoid repetition of information which is distributed

in other newsgroups. However, this information seemed particularly

timely. I've also been hearing from individuals that they are not always

receiving the newgroups but those on the mailing list do receive their

digest. Since I am keeping old issues you may request any you have

missed. -- JDD]

--------------------------------------------------------------------------

 

Date: Fri, 14 Nov 86 14:24:28 est

From: ihnp4!ihwpt!knudsen

 

John: here is a 5-page map of the new Coco-III MMU/graphics chip

That many hackers will find useful. Its authors are identified

In its original header, and I've added some things here & there.

It may be too big for mod.os.os9, or maybe it should be one

Posting by itself. There has been nothing here from mod.os.os9

For two weeks or so, but then ihnp4 tends to "blink" a lot and miss

what's going by.

 

PS: Latest rumor is that OS9 Level II for the Coco-III won't be out

Until Feb '87.

Several sources to fix up older OS9 for the Coco-III (ramdisk,

boot fix) have come thru on comp.sys.m6809 (the new net.micro.6809.

 

------- Reposted article starts here --------

>From ihnp4!chinet!draco (Kent D. Meyers) Sat Nov 8 21:49:06 1986

Newsgroups: net.micro.6809

Subject: COCO3 GIME chip specs.

 

This information was gathered by Kevin K. Darling.

Edited and commented some more by Mike Knudsen.

This is a text for you to use to study the capabilities of the CoCo-3.

Some minor parts may be in error (??). Insiders should clue us in on these.

Purpose of release is to show some of the extra thought in the machine.

In NO way should it be construed as an "official map".

Now have fun! -- Kevin

* Many Thanks from All of Us to the Contributors who shall remain UnKnown!

 

--------------------------------------------------------------------------

I COCO-3 MEMORY, and GIME REGISTER MAP (1 Sept 86) KD ver1 I

--------------------------------------------------------------------------

 

SYSTEM MEMORY MAP:

RAM 00000 - 7FFFF (512K bytes)

ROM 78000 - 7FEFF when enabled

I/O XFF00 - XFFFF I/O space and GIME regs

 

64K PROCESS MAP:

RAM 0000 - FEFF (possible vector page FEXX)

I/O FF00 - FFFF (appears in all pages)

 

Note: the same page of Vector Page RAM at 7FE00 - 7FEFF (when enabled),

will appear instead of the RAM or ROM at XFE00 - XFEFF. (see FF90 Bit 3)

 

XFF00-0X PIA0 (not fully decoded)

XFF10-1F reserved

XFF20-2X PIA1 (not fully decoded)

XFF30-3F reserved

XFF40-5F SCS see note below (usually Disk Controller)

XFF60-7F undecoded (for current "legal" peripherals)

XFF80-8F reserved (This time we'll believe it, right?)

XFF90-BF New GIME Features (Modes, MMU, and Palette)

 

NOTE: If MC2=0, then XFF50-5F is SCS, and XFF40-4F is internal to CoCo.

This helps to reject non-RS disk controllers.

--------------------------------------------------------------------------

 

FF90 INITIALIZATION REGISTER 0 (And ... CocoMax's Mouse!)

Bit 7 - CoCo Bit 1= Color Computer 1|2 Compatible

Bit 6 - M/P 1= MMU enabled

Bit 5 - IEN 1= GIME IRQ output enabled to CPU

Bit 4 - FEN 1= GIME FIRQ " "

Bit 3 - MC3 1= Vector page RAM at FEXX enabled

Bit 2 - MC2 1= Standard SCS

Bit 1 - MC1 ROM mapping 0 X - 16K int, 16K ext (Old 1|2)

Bit 0 - MC0 " " 1 0 - 32K int (New 3 pwr-up)

1 1 - 32K external (New)

CoCo bit set = MMU disabled, Video address from SAM,

RGB/Comp Palettes => CC2.

Clearing MC3 SHOULD let us run programs that clobber FEXX, no??

--------------------------------------------------------------------------

 

FF91 INITIALIZATION REGISTER 1

Bit 6 - 0=64K chips, 1 = 256K chips

Bit 5 - TINS Timer INput Clock Select: 0= 70 ns, 1= 63 us

Bit 0 - TR MMU Task Register Select (0/1 - see FFA0-AF)

--------------------------------------------------------------------------

 

FF92 IRQENR Interrupt Request Enable Register (IRQ)

FF93 FIRQENR Fast Interrupt Request Enable Reg (FIRQ)

(Note that the equivalent interrupt output enable bit must be set in FF90.)

Both registers use the following bits to enable/disable device interrupts:

Bit 5 - TMR Timer

Bit 4 - HBORD Horizontal border

Bit 3 - VBORD Vertical border

Bit 2 - EI2 Serial data input

Bit 1 - EI1 Keyboard. Does this really work??

Bit 0 - EI0 Cartridge (CART)

 

I have no idea whether both IRQ & FIRQ

can be enabled for a device at same time.

--------------------------------------------------------------------------

 

FF94 TIMER MSB Write here to start timer.

FF95 TIMER LSB

Load starts timer countdown. Interrupts at zero, reloads count & continues.

Must turn timer interrupt enable off/on again to reset timer IRQ/FIRQ.

 

FF96 reserved

FF97 reserved

--------------------------------------------------------------------------

 

FF98 Alpha/graphics VIDEO MODES, and lines per row.

Bit 7 = vidmode 0 is alphanumeric, 1= bit plane (graphics)

Bit 6 = na ...

Bit 5 = DESCEN 1= extra DESCender ENable

Bit 4 = MOCH MOnoCHrome bit (composite video output) (1=mono)

Bit 3 = H50 50hz vs 60hz bit

Bit 2 = LPR2 Number of lines/char row:

Bit 1 = LPR1 (Bits 2-1-0 below:)

Bit 0 = LPR0

000 - 1 line/row 100 - 9

001 - 2 101 - 10

010 - 3 110 - 11 (??)

011 - 8 111 - 12 (??)

--------------------------------------------------------------------------

 

FF99 VIDEO RESOLUTION REGISTER

Bit 7 - na ... (bits 6-5):

Bit 6 - LPF1 Lines Per Field: 00= 192 lines 10= 210 lines

Bit 5 - LPF0 " " " 01= 200 lines 11= 225 lines

Bit 4 - HR2 Horizontal Resolution

Bit 3 - HR1 " "

Bit 2 - HR0 " " (see below for HR, CRES bits)

Bit 1 - CRES1 Color RESolution bits

Bit 0 - CRES0 " "

---------------------------------------------

TEXT MODES:

 

Text: CoCo Bit= 0 and FF98 bit7=0. CRES0 = 1 for: use attribute bytes.

 

HR2 HR1 HR0 (HR1 = don't-care for text)

80 char/line 1 X 1

64 " 1 X 0 (not in BASIC)

40 " 0 X 1

32 " 0 X 0

 

---------------------------------------------

GRAPHICS MODES:

X Colors HR2 HR1 HR0 CRES1 CRES0 Kmem

H4 640 4 - 1 1 1 0 1 32

H3 640 2 - 1 0 1 0 0 16

 

(not 512 4 - 1 1 0 0 1 24

BASIC) 512 2 - 1 0 0 0 0 12

 

H2 320 16 - 1 1 1 1 0 32 Other combo's are

H1 320 4 - 1 0 1 0 1 16 possible, but not

(no 320 2 - 0 1 1 0 0 8 supported.

...

support 256 16 - 1 1 0 1 0 24

... 256 4 - 1 0 0 0 1 12

in 256 2 - 0 1 0 0 0 6 Like PMODE4

...

BASIC) 160 16 - 1 0 1 1 0 16

 

Old SAM modes work if CC Bit set. Then HR and CRES bits are Don't-Cares.

Note the correspondence of HR2 HR0 to the text mode's bytes/line.

Also that number of colors = 2 * (2 ^ CRESbits). No 8-color modes??

--------------------------------------------------------------------------

 

FF9A BORDER PALETTE Register RGBRGB (XX00 0000 = CoCo 1|2 compatible)

FF9B Reserved

 

FF9C VERTICAL FINE SCROLL

FF9D SCREEN START ADDRESS Register 1 (bits 18-11)

FF9E SCREEN START ADDRESS Register 0 (bits 10-3)

FF9F HORIZONTAL OFFSET Register (And ... MultiPak's Ghost!)

Bit 7 = horizontal offset enable bit = 128 char width always

Bit 6 = X6 ... offset count (0-127)

Bit 0 = X0

 

Note that video start address can be given to nearest 8 bytes, not 512!

If Bit 7 set & in Text mode, then there are 128 chars (only 80 seen)/line.

This allows an offset to be given into a virtual 128 char/line screen,

useful for HORIZONTAL HARDWARE SCROLLING on wide text or spreadsheets.

And for moving 40-char windows around on 80-char screens??

--------------------------------------------------------------------------

 

FFA0-AF MEMORY MANAGEMENT UNIT (MMU)

FFA0-A7 Task #0 DAT map (8K block numbers in the 64K map;

FFA8-AF Task #1 DAT map task map in use chosen by FF91 Bit 0)

 

Each register has 6 bits into which is stored

the block number 0-63 ($00-$3F)

of the Physical 8K RAM block (out of 512K) that you wish to appear at the

CPU Logical address corresponding to that register.

Also can be shown this way: the 6 register bits,

when the Logical Address is in the range of that register,

will become the new Physical RAM address bits:

18 17 16 15 14 13

 

MMU Register: CPU:

Task0 Task1 Logical Address / Block#

FFA0 FFA8 0000 - 1FFF 0

FFA1 FFA9 2000 - 3FFF 1

FFA2 FFAA 4000 - 5FFF 2

FFA3 FFAB 6000 - 7FFF 3

FFA4 FFAC 8000 - 9FFF 4

FFA5 FFAD A000 - BFFF 5

FFA6 FFAE C000 - DFFF 6

FFA7 FFAF E000 - FDFF 7

 

-------------------------------------------------------------------

Ex: You wish to access Physical RAM address $35001. That Address is:

 

A- 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

.....3.... .......5...... .......0...... .......0...... .......1......

0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 1

 

Taking address bits 18-13, we have: 0 1 1 0 1 0, or $1A, or 26. This is the

physical RAM block number, out of the 64 (0-63) available in a 512K machine.

 

Now, let's say you'd like to have that block appear to the CPU at Logical

Block 0 (0000-1FFF in the CPU's 64K memory map).

 

You would store the Physical Block Number ($1A) in either of the two Task Map

registers that are used for Logical Block 0 (FFA0 or FFA8). Unless your pgrm

that is doing this is in the Vector RAM at FEXX (set MC3 so ALWAYS there),

you would want to use your current Task Map register set. If the TR bit at

FF91 was 0, then you'd use MMU register FFA0 for the $1A data byte.

 

To find the address within the block, use Address Bits 12-0 plus the Logical

base address (which in this case is $0000):

Now you could read/write address $1001, which would actually be $35001.

--------------------------------------------------------------------------

 

FFB0-BF COLOR PALETTE Registers

 

Reg bits- 5 4 3 2 1 0

CMP ... I1 I0.P3 P2 P1 P0 Intensity and Phase (16 colors x 4 shades)

RGB ... R1 G1 B1.R0 G0 B0 Red Green Blue (64 RGB combo's)

 

When CoCo Bit is set, and palette registers preloaded with certain default

values (ask, if you need these), both the RGB and CMP outputs appear the same

color, supposedly.

 

40/80 Column Text Screen Bytes are Even=char, Odd=attribute, in memory.

Characters selected from 128 ASCII. NO text graphics-chars.

 

Char Attributes- 8 bits... F U.T T T.B B B

Flashing, Underline, Text foregrnd, Backgrnd colors 0-7.

--------------------------------------------------------------------------

 

FFC0-DF SAM : same as before (mostly compatible Write-Only Switches)

FFD8 = CPU .895 MHz (no address-dependent speed)

FFD9 = 1.79 MHz

FFDE = Map RAM/ROM (RAM accesses use MMU translations)

FFDF = all RAM

--------------------------------------------------------------------------

 

Comments by MJK:

Seems that BASIC's power-up initialization doesn't do as much as it could

to insure Coco 1|2 compatibility. In FF90, should set Bits 7 and 2,

and clear Bits 6 and 3. Would allow continued use of FEXX page.

BASIC is giving us only a fraction of the powers inside the GIME;

hope OS9 Level II does better (not till Feb. '87??).

RS disk controllers "ghost" all of FF4X at FF5X, and some software is said

to use FF5X addresses instead of official FF4X.

FF90's MC2 bit probably was intended to accomodate such code,

but nothing (??) can save DISTO controller, which uses FF5X for

add-on hardware features.

 

How many of these registers and bits are Read/Write, not just Write-Only??

MMU (FFA0-AF) and Palette (FFB0-BF) read correctly.

Attempts to read FF90-9F show all 7E with a couple 40s.

POKEs to FF90 have momentary effect (screen flashes), but BASIC seems

to refresh most of the GIME registers after each timer interrupt

or some such interval. Hopefully the refresh values are kept in

low system RAM, maybe C0 and up -- so POKE values in there and let

BASIC put them into the GIME for you. Meanwhile, block 6809 interrupts

to play with the GIME.

 

-30- Fine. --MJK

 

 

-------------------------------------

 

 

18461 24NOV86-0419 Hardware Hacking

RE: MONITOR CONNECTION (Re: Msg 18417)

From: MARTYGOODMAN To: DAVIDJOHNSON

 

Just to clarify...

 

I DID design the OLD dual driver Moreton Bay used

to sell for the Coco ONE, but I had NOTHING what so ever

to do with the design of the dual driver

they sell for the Coco 2. Tho, as I said, I hear it is

a good unit.

 

---marty

 

 

18464 24NOV86-0424 CoCo 3 Graphics

RE: tsedit fix (Re: Msg 18457)

From: ARTFLEXSER To: RICKADAMS

 

I would imagine that a POKE&HFFDF,0 for RAM mode would

probably restore the CoCo 3 commands to functioning. Pressing RESET or typing

DLOAD should do the same.

 

-*-

 

 

18465 24NOV86-0432 CoCo 3 Graphics

RE: memory mapping (Re: Msg 18428)

From: MARTYGOODMAN To: DENNYSKALA

 

 

(1) I have had the TAB bug reported to me from several folks.

Another example of the shoddy job Tandy and Microware did

with the Basic on the CoCo 3. To call their work

third rate would be too much of a compliment!

 

(2) KDARLING has posted a set of GIME chip specs on the

CoCo 3 data base. These, I believe, will tell you all

you need to know about ROM addressing on the CoCo 3.

It is an old file... but a valuable one! Get it now!

 

In brief, tho, in answer to yer question:

 

The GIME chip controls decoding of ROM addressing.

It can be programmed to see any of the three following

situations:

 

16K of "internal" ROM and 16K of "external" ROM

(this is the only mode available on the old CoCo 1 and 2)

 

32K internal ROM

 

32K external ROM

 

All this is controlled by a port at $FF90.

The low order two bits of that port. (bits 1 and 0)

 

If bit 1 is zero, then you are in 16K int and 16K ext mode.

That is, the thing behaves like a CoCo 1 or 2.

 

If bit 1 is set to 1 and bit 0 is zero, then the thing

decodes all of $8000 thru $FEFF from its internal 32K ROM.

 

If bit 1 is set to 1 and bit 0 is also set to 1, then

the thing decodes all 31.75K ($8000 - $FEFF)

from a 32K ROM in the cartridge port.

 

 

Note taht this allows you to make a 32K ROM pak.

 

---marty

 

18473 24NOV86-0607 Hardware Hacking

RE: J&M controller (Re: Msg 18449)

From: MARTYGOODMAN To: ARTFLEXSER

 

FASCINATING!

 

Off the top of my head I'd ordinarily be skeptical about

55 milliamps making a differnce, but in that application

we are at the very limits of the capabilities of the

power supply of the CoCo, which is marginal for such applications.

 

J&M should be told about this suspicion. It should be very

easy for them to drop power consumption by 55 ma by

using CMOS chips for some of their logic.

 

---marty

OMG!!!!

OMG!!!!

OMG!!!!

There is a community of CoCo progammers consisting of nearly 300,000 world wide who have talked about this conversation for years yet have never been able to prove it or give any details of use.

And OMG!!! Here you have been sitting with this collecting dust all this time !!!

OMG!!!

Thank you!

GZ: Huh. I had no clue. First I've heard of it.

GZ: Attatched is an archived PDF document containing a lot of info on CoCo

Hardware, started by me and greatly expanded upon by others, finally

Sorted by Dale.

It may contain some useful info.

GZ: Also, everyone is too fixated on just the GIME

Everyone is looking for a GIME spec when they should be looking for

the SALT and VDG specs as well since they also affect video.

 

I think I have some of those around... been digging into boxes I've

Not look at in some 30 years.

 

30JUL86 General Information

New CoCo is HERE!

From: RAINBOWMAG To: ALL

 

BULLETIN

 

New York -- Tandy Corporation today announced the release of

The long-awaited Color Computer 3! The much-rumored successor

To the Color Computer 2 offers several improvements in

Performance as well as price. It is expected this new

Machine will overwhelm the home computer market.

 

The Color Computer 3 comes standard with 128K RAM and can be

upgraded to 512K RAM. The Microsoft BASIC in ROM has been

Enhanced by Microware to allow several new features. The new

CoCo also supports OS-9 Level II, which has been rumored

By many OS-9 experts.

 

Color Computer 3 uses the 68B09E which is designed to operate

At 2MHz. The CoCo will still normally operate at 1MHz, but a

Double-speed poke is fully supported to take advantage of 2MHz

Operation. However, the heart of the new machine is an

Advanced technological design by Tandy. The functions of the

SAM and VDG chips have been combined into one chip called the

GIME (an acronym for Graphics Interrupt Memory Enhancer). Use

Of this chip allows the Color Computer 3 to operate at an

Effective speed nearly four times that of the old system and

Display a full 256 colors.

 

Of course, once officially sold, the flyers changed...

 

-- Composite and RGB video, as well as standard RF output.

 

-- 64 colors to choose from.

 

-- 320 x 192 graphics in 16 colors.

 

-- 640 x 192 graphics in 4 colors.

 

-- Text-screen widths of 32, 40 and 80 characters.

 

-- Upper- and lowercase characters with true descenders.

Where did that 256 color mode dissapear to?

GZ: back in the day I contracted to Pioneer Eletronics for a while... back

Then the US still had a parts standard set by N.A.P.C.O. and crossed

Parts with MCM and SK.

TCC1014 vc2645qc is the full UIC Part number for what is commonly

Called the GIME.

I pulled out the old service manual, made in Taiwan...

And several of us discussed the findings.

 

 

FF40 - FFBF: Not used

 

Note: FF22, FF23 are duplicated in tcclOH (VC2645QC), and V.D.G Control Bit

(Bit 3 through Bit 7) affects this IC (TCC1014) only.

 

TCC1014 (VC2645QC)

1) System Timing, Address Multiplex,

Device Select, MMU

 

By now, it should be apparent that

controlling DRAMs is a fairly complex

task. In the Color Computer 3, it is

done by the TCC1014 (VC2645QC: ACVC).

In addition to address multiplexing,

RAS* and CAS* generation, WEO*, WEI*

timing control, and refresh

generation, the ACVC performs other

Tasks. It contains the Master

Oscillator, the frequency of which is

controlled by a 28.63636 MHz (PAL:

28.4750 MHz) crystal (XI). The Master

Oscillator is divided by eight to

give a 3.579545 MHz color reference

Signal to the Video Display Generator

LOGIC and Composite Video Signal

(NTSC version only). This reference

Signal is then divided by 4 Cor 2)

Again to provide the 0.89 MHz

(1.78 MHz) E and Q clock signals for

The processor.

 

In the PAL version, the Master

Oscillator frequency is slightly

Shifted down than in the NTSC version

For fitting with the PAL encoder

Circuit.

 

The ACVC (IC6) also controls

access to the memory, granting

access to the processor during the

high time of E (CPU portion) and

 

 

 

access to the VDG LOGIC during the

low time of E (Video portion). During

each access, whether by the CPU or

the Video, the ACVC must provide

appropriately synchronized RAS* and

CAS* signals, as well as the

corresponding address signals, to the

DRAMs. Note that the DRAM access time

must be twice as fast as that

required by the CPU alone in order to

be able to respond to VDG accesses.

 

In order for the ACVC chip to provide

the appropriate addresses to the

DRAMs, all 16 CPU address lines are

input to the ACVC. It then

multiplexes these into low order and

high order addresses (ZO through Z8,

refer to MMU) which are sent to the

DRAMs along with RAS* and CAS*.

 

Another function of this section

is to provide address decoding and

device selection for the computer.

Figure 5-6 shows how the SO, SI, and

S2 lines are connected to IC9, a

74LS138, in order to provide

appropriate signals to enable ROM

selection, PIA selection, and various

cartridge selection signals. Due to

the nature of the ROMs and in order

to prevent data bus contention, the

ROMs are enabled only during the E

portion of a read cycle.

 

As it is clear from the Memory Map,

the memory area of the CoCo3 is from

&00000 through &7FFFF (512K bytes).

The Memory Management Unit (MMU)

 

inside of the TCC1014, pins FFAO

through FFAF, selects A13 - A18

(actually A16 - A18). Figure 5-7

shows the Block Diagram of the MMU.

 

TCC1014(VC2645QC) PLCC ACVC C-MOS

 

[Coco] GIME chip information data

 

Analysis of the following data would indicate that there were possibly 3

series of production GIME's, 6xx, 7xx and 8xx.

 

There were 2 manufacturers, VTI and VLSI. The VLSI manufactured chips

had an A at the end of the chip number (TCC1014A).

 

 

623 V B769 2645A0001 TCC1014 Tandy 1986 KOREA A VTI

623 V B823 2645A0001 TCC1014 Tandy 1986 KOREA A VTI

623 V B825 2645A0001 TCC1014 Tandy 1986 KOREA A VTI

625 V C027 2645A0001 TCC1014 Tandy 1986 KOREA A VTI

625 V C135 2645A0001 TCC1014 Tandy 1986 KOREA A VTI

627 V C192 2645A0001 TCC1014 Tandy 1986 MEXICO R VTI

627 V 8917 2645A0001 TCC1014 Tandy 1986 MEXICO R VTI

629 V C030 2645A0001 TCC1014 Tandy 1986 KOREA A

733 Z X323 2838-0001 TCC1014A Tandy 1987 MEXICO R VLSI

737 Z X482R 2838-0001 TCC1014A Tandy 1987 MEXICO R VLSI

746 Z X546 2838-0001 TCC1014A Tandy 1987 KOREA A VLSI

807 Z X555Q 2838-0001 TCC1014A Tandy 1987 KOREA A VLSI

824AV M9823 2838-0001 TCC1014A Tandy 1987 VLSI

 

As a comparison, the numbers below are from Brother Jeremy's prototype

CoCo3. It seems to have a code name of "Tequila".

 

615 V VB140

05ES VC 2645A

TCC1014-TEQUILA

VTI

 

The first number, possibly a batch number has come in three variants.

 

A 6xx number which appears to be batches of Korean '86 chips.

 

A 7xx number which appears to be batches of Mexican '86 chips.

 

A 8xx number which appears to be batches of Korean '87 chips.

 

Does this first digit signify a batch? Maybe a version number?

 

Someone once told me that there were at least 7 revisions of the GIME

and that the '86 and '87 were the last and final 2 releases. We all know

that the '86 GIME has more bugs than the '87 so could there be various

versions of the '86 with different fixes?

 

Also the chip "model number" is TCC1014 on the Korean '86 chips whereas

it is TCC1014A on the Mexican '86 and Korean '87 chips. Maybe the Korean

'86 chips are the buggy ones while the other '86 and the '87 are fixed?

 

Could those "fixes" have removed certain funtions thought "unused"?

 

>>>

12/13/87

TCC1014A

From: HARBIE To: MARTYGOODMAN

 

I JUST GOT A CHANCE TO TEST ONE OF THE NEW COCO 3 ON SPECIAL .

 

THE GIME CHIP IS MARKED TCC1014A BUT OTHERWISE THE PCB IS THE SAME .

 

THIS NEW GIME DOES FIX THE HORIZONTAL SCROLL BUG AND ALSO FIXES THE PROBLEM OF

SOME SCREEN MODE LIKE 80 COLUMN 2 COLORS WHICH USED TO HANG THE MACHINE . I

WILL HAVE TO RUN TEST ON ALL THE OTHER UNOFFICIAL MODES TO SEE HOW THEY BEHAVE

AND IF

THEY WERE CHANGED .

 

THAT COULD BE AWHILE SINCE I CANT FIND THE FILE I MADE OF THE SCREEN MODES AND

THEIR PROBLEMS .

 

THEY DID NOT , REPEAT >>>NOT< << FIX THE TIMING PROBLEM WITH THE MEMORIES , THE

512K UPGRADE RUNS AS HOT AS EVER !

>>>

 

From: MARTYGOODMAN To: HARBIE

 

One other difference you may note on the new GIME chip is

that in addition to the A added to the part number,

the COPYRIGHT DATE on the chip is now 1987, not

1986 as before. At least, that is what MY

new “A” model TCC1014A has as ITS copyright date.

 

I am MOST annoyned that the DRAMS still run sizzling!!!

 

DRAT!

 

—marty

>>>

 

From: HARBIE To: MARTYGOODMAN

 

YAR RIGHT ABOUT THE © YEAR .

 

AND I BBURNED MY FINGER WHEN I TOUCHED MY DRAMS AFTER I MODIFIED THEN THE RS

RECOMMENDED WAY . THE EMPHILL WAY STILL RUNS QUITE HOT BUT A LOT BETTER .

>>>

From: Greg Zumwalt

Use 2 of the RS-HS101 sinks, placing one on bank A and the other on C.

This greatly reduces the thermal output and allows the 1.9MHz overclock

to work without delay. SImple and cheap solution. You can also load the

circuit and remove C4 and C5 to adjust timing and reduce heat.

 

From: MARTYGOODMAN To: HARBIE

 

I take it you recommend the Hemphill mod of adding a resistor

in parallel with the 120 ohm one (a 47 ohm one, I believe, yes?)

as opposed to the more widely suggested fix of clipping out

both caps??

 

That is what some others seem to be concluding.

 

—marty

>>>

 

From: HARBIE To: MARTYGOODMAN

 

YEP , IT’S A TAD COOLER AT LEAAST .

 

BTW , I JUST COMPLETED A CHECK OF ALL THE GRAPHIC MODES AND THE CONCLUSION IS

THAAT THE ONLY THING THEY FIXED WAS THE HORIZONTAL SCROLL BUG . ANY OTHER

IDIOSYNCRAZIE OF THE UNSUPPORTED MODESS IS STILL THERE .

ALSO THE 210 LINES MODES STILL SCRAMBLES THE SCREEN AND THE 200 LINES MODE

STILL HAS ONLY 199 LINNES . MAY BE THE TCC1014B ?

>>>

 

 

E-Mails with Kevin

 

30-Dec-91 11:52:12

To: Kevin Darling

Where might I find the 25 line patch by Kevin Darling. Convential means of

searching have not turned up any reference to a patch by anyone to generate a

25 line display, that I can find. Joerg Sattler,

74016,631

...

I took the GIME chip out and cleaned the connections on it and in its socket

and still got the same results. I was wondering if the chip I have was one of

the old ones or the supposably update GIME chip. The info I got off of it is

this:

627v8984

2645A0001

TCC1014

Tandy 1986

Is that one of the old ones or one of the new ones? Does CRC have any GIMeE

chips also?

...

Drat. The new part is TCC1014A, I believe. The Tandy stock number is MX-0992

for the CoCo-3. Hey, I bet Frank Hogg has some GIMEs! He's been posting here

lately, so either he'll spot your question or you can ask him here or in email.

Luck!

...

I have GIMEs in stock. Probably the last known supply of them. Call the office

for details. I don't think I can quote prices etc here. (rules you know)

Frank Hogg -- FHL 315-469-7364

...

well one thing for sure is OS9 is stable! The longest record for running the

machine without re-booting is 4 months. Im sitting about 2-3 months now and

unlike that time I use the machine more. (that 4 months i was away at college

the bbs was the only thing running)

...

03/13/94

New GIME

From: NEALSTEWARD To: ALL

 

I’m back after suffering from all sorts of strange bugs and crashes. It

turns out that my old GIME gave out on me. New ones are available from

Radio Shack Consumer Mail. The part number is MX-0992 and the cost is

a steep $34.17 + $2.00 shipping + tax. Almost 40 bucks later, my coco3

is alive and well. I can even run Gshell with my 2 megs, which wouldn’t

work before. It’s like getting a new machine.

...

 

What is odd, is that I can find no schematic for the inner IC map,

only the block diagrams and logic maps.

I'll keep looking, but most of what I have left is of little value.

 

Can you send me your OS9 graphic viewer?

GZ: This is the IrfanView of its era. It is a multi format image viewer.

Originally it was just for RAT and BMP. Later, upon request, DM3 and

many other formats were added, including GIF... think about it, that's

256 colour display.

Do you have a bit spec for the supported 64 colors?

GZ: It would seem I still do. Here you are.

Do you have anything on the HSCREEN modes?

And, it is true you helped the great Pike, master of his domain, never needed anyone's help, to fix his drive controller? It's just one of the rumors we've all heard and wonder about.

Also, why is it no one can find any of the POKE codes or the upper address set? Were they in Rainbow or another magazine or book?

GZ: No, these were never in print. Back so long ago, these were part of

An ongoing correspondence with G.W. Pike. He was working on his 6Gun

Drive controller that allowed for up to 6 floppy drives and 2

Asynchronous read/write. He was experiencing issues with video due to

Where he was storing his code. Eventually I helped him resolve the

Code and he sold the work to Owl Ware. Eventually Owl Ware and I got it up to 256 drives, as shown in my photo of my old work center. Pike didn't finish the project because of person issues, getting divorced.

So, these are just from some of my old notes I recently pulled of some

Old disks.

I've only got over 2,600 disks... only about 400 of which are sorted.

> Mmmm hopefully this Bob is still alive. Do you know how I could reach him?

> The more we think we have discovered all the tricks in the coco 3. New

> things pop up.

> This reprogramming to get old address paths working sounds like a pain

> lolz.

> Its awesome you still have all this knowledge hidden on old floppies. I

> know I archived close too a thousand floppies full of coco 1,2 and 3

> software and still doing it today, just from what you sent me.

> I feel like a child in a playfair as I was looking thru your

> floppies.

> If you have decayed disks there is a way too extract the data from

> it. I did it on a very bit rotted copy of Cbasic3. Using a program called

> defender. It allows you too copy sectors and tracks seperately it might be

> something worth looking at if you have some. But it is very annoying as it

> is a PC tool and it requires you attach a physical 5.25 drive to your PC.

GZ: Bob Rusell

R.R. Enterprises

PO Box 975

Farmingdale, NY

11737

 

But that was back in 1983

 

Yeah, we were the CoCo gods back then... no internet, no national free

Calling, no info like they have now. But like I say, it's been a very

Long time.

 

You should look at my DEdit program. It does sector by sector

editing. Made for the CoCo DEdit 3.0 last version.

Fortunately I have ported all my 5.25 disks to PC as virtual DSKs.

Many years back I donated my 8 and 14 inch floppy drives to a computer museum.

 

If I do find more, I will let you know.

Any chance you can send me your unsorted collection as well?

GZ: Lowell Turner has provided me with copies of all my old floppies,

including about 100 missing ones. I have a LOT of disks to sort out.

Also found some of my A.I. projects and Turtle codes or the robotic controls.

Once I have everything sorted "enough" I will send you an updated archive.

GZ: Okay, recovered about 1,200 disks.

And.... guess what I found? Some of my 256 demo programs!

I don't know what became of Lowell. He had big plans, lots of good

ideas, and just vanished.

 

I now have 1042 duplicate disks to sort out, from, 5,354, leaving me

with 4,330 to organize.

Do you think Bjork might have any information as he was also an uber coder of that era?

I keep trying to contact him as he is active on NitrOS but everyone says he's a stuck up SOB who won't speak to anyone and never helps others. He refused to release his software even for a system over 20 years old.

GZ: Steve and I go

Back a long way, but we were never close so I don't think it would

Help. Beside, I understand his position, although I think he's a bit

Of a tight ass. I released all my CoCo software years ago to the

Public.

[Mr SQL]

Awesome stuff Greg! Liked the technical info and the classic email exchange from all of those CoCo luminaries. Bit of Trivia you might like - I met Marty Goodman at the Princeton expo and he made such an impression that I made him a character in a text adventure I wrote for Rainbow (The Parlog Building).

 

256 colour mode is truly amazing - I remember Dies doing games with 64 colours on screen at once that I thought was pretty impressive.

 

Wish I knew that Pickett had preserved the extra semigraphics modes in the GIME bitd; I found out only recently from some CoCo folk on this forum that those modes could be reenabled with the exception of text not working on them - wonder why they were disabled. I could see the reason for disabling the 256 colour mode (Tandy 1000) but not the semigraphics.

 

 

[Greg Zumwalt]

Wonder why they were disabled. I could see the reason for disabling the 256 colour mode (Tandy 1000) but not the semigraphics.

 

Certain modes are disabled due to timing and resource use.

If you paid real close attention, the thing that really confounds us is the meantion of the 512 colour mode.

It has been achieved by flicker and strobe methods, but not by re-enabling a MODE.

 

The Parlog Building

 

February 1988 and again in December 1989The Fourth Rainbow Book of Adventures A gathering of 14: winning: entries in our fourth Adventures contest. Includes Term Paper and Life: An Everyday Adventure for the CoCo 3. Also features Captain Rodgers, Aandark II, Superspy, Intrigue, the Parlog Building and many more! Book $7.95, Tape $6.95, Disk $1 1 .95 — a savings of up to 30%! 

The Sleeper Award goes to ******, of ******, New York. His entry. The Parlog Building, is a 32K text Adventure in which you arc trapped on a military base. Your only goal is to escape unharmed. It is just a little trickier than imagined, though. The input routine on this game allows you to enter fully descriptive commands or shorten them to a simple noun/ verb combination. The Parlog Building is a good warm-up Adventure for the hardy Adventurers and an excellent learning tool for novices.

Found it on my RNBADV4b.dsk

[Mr SQL]

Very cool you have The Parlog building! That descriptive text brings back memories - I think Judy (Falsoft) wrote it. I had no idea there had been a second round in 89!

Edited February 3, 2015 by Mr SQL

[+wongojack]

Well, this has become a fascinating thread . . . .

 

 

Below are a few websites that carry games and news of Atari games coded by me.

I presently have 42 Atari 2600 cartridges which have been sold by several distributors and put together by several manufacturers outside of AA.

A few are hacks, mostly by request or in that they correct original code to make the game work better.

Not all are games such as Message Maker, ImageCarts, Music carts, demos.

Further, not all carry my name.

Even AA carries work done by me and released by others.

As a programmer, I don't care to be in the public spotlight. My work is released by others and I don't care about the fame or infamous results.

Why these games and sites have not received mention on AA has a lot to do with internal politics and petty feuding which I won't bring up here and hope will be quickly brought to an end.

Suffice to say, many programmers, manufacturers, distributors, expo hosts and magazines have been covering new Atari games not mentioned on AA.

Part of this is also due to the amount of news. Not any one site, not even AA, can cover everything.

At these listed sites one can find many other new Atari 2600 games not widely covered by Atari Age (if at all). Many are covered.

http://www.gooddealgames.com
http://www.atari2600homebrew.com
http://readretro.com/
http://www.packratvg.com
http://www.gooddealgames.com
http://www.atari2600.com
https://www.8bitclassics.com
http://mag.mo5.com/actu/57402/huit-nouveautes-atari-vcs-2600-chez-good-deal-games/
http://ffxi.gamerescape.com
http://allgamers.fr
http://videogamehomebrew.wikia.com/wiki/Atari_2600_Homebrew
http://www.rolentapress.com
http://www.vizzed.com/videogames/index.php
http://www.cgexpo.com
http://www.2600connection.com
http://www.atarimagazines.com
http://www.atarimania.com
http://www.retrogamer.net
http://www.rdrop.com

 

 

I go to almost all of those from time to time, but none really seem to be as compelling as AtariAge. There is also quite a bit of repeat content. I appreciate this statement:

 

"Why these games and sites have not received mention on AA has a lot to do with internal politics and petty feuding which I won't bring up here and hope will be quickly brought to an end."

 

I don't know about the history of this petty feuding (and please no one get into it in this thread), but I certainly hope it can be brought to an end. It seems quite a few members are re-activating old accounts which I consider a VERY good thing.

[+wongojack]

Because it relates to my original question/observation, I organized and noted the list of links above

 

http://allgamers.fr Jan 21st update indicates site is closing (site will continue to exist through end of 2015)

http://ffxi.gamerescape.com Looks like a Final Fantasy XI wiki site

http://mag.mo5.com/actu/57402/huit-nouveautes-atari-vcs-2600-chez-good-deal-games/ Publicity about Good Deal Games (But doesn't like their ugly site)

http://readretro.com/ I started a thread about this one

http://videogamehomebrew.wikia.com/wiki/Atari_2600_Homebrew Focused on 2600 Homebrews, I'll have to spend more time here (heavy ad content)

http://www.2600connection.com Hadn't been back here in a while

http://www.atari2600.com Never bought from them, but informative

http://www.atari2600homebrew.com Good site, seems like repeat content from AA

http://www.atarimagazines.com Great site, but all old mags

http://www.atarimania.com Legendary site, but I've never looked here from homebrew info

http://www.cgexpo.com Never thought to look at the CGE website

http://www.gooddealgames.com Mentioned in this thread already

http://www.packratvg.com Have bought from them before

http://www.rdrop.com Don't See Gaming Content here

http://www.retrogamer.net I'd never been to their site! I'll probably have this open all week now

http://www.rolentapress.com Focuses on print books

http://www.vizzed.com/videogames/index.php Loaded REALLY slowly for me - can't evaluate

https://www.8bitclassics.com Online store currently offering no homebrews or homebrew news

Edit to try and fix formatting. Can't remember how to paste a table.

[+SpiceWare]

I asked Greg about this, and here is his reply: "It is homebrew, but it is based on existing code and games with my own contributions. As you know, it was an attempt to recreate, NOT to come up with something new.

So... As I said, it is not original at all in concept.

I just ran a comparison between the two roms and they have a total of 3 lines of code the same."

 

See last image for comparison of both roms:

https://www.facebook.com/media/set/?set=a.772138139537078.1073741842.100002226978557&type=1&l=d35b228df0

 

So yes, The Shaman is a homebrew.

 

Hmm - The Shaman sure looks and plays an awful lot like Assault...

 

I ran both games for a while in Stella then used the savedis command in the integrated debugger to generate these two disassemblies:

Assault (1983) (Bomb).asm

the_shaman_qtm__2014__greg_zumwalt_.asm

 

I then ran them thru filemerge, a file comparison program on the Mac. In the scroll bar on the right you can see a bunch of little lines, those denote differences:

 

In these screenshots the arrow points to the scrollbar positions, so you can see some of the differences that were found. Lines that are different are shown with a grey background, and cyan background is used to show the values within the line that are different. All of these changes are only graphics:

 

 

 

 

 

Scroll up a bit and you can see that all the code is identical.

 

 

 

 

So while Thomas got the name wrong, he was right about it being a hack job.

 

[RevEng]

As you insist upon making a fool of yourself and trolling this post, this is the last time I will respond as I grow ever sickend by having to show the public your arrogance and "prove myself to you".

 

For future reference, don't ever post again to any of my posts if all you plan to do is troll.

You've already tarnished the good news of my games being released and I don't appreciate it.

That's the problem with using bluster and righteous indignation to cover your fraud. Truth will out.

 

None of us will hold our breath waiting for an apology to Thomas and the buyers you lied to, but it would be the right thing to do.

[Atari Charles]

Looks like this post was resurrected from the dead, from Feb. 3rd, 2015 all the way to August 23rd, 2016. Man, if I resurrected a post from that far back, I would have been crucified, flame broiled, or outright banned. So, I am wondering what your motivation is to research and compare roms and resurrect a post in such a way out of the blue?

So let's first get this out of the way. The code as Greg mentioned "...it is based on existing code and games with my own contributions. As you know, it was an attempt to recreate, NOT to come up with something new.
So... As I said, it is not original at all in concept..."

Nowhere on the Good Deal Game site nor at shows is this release being touted as a homebrew or a hack. It is sold with a small manual, so if someone wants to buy the cart then they can buy the cart. If they don't then they don't. I highly doubt an obscure thread would have been seen by anyone before they bought the game, and even if it was, well I doubt the homebrew vs. hack argument would truly matter.

As for the similarities, Greg will have to comment on that and the methodology you used to compare both roms. I'll let him know. I assumed it was pretty much a homebrew based on his email to me. But if indeed, it is a hack, then I apologize.

As for RevEng comments. Speaking for myself, I could never possibly be able to live my life with such high standards such as yourself. Alas, I am a rake and an unforgivable one at that May William Shakespeare shoot me in the heart with a silver arrow so that I may find peace in death and forgiveness with god. Only Superman(if he were real), Mother Theresa, and Jesus Christ could possibly live up to your standards . Now seriously, way to jump on the bandwagon. You'd make a good Fire and Brimestone Preacher from the 1800's.

Edited August 24, 2016 by Atari Charles

[alex_79]

Looks like this post was resurrected from the dead, from Feb. 3rd, 2015 all the way to August 23rd, 2016. Man, if I resurrected a post from that far back, I would have been crucified, flame broiled, or outright banned. So, I am wondering what your motivation is to research and compare roms and resurrect a post in such a way out of the blue?

You're confusing with some other forum, as on AtariAge replying to old threads is perfectly fine if you're adding relevant information.

 

The "programmer" deliberately lied trying to pass a quick hack of a commercial game like a much more personal creation.

Thanks to Spiceware's post, anyone reading this thread in the future can see that the "homebrew" is really just a graphical hack, which can be made in a few minutes by anyone using freely available tools and that involves no coding AT ALL!

 

 

The code as Greg mentioned "...it is based on existing code and games with my own contributions. As you know, it was an attempt to recreate, NOT to come up with something new.

So... As I said, it is not original at all in concept..."

You left out a few words, there isn't 140 character limitation here, so why not quoting the entire paragraph?

 

"It is homebrew, but it is based on existing code and games with my own contributions. As you know, it was an attempt to recreate, NOT to come up with something new.

So... As I said, it is not original at all in concept.

I just ran a comparison between the two roms and they have a total of 3 lines of code the same."

The last sentence is especially baffling. I'm just an amateur programmer but I know that comparing two binary roms using a software made for comparing text files makes absolutely no sense.

"3 lines of code"? In a binary file? Really?

From what he wrote, I find hard to believe the "programmer" actually ever coded anything in his life.

 

It's also deplorable the way the he tried to use the Clonespy results to pass the game as his own work using the fact that Thomas immediately spotted it as an hack, but mistaked it for "Demon attack" (which is visually very similar to "Assault"). And remember that, at the time, the rom wasn't available.

 

As for you Thomas. You should know better by now than to publicly challenge me.

It only serves to embarrass yourself, tarnish Atari Age and keep even more programmers from ever wanting to post on AA.

By your own software, my ROM has less than a 1% match. Feel better now? Want to explain to IDM why their software comparison tool isn't good enough for you?

I made it clear from the beginning the game was intentionally made to resemble others but is my work. Their is nothing that needs to be changed in the post and you yourself could have asked in private for this information without the public challenge.

You're testing my patience.

 

 

Edited August 24, 2016 by alex_79