Greg Zumwalt

SnailSoft Software's Atari 2600 ROM's Report Mon 09/05/2016 16:04:23.66. [10918] .A26 Roms identified. It has been some time since I have done any updates on this database, but as I presently have broadband, I thought I would take the time. Some people have asked me what this is and why it is important. This is an HTML generated document. It lists over 10,000 roms and their unique CRC/MD5 identifiers. Due to the file being over 10 Mb it must be downloaded and viewed locally. How does it work? Found a rom on the internet? Only it doesn't have a name, or has nothing but numbers for a name, or perhaps you downloaded two (or more) roms with slightly different names... Well, you may not be able to tell what the rom is by just looking at it. Every file created has a unique value. This value can be found with an MD5 or CRC hash calculator. http://www.winmd5.com has one for free. Put all your unknown roms into a folder, run WinMD5 (or what ever calc you like) and generate the hash tags. (These are not the bullshit Twitter messages! These are real HASH tags.) In this example we have 2 roms. One, Pacman, the other, Qbert. When we run our hash calculator and select Create, the hash values are generated. Having download and extracted A26Report.rar to get the A26Report.html file, load the A26Report.html into any web browser. Be warned. It is a very large file and may cause your browser to freeze for a while. Once loaded, go back to your calc and COPY the hash value. In your browser, SEARCH for that value... and wait.... As it turns out, ba3525368894f36e20b411d2f26caaf7, is NOT Pacman at all! It is Qbert. Code: QBERT2.a26 BA3525368894F36E20B411D2F26CAAF7 DFF5FD5BC17129E73A96F6AD6EDCDCDBFFEF6F84 32BE7E22 4931796697C9FD86C30A14A488920370E5811EC4E1771EB8AC54D3A34561FD1E FEC1C1C859A0A6553D371A57F5049357FB9C1A726F15444417641494DFE86750A051A6FA7BAF64B4DF6AC9F176200168262BE2581DBDB0CB10F78ED1E11E86E2 87AF2A265FAA77246596D8A0BAF21481F85D299689833820BD6EDC5A038591AC644C2D9421F99E2AF1ECB43E892FEB63 ..\..\Atari_2600\Roms\QBERT2.a26 And, 369d7b869bfd2785179aff18af07bc63, is Qbert, but not the original. It is Nukey's modified version! Code: Qbert(Supercharger)_(Nukey_Shay_Modified).a26 369D7B869BFD2785179AFF18AF07BC63 16C9B1EC1D78A9A5A748FFCDA713EC14316B22BA B8034CEA DB5E8997000C734FF83C6DCF421B75576117B50FEC4DB7366FC3EF06AFDBDFF9 B144BD565D28553377E18CBDE43ADD76F5F08525AEC04E83EE796FAFCE72CC688F75A703E99972D77BD4F37A735E87D28D6428796395B2694DCD3268A23C4294 0C83473845F64892EACFBCCDDC0AB7064407E5681DEDF136D89C599A0500763321278173085147B09DF11191B562B369 ..\..\Atari_2600\Roms\Qbert(Supercharger)_(Nukey_Shay_Modified).a26 And THAT is what one can do with this database It also includes other HASH reports, file size and more, all meant to be used to identify roms. Filename MD5 SHA1 CRC32 SHA-256 SHA-512 SHA-384 Full Path Modified Time Created Time File Size File Version Product Version Identical Extension File Attributes For those of you who are familiar with Cowering's GOOD Atari 2600 tool, you may ask, why use this database? 1. Cowering has not updated his tool in years 2. His database is not public 3. His database contains hundreds of roms never released 4. His database contains less than 2,000 roms 5. His database is based on CRC16, which has known issues 6. His tools do not work well on Win8 up 7. His tools use all sorts of flags in renaming roms that look ugly and often are wrong His tools were good back in the day of XP and when far less roms had been dumped or created, but its lack of update no longer make it viable. What's that you say?!?!?! You have a ROM and it doesn't appear in the database? Well, send me a copy of the ROM. I will test it to confirm it is an Atari 2600 rom and add it to the database Using this database, and a simple comparison tool, archives like this- get reduced down to less then 2,000 and everyone of those roms identifiable in the database. No, this database will not automate testing. I have a private tool I use to do that. If someone wants to make a new tool based upon this data, you have my permission. If you have ROM's you feel are not in the database, send them to me snailsoftsoftware@gmail.com Do not ask for roms. A26Report.rar winmd5free.zip

I posted my response publicly as the attack and slander were done publicly and it is about time people on this forum know the consequences of such blatant public attacks. I've been a member of this forum for over a decade yet it made no difference. HAD Chris asked about the games in private; had he stated his opinions in private; had he not publicly lied about my work; had his public attacks not affected sales of my work, this could have remained private. But that is not what he did. He publicly attached my work and has cost sales. And those are crimes. Chris could have just as easily said he purchased the game and didn't like it for FACTUAL reasons. He did not. This forum is not being used to state facts or general opinions, it is being used to commit crimes. Slandering a person and causing loss of sales based upon those lies has its consequences. I've said it before and I'll state it again. I've have dozens of games sold by many distributors and which have been covered in several magazines. No where else other than this forum does that work get attacked and it quite clearly is going to take legal action to send the message that this behavior is not conducive to this community. This is all the more I will say on this subject publicly. .

Chris Leach, As the programmer of Sunset Drive, who spent more than 6 months coding and recoding the game from the ground up as a 100% new game until all 3,692 lines were complete and working, I consider your public attack on my code as slanderous. You are a real piece of shit to think you can attack my work by calling it a “a poorly done hack over yars revenge programming”. “I wasted my money for sure......think I can send them back? “ Quite frankly, I woudn't want a piece of shit like you owning one of my games. I did not hack Yar's Revenge nor any other game. The two don't even look remotely similar. As your attack is public and affecting the sales of my game, I will be talking with Albert and if law permits, I will be suing you for Libel and economic loss as a result of your statements. Greg Zumwalt

I would have to concur. I have made 128K demos of animated images and music. I ended up repeating about 1K of code per bank and used 2 separate banks to keep track of addressing and indexing. I've also done text message displays up to 256K and it was the same. I'm not as savvy with the 650x as some here, so I would not say going up to 1M is impossible, but the biggest issues I hit were in branching too long outside the logic loop in trying to keep track of all the banks and indexes. You're approach intrigues me. It does seem wasteful to an extent, then again, if it doubles the current maximum hardware capacity, that would make the overhead worth while. In my code I use GRP1 as the main and then used GRP0, ENAM0, ENAM1, ENABL to display a full frame rendering. For applications such as this, the more banks the more pages. Your method would prevent the use of the addition bytes per bank for those additional 5 pages per 32K, however, it would expand the storage x32. That's about 295,000 characters or roughly 37,000 words per game! That would make for one amazing read. 30,000-50,000 words is considered a Novel. Think about that... the Atari 2600 being able to display an entire NOVEL. True, like the Tiger chips, not a whole lot of demand. This is mainly due to the cost of producing a cart using those chips. Still, it would really be something to see. Keep up the great work!

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. 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

Returing as what, a crazy guy with bombs or a squishy alien... and where was he before all this?

Oops. The challenge of the programmer. Hope I didn't take too much liberty with changes. Aside from which, in order to discover the bug I had to go through all the code and they were just issues I saw along the way to the problem. No point in just leaving them in the code. Logic errors are the worst since they work incorectly. Worse one I ever did was a 60,000 line of code program that kept crashing during assembly all because I hit a semicolon instead of a colon. Took me 3 days of pulling hair and finally stepping the code one line at a time before I discovered the mistake. It's always worse when your looking at your own code and can't see it.

Oh, I should point out, though it may be obvious, that until the remaining levels are added the game will continue to crash. I thought it might be rude for me to add more code.

Greetings. Nice game. Here are a few things I found and corrected. To me it seems the biggest issue are keeping track of gosub routines and returning from them. A LESS than instead of GREATER than was the main issue mentioned here. A simple typo. Annoying. ; Alien Greed 5 beta 14 ; "Fixed courtesy of Snailsoft Software and Gray Games". ; Changes- ; if switchreset then goto i_hate_life ; to if switchreset then reboot and moved to Mainloop loop, removed duplicates. ; i_hate_life removed ; fixed multiple GOSUB without returns ; P continued to increment with no goto level. A level logic trap has been added. ; clear_score was GOSUB and GOTO'd. All gosub now. ; you had an error trap logic inverted - bally<199 should have been bally>199 (this caused the issue you point out) ; removed redundant gosub anim ; moved sub routines to end of code This has the game working to the point you had it with some extra bytes added back. Good luck. aliengreed5version14.bas

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 CoCoHardware, 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 GIMEEveryone 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 ZumwaltUse 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 ofAn 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 RusellR.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 goodideas, 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 goBack 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.

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

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.

Thanks. I was not aware of that feature.

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.

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.