HP Forums
MLDL2000 update - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: MLDL2000 update (/thread-172421.html)

MLDL2000 update - Meindert Kuipers - 09-26-2010

After having finished the design of the MLDL2000 and about to request quotes from assemblers I was pointed to the website www.mbed.org, and this is really a great product. I have made the decision to add it to the MLDL2000, instead of specialized SD card controller. The mbed controller will be able to support SD cards, and a lot more, including ethernet connectivity, serial ports and user application programming. It actually gives you a complete ARM Cortex to play with, complete with development tools, libraries and a user community online.

The only disadvantages are its somewhat higher price, and the size. Due to this size I have to redo the layout of the MLDL2000 from scratch, but it will be worth it. Imaging controlling an ethernet port from your HP41 (yes, there will be an RJ45 port on the MLDL2000 V2)!

Have a look at the mbed website, if you have any ideas let me know,


Re: MLDL2000 update - Håkan Thörngren - 09-27-2010

The possibility of having TCP/IP and USB connectivity is very appealing. While the HP-41 is a bit slow, the ARM could be used as a smart device to speed things up.

However, my initial impression is a little bit concerned about the business model. They model their tools around a cloud, meaning you need to sign up to use their website. The tools are executed on their side and what does that mean for the future? We are running very old orphaned hardware and would probably like to do so for some considerable future.

How long will that website exist and how long will it support the hardware we choose? What about the pricing model, is something that might change at any time in the future? Pay for each build?

Can we keep the project home to have full control over it?

Re: MLDL2000 update - Meindert Kuipers - 09-27-2010

That was also one of my concerns first. The community has several threads about offline compiling (see here for example), and that, plus the ease of use convinced me.

Re: MLDL2000 update - Håkan Thörngren - 09-29-2010

Then I feel relieved.

I wonder, how do you plan to interface to it? Will it be possible to write some firmware for it to implement our own devices, i.e. support PFAD=C, C=REGN and REGN=C instructions to keep the standard low level interface?

Would it also be possible to draw I/O flags like the time module do (flag 13 when something is up, and then only draw secondary flags when that particular device is selected)?

This could really open up for a lot of possibilities!

Re: MLDL2000 update - Meindert Kuipers - 09-29-2010

Keep in mind that the MBED module will be an (optional) expansion to the existing MLDL2000 structure (although in a completely new layout), meaning that the MBED module will talk to the MLDL2000 through a communication path. The plan is to have a communication interface based on register I/O, such that your HP41 sees a register (somewhere in the ROM memory map) and can send commands and data to the MBED, and receive data back.

It is not my intention to expose the HP41 interface signals to the ARM processor, although that is not impossible. Generation of the I/O flag will be prepared in the hardware, just waiting for a possible use case.

Disadvantage of the MBED module is the current consumption (up to 200 mA), so in practice you always need an external power supply. For those who wish to use the SD card interface only an alternative will be offered, the new MLDL2000 will also support the GHI uALFAT module (embedded micro SD card controller).


Re: MLDL2000 update - Håkan Thörngren - 09-30-2010

Sounds good in any case. I think being able to control FI 13 in hardware is the important thing, how the rest of the low level interface looks is not important. Even the secondary FI flags are not important as that status should be possible to obtain by just reading suitable interface registers.