Re: TI-H: Ph34r my 3r337 nu hax0red t0y

[Prev][Next][Index][Thread]

Re: TI-H: Ph34r my 3r337 nu hax0red t0y


Oh yeah, and since I'm so damn lazy, can I just clip off the pins that are Xed
off in your schematics?  The alternative is for me to do more work on the PCB
in order to accomodate the pins, and I'm lazy... to hell with the MMOD for
me... I might just order the 1MB chip after all.
CK

Bryan Rittmeyer wrote:

> Christopher Kalos wrote:
>
> > But as long as I'm mentioning ideas, how about that old idea of
> > redesigning the TI cases?  I'd like one that properly holds AA
> > batteries, and maybe even has a belt clip.  Maybe this would some kind
> > of holder for the calc itself, much like the cover, only better desgined
> > to be permanently attached, yet unobtrusive.  THIS is more realistic
> > than say, TILinux... although, that would also be very cool.  (Bryan,
> > how much storage can you cram onto that current EII based on the latest
> > firmware?)
>
> If you wanna bother with SMD chips, you could use the 1MB chips. I may
> actually build in 1MB functionality into the driver and have it
> auto-detect. In theory the 45D041 chips have a different status word
> than the 081s... however all of the 041s I have return '10000000' when
> they're in the ready state, which does not follow the data sheet at
> all. Maybe I got a bad production run?
>
> Also... The ESF used a chip with something like 4096 bytes per page,
> whereas the the E2 chip has 264 byte pages. In both designs it is
> impossible to have two programs share a page... so as you can
> imagine, if you have a bunch of 600 byte levels or something, you are
> going to be wasting a LOT of space on the ESF, but not nearly as much
> on the E2. That is why 512k should be enough for all of the
> calculators, possibly excluding the 85.
>
> > Other stuff... now that we have a schematic, who can make an IR link off
> > of the EII?
>
> It wouldn't be too difficult, you have 6 I/O lines to play with, but
> I yanked the RS-232 code... you'd need to keep the bitrate waaay down
> (below
> 30bps, probably) in order to use RS-232 anyway, and its probably better
> to
> design a two-way protocol, to keep the errors relatively down. Error
> checking and packet processing is fine, but its better to keep errors
> from
> happening in the first place.
>
> Bryan
>
> --
> Bryan Rittmeyer
> mailto:bryanr@flash.net
> http://www.flash.net/~bryanr/
Follow-Ups: References: