+Larry Posted July 22, 2019 Share Posted July 22, 2019 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. -Larry Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 22, 2019 Share Posted July 22, 2019 SpartaDOS X has QUICKED.SYS. Not sure if that's any good to you. 1 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted July 22, 2019 Share Posted July 22, 2019 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 Quote Link to comment Share on other sites More sharing options...
dmsc Posted July 22, 2019 Share Posted July 22, 2019 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 7 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 22, 2019 Share Posted July 22, 2019 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? Quote Link to comment Share on other sites More sharing options...
dmsc Posted July 23, 2019 Share Posted July 23, 2019 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. 3 Quote Link to comment Share on other sites More sharing options...
+Larry Posted July 23, 2019 Author Share Posted July 23, 2019 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 Quote Link to comment Share on other sites More sharing options...
Xuel Posted July 23, 2019 Share Posted July 23, 2019 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? Quote Link to comment Share on other sites More sharing options...
dmsc Posted July 24, 2019 Share Posted July 24, 2019 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! Quote Link to comment Share on other sites More sharing options...
Xuel Posted July 24, 2019 Share Posted July 24, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted July 24, 2019 Share Posted July 24, 2019 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 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 24, 2019 Share Posted July 24, 2019 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). Quote Link to comment Share on other sites More sharing options...
dmsc Posted July 24, 2019 Share Posted July 24, 2019 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 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 3 1 Quote Link to comment Share on other sites More sharing options...
+Larry Posted July 24, 2019 Author Share Posted July 24, 2019 MyDos -- now you're talking! ? -Larry 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 25, 2019 Share Posted July 25, 2019 MyDOS: The best Atari DOS besides the "Sparta" types! ? Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted July 28, 2019 Share Posted July 28, 2019 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... 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 3 Quote Link to comment Share on other sites More sharing options...
+Larry Posted July 28, 2019 Author Share Posted July 28, 2019 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 2 Quote Link to comment Share on other sites More sharing options...
dmsc Posted July 28, 2019 Share Posted July 28, 2019 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! Quote Link to comment Share on other sites More sharing options...
+Larry Posted July 28, 2019 Author Share Posted July 28, 2019 Found it! Fast Print by Bill Bodenstein Analog Computing June, 1988 -Larry Fast Print from Analog Computing.pdf 5 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 28, 2019 Share Posted July 28, 2019 (edited) hmm typing it in doesn't seem like it would be too bad if you skip all the remarks etc... Edited July 28, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
+Larry Posted July 28, 2019 Author Share Posted July 28, 2019 I'll look through my Analog ATRs -- surely it's there. Edit: Here is the Analog ATR with the Fast Print .M65 and .OBJ files on it. 88_JUN.ATR Quote Link to comment Share on other sites More sharing options...
+Larry Posted July 30, 2019 Author Share Posted July 30, 2019 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. Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted July 30, 2019 Share Posted July 30, 2019 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. Quote Link to comment Share on other sites More sharing options...
dmsc Posted July 30, 2019 Share Posted July 30, 2019 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! 1 Quote Link to comment Share on other sites More sharing options...
Alfred Posted July 30, 2019 Share Posted July 30, 2019 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.