HP Forum Archive 18

[ Return to Index | Top of Index ]

The MOARP (a "concept module"... wouldn't it be nice?) Message #1 Posted by Diego Diaz on 18 Oct 2008, 8:41 p.m. Hi all, This is just a topic to talk about... would it be interesting or not to have a microSD card attached to an HP-41? MOARP stands for the Mother Of All Rom Pacs (I know... not very ingenious... :-\ ) However the concept is clear, having all available ROM Pac images into a single module with the type of management already available to NoV-64... i.e. you can swap them just from the keyboard thru a few control words... The HW is ready... the code is NOT... so this is only a discussion to see what you think about. Feel free to comment, praise or critic... ;-) Cheers from Spain. Diego.

You could hard wire it inside the calc and that would.. Message #2 Posted by Geoff Quickfall on 18 Oct 2008, 9:11 p.m., in response to message #1 by Diego Diaz free up all the ports for HPIL. All rom images on the SD, now beat that everyone. Diego, that WOULD be incredible!!!! Geoff

Re: You could hard wire it inside the calc and that would.. Message #3 Posted by Diego Diaz on 18 Oct 2008, 9:39 p.m., in response to message #2 by Geoff Quickfall Hi Geoff, While wiring it "inside" the calc will certainly leave all four ports free, I see some drawbacks: - You could not remove the micro SD to load new "released" or "discovered" module images. - You'll be using extra battery power even if you don't need any of the modules (although this could probably be avoided by configuration) - You could not upgrade the microcontroller code in case (quite likely) some improvements were made...or bugs were found and fixed. - Last (have to say: but not least) you'll need to open your beloved HP-41 and fiddle around with solder iron, wires, etc... I must confess that I don't like this sort of surgery at all. I preffer HP-41 as it is and open a calc if this is required for repairs... (but that's just my opinion.) Obviously, the idea is to have a configuration utility in your PC than can read/write ROM images from/to the micro SD card. Of course, HP-41 can not handle the directory structure of a 1GB FAT32 formatted card, (there are ways to overcome that limitation though) and certainly 1GB is far more than will ever be required to hold all conciveable ROM images. (I've calculated a total of 512 images, 8k each = 4MBytes) So in order to not waste the remaining 996MBytes, it would be prefferable to keep micro SD card removable. Thanks so much for your opinion and your enthusiasm! :-)) Best wishes. Diego.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #4 Posted by Egan Ford on 18 Oct 2008, 9:20 p.m., in response to message #1 by Diego Diaz I'd also like the ability to read .RAW program files and import and export EM. If a SD card directory could act as HEPAX RAM I think that would cover it.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #5 Posted by Diego Diaz on 18 Oct 2008, 11:09 p.m., in response to message #4 by Egan Ford Hi Egan, Well, you're "playing major leagues"... :-) While reading from a microSD (or SD for that matter) card is "reasonably" easy, writing is not trivial. The core memory inside these devices is just a Flash memory cell array; and this kind of memory requires of an "erase" cycle prior writing. Such erase cycle clears the contents of a whole sector (64, 256,... bytes) thus, in order to write a single byte/word you must first read the whole sector into some temporary buffer, then modify the required byte(s), erase the whole sector, and finally re-write the updated contents. All this process can of course be done by the microcontroller... but it cannot be achieved fast enough to cope with HP-41 bus timing requirements. Sorry for the bad news. As the title shows, the concept is having access to all the *ROM* pacs in a snap. However, procedures like the one used by RAM2ROM.HEX on NoVRAM, can be build to allow sort of back-up copies. Regrettably, my knowledge on M-code is so limited that handling user RAM, Extended Memory or Focal programs and moving them back and forth is far from my scope... :-( Some M-code gurus out there may be interested in the project though... any volunteers? :-) Thanks for your comments and best wishes. Diego.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #6 Posted by Meindert Kuipers on 19 Oct 2008, 5:01 a.m., in response to message #5 by Diego Diaz Great piece of work Diego! Just yesterday I have my own SD card interface running with the MLDL2000. HW is ready (on a breadboard), SW to be done. My approach is a bit different since I use a ready made SD card controller that handles the file system. I will show this in Allschwil. And of course it will not fit in a module case but a cardreader housing or other external box is required. Meindert

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #7 Posted by Diego Diaz on 19 Oct 2008, 9:04 a.m., in response to message #6 by Meindert Kuipers Yes, I hope we all can share some words about this topic too at Allschwil... ;-) Best from Spain Diego.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #8 Posted by PeterP on 19 Oct 2008, 11:20 a.m., in response to message #5 by Diego Diaz brilliant idea diego!! And, I would think that at least reading in of focal programs should be doable as well as reading in of em, key assignements etc. I don't knowthe .raw format so I don't know if one would have to change the format first. Clearly, having some q-ram for mcode programming would be great (a advhepax emulation with it's memory would do re trick ;-) but it seems that there are timing problems that one would have to overcome. Maybe there is a way...

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #9 Posted by Egan Ford on 19 Oct 2008, 7:07 p.m., in response to message #5 by Diego Diaz Quote: While reading from a microSD (or SD for that matter) card is "reasonably" easy, writing is not trivial. Read-only is still fine. It would make a great substitute for HP-IL or the wand for getting programs into the 41.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #10 Posted by Geoff Quickfall on 19 Oct 2008, 7:25 p.m., in response to message #9 by Egan Ford I have to agree with Egan, read only would be perfectly acceptable! Cheers, Geoff

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #11 Posted by Geir Isene on 19 Oct 2008, 8:33 a.m., in response to message #1 by Diego Diaz Now, this would be the second coming (Clonix/NoVRAM being the first)! The remaining memory (996MB) I would use to hold the Museum or TOS DVD so that wherever I go, I would have access to the whole world of useful information on any available PC... I would go to great lengths to support this endeavor. I guess it will be a good topic in two weeks :)

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #12 Posted by Diego Diaz on 19 Oct 2008, 9:21 a.m., in response to message #11 by Geir Isene Hi, Although 996MB is not enough to hold these DVD's it can certainly be filled with a nice amout of info form both sites :-) Please, don't forget to save a small folder for the Clonix, NoV and MLDL2000 related files!! Will see you soon. Diego.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #13 Posted by Dan Grelinger on 20 Oct 2008, 1:33 p.m., in response to message #12 by Diego Diaz Diego, 1. Awesome concept! 2. Why is the limitation 1GB? (Perhaps I read the previous posts too quickly and missed it.) Why not the max 'standard' SD capacity of 2GB? These 2GB SD cards are selling for just $6 now (free shipping the in the U.S., too!) And would allow more 'other' storage such as the pdf manuals of all the ROMs, and then some. 3. Awesome concept! Dan

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #14 Posted by Winfried Maschke on 19 Oct 2008, 9:39 a.m., in response to message #1 by Diego Diaz How do you handle the low-level signals on the micro SD? As far as I know they work only up to 3.6V and the 41 needs a higher level. There is not much room left inside the module case beside a PIC and the micro SD connector. Is it possible to run the PIC with up to 6V signals and Vcc (on the 41 side) and interface to a micro-SD on the other side with 3.3V at the same time?

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #15 Posted by Diego Diaz on 19 Oct 2008, 10:39 a.m., in response to message #14 by Winfried Maschke Hi Winfried, Good to see some tech questions!... :-) The PIC Vcc is limited to some 4.5 volts thru a small resistor. This takes advantage of the highly stable current drain rate of PIC microprocessor at a given (fixed) frequency. It can stand 6v on its input lines, and HP-41 takes 4.5v as a "valid" High level when it comes to accept data from the PIC into the ISA line. Micro SD certainly work at 3.6v max. but (fortunately) it has separate data input and output lines (DI & DO). We need 3 voltage dividers (6 SMD resistors) to handle the required 0.9v step-down: - One for Vdd. - One for DI. - One for CLK. And there is enough space in the module housing for 4 more SMD resistors (currently there are already tree of them.) The SD adapter takes the place used by the pulling handle so it does not need extra room. DO is directly connected to its PIC port. DO High level is 0.75 Vdd min. (2.7v) and PIC input accepts 2.0v and above as valid High level. It should work... but time will tell ;-) Cheers Diego. Edited: 19 Oct 2008, 10:56 a.m.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #16 Posted by Winfried Maschke on 19 Oct 2008, 12:08 p.m., in response to message #15 by Diego Diaz Hi Diego, it looks like you are lucky to have the PIC in between 6 and 3.6 V ;) I intended to do some Interfacing with the eZ430 from TI (don't kill me for connecting a TI processor to a HP), but it is working only up to 3.6 V. Up to now I see no way to connect it to the 41 without level shifting for each line. They have got those nice and handy USB Development Tools Cheers Winfried

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #17 Posted by Garth Wilson on 19 Oct 2008, 5:19 p.m., in response to message #15 by Diego Diaz Quote: We need 3 voltage dividers (6 SMD resistors) to handle the required 0.9v step-down: - One for Vdd. - One for DI. - One for CLK. Do not use a voltage divider for Vdd. There's too much variation in current from one lot to the next, across temperature, etc. for the resulting voltage drop to be predictable and dependable for production units. Instead, use a micropower linear regulator IC. And on the data line, if you must use a voltage divider, definitely put a small capacitor across the first resistor, perhaps 15pF, so you don't slow the input waaaaay down with the input capacitance of the microSD, socket, etc. and make it unable to operate at the intended frequency (even if that's only a 500kHz SD CLK). Edited: 19 Oct 2008, 5:20 p.m.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #18 Posted by Diego Diaz on 19 Oct 2008, 5:48 p.m., in response to message #17 by Garth Wilson Hi Garth, Thanks for your hints. As I'm still in the "brain-mess" part of the proto-project (far away from a working board... ) every comment/idea is very valuable. I'll keep posted as the HW takes a more defined form. The working frequency will be really low, as you said, around 500KHz. Regards.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #19 Posted by Meindert Kuipers on 20 Oct 2008, 7:46 a.m., in response to message #15 by Diego Diaz The SD card interface (SPI at least) basically used 4 signals: - SDO (data out) - SDI (data in) - CLK (SPI clock) - SSEL (Device select) So you would need a voltage divider on SSEL as well. I do not like voltage dividers on data signals as this will mess up rise times. And from the software side (PIC firmware) I think this would be a big challenge. In the new MLDL2000 I am using the uALFAT controller from GHI Electronics, and that seems to work quite well. This is actually a pre-programmed LPC2103 ARM controller, and it seems like shooting a mouse with a cannon. The advantage is that the firmware effort is minimal (and it supports SDHC cards, 2 GByte is not the limit, if that might ever be a problem) I think Diego and I will have a long talk at the Allschwill meeting and I am looking forward to it! Meindert

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #20 Posted by Diego Diaz on 23 Oct 2008, 11:17 a.m., in response to message #19 by Meindert Kuipers Hi Meindert, Will have that conversation for sure! :-) On the tech side of the question, the CS signal will always be active (LOW) tied to GND, as there is no other card in the bus, no conflict can arise. My main concern at this point is the power requirements of the microSD card in active mode. As I said before: still a long path to walk on this project... but a nice path! :-)) See you soon. Diego.

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #21 Posted by Meindert Kuipers on 24 Oct 2008, 3:25 a.m., in response to message #20 by Diego Diaz Diego, I will show you my implementation in Allschwil. I use a handshaking mechanism that is independent of the HP41 timing. On the tech side: I am pretty certain that the CS signal must be toggled between transfers even if there is only one SPI slave. See you soon! Meindert

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #22 Posted by Didier Lachieze on 20 Oct 2008, 8:16 a.m., in response to message #1 by Diego Diaz Hi Diego, Some time ago I've had also the idea of implementing a micro SD card interface in an HP 41 module to be able save/load programs or data without a complex HP/IL interface system and to be able to carry module images. However I've not got very far in the investigation as I have limited spare time... Anyway here are some of my ideas/findings that you may or may not find helpful ... :-) On the HW side such module could be based on the Clonix module plus the SD card connector and signal interface. I was considering using for the SD card power a small linear regulator such as the Microchip TC1054. Adding the SD card connector should be challenging for the PCB routing given the limited size available. One more point is how to solder this SD card connector as for the ones I've looked at, the pins are not accessible: they are meant to be soldered using reflow soldering, which could be difficult to do, even on your nice bench ! For reference I've used the AN1003, a Microchip Application Note which includes some schematics for interfacing a SD / MMC card to a PIC microcontroller. On the SW side there is the AN1045, a Microchip Application Note about implementing a FAT file system on a SD card, the source code is also available. The memory usage for this FAT file system implementation goes from 11364 bytes (program memory - read-only mode) up to 33348 bytes for a full implementation with different steps in between depending on the functions supported (details are page 10 of the AN1045). So I'm not sure you can still have enough memory for a full Clonix module without adding extra memory chips which may be difficult due to the space constraint on the PCB. My idea was to build a SD card reader (/writer) module with an interface similar the HP 9114 HPIL Disk Drive on the HP 41 side. In my mind the PIC memory would contain: The Clonix code to manage the low level interface on the HP-41 bus a M-Code page with the Disk Drive emulation functions accessible by the HP-41 the FAT file system to manage the SD card memory (from the AN1045) A way to access the file system functions from the M-Code (not yet defined) Some functions to transfer a module image from the SD to another Clonix/Nov module in the HP-41 All in all it's an exciting project !!

Re: The MOARP (a "concept module"... wouldn't it be nice?) Message #23 Posted by Diego Diaz on 23 Oct 2008, 12:20 p.m., in response to message #22 by Didier Lachieze Hi Didier, My project is far less ambitious than your proposal... just a way to have ROM images handy in a single module. The usage of a Flash support as HP-IL-like Mass storage is way beyond my knowledge... :-( I've read the Microchip documents about SD controller and FAT building in SD cards, however I think I'll take the easy way and let Windows to do the "dirty job" of formatting, etc... The main issue is that the PIC inside the module has very little time to perform the required tasks inherent to the HP-41<>PIC<>microSD transfers, as this *must* be done during HP-41 working cycle of 155uSec. Also the required memory for this implementation is a serious inconvenient. I'll re-take my work on this as I get back from Allschwil. Regards. Diego.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall