▼
Posts: 297
Threads: 25
Joined: Nov 2006
Is there any way to disable the "goose" during program execution?
It's a waste of time...
Thanks,
Monte
▼
Posts: 882
Threads: 23
Joined: Jan 2005
Have a look here, Monte.
Greetings, Massimo
▼
Posts: 297
Threads: 25
Joined: Nov 2006
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
Posts: 4,027
Threads: 172
Joined: Aug 2005
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)
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, Monte;
I thought you were trying to change the OS for your Newt experiment...
Luiz (drifting out of Space...)
▼
Posts: 297
Threads: 25
Joined: Nov 2006
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
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
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.
▼
Posts: 297
Threads: 25
Joined: Nov 2006
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
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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??
▼
Posts: 882
Threads: 23
Joined: Jan 2005
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
Posts: 297
Threads: 25
Joined: Nov 2006
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
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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 :)
Posts: 55
Threads: 9
Joined: Apr 2008
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
Posts: 1,253
Threads: 117
Joined: Nov 2005
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.
|