[Coco] Nick's Survey results

[mmarlett at isd.net]

>On Friday 05 December 2003 14:16, mmarlett at isd.net wrote:

I look at us as being a small enough group as we are. If I start to create hardware
that eliminates any part of the group, it is a loss. A loss in sales and a loss
in support as a community. We look at all aspects of this. You can't please
everyone and sometimes there are no work arounds. In this case maxtrix scan
and new improved PS/2 port is the meal ticket. A bit of firmware in an Atmel
AVR and then a SUPER CPLD from Altera. I have the scan matrix done and going
to work on the mouse packet buffer after SuperIDE is completed. Details, details......
At the same time I'm going to be making a generic Altera CPLD board that plugs
in to the Atmel STK500's expansion ports. This will allow you to do firmware
development along with your target CPLD on the Atmel development kit. One serial
port controlling the STK and a printer port controlling the Cloud-9 ByteBlaster
board to reprogram the CPLDs. Will be quite nice! Better yet anyone will be
able to do this! Hardware understanding will be helpful.

:)

Regards,

Mark
Cloud-9




>>This has been done....The SuperBoard and SuperIDE cards have the
>> FLASH option. The keyboard....Even though it might be a good idea,
>> it will only work with a patched RSdos or NitrOS-9. Boisy has
>> already done this for the up coming option of the PS/2 port on the
>> SuperBoard. The problem is that when you do not have backwards
>> compatibility all of the old software will not work. So unless you
>> aren't going to run old software and just the new CoCo software
>> being produced today, you will be frustrated. Even with patches to
>> the RS routines yoou will still have programmers that talked to the
>> hardware directly. That is why we selected the platform that we
>> did.
>>
>>???? Did that make sense??? The polling method is a burden for sure.
>>
>>Regards,
>>
>>Mark
>
>Yes it does make sense Mark, perfect sense.  For those games that 
>insist on hitting the hardware for just a partial scan, just enough 
>to determine if key so-and-so is pressed, I don't think they'd ever 
>had any business doing anything but their own hardware scan which 
>should still work, as opposed to jumping into the middle of the basic 
>keyboard scanner routine.  If they do that, they are going to break, 
>and will need fixed, while grumbling about bad dogs etc.
>
>OR... The solution might be a reversable patch to the coco3's all ram 
>image of the roms so that it can overlay the scanner routine with a 
>read the port routine that lives at the entrance point of the 
>overlaid scanner routine.  Something similar in operation to the 
>rom-->ram routine we used in the cocos before the 3 might be in 
>order, but as it overwrites the scanner, it should also save whats 
>there, either as a disk file or in some high memory location not used 
>by the system, something thats in short supply for a coco3, and leave 
>behind a trigger check so that if a certain key combo is pressed, the 
>original keyboard scanner is restored and the stock keyboard becomes 
>active again.
>
>The question then becomes:  Are the coco3's roms consistent enough 
>that this 'patch' could be carved in stone and used in every one ever 
>made, or are such things as pal/ntsc etc going to require multiple 
>versions of what should be a simple little utility?  That I do not 
>know.  I quit messing with those overlays when the 3 came out and I 
>lost the memory above the disk controllers roms as a hidey place for 
>all sorts of neat things like Jake Commanders Chrmakey editor.  I was 
>also using os9 exclusively by then.
>
>>>I for one would love to see a centralized site for COCO. Not
>>>just for games though. If Nitros9 is free then where do I get
>>>it? The coco all versions would make a great little
>>>developement system. How about downgrading the basic roms to
>>>just a BIOS Placed in a small Flashable prom,64k Static ram
>>>using two 43256(32k x 8)chips,a serial keyboard that is NOT
>>>an AT keyboard interface(COCO3 matrix keyboard with scanning
>>>done by an encoder or a Pic processor sending serial scan
>>>code to only the row I/O port,then change POLCAT to read
>>>ASCII or other byte of key code). Making an AT keyboard
>>>interface seems to me to be an excessive use of both hardware
>>>and software just to have a lap keyboard that is transparent
>>>to coco. Also perhaps an 8-bit ISA type slot or two.
>>>
>>>--
>>>Coco mailing list
>>>Coco at maltedmedia.com
>>>http://five.pairlist.net/mailman/listinfo/coco
>
>-- 
>Cheers, Gene
>AMD K6-III at 500mhz 320M
>Athlon1600XP at 1400mhz  512M
>99.22% setiathome rank, not too shabby for a WV hillbilly
>Yahoo.com attornies please note, additions to this message
>by Gene Heskett are:
>Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
>
>
>-- 
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
>
>