It’s quite normal. Usually these have ~4kB of a battery-backed SRAM region for pseudo-NVRAM scratch space, and an assortment of 16, 32, 64, 96, or 128kB ranges scattered elsewhere. The sum of these isn’t always an even power of two or anything.
As @Vertiginous mentions, microcontrollers are often very weird looking memory systems. GPUs are similarly bizarre at times. But this sort of “Well, you can use it all as one block, but if you need something special, here’s how it’s physically laid out…” thing is quite common to find.
I spent a bit of time with the datasheet, and a few things worth pointing out:
There are 12 DMA engines on this thing that can run! No wonder they’re striping memory by default - you can shove a ton of data around.
The “PIO” state machines? Those are arbitrary output drivers. You program them with how to emit a data stream, with cycle-specific delays based on the input clock, and then it does it. So if you want I2C, or UART, or WS2812 LED, or DMX, or… whatever you want, you can program it. Properly impressive.
In general, this is a massive uC with a ton of features. It’ll do just about anything you ask, near as I can tell.
Yeah they’ve been making a big deal out of the PIO peripherals… they can drive VGA for instance! And apparently do DSD audio through a simple RC LPF to fairly high levels of precision (ok, jitter is going to be your worst enemy here, but it’s probably going to end up as good quality as a consumer grade dedicated DAC or ADC will).
12 DMA engines, or 12 DMA channels?? Not sure what you mean by “engine”… my experience with ARM DMA is that it is usually coordinated by one mux unit with the ability to stream several connections simultaneously in channels… if you have a BIG.little arch you might have two DMA units, but I can’t see how 12 would be useful for a symmetric dual core setup…
I’m not sure how printers really interface. It would likely work fine (very well, even) for an on-printer microcontroller, but it wouldn’t handle the full 3d files and such.
Could be quite a full featured GRBL style controller though. Just feed it g-code from Cura or Slic3r and it’s got more than enough power to handle that.
I’m sure the raspi-cam is out but it would probably interface well with an OV2640.