Programmer editors for 80 columns?

[tschak909]

Does anyone know of any programming editors that work correctly with e.g. XEP80, or BIT3, or any of the other Atari 80 column options? The Atari MEDIT for AMAC doesn't work very well (although AMAC has no problem running with the XEP80's console driver...)

 

-Thom

[+Stephen]

I am not aware of any. I love The Last Word, but it's huge. I know fjc said at one point he was thinking about using some of that code, to make a stripped down code editor that supported folding. Would be awesome.

[drac030]

I recommend MAE. http://atariki.krap.pl/index.php/MAE

[tschak909]

Wow, John did a really great job on this package! I had heard about it for years, but never tried it until now.

 

It's definitely meant for no-nonsense professional use, and it works great with this corvus and XEP80 setup that I have going here. So this is another potential environment to video.

[kenfused]

My old editor KEdit does 40 or 80 columns. Available here: http://kensclassics.org/ It attempts to work with any E: device but have no idea if it works with anything beyond the provided handlers and the OS handler.

 

--Ken

[tschak909]

Well, too late now, already writing one in MEDIT+AMAC.

 

-Thom

[drac030]

And MEDIT is what?

[ijor]

And MEDIT is what?

 

The Atari editor bundled with AMAC. Probably the first full screen editor for Atari?

 

I liked MEDIT a lot. Very powerful for the time. MEDIT was the main reason I preferred AMAC over MAC65 back on the day.

[drac030]

Yes, I get it now, thanks.

[tschak909]

 

MEDIT, and an AMAC printout, as i'm working on this text editor...

[drac030]

You wrote that that editor (MEDIT) "does not work very well". What is the exact problem? If it works with XEP80, it should work on any E: driver.

 

I am interested if (or: how) does it work with the VBXE 80-column text mode.

 

EDIT: ok, I tried it an can see my error now - I thought that MEDIT was integrated with AMAC, while they are two separate programs. And MEDIT does not seem to work through E:, so no question that it "does not work very well" with other than vanilla 40-column display.

Edited April 15, 2017 by drac030

[tschak909]

The editor (tenatively called Keypunch), starting to breathe:

 

40 columns:

 

80 columns:

 

[drac030]

When there will be something to test already, I am willing to try out a beta (or even alpha) version.

 

PS. I know of at least two programmers (both of not negligible skill) who during last years undertook to write a new, handy text editor, but both programs ended up LIA.

Edited April 15, 2017 by drac030

[tschak909]

Soon. I am a professional software engineer by day...but I've never undertaken a text editor before. I do have a couple of books on text editor algorithms, including one discussing buffer gaps, which I understand.. so, while this won't be easy, it won't be insurmountable either.

 

I have an exact small set of features that I want, and I know how I want to interact with the program, so this should be doable.

 

-Thom

[tschak909]

I'm hoping relying on the CIO for single key input, and for output will simplify what needs to be done on the display side.

 

(no I'm not just pointing to the E: and asking for input...this is how I get the editor behavior I DON'T want)

 

-Thom

[Kyle22]

I'd like to see AMAC fixed to work under SDX.

[drac030]

I have no experience with AMAC, but from what I tried, it seems to work (AMAC v.1.0a). Could you prepare a test case (on an ATR form example) which demonstrates that it does not work correctly?

[luckybuck]

@Thom & Kyle22:

Everything about the XEP80 we have collected here:

https://atariwiki.org/wiki/Wiki.jsp?page=XEP80

Source codes, drivers etc..

That case is closed

My suggestion: mixing this with the sourcce codes we already have? Maybe just adapt to existing editors?

@all:

By the way, AMAC, who wrote it? Who holds the rights? Bob Shepardson?

AMAC is on my top 10 list for the source codes to find and holds #1 besides the Atari Assembler Cartridge

[tschak909]

No Roland. I am explicitly writing this editor to use the OS E: device for output, so that it will work with _ANY_ output device. (I do certain things to figure out how big the display is, etc.)

 

As for who wrote AMAC, it was subcontracted by Atari to another company called Sorcim.

 

Sorcim was an early software company that spent the first part of its life writing programming languages and assemblers for a variety of different CPUs, and later on were subcontracted by other companies to write application software (e.g. by Adam Osborne to write a cheaper competitor to VisiCalc for the Osborne portable CP/M machines)

 

-Thom

[Kyle22]

@Konrad:

 

I have attached AMAC. These are the original files, except that I renamed the binary executables to .exe, and I patched one byte of AMAC.EXE to bypass the bad sector copy protection check. It will load and run, but it always errors out at Pass 2 Assembly under SDX.

 

I think I remember Jon having some experience with the same issue, but I don't think he ever found a solution. Please correct me if I'm wrong Jon.

 

amac.arc

 

Edit: Good AMAC info here: http://mixinc.net/atari/amac.htm

Edited April 22, 2017 by Kyle22

[tschak909]

It really is a damned good assembler, and if anything, could stand to be patched or made to run under SDX, with command line parameters. Insanely flexible, and the ONLY assembler I am aware of with a full cross reference listing capability (which is GREAT for large projects!)

 

-Thom

[drac030]

@Ky

@Konrad:

 

I have attached AMAC. These are the original files, except that I renamed the binary executables to .exe, and I patched one byte of AMAC.EXE to bypass the bad sector copy protection check. It will load and run, but it always errors out at Pass 2 Assembly under SDX.

 

I think I remember Jon having some experience with the same issue, but I don't think he ever found a solution. Please correct me if I'm wrong Jon.

 

amac.arc

 

Edit: Good AMAC info here: http://mixinc.net/atari/amac.htm

Kyle, thanks. There is something weird going here, as last time I checked, AMAC worked for me. I even still have the object file produced by it (it is 0 bytes, because I just have compiled the SYSTEXT file containing the system labels). But today it does not work, neither the version I tried that time nor yours. It really looks like something needs patching.

[flashjazzcat]

Originally I assumed that the issue was that - at the end of the first pass - AMAC expected CIO status code 3 after reading the last byte of the file (but not reading beyond the end of the file, which returns EOF). Back in 1990 or so SDX did not return status code 3 on the last byte of the file, although since then I believe this has been fixed. I must admit I didn't try AMAC since then to see if the change rectified the hang after the end of pass 1, but it appears something is still wrong.

[drac030]

I wrote such a "program" for AMAC:

 

   ORG $2000

START LDA $0600
   STA $0601
   RTS

   END $0600

When it asks about parameters, I type D3:TEST.ASM L=S:

 

It compiles and even generates a listing to the screen, but the object code on the disk ends up to be 0 bytes. I am using Kyle's version of AMAC. Is this the problem which should be found out, or I am doing something wrong?

[tschak909]

Shouldn't that be END START ?

 

-Thom