Now I remember why I hate the 8032...

...and pretty much EVERY CPU designed by intel, ever.

It's not like they could have turned a 16 bit CPU into a 24 or 32 bit addressing one, because that's way harder to do than extending the 32 bit x86 to 64 bit for instance (or the original 16 bit x86 to 32 bit)...

"Look Ma! It's a flock of randomly chosen flying search engine terms to direct a certain kind of people here!": Mediatek, MT8226, 8226, LCD, Samsung, 8032, 8051, MT13x9, bank, page, 0xFFFF, reverse engineering, firmware.

The usual trick, apparently originally devised by Philips, is to use one of the 8032 ports (usually P1) as an extention of the 16 bit address bus, thus acting as a ROM bank selector => if you use 8 bits of that port, you now have 24 bit addressing.

Of course, this doesn't mean that your PC will suddenly become 24 bit aware, and since it still remains 16 bit, you need to have overlap code, for each of your 64 KB banks ([0000-FFFF]) so that, as far as the CPU is concerned, the same bank is still being used.

This usually results in LOADS AND LOADS of ROM space wasted with the following kind of crap:

ROM:8301 ; --------------------------------------------------------------------------
ROM:8301 mov DPTR, #0x7E2D
ROM:8304 ljmp bank_0E
ROM:8307 ; ---------------------------------------------------------------------------
ROM:8307 mov DPTR, #0xE4D1
ROM:830A ljmp bank_0B
ROM:830D ; ---------------------------------------------------------------------------
ROM:830D mov DPTR, #0xF51E
ROM:8310 ljmp bank_0F
ROM:8313 ; ---------------------------------------------------------------------------
ROM:8313 mov DPTR, #0xFA0D
ROM:8316 ljmp bank_0F
ROM:8319 ; ---------------------------------------------------------------------------
ROM:8319 mov DPTR, #0xF924
ROM:831C ljmp bank_0F
ROM:831F ; ---------------------------------------------------------------------------
ROM:831F mov DPTR, #0xFDA7
ROM:8322 ljmp bank_0D

with the bank switching function of the like:

ROM:8288 ; ---------------------------------------------------------------------------
ROM:8288 bank_0E: ; CODE XREF: ROM:84F6j
ROM:8288 ; ROM:852Cj ...
ROM:8288 mov A, P1 ; Port 1
ROM:828A anl A, #0xF ; 8 bits for high addressing => 16 banks
ROM:828C cjne A, #0xE, ROM_8291 ; bank 15 (0x0E)
ROM:828F clr A
ROM:8290 jmp @A+DPTR
ROM:8291 ; ---------------------------------------------------------------------------
ROM:8291 ROM_8291: ; CODE XREF: ROM:828Cj
ROM:8291 swap A
ROM:8292 rr A
ROM:8293 push ACC ; Accumulator
ROM:8295 mov A, #0xBF ; '+'
ROM:8297 push ACC ; Accumulator
ROM:8299 push DPL ; Data Pointer, Low Byte
ROM:829B push DPH ; Data Pointer, High Byte
ROM:829D ljmp ROM_BF70
ROM:82A0 ; ---------------------------------------------------------------------------
ROM:BF70 ; ---------------------------------------------------------------------------
ROM:BF70 anl P1, #0xF0 ; Go trough bank 0
ROM:BF73 orl P1, #0xE ; Set the high address lines to bank 0x0E on Port 1
ROM:BF76 ret
ROM:BF76 ; ---------------------------------------------------------------------------

As indicated above, each bank has to DUPLICATE this whole bank switching business at the exact same address. And there will be a short period where code is actually ran in Bank 0 (right after the "anl P1, #0xF0") before switching to the actual destination bank (here Bank 0Eh)

Only thing I can say is, seeing how crappy a CPU it is (don't get me started about how poorly optimized all the 8032 code I see seems to be), licensing for the 8032 must come really REALLY cheap!

But then again, having SoC makers like MediaTek design their systems on the cheap might have its advantages...

No comments:

Post a Comment