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

Thanks,
Monte

Have a look here, Monte.

Greetings,
Massimo

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)

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

Hi, Monte;

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

Luiz (drifting out of Space...)

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

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

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.

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.

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

Quote:

---

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

---

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

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