Re: Some More SPLB20D Information (long) Message #3 Posted by Bill Wiese on 13 June 2003, 10:48 p.m., in response to message #2 by Michael F. Coyle
Michael..Hi Bill,
> Yes, the CPU is a 6502 of some sort, but no hint as to
> whether it has any extra instructions. They call their
> 6502 core the "CPU14B."
If it has bit set/clr operations it's a 65C02. There's prob a few extra addressing modes for a few instructions in the 65C02 not in 6502. Don't think there's any new addressing modes though. If not it's a plain ol' 6502.
I wonder if they still have the original Rockwell JMP bug
(IIRC, JMP instruction crossing page boundary doesn't increment the PC's MSB. Thus orig 6502 assemblers had to check for this and pad with NOPs).
> SPL61A/191A CPU is an 8-bit Full Instruction Set
> microprocessor. It includes 151 instructions with
> Y Index Register.
The 151 sounds like 6502 - all valid operations with all valid addressing modes. The "..with Y index register" worries me but it just could be Chinese phrasing: a normal 6502 has both X and Y index registers.
> Note that the ICE command, "CPU F6502", must be
> applied on ICE command line for Full Instruction Set.
Now that I vaguely remember, these may be the guys offering a skinny 6502 that has only an X register and few addressing modes. So it sounds like this is a std 6502.
> There is a Test pin. I suspect it generates an interrupt
> on one of the three reserved vectors in high memory
> ($FFF2-$FFF7).
Hmmm. Maybe this is an old design without JTAG scan test.
Wonder if the test pin is just held Hi or Lo or if you can shift stuff in and read stuff back. JTAG scan tests can drive logic with test sequences. Sometimes on CPUs instructions can be shifted in - might be a way of peeking at ROM using an LDA $addr opcode/operand shifted in.
I once wrote a flash EPROM burning routine so a 'naked' (i.e., no bootcode) oddball CPU could burn its own flash by shifting in instructions over JTAG port. Since P/ROM was mapped out, you only had an address space depth of one, so you couldn't branch anywhere. Just loads & stores.
> bottom 2K of ROM is reserved by Sunplus for a
> test program.
Interesting. With JTAG that really shouldn't be necessary.
JTAG can excercise more of the die than any program code can.
> SPLB20D has 32K ROM, and three areas of RAM: 128 bytes
> CPU RAM ($80-$FF), 64 bytes display RAM ($00-$3F) and
> 2K data RAM ($1000-$17FF). I notice that none of the
> memory is mapped to the 6502 stack area ($01xx);
> the data sheet shows this area as "Reserved."....
> ... amt of RAM on the chip is probably not customer-
> selected as you state, but different members of the
> family have various amounts of ROM and RAM so the
> customer will pick the appropriate device after he
> knows how much memory he'll need.
OK so these are separate RAM sections. From the way I (quickly) looked at the diagram there might have been 3 flavors w/3 differing RAM amounts. Guess not, just different areas.
On pg 5 of 13 on the Sunplus LB20DV12.PDF document I see that "CPU working SRAM" is from $80-$FF so that must be the stack. They put the I/O registers and LCD buffer all below $100 so as to take advantage of 6502's more efficient zero-page addressing opcodes.
> It looks as if there's an emulation board with EPROM
> for testing. No other details are given.
That prob means they have a 'bond out' chip. Everything's mapped the same but there are extra pads for external addr/data bus. Perhaps this die could be bonded out...
> I think we're out of luck as far as dumping ROM is
> concerned. The Sunplus test program might include
> that function but there's no way to know.
Yes. If we found out more about the Test pin that might be useful.
> one other possibility though. It might be possible
> to dissolve the glop covering the chip, photograph
> the ROM and get the bits from there. Peter Monta
> did this with the HP-35 ROMs so it's at least possible.
Yes. However this is likely a much smaller geometry chip than the HP35. What was that, 10+ microns? This is prob something around a .75 or .90 micron process. So might be hard to photomicrograph well without blowing away the glass passivation layer. Even then detecting 1s from 0s may take a bit of effort. Bit/byte addressing may be scrambled/interleaved too so that's another puzzle to solve.
Bill Wiese
San Jose, CA
bill[at]bwiese[dot]org
|