Another dumb HP-41 question

[Monte Dalrymple]

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

Thanks,
Monte

[Massimo Gnerucci (Italy)]

Have a look here, Monte.

Greetings,
Massimo

[Monte Dalrymple]

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.

Monte

[Vieira, Luiz C. (Brazil)]

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.

Cheers.

Luiz (Brazil)

[Vieira, Luiz C. (Brazil)]

Hi, Monte;

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

Luiz (drifting out of Space...)

[Monte Dalrymple]

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.


Thanks,

Monte

[Vieira, Luiz C. (Brazil)]

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...

Cheers.

Luiz (Brazil)

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

[Monte Dalrymple]

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

[Ángel Martin]

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??

[Massimo Gnerucci (Italy)]

Quote:

---

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

Greetings,
Massimo

[Monte Dalrymple]

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

[Ángel Martin]

Quote:

---

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 :)

[Raymund Heuvel]

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"!

BR

Raymund

[Ángel Martin]

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...

HTH.