XEP80-II a new beginning

[+Eyvind Bernhardsen]

A quick test, if there’s room on the ATR, would be to copy autorun.sys to ap.obj so that both files are available (if there’s no room you could copy everything to a bigger image). If that works it’s a simple matter of programming to write a small autorun.sys that loads and runs ap.obj.

[_The Doctor__]

5 hours ago, Eyvind Bernhardsen said:

A quick test, if there’s room on the ATR, would be to copy autorun.sys to ap.obj so that both files are available (if there’s no room you could copy everything to a bigger image). If that works it’s a simple matter of programming to write a small autorun.sys that loads and runs ap.obj.

sounds like a way of doing it, in that way, if either filename is hard coded or just one or the other it should get what it needs, since both ap.obj is there and autorun.sys would be there too, even if a person or program did a quick and dirty reset... it should load back up...

There was an issue with HSIO years back where every other drive would do directories and high speed, and the other would not. I hope there isn't a regression of some kind. I hit that wall back in the MyIDE infancy days. Vaguely remember it happening with the flashdisk (atarimax car emulates storage drives). I believe it was fixed at some point. No harm in killing HSIO in the OS to find out.

Edited August 28, 2021 by _The Doctor__

[+mytek]

Ok so here's where I am thus far with this AtariWriter 80 stuff.

 

I changed all the hard coded entries from AP.OBJ to *1.SYS which matches the original string length, and things began working for the most part. And now for a little background as to why I made that specific change. I have modified the DOS 2.5 to now be a Multi-AUTORUN version. Here's the run sequence in the order that it occurs.

• AUTORUN.SYS = my very tiny XEP80-II toggle program which when run, checks if the video switch on my board is set to 80 columns already, if not, then this program toggles it to be in 80 column mode (selects XEP80 video output as source for AV-to-HDMI converter.
• AUTORUN1.SYS = former AP.OBJ file, and is the actual AtariWriter 80 program.

So by re-coding the return to *1.SYS will point it to the AUTORUN1.SYS file and execute the AW80 program. This was done in 3 files: AUTORUN.ORG, MM.OBJ, PROOF where I found references to AP.OBJ

 

Here's the 130XE version file with all these changes (requires =>128K RAM and an XEP80): AW80XE XEP80-II.atr

 

What Still Doesn't Work?

 

The return from the spell checker attempts to reload the AW80 program but locks-up a few seconds into the load.

 

What Does Work?

 

Everything else as far as I can tell. I can run the mail merge program, and I can exit back to the AW80 program no problem. Both disk directory 1 and 2 work just fine, loading and saving work just fine.

 

Perhaps someone can check out this ATR and see if there is an explanation for why the exit from the PROOF program hangs.

 

Edited August 29, 2021 by mytek

[Mathy]

Hello Michael

 

MyDOS at some point copied the autorun methode I guess SmartDOS was using.  It uses FILENAME.AR0 for the first file that needs to be run automatically, FILENAME.AR1 for the second, etc.

 

Wouldn't that be a more compatible way, instead of creating yet another methode of autorunning multiple files?

 

Or, if that's not your thing, you could make your own "very tiny XEP80-II toggle program" autoload the AP.OBJ file.  That should work with all DOSses without modification (to those DOSses).

 

Sincerely

 

Mathy

 

Edited August 29, 2021 by Mathy

[+mytek]

2 hours ago, Mathy said:

MyDOS at some point copied the autorun methode I guess SmartDOS was using.  It uses FILENAME.AR0 for the first file that needs to be run automatically, FILENAME.AR1 for the second, etc.

 

Wouldn't that be a more compatible way, instead of creating yet another methode of autorunning multiple files?

I could certainly do that in the final form (and probably will), but first I need it to work properly in all regards with the present method, since I will presume with MyDOS the end result would still be the same. The problems I see (and attempting to fix) with using AW80, appear to be present when also booting from the unmodified versions in the original ATR downloads.

 

If these failures with either the original or 'working' versions of AW80 are due to booting from non-floppy media and/or from a HSIO patched OS, is unimportant to me, because that is the environment I want it to work within. And I'm very close to doing that, with the only exception being the return from the spell checker locking up, which is what I am seeking an answer to.

 

2 hours ago, Mathy said:

Or, if that's not your thing, you could make your own "very tiny XEP80-II toggle program" autoload the AP.OBJ file.

I don't think that would solve the problem, per what I have already stated.

 

[+mytek]

2 hours ago, Mathy said:

you could make your own "very tiny XEP80-II toggle program" autoload the AP.OBJ file.  That should work with all DOSses without modification (to those DOSses).

Just an additional observation... from what I have seen AW80 seems to be standard Atari DOS fixated, so it's unlikely that it would successfully do a directory listing from something other than that.

 

It would also mean having to maintain a specific version of my toggle program for AW80, and then having something else for other implementations.

 

Edited August 29, 2021 by mytek

[_The Doctor__]

as stated there is a SpartaDOS compatible fix/ hack of AtariWriter that the users group passed around that took AtariWriter out of that realm, it handled directories et al just fine. Maybe it would be dug up, looked at, and used to help in your quest.

Edited August 29, 2021 by _The Doctor__

[+mytek]

8 minutes ago, _The Doctor__ said:

as stated there is a SpartaDOS compatible fix/ hack of AtariWriter that the users group passed around that took AtariWriter out of that realm, it handled directories et al just fine. Maybe it would be dug up, looked at, and used to help in your quest.

Yes that might be a good option to look at, assuming it can still work in a non-SpartaDOS environment. Anyone have download link?

 

[Goochman]

For the Spellchecker issue - is it trying to find AP.OBJ which no longer exists on the disk?

[ivop]

1 hour ago, Goochman said:

For the Spellchecker issue - is it trying to find AP.OBJ which no longer exists on the disk?

Or perhaps there's a difference in RUN or INIT address at the end of the file that's (re)loaded through finding *1.SYS? Or it doesn't find the right file when the wildcard is filled in?

 

Edit: why does it reload the driver again after exiting the program?

Edited August 29, 2021 by ivop

[+mytek]

1 hour ago, Goochman said:

For the Spellchecker issue - is it trying to find AP.OBJ which no longer exists on the disk?

Well it shouldn't be after my modification of what file it should be loading from. And as far as I can tell, it is initially attempting to load the renamed file AUTORUN1.SYS (or some file, because I hear the load beeps for a bit).

 

13 minutes ago, ivop said:

Or perhaps there's a difference in RUN or INIT address at the end of the file that's (re)loaded through finding *1.SYS? Or it doesn't find the right file when the wildcard is filled in?

All good questions, but I don't have an answer myself, hence the reason I provided the ATR so that someone more in the know might be able to provide that answer. It's interesting in the fact that when I applied the same solution to the MM.OBJ file it worked, only the PROOF doesn't.

 

I should go back to the original AW80 file which has the directory #1 issue and see if it can return properly from the spell checker program. If it does, then maybe there is a way to get the directory aspect fixed instead.

 

BTW, the ATR file I provided should still work fine with an original Atari built XEP80. It'll just ignore the XEP80-II toggle feature which is manipulating extra normally unused bits on joystick #2 - oh yeah I forgot to mention earlier that you need to be plugged into joystick #2 for that aspect to work anyway. Kind of a moot point since I'm the only one in the universe that has a working XEP80-II

 

Edited August 29, 2021 by mytek

[+mytek]

21 minutes ago, ivop said:

Edit: why does it reload the driver again after exiting the program?

Opps missed this question. It reloads the AtariWriter program because the Mail Merge or the Spell Checker are independent programs that when loaded, wipe out the AW80 program. Hence when wanting to return from those auxiliary programs you need to reload the one you exited from.

 

Edited August 29, 2021 by mytek

[Mathy]

Hello Michael

 

7 minutes ago, mytek said:

Kind of a moot point since I'm the only one in the universe that has a working XEP80-II

 

At the moment, yes.  But somebody with an interest in your XEP80-II might be reading this in a couple of years.  And he or she (or it) might be glad to find that information here.

 

Sincerely

 

Mathy

 

[+mytek]

3 minutes ago, Mathy said:

At the moment, yes.  But somebody with an interest in your XEP80-II might be reading this in a couple of years.  And he or she (or it) might be glad to find that information here.

Yes so true.

 

Getting back to why I'm trying so hard to get fully functional AW80 programs working with and exploiting special features of my new XEP80 version, is that my intention is to provide these as turn-key downloads from my website when I also release the design files. Always nice to have something ready to go, and proven to work to see if all is well with the product. But I'm not going to try and provide for every possible scenario imaginable, and will leave it up to others to fine tune or embellish this in whatever way they see fit to suit their needs. In the words of Clint Eastwood "A man's got to know his limitations".

 

[+mytek]

Time for another update...

 

Putting the AtariWriter 80 software issues aside for the moment, I discovered something interesting that appears to be at the root of another issue hardware-wise that I was seeing. There is a reset pin on the NS405 Display Processor that in the Atari implementation of the XEP80 they placed a 1uf capacitor to ground. Apparently there is an internal pull-up resistor that in combination with the capacitor gives you a power-up reset as it charges up (initially held low at a reset condition, and then releasing soon after). However when I looked at the NSD405 datasheet, they also showed a diode connected between the reset pin and +5V, with it's purpose to drain the capacitor quickly when the circuit gets powered down, thus being ready for the next power up cycle.

 

 

,

 

This corresponded with an issue I had been seeing when using my 576NUC+ as the computer driving my XEP80-II, where sometimes things would be a bit strange after re-booting, as if some parts of memory hadn't been properly cleared or initialized. So I added the diode, which really did the trick. Now all appears to be well when using my 576NUC+ with this board.

 

So the reason why the 576NUC+ made this issue more apparent, has to do with how it differs from a conventional Atari in regards to power control and slot selection. In the NUC+ power control is being handled via the TK-II variant onboard which directly turns power ON or OFF going to the logic circuits via keyboard control, and also powers down 'briefly' when changing slot assignments in order to re-boot in the new configuration. This re-boot process is very short in duration, and only long enough to effectively look like a cold restart. It's because of its brevity that the XEP80's power-up reset capacitor wasn't discharging much without the diode in place - it simply wasn't powered off long enough to allow the capacitor to fully discharge without the diode.

 

Along with the diode, I also added the pull-up resistor back in for the RXD circuit, which gave me an even better looking signal in combination with the schmitt trigger logic I previously added. So now I think I am truly at a final version with the hardware, and feel confident enough to also release the newest schematic.

 

 

Schematic: XEP80-II_V1.1_schema.pdf

 

I'll probably press the trigger on ordering more sample boards next week.

 

BTW, although I would normally have written this as a blog post in my website, that has been put on hold as I have been actively revamping my site behind the scenes getting ready for releasing the designs for the 576NUC+, XEP80-II, and a new MIDI board this coming Fall. Because I'm not sure if adding a blog post will trigger a re-publish of the site, I will hold off until such time that everything is completely ready.

 

[+mytek]

Now getting back to my work on tailoring a specific XEP80-II AtariWriter 80 disk.

 

I believe that the suggestion of appending my toggle program and the main Atari program together, and then replacing that on the original AW80 disk will likely make things completely functional without any other alterations. So that leads me back to this posting about 3 pages back about a StreamLiner utility that can aid in creating this.

On 8/11/2021 at 10:10 PM, Nezgar said:

This "hack" results in the standard 2-byte "FFFF" header for executable showing up mid-file, which is supported, but utilities like StreamLiner can remove them extra bytes. Or use a hex editor of your choice to do it. There might be some other quirks like making sure the first segment has an init address not just run, etc...

Does anyone have more info on this program, and/or a download link?

 

[_The Doctor__]

ANALOG computing had a program called "The Streamliner" which would take binary files made up of a series of blocks and convert them to a single block. Hope that helps.

 

https://www.atarimagazines.com/analog/issue59/reader_comment-1.php

Edited August 31, 2021 by _The Doctor__
added link

[+Nezgar]

21 minutes ago, mytek said:

Does anyone have more info on this program, and/or a download link?

The Streamliner by James Hague, ANALOG #56 page 33:

https://archive.org/details/analog-computing-magazine-56/page/n33/mode/2up

 

Attached is my copy...

 

Edit: Also, another useful utility is Super Packer, also attached. lets you compress individual segments, maybe re-save "optimized" (remove FFFF between segments) without packing too - can't remember.

streamln.xex superpck.xex

[_The Doctor__]

is that with the fix from issue 59?

 

---snip---

Streamlining Streamliner.

    I recently discovered a minor bug in my "Streamliner" program, in issue 56 of ANALOG Computing. Specifically, if you try to Streamline a file that won't fit in memory, the program kind of, uh, dies. The logic to handle this is already in the program, but a dumb mistake on my part causes it not to work. To fix it, place a disk with an unlocked copy of D:STRLINER.OBJ in drive 1 and carefully type in and run the following:

  10 REM STREAMLINER V1.0 PATCH
  20 REM by James Hague
  30 OPEN #1,12,0,"D:STRLINER.OBJ"
  40 FOR A=1 TO 908:GET #1,B:NEXT A
  50 PUT #1,160: CLOSE #1

    When you see the READY prompt, the bug will have been corrected. To change the assembly language source code to reflect this fix (not necessary, unless you want to fool with the assembly version), change the LDY $FF in the PUTBUF routine (page 39) to LDY #$FF. Assembly programmers will recognize my mistake right away-I wish I had, sooner.
    James Hague
    Richardson, TX

---snip--

 

I posted the link to this so no matter if you look a the back issue or are provided it from any other source, you'd know to check or patch them

Edited August 31, 2021 by _The Doctor__

[Brentarian]

3 minutes ago, _The Doctor__ said:

is that with the fix from issue 59?

 

---snip---

Streamlining Streamliner.

    I recently discovered a minor bug in my "Streamliner" program, in issue 56 of ANALOG Computing. Specifically, if you try to Streamline a file that won't fit in memory, the program kind of, uh, dies. The logic to handle this is already in the program, but a dumb mistake on my part causes it not to work. To fix it, place a disk with an unlocked copy of D:STRLINER.OBJ in drive 1 and carefully type in and run the following:

  10 REM STREAMLINER V1.0 PATCH
  20 REM by James Hague
  30 OPEN #1,12,0,"D:STRLINER.OBJ"
  40 FOR A=1 TO 908:GET #1,B:NEXT A
  50 PUT #1,160: CLOSE #1

    When you see the READY prompt, the bug will have been corrected. To change the assembly language source code to reflect this fix (not necessary, unless you want to fool with the assembly version), change the LDY $FF in the PUTBUF routine (page 39) to LDY #$FF. Assembly programmers will recognize my mistake right away-I wish I had, sooner.
    James Hague
    Richardson, TX

---snip--

 

I posted the link to this so no matter if you look a the back issue or are provided it from any other source, you'd know to check or patch them

I remember typing that program in using DATA statements in Analog mag.  Anyway, I downloaded that Analog disk and ran the patch on the strliner file.  Attached is the fixed copy.STRLINER.OBJ

[+Nezgar]

20 minutes ago, _The Doctor__ said:

is that with the fix from issue 59?

Good Q, not sure -- looking in a hex editor offset 908 decimal is A4 (LDY Zero Page)... the above patch replaces it with 160, or A0 (LDY Immediate) , which seems right according to above?

 

There I patched it, I also patched it to say "V1.1" instead of "V1.0" ?

Hopefully I did it right!

streamln11.xex

[Roydea6]

1 hour ago, Nezgar said:

There I patched it, I also patched it to say "V1.1" instead of "V1.0"

Could this program be patched so other drives can be used also.  Preferably for just "D:" so spartados can use it.

 

[+Nezgar]

44 minutes ago, Roydea6 said:

Could this program be patched so other drives can be used also.  Preferably for just "D:" so spartados can use it.

Hehe, I've thought the same thing over the years.... but it does work in SpartaDOS... as long as your file is on D1:

 

Edit: Looks like the three bytes that spell "D1:" are at 0x0347-00349 and maybe easy to change it to a different drive # , ie D2:, but it has to be three bytes. D:<00> puts a heart after.... and same if I shift the preceding RTS forward a byte with a NOP... Time to look at the source code...

[+Nezgar]

I think i got it - with the help of the source in the ANALOG article, and Omnivore disassembly:

 

*= $252c
LDX #$02 ; read three bytes - changed to #$01 to only read 2 bytes
STX MEMTOP
L2530   LDA D1,X

 

Then down in the 3 bytes "D1:"

        *= $25e1
D1   .byte $44, $31, $3a

 

Changed it to

D1   .byte $44, $3a, $00

 

but it only reads the 1st 2 of those 3 bytes, resulting in just D : - so now it should operate on a file in the same drive the program was run from, at least in SDX. Please test, as I didn't test on a real DOS

 

I present v1.2 - (could save a few bytes here by assembling from source instead of this binary patch...)

streamln12.xex

[Mathy]

Hello guys

 

Streamliner can also be found on my BlackBox page.

 

If you use Streamliner, make sure you have an extra copy of the file you want to streamline.  In some cases, streamlining a file might cause problems.  As I found out with BBXFER.COM.

 

Sincerely

 

Mathy