Jump to content
IGNORED

Hyper E:


Recommended Posts

I've used both a lot, and they seem to perform equally as well.

 

The Hyper E:  im thinking of was written by Doug Wokoun, have to check but I recall it was dated somewhere 89-91. It was a regular in my disk based SpartaDOS startup.bat's. I always liked how it consistently scrolled one line at a time, where the native OS one would scroll 3 lines at a time...

 

I recall the documentation also described it could be patched into the OS rom, maybe in the international charset range.

 

Stephen J Carden's "TurBoss O/S" includes an an acellerated E: handler so all programs benefit out of the box. I havent tried it, so im not sure if it is, or is based on, Doug Wokoun's replacement handler.

 

http://www.realdos.net/prodturboss.html

Link to comment
Share on other sites

Hi Larry!

2 hours ago, Larry said:

Hyper E: is a screen speed-up utility from (IIRC) Analog magazine.  Are there others, perhaps even better?  I'm thinking there was at least one other, but don't remember what it was.

I have another very small accelerator, only 169 bytes resident at MEMLO, that I developed based on HYP.COM by Doug Wokoun and John Harris; I wrote it thinking on integrating to the FastBasic IDE, so it should be as small as possible.

 

Source is in https://github.com/dmsc/e-accelerator , binary attached. Github says that I should write a README...

 

efast.com

  • Like 7
  • Thanks 1
Link to comment
Share on other sites

Haven't looked at any of the source code for these.  What's the basic premise for the speedup?  Is it something like using LMS for fast scrolling, or a general speedup of "putting" all characters to the screen?

Link to comment
Share on other sites

Hi!

4 hours ago, Stephen said:

Haven't looked at any of the source code for these.  What's the basic premise for the speedup?  Is it something like using LMS for fast scrolling, or a general speedup of "putting" all characters to the screen?

At least my code (optimized for size) only accelerates normal character output, the code is:

- If not GR.0, skip to OS handler;

- If current column is on right margin, skip to OS handler;

- If character to write is a control character (cursor movement, tab, delete, clear, bell, ESC or EOL), skip to OS handler;

- If position has changed, calculate new screen pointer, then write character to screen and increment pointer and column.

 

As you see, scrolling and clearing are not accelerated at all.

 

  • Like 3
Link to comment
Share on other sites

Thanks for the info and especially including the version written by dmsc!  I haven't looked into it yet, but definitely will.

 

This has become a quest for me to find the screen accelerator article that I think I remember.  Does anyone else remember it?  My recollection is that it was from a mid-80's issue.  I've searched through my Analog PDF files, and so far -- nothing.  Maybe a "false memory?"  Anyone else remember the article -- maybe in another mag?  I did find the "README" docs from John Harris for HyperE, but what I remember was a full-blown article with type-in code, etc.

 

BTW, I discovered that Adobe Reader DC (free version) can search for text in multiple PDF files in a folder.  That's handy!  Probably many folks already knew that, but it was new to me, and perhaps might be to a few others, also.

 

-Larry

Link to comment
Share on other sites

21 hours ago, dmsc said:

Hi Larry!

I have another very small accelerator, only 169 bytes resident at MEMLO, that I developed based on HYP.COM by Doug Wokoun and John Harris; I wrote it thinking on integrating to the FastBasic IDE, so it should be as small as possible.

 

Source is in https://github.com/dmsc/e-accelerator , binary attached. Github says that I should write a README...

 

efast.com 383 B · 7 downloads

This is cool! I tried it with Dos 2.5 and the menu drawing is noticeably faster. However, it seems to lock up whenever I try to perform a directory listing (pressing "A" and "Return"). Is that a known issue?

Link to comment
Share on other sites

Hi!

7 hours ago, Xuel said:

This is cool! I tried it with Dos 2.5 and the menu drawing is noticeably faster. However, it seems to lock up whenever I try to perform a directory listing (pressing "A" and "Return"). Is that a known issue?

No, and I could not reproduce it :(

Attached is an DOS25 image with "EFAST.COM" and a little "HELLO.BAS" program that I used for testing.

 

But I discovered another problem - EFAST reinstall itself after a RESET, but not if you press RESET twice.... I would investigate that.

 

Have Fun!

Link to comment
Share on other sites

1 hour ago, dmsc said:

Hi!

No, and I could not reproduce it :(

It seems to happen when there is extended memory (i.e. 128K or more) and RAMDISK.COM is active. It works fine when there is only 64K. I'm attaching the ATR I'm using. Dos 2.5.atr

 

1 hour ago, dmsc said:

Attached is an DOS25 image with "EFAST.COM" and a little "HELLO.BAS" program that I used for testing.

I don't see an attachment on your message.

  • Like 1
Link to comment
Share on other sites

Hi!

40 minutes ago, Xuel said:

It seems to happen when there is extended memory (i.e. 128K or more) and RAMDISK.COM is active. It works fine when there is only 64K. I'm attaching the ATR I'm using. Dos 2.5.atr

 

I don't see an attachment on your message.

Mmmm, I was sure I attached it before.... well, try 2 :)

 

In the mean time, I discovered why the handler is removed at reset: DOS 2.5 rewrites DOSINI when you run programs or cartridge :? ... I suspect the problem with the ramdisk is similar, will investigate.

dos25.atr

Link to comment
Share on other sites

55 minutes ago, Xuel said:

It seems to happen when there is extended memory (i.e. 128K or more) and RAMDISK.COM is active. It works fine when there is only 64K. I'm attaching the ATR I'm using. Dos 2.5.atr

 

I don't see an attachment on your message.

It also crashes after loading handler and then trying to exit DOS to BASIC (extended memory modes).

Link to comment
Share on other sites

Hi!

47 minutes ago, Stephen said:

It also crashes after loading handler and then trying to exit DOS to BASIC (extended memory modes).

So, I officially don't like DOS2.5 anymore :P

 

It seems that the RAMDISK driver in DOS2.5 overwrites some part of the handler, don't know why yet. Without loading RAMDISK it seems to work ok. In the meantime, you can use BWDOS, SpartaDOS or MyDOS :)

 

Note that the handler could be made smaller (20 bytes less) by removing the "reset protection", fo DOS 2.5 I think it is better, as it does not work reliably.

 

Attached a MyDOS ATR with the handler and a little BASIC demo.

mydos.atr

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

I dug through my BBS file areas to find my original ARC file of Hyper E:. The date is Oct 17, 1993, and according to the documentation it is indeed modified by John Harris, which must be the reason of the "JH" in the version number. File timestamp I downloaded it was Jul 17, 1994.


HyperEv1_3JH.thumb.jpg.2e4a0d6a94845ed8d6726b2fc432c128.jpg

 

Here is the documentation, and below is the original ARC, and a converted ZIP. It does also include the OS ROM patch I remembered reading about. Unfortunately, not much deatil about HOW it accelerates the screen...

The Hyper E: accelerator will double
your screen display speed, while taking
up only 140 bytes or so of low memory.
If you are using a DOS other than
SpartaDOS, it will take up an addtional
30 bytes, but that's still a pretty
small amount.

The Hyper E: accelerator was originally
written byDoug Wokoun.  I found some
compatability problems with it, and
have released modified versions.

There are three versions of the Hyper
E: screen accelerator in this archive.

HYP.COM is the normal version.

HYPS.COM includes a routine to set the
screen color to a user defined value
any time the E: device is opened.  The
color values are preset to $82 and $0C
intensity, and the only way to change
them right now is with a disk file
editor.  The change is almost at the
end of the file, and will start with
the bytes, $A9,$82,$8D,$C6,$02.

Finally, for the hackers out there, I
included version HYP.ROM that can be
burned directly into the OS ROM.  There
are a few advantages to this.  It won't
take up any memory.  It will accelerate
any programs that use the $E400 vectors
directly, and there are alot of those.
RAM loaded versions will only speed up
programs that use CIO though E:.
Installation of the ROM version will be
described at the end of this file.

Use of HYP.COM and HYPS.COM is as
simple as loading the program.  Hyper E
is relocatable, and will position
itself right above MEMLO.  When it
installs, it will check to see if the
E: handler has already been patched, as
is the case with SpartaDOS, and if so
it will install into the patched
handler.  This allows Hyper E: to
remain compatable with Sparta's I/O
redirection abilities.  If no patched
handler is found, Hyper E: will create
it's own, along with a DOSINI routine
to reinstall it after a system reset.

It is possible that Hyper E: may find a
patched handler, but be unable to
integrate itself into it.  If this
happens, Hyper E: will display the
message, "Can't Install", and you will
be unable to use the program.  Please
contact me if you see this message, let
me know what is running in your system,
and I will try to adapt Hyper E:.

- ROM version install-

The HYP.ROM file is 128 bytes long, and
is designed to execute as the start of
the OS's E: PUT routine.  You will need
to know the location of this routine in
your particular ROM, as well as a free
128 byte area.  In my130XE ROM, the E:
PUT routine is at $F2B0, and there is
an unused space at $CB65.  This is
where the supplied file is set to work,
but itcaneasily be changed to other
locations.

The first step is to copy the ROM image
to someplace in RAM, and then find 128
bytes of space that you can use.  You
can try searching fora long string of
0's.  The HYP.ROM file has a load
address of$4B65.  Ifyou have moved
the ROM down to $4000, and have free
space at $CB65/$4B65,you may simply
load the binary file HYP.ROM.
Otherwise,use whatever method you are
comfortable with to place the contents
of theHYP.ROM file into your empty
space area.  The codeis relocatable,
so youdo not have toworry about
movingit.

Next, the existing PUT routine needs to
be changedto jump tothis new code.
Right now,the first instruction of the
PUT shouldbe "STA $2FB".  This needs
to be changed to a JMP to the new code
we just loaded.  The first instruction
of HYP.ROMis "STA $2FB", so that will
take the place of theexisting one that
you are about to overwrite.  The byte
valuesyouwant to store, are $4C, then
the low byte of HYP.ROM, and then the
high byte. In my example, these bytes
would be $4C, $65, $CB.  (Make sure you
use the upper ROM address like '$CB',
and not the '$4B' temporary RAM
address!)

The final step is a JMP instrustion
back to the OS ROM.  The JMP is located
in theHYP.ROM code, $26 bytes from the
beginning. In our example, that would
be location $4B8B.  This JMP needs to
point to the location*after* the
original "STA $2FB" in the OS PUT
routine --the one you replaced with a
JMP intheprevious step.  In other
words,this location will be the
original PUT address +3.  In the
HYP.ROM file supplied, this JMP is set
to $F2B3.If this isthe right place,
leave it alone.  Otherwise, change the
address topoint to the correct spot.

You shouldbe able tosave the binary
image of the ROM filenow, and burn a
27256 EPROM.

If youhaeany questions or comments,
pleasefeel free to contact me.

John Harris
GEnie:J.HARRIS32
Internet: jharris@cup.portal.com

 

hyp.arc hyp.zip

  • Like 3
Link to comment
Share on other sites

It may take awhile, but I still intend to find that article that I originally mentioned.  I've got it on "my to-do list!"

 

BTW, if perchance you are not familiar with John Harris, he was a terrific Atari game programmer in the early days as well as MAE later.  Here is a relatively brief and incomplete description in Wikipedia:

 

https://en.wikipedia.org/wiki/John_Harris_(software_developer)

 

I may be dreaming this, but I seem to remember that he popped up here at AA once or twice. (?)  I met him at the World of Atari show in 1998 at Las Vegas.

 

-Larry

  • Like 2
Link to comment
Share on other sites

Hi!

10 hours ago, Nezgar said:

I dug through my BBS file areas to find my original ARC file of Hyper E:. The date is Oct 17, 1993, and according to the documentation it is indeed modified by John Harris, which must be the reason of the "JH" in the version number. File timestamp I downloaded it was Jul 17, 1994.

 

 

Here is the documentation, and below is the original ARC, and a converted ZIP. It does also include the OS ROM patch I remembered reading about. Unfortunately, not much deatil about HOW it accelerates the screen...

 

It is about the same as my own accelerator, as I based mine on that idea. I have a disassembled source if you are interested.

 

Have Fun!

 

 

Link to comment
Share on other sites

Well, the first test of Fast Print did not go too well.  I was printing a list of movie titles using a Basic XE program to list and sort them, and about half way through the list, the screen display started going berzerk.  No issue when using the standard E: display.  Could be lots of things, but seems not too robust.

Link to comment
Share on other sites

On ‎7‎/‎28‎/‎2019 at 2:31 PM, Larry said:

Edit:  Here is the Analog ATR with the Fast Print .M65 and .OBJ files on it.

It seems that you could modify the .M65 source to help it out.  I really do not like the press any key message at screen full it should be continuous streaming until end is reached.  Otherwise why call it FASTPRINT if it stops every screen full.

 

Link to comment
Share on other sites

Hi!

2 hours ago, Larry said:

Well, the first test of Fast Print did not go too well.  I was printing a list of movie titles using a Basic XE program to list and sort them, and about half way through the list, the screen display started going berzerk.  No issue when using the standard E: display.  Could be lots of things, but seems not too robust.

The "Fast Print" shares a lot of code with that of Hyper-E:, and use the same approach that my own accelerator.

 

Problem with the Analog code is that it resides in page-6, so any INPUT of more than 127 bytes will override the handler (this happens with any code at the start of page-6), or any other ML routine that uses the same address. This is why Hyper-E: (and also my EFAST accelerator) install at MEMLO, dynamically adjusting the code to the location. But, this is a problem with DOS 2.5, as DUP loads itself over MEMLO also!!

 

I could code three versions of my EFAST, to be compatible with most DOS:

 

- A version for BW-DOS, SpartaDOS and other DOS with integrated DUP, that installs over MEMLO and protects from RESET;

- A version for DOS-2 and DOS-2.5, that installs over MEMLO but de-installs itself when you call DUP (i.e., with "DOS" command from BASIC).

- A version for MyDOS, installs over MEMLO and does not protect from RESET.

 

Perhaps it could detect DOS version and install the proper handler depending on that...

 

Have Fun!

 

  • Like 1
Link to comment
Share on other sites

Do any of these accelerators actually handle all the Atascii key codes ? The few I've used generally only print the next character on the line, and punt to the OS for anything else, like EOL or cursor movement or clear screen.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...