RP2350 and Pico 2 - things missing

I suspect the analogue drive circuit is not that simple - would take area and may compromise power, especially idle power.

You can get some of the way by using PWM and an external R-C network to low pass filter the PWM. Depends what kind of frequency you need. Or there are I2C DACs if you need a more accurate output.

That does look to be the case. Looks like the original RP2040 design optimised them into a corner that's difficult to get out of.

Theo

Or, you could bring back the old PDP-8 trick, of having the jump address be in the *current page*. That means the upper bits are taken from the current program counter.

There was actually a separate mode bit that indicated whether the address was in the current page or page 0. And another bit to indicate whether the access was indirect (i.e. don’t take the contents of that address, take the contents of the contents).

I would have thought that such a circuit could be gated to reduce/remove power consumption. DAC needs far less circuitry (and no iteration) than ADC.

I was hoping for analogue output pins initially in order to drive a VGA display. Would PWM work for that, do you think? My guess is that it would be too slow or jittery.

I have seen Pico set up to drive VGA through five resistors per colour. It may be a Pico reference design but there's a great version of it at

Of course, external DACs increase the chip count and add latency and cost but I take your point.

Agreed. The curse of upwards compatibility. Though they could still have supported two different modes.

I suspect it takes (quite) some design effort to get it right (see the ADC on the RP2040), and requires analogue circuitry which is more difficult to implement in a given process than digital.

Also, on-chip DACs are not too common in competitor parts - there are some that have it, but it is not standard.

That requires a *really fast* DAC. IIRC, standard VGA was ~25MHz pixel clock.

For comparison, the STM32F407 DAC has a settling time of 3us (typical), meaning you can't do anything above ~300kHz.

Getting a DAC to VGA speed (even at reduced resolution) requires quite some more design effort (and probably also chip area), and aside from analog VGA, there are probably few use cases.

I agree.

Well, the new RP2350B has 48 instead of 30 GPIO pins available, so that should be anough for 6 bits / colour ;-)

cu Michael

That must be damn annoying to program in assembler. Probably slows compilers down a fair but too.

IIRC 8086 was the same for conditional jumps.

In fact the whole small model thing was coding for a 64k page.

There were a few instructions that worked across pages...but my memory is dim.

FAR and NEAR specifiers used with JMP were often used for intra segment calls. Data could also be accessed with the same specifiers too, hence there were five different memmory models, tiny, small, medium, large and huge with different code and data accesses.

Yes, that all sounds vaguely familiar. All that forgotten knowledge that I will take to the grave with me, where, arguably, it belongs...

It was a horrible processor to do assembler on, but I made a living out of it for several years.

Thank Clapton for 'C' and Unix/Linux/Gnu and the 386 series at which point one no longer had to...

The obscenity was these qualifiers making their way into C source code - try writing (or even reading) the declaration for a near pointer to a function returning a far pointer to an array of functions returning near pointers to integers.

Then realise that you *alos* wanted this source code to be portable.

Which was why one used macros to conditionally compile code on MSDOG and other platforms. And there were macros for far pointers, MK_FP() for example. I think I have the remains of a hex disk editor somewhere in my archives written in C with some assembler using Zortech C.

Fun times(!)

So I've had a rummage around, and the original diskedit sources isn't with us anymore, but it looks like I ported it to windows 95 and threw out all the MSDOGisms.

I do wish I still had the original sources though, but it's lost in the mists of time.

What happened to backups?

;)

I think they must have been on these Travan tape backups that I threw out decades ago. :(

A bloody pain in the ass, all of it. Forget the 640K barrier - I was much more concerned with the 64K barrier. I wound up writing pointer normalization routines and all sorts of other hacks to handle large tables - and still keep it compatible with *n*x. I only recently stripped out all that crap. Good riddance.

Huge pointers for code + data for up to 1MB, oh the Ghods, much slower than using using tiny pointers limited to 64KB segments. But yes, playing games with segment registers and splitting data into 64KB segments was significantly quicker and generated smaller binaries.

I don't recall them ever appearing in C source. They are not part of the C language. AIR you could compile for 'small model' or 'large model'

And with the early compilers I used, no attempt was made to think about whether a jump was near or far.

I think you got an assembler or linker error if a target was 'out of range'

No I remember the joy of using NEAR and FAR in C for 8086 code. I can remember being forced to use them in zORLAND C/Zortech C++ and Borland C on 8086 code for PCs running DOS and in embedded 80186EB code.

No they are not - but they did appear as extensions in every

There were several models available (tiny had one segment shared for code and data, small had separate code and data then there were mixed small code large data and vice versa). These set the memory mapping and the default sizes of pointers but the near and far keywords could override those defaults in some models.

It was *horrible*, the 80386 was a breath of fresh air.

Dint appea as extensions in ANY of the ones I used. You compiled for small model or for large model. Small model couldnt exceed 64k program space

Not in any compiler I used.

I'll grant you that.