Faster spooling

[Lawrence Woodman]

Hello,

i have just added a -S switch (note the capitalization), which will
spool the file at twice the speed and execute much faster until the
file has been fully spooled. Commit:

https://github.com/LawrenceWoodman/xAce/commit/07bc37bb9519405de3d399d1611badcd18b3849c

Unfortunately, I can't seem to get it to work reliably faster than this
because of the strange way that the refresh is linked to the interrupts
in the emulator. But I have an idea, so we'll see what happens.

For the moment though this should at least speed spooling up.


Lorry

--
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry, CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com

[Marcos Cruz]

En/Je/On 2012-10-08 13:07, Lawrence Woodman escribi� / skribis / wrote :

> i have just added a -S switch (note the capitalization), which will
> spool the file at twice the speed and execute much faster until the
> file has been fully spooled.

It works fine. It's a good improvement. Thank you.

> Unfortunately, I can't seem to get it to work reliably faster than this
> because of the strange way that the refresh is linked to the interrupts
> in the emulator. But I have an idea, so we'll see what happens.

Do you mean the screen refresh done by the emulator?
What about disabling it while spooling?

It would be great if the maximum speed would be limited only by the host
machine.

Marcos

--
http://programandala.net

[Lawrence Woodman]

The problem is with the screen refresh within the emulator or the way
that the routine to load the next byte from the spool file is called
(they are
linked). I did try to turn off the refresh during spooling, but the results
were unreliable, presumably due to some side-effect that I hadn't noticed.

I need to refactor further to get to the bottom of it and will endeavour to
do so.

bfn

[Lawrence Woodman]

On 08/10/12 16:19, Marcos Cruz wrote:

> It would be great if the maximum speed would be limited only by the
> host machine. Marcos

Got it! While in fast spool mode e.g. when using -S I have increased
the interrupt frequency.

This seems to work well, let me know what you think. The commit is at:
https://github.com/LawrenceWoodman/xAce/commit/eddcf035a368a1a008a6922f9c7590a8f836a5f6

This should really speed up cross-development.

[Marcos Cruz]

En/Je/On 2012-10-28 07:29, Lawrence Woodman escribi� / skribis / wrote :

> Got it! While in fast spool mode e.g. when using -S I have
> increased the interrupt frequency.
>
> This seems to work well, let me know what you think.

It works very fast, but I have problems. It seems the input fails. I
tried with my program
<http://programandala.net/en.program.beetle_break_chase>. First I
suspected It had something to do with my definitions of back slash and
'(', but I removed them and all comments from the source, and nothing
changed: Soon a line is not accepted, but the typing goes on and the
input line grows until it fills the whole screen.

I remember I always had a similar problem with file spooling: If I
pressed any key during the process (for example to change the window and
work with other program) the spooling almost sure failed (it seems the
key press corrupted the input) and Ace Forth detected a syntax error but
the automatic typing didn't stop... In order to try this new version I
didn't touch the keyboard, but the effect is the same.

The normal speed spooling of the same file works fine (it takes a long
time!).

By the way, if I press Enter during the spoolings (-s or -S), the
emulators stops. I don't remember this behaviour in previous versions.
Is it intended?

Marcos

[Lawrence Woodman]

On 02/11/12 23:22, Marcos Cruz wrote:
> En/Je/On 2012-10-28 07:29, Lawrence Woodman escribi� / skribis / wrote :
>
>> Got it! While in fast spool mode e.g. when using -S I have
>> increased the interrupt frequency.
>>
>> This seems to work well, let me know what you think.
> It works very fast, but I have problems. It seems the input fails. I
> tried with my program
> <http://programandala.net/en.program.beetle_break_chase>. First I
> suspected It had something to do with my definitions of back slash and
> '(', but I removed them and all comments from the source, and nothing
> changed: Soon a line is not accepted, but the typing goes on and the
> input line grows until it fills the whole screen.

Sorry about that, this and the enter bug below were introduced when I
refactored process_keypress(). I know what that problem is and am
working on a solution, which should be released Sunday/Monday.

> I remember I always had a similar problem with file spooling: If I
> pressed any key during the process (for example to change the window and
> work with other program) the spooling almost sure failed (it seems the
> key press corrupted the input) and Ace Forth detected a syntax error but
> the automatic typing didn't stop... In order to try this new version I
> didn't touch the keyboard, but the effect is the same.

You have given me a good idea. I think I'll turn off the keyboard while
spooling is taking place. This will ensure that normal operation of the
computer won't be effected.

[Lawrence Woodman]

On 02/11/12 23:22, Marcos Cruz wrote:

It works very fast, but I have problems. It seems the input fails. I
tried with my program
<http://programandala.net/en.program.beetle_break_chase>.  First I
suspected It had something to do with my definitions of back slash and
'(', but I removed them and all comments from the source, and nothing
changed: Soon a line is not accepted, but the typing goes on and the
input line grows until it fills the whole screen.

This bug should now be fixed with commit:
https://github.com/LawrenceWoodman/xAce/commit/eb43d77e3834355de1324fc12120a4c84586ded2

I couldn't try it with the link that you provided as it was 404ing, but I am fairly confident that I've got to the bottom of it.  Let me know if not.

Best wishes

[Marcos Cruz]

En/Je/On 2012-11-05 09:17, Lawrence Woodman escribi� / skribis / wrote :

> This bug should now be fixed with commit:

> [2]https://github.com/LawrenceWoodman/xAce/commit/eb43d77e3834355de1324fc12120a4c84586ded2

I downloaded and compiled the package xAce-master.tar-gz, the only one
available now, is it right? I doubted because the name format is
different: the previous one was
LawrenceWoodman-xAce-v0.4.1-24-gee9eb03.tar.gz. Anyway, I see no
difference about spooling.

> I couldn't try it with the link that you provided as it
> was 404ing,

Sorry for that, it was a typo of mine ("brick", not "break"):
http://programandala.net/en.program.beetle_brick_chase

Anyway please find attached the sources I'm using for the testings. Try
them from 00 to 03.

Marcos

[Lawrence Woodman]

On 05/11/12 10:39, Marcos Cruz wrote:
> En/Je/On 2012-11-05 09:17, Lawrence Woodman escribi� / skribis / wrote :
>
> I downloaded and compiled the package xAce-master.tar-gz, the only one
> available now, is it right? I doubted because the name format is
> different: the previous one was
> LawrenceWoodman-xAce-v0.4.1-24-gee9eb03.tar.gz. Anyway, I see no
> difference about spooling.
>

> Sorry for that, it was a typo of mine ("brick", not "break"):
> http://programandala.net/en.program.beetle_brick_chase Anyway please
> find attached the sources I'm using for the testings. Try them from 00
> to 03.

I have just downloaded xAce from github, tried the game and it spooled
in fine. I think you may have been unlucky and downloaded the latest
commit of xAce before github had created a new download for it. So it
should be fine now. The clue is whether or not you have the file
src/keyboard.c

Yours is the longest program that I have spooled in and suddenly fast
mode doesn't seem so fast any more. I'll see about making it even faster.

Neat little game by the way.

[Marcos Cruz]

En/Je/On 2012-11-06 07:11, Lawrence Woodman escribi� / skribis / wrote :

> The clue is whether or not you
> have the file src/keyboard.c

Yes I have it in the last two versions I tried: Some days ago I
downloaded the emulator with the git command; yersterday I downloaded the
master zip.
[A little suggestion: I think it would be useful to show the
release/revision number (or the date/time of the last change, in
"yyyy-mm-ddThh:mm" format) after the version.]

No difference. The slow spooling works fine but the fast one
doesn't.

I see the keyboard is not deactivated yet: typing is possible and the
characters are mixed with the spool file. But I don't touch the
computer during the process, so it's not the cause of the problem.

I attach two screenshots of corrupted spooling.

By the way, I get this warning in the last versions (I don't remember
how long ago),
at the end of the compilation. I think it has nothing to do with the
problem:

----8<----------------------------------------------------------
Scanning dependencies of target tape_test
[ 87%] Building C object tests/CMakeFiles/tape_test.dir/tape_test.
c.o
[100%] Building C object tests/CMakeFiles/tape_test.dir/__/src/tap
e.c.o
Linking C executable tape_test
CMakeFiles/tape_test.dir/tape_test.c.o: In function `test_tape_att
ach_file_doesnt_exist':
tape_test.c:(.text+0x5bc): warning: the use of `tmpnam' is dangero
us, better use `mkstemp'
[100%] Built target tape_test
----8<----------------------------------------------------------

> Yours is the longest program that I have spooled in and suddenly fast
> mode doesn't seem so fast any more. I'll see about making it even
> faster.

Some of my paused projects are even longer... That's why are paused,
until fast spooling works for me [:)].

It seems the problem is not in the Forth code. If it works for you,
maybe the problem hides in the compilation (I'm using Debian armel in a
Pandora). Nevertheless I'll try other Forth programs, better simpler
and shorter; maybe I could find an obscure error condition.

Marcos

--
http://programandala.net

[Lawrence Woodman]

On 11/11/12 14:44, Marcos Cruz wrote:

En/Je/On 2012-11-06 07:11, Lawrence Woodman escribió / skribis / wrote :

yersterday I downloaded the master zip. [A little suggestion: I think it would be useful to show the release/revision number (or the date/time of the last change, in "yyyy-mm-ddThh:mm" format) after the version.]

The master zip is automatically generated from the last commit, so I
have no control over the filename.  The tagged releases are at:
    https://github.com/LawrenceWoodman/xAce/tags

But they are only the historical tagged releases.

By the way, I get this warning in the last versions (I don't remember
how long ago),
at the end of the compilation. I think it has nothing to do with the
problem:

----8<----------------------------------------------------------
Scanning dependencies of target tape_test
[ 87%] Building C object tests/CMakeFiles/tape_test.dir/tape_test.
c.o
[100%] Building C object tests/CMakeFiles/tape_test.dir/__/src/tap
e.c.o
Linking C executable tape_test
CMakeFiles/tape_test.dir/tape_test.c.o: In function `test_tape_att
ach_file_doesnt_exist':
tape_test.c:(.text+0x5bc): warning: the use of `tmpnam' is dangero
us, better use `mkstemp'
[100%] Built target tape_test
----8<----------------------------------------------------------

Thanks.  tmpnam isn't ideal and I will change it to mkstemp.

Yours is the longest program that I have spooled in and suddenly fast
mode doesn't seem so fast any more.  I'll see about making it even
faster.

Some of my paused projects are even longer... That's why are paused,
until fast spooling works for me [:)].

I can really see why you want the fast spooling now.  I do wonder how
some of the longer forth games were written originally.  Presumably with
another machine spooling to the ace through one of the ports at the back.

It seems the problem is not in the Forth code.  If it works for you,
maybe the problem hides in the compilation (I'm using Debian armel in a
Pandora).  Nevertheless I'll try other Forth programs, better simpler
and shorter; maybe I could find an obscure error condition.

I'm sure it's nothing to do with the forth code, but instead I'm guessing that
the interrupt frequency maybe a bit too fast for the Pandora.  Try going into
the src/ directory and run the following. it will slow the interrupt frequency
to 500 interrupts per second.
    sed -i 's/set_itimer(1000)/set_itimer(500)/;s/1000 ints/500 ints/' xmain.c

If that still doesn't work run the following as well after running the previous
command to slow things further:
        sed -i 's/set_itimer(500)/set_itimer(100)/;s/500 ints/100 ints/' xmain.c

If this works, then I will need to work out how to detect if interrupts are being missed
or confused within the emulator.

bfn

[Marcos Cruz]

En/Je/On 2012-11-12 07:33, Lawrence Woodman escribi� / skribis / wrote :
> The master zip is automatically generated from the last
> commit, so I
> have no control over the filename.

I meant the credits shown at the start, not the filename. The version
number is always the same, without mention of the date of the last
change or fix, for example:

xace: Jupiter ACE emulator v0.4.1 (release 2012-11-12) (by Edward Patel)

Anyway it's not important.

> sed -i 's/set_itimer(1000)/set_itimer(500)/;s/1000
> ints/500 ints/' xmain.c

I changed that value. You are right: 500 doesn't work, but 200 does;
300 doesn't; 250 does; 275 doesn't; 270 doesn't; 260 does; 265 doesn't;
263 doesn't; 262 and 261 do work sometimes. The winner is... 260!

> If this works, then I will need to work out how to detect
> if interrupts are being missed
> or confused within the emulator.

It would be helpful. Meanwhile, it is perfectly usable, though the
keyboard is not deactivated yet. In my keyboard-driven environment, in
order to send xAce to the background I have to press the window
manager's key shortcut right when the emulator is interpreting a
comment; otherwise the Forth code gets corrupted. Bringing xAce back to
the foreground is even more adventorous, because I can't see what line
it's interpreting in that moment :)

It's great to see xAce working fine at higher speed.

Thank you.

Marcos

--
http://programandala.net

[Lawrence Woodman]

On 12/11/12 15:21, Marcos Cruz wrote:
> En/Je/On 2012-11-12 07:33, Lawrence Woodman escribi� / skribis / wrote :
>> The master zip is automatically generated from the last
>> commit, so I
>> have no control over the filename.
> I meant the credits shown at the start, not the filename. The version
> number is always the same, without mention of the date of the last
> change or fix, for example:
>
> xace: Jupiter ACE emulator v0.4.1 (release 2012-11-12) (by Edward Patel)
>
> Anyway it's not important.

I see what you mean, when I saw this I thought that would be great if
I could automate it, but alas, although there are automated
solutions to integrate it with git, they're far from ideal.

>> sed -i 's/set_itimer(1000)/set_itimer(500)/;s/1000
>> ints/500 ints/' xmain.c
> I changed that value. You are right: 500 doesn't work, but 200 does;
> 300 doesn't; 250 does; 275 doesn't; 270 doesn't; 260 does; 265 doesn't;
> 263 doesn't; 262 and 261 do work sometimes. The winner is... 260!

Great at least this can be used as a temporary fix.

> though the keyboard is not deactivated yet. In my keyboard-driven environment, in
> order to send xAce to the background I have to press the window
> manager's key shortcut right when the emulator is interpreting a
> comment; otherwise the Forth code gets corrupted. Bringing xAce back to
> the foreground is even more adventorous, because I can't see what line
> it's interpreting in that moment :)

I do understand your pain on this one. From memory, you use
ratpoison don't you? I used to be a big fan of wmii, but unfortunately
because I couldn't find a nice way of switching users, I had to abandon
it as I like to provide easy access to the machine for my wife, who
understandably would prefer a more familiar mouse driven environment
(and no she doesn't have three hands, as the designer of the mouse must
have had). So I will soon implement keyboard disabling during spooling,
which
should make it much easier to use.

[Marcos Cruz]

En/Je/On 2012-11-14 08:32, Lawrence Woodman escribi� / skribis / wrote :

> >xace: Jupiter ACE emulator v0.4.1 (release 2012-11-12) (by Edward Patel)

> I see what you mean, when I saw this I thought that would be great if
> I could automate it, but alas, although there are automated
> solutions to integrate it with git, they're far from ideal.

There's a manual solution, maybe you already considered it:

Keep the date (or release number, or what you prefer --I think ISO date
is easier and more useful) in CMakeLists.txt:

add_definitions(-DSCALE=2 -DWHITE_ON_BLACK -DXACE_VERSION=\"0.4.1\" -DXACE_DATE=\"2012-11-14T10\")

And modify the concerning line in xace.c:

printf("xace: Jupiter ACE emulator v%s (r%s) (by Edward Patel)\n", XACE_VERSION, XACE_DATE);

(I didn't try it.)

Of course the problem is you have to change it every time, what can be
annoying and worthless for small changes in the code.

I ussualy keep several different versions, in case I have problems, and
it's useful to see which one is the last I compiled. But as I said it's
not important.

Marcos

--
http://programandala.net

[Marcos Cruz]

En/Je/On 2012-11-14 08:32, Lawrence Woodman escribi� / skribis / wrote :

> you use
> ratpoison don't you? I used to be a big fan of wmii,

I use Ratpoison, with an internal session of GNU Screen. this lets me
manage both X Window and console apps the same way, just with a
different initial keyboard shortcut.

Long ago I tried many more standard window managers but at the end I
found this solution the most comfortable and productive for me by far.
When sometimes I have to use a windows-menus-panels-buttons-mouse
environment I feel I have to work a lot to do any simple task.

The main Ratpoison shortcut (Ctrl-T in my case) should not be accessible
by the foreground application, but intercepted by the window manager.
My key combination to exchange the foreground app and the more recent
app is "Ctrl-T T". The interesting thing about xAce is that sometimes
it is affected by those keypresses and the spool gets corrupted. I don't
know why. It never happened to me with any other program.

Ratpoison can divide the screen in frames, so different programs can be
seen at the same time. But bringing any app to the foreground is easy
and fast, and for me there's no need to see two or more programs at the
same time, so I never use frames. But in order to work with xAce I
could divide the screen in two frames and show xAce in one of them
alone; this way no keypress would affect it. That would let me know when
the spooling is finished. But the little screen of the Pandora makes it
unpractical.

> my wife, who understandably would prefer a more familiar mouse driven
> environment (and no she doesn't have three hands, as the designer of
> the mouse must have had)

Three hands --with rubber wrists; and an elastic spine as well... :)

> So I will soon implement keyboard disabling during spooling, which
> should make it much easier to use.

Thank you in advance. No hurry.

Marcos

[Lawrence Woodman]

On 14/11/12 10:21, Marcos Cruz wrote:
> En/Je/On 2012-11-14 08:32, Lawrence Woodman escribi� / skribis / wrote :
>
>
> The main Ratpoison shortcut (Ctrl-T in my case) should not be accessible
> by the foreground application, but intercepted by the window manager.
> My key combination to exchange the foreground app and the more recent
> app is "Ctrl-T T". The interesting thing about xAce is that sometimes
> it is affected by those keypresses and the spool gets corrupted. I don't
> know why. It never happened to me with any other program.

I have just made a couple of commits to ensure that the host keyboard
is ignored during spooling and that keys pressed while CTRL is held-down
are never passed to the Ace. This should make it much more comfortable
to use in keyboard driven environments.


https://github.com/LawrenceWoodman/xAce/commit/0c626ea2b255e25405632c667e89a605e1a33a89

[Marcos Cruz]

En/Je/On 2012-11-27 16:08, Lawrence Woodman escribi� / skribis / wrote :

> the host keyboard is ignored during spooling and that keys pressed
> while CTRL is held-down are never passed to the Ace.

It works great, now the spooling seems invulnerable :-)

Thank you!

Marcos

--
http://programandala.net