Another dumb HP-41 question


Is there any way to disable the "goose" during program execution?
It's a waste of time...



Have a look here, Monte.



Ahh... thank you Massimo. If I can get the display update

disabled perhaps I can get my design to do better on the

"loop of add" benchmark.



Hi, Monte;

I have no idea about how to do it, but I am curious about how much of system time is spent with it.

AFAIK, the goose NORMALLY moves one digit to the right everytime a LBL is 'executed' in a running program, unless a user/system message is shown in the LCD; is that correct? I also have a vague recollection about one other circumstance it is also updated, but I cannot remember it.

So, if it moves only after a LBL is 'executed', I'd guess it would be a matter of either finding the part of the code that updates the goose on each LBL and remove the jump to it (replace the jump for NOP´s, perhaps).

Also, Bill Wickes' Synthetic Programming on the HP41 shows a way to make it fly backwards. Never tried it, though...

Not much of a help, I know. But I am curious a lot about it.


Luiz (Brazil)


Hi, Monte;

I thought you were trying to change the OS for your Newt experiment...

Luiz (drifting out of Space...)


Hi Luiz,

It was never my intention to change the OS. I'm not a software

guy, although I've become rather familiar with the code out of

necessity. And there isn't really a way to patch the OS on the

board without reprogramming the FPGA into something other than

a NEWT while doing so.

The issue with my turbo mode is that I have to slow down the

clock to normal speed when talking to the display or any other

peripheral device. I also have to run 1x while fetching

register data (writes run at speed). So my first numbers for

the simple benchmark were disappointing, but not surprising.

If I can somehow eliminate the display update the code won't

have to throttle back as often.

I should have some numbers tomorrow.




Hi, Monte;

about speeding up the machine: I support Raymund´s suggestion of compiling GTO´s. In fact, if I am not wrong, your HP41MD (how did you like it?) already deals with expansions, right? In a way, it incorporates features available with, say, MLDL2000 and HEPAX memory, right? If so, compiling programs is automatic when you incorporate their codes into HEPAX memory (HSAVEP), for instance. I am using HEPAX as an example because it needs only a few keystrokes to generate a compiled copy of a user code as a ROM program, and this compiled program runs as fast as any other ROM-based user code, AFAIK.

If a single CLA (or any suggestive message, like WAIT...) AVIEW is added to the beginning of a time consuming routine or procedure, the LCD contents will be unchanged till it ends. Based on what has been written in the follow-ups, that would be just a matter of choice while writing programs.

Just an extra comment: back in the 80´s, when I was at the University, I remember being scared to death when running a program with controlled loops, error detection and status messages. Suddenly the message in the display began to rotate around the edges in the LCD and I briefly thought: "God d*** it! My 41C is broken!" I felt my heart pumping in my cheeks for a while, and then I decided to investigate. The only possible explanation was related to flag 25: after an error occurrence the display contents would behave as the flying goose. Scary experience of mine...


Luiz (Brazil)

Edited: 20 July 2010, 12:52 a.m.


Hi Luiz,

I actually call the design the 41CL (41C -> 41CV -> 41CX -> 41CL ... roman numerals!).

As far as tricks like compiled GTO, perhaps I'll try that once I get the various bugs worked out.

I just wanted to do something simple to see how the design was working.

You are right about the capabilities of the design. I have written and included some "Y-functions", and

it's a good thing that I did, because I use them in the debugging. Unfortunately I have some errors in the functions

so I have to patch them before I can use them. This involves copying the 4K block to RAM and the POKEing

different values to about a dozen different locations in the copy in RAM. Then I have to manually program the MMU

to point to this patched copy (because the PLUG function has a bug for RAM addresses) and then manually

enable the MMU (because the MMUEN function has a bug). All of this patching takes about 10 minutes, which

is more time than it takes to modify the design and download it to the FPGA. In retrospect I wish I had

included a way to reprogram the Flash memory easily. Live and learn I suppose.

Once I have the patched version of the Y-functions available it's cool to turn on the Turbo mode or

virtually plug ROM images into the ports and play with them.

Thanks, Monte


The more I read about this project the more difficult is to stop salivating all over it... Good luck with the debugging, is there anything we can help with??


The more I read about this project the more difficult is to stop salivating all over it...

Ángel, maybe is this salivation from us all that causes bugs in Monte's actual design... :-D


Answering my dumb questions is about all anyone can do right now. I only have two boards built up

(I ruined three trying to solder them myself). Until I figure out why the current drain in Light Sleep

is high I don't dare have more boards fabricated. At some point I _might_ ask for a beta tester for the

second board, but I haven't decided yet.

Since I am a hardware guy, my hope is that others will take the initiative to write software to do more

with the available memory. I have functions that plug module images into ports or unplug them from ports.

And of course the 4k block copy, but nothing like file management.
I also don't have anything to use the

RS232 port except a way to PEEK and POKE bytes one at a time.

By the way is it okay that I include images of the 41Z, Sandmath
and Games software in the Flash

memory on the board?

Thanks, Monte


By the way is it okay that I include images of the 41Z, Sandmath and Games software in the Flash
memory on the board?

It's more than ok to include them, I feel honored and glad to have something to contribute with to the project. BTW an updated version of the 41Z is in final testing stages, should be posted in a few more days. Also, don't forget the Alpha ROM and the ToolBox ROM :)


Hi Monte

If your goal is maximum speed, consider using compiled GTO's in
your program. Requires heavy synthetics, See "Synthetic Programming
on the HP-41C" by Bill Wickes.

Don't forget to change the END instruction into "Packed"!




The simplest way I can think of would be by displaying a blank (or any other text) message at the beginning of the program execution.

The caveat is error conditions with flag 25 set - then the complete message scrolls instead of the goose... even worse for your purpose.

AFAIK changing this would require patching the OS...


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-41(CL): The easiest way to transfer FOCAL programs from a Linux PC to the HP-41 Geir Isene 13 2,116 12-05-2013, 02:40 AM
Last Post: Hans Brueggemann
  Non-Prime question alert: Hp-41 and synthetic instructions Marcel Samek 11 1,563 11-04-2013, 09:31 PM
Last Post: sjthomas
  hp 41 series wire-wrapped connector question. Matt Kernal 3 594 06-19-2012, 01:48 AM
Last Post: Luiz C. Vieira (Brazil)
  Re: HP-41 Navigation PAC question Timo 0 314 02-27-2012, 04:06 AM
Last Post: Timo
  HP-41 Navigation PAC question Diego Diaz 7 787 02-24-2012, 12:09 PM
Last Post: Dave Shaffer (Arizona)
  HP-41 NUT Assembler question MichaelG 6 742 02-14-2012, 03:35 AM
Last Post: MichaelG
  HP-41 printer interface question. (To the M-code gurus out there) Diego Diaz 2 481 01-29-2012, 12:18 PM
Last Post: Diego Diaz
  wp34s - Maybe dumb question John Abbott (S. Africa) 5 629 11-02-2011, 10:31 AM
Last Post: John Abbott (S. Africa)
  41-MCODE Question Ángel Martin 3 499 10-10-2011, 05:03 PM
Last Post: Eric Smith
  41 halfnut character question Eric Smith 5 667 08-23-2011, 02:09 PM
Last Post: Eric Smith

Forum Jump: