New (Updated) Assembler/Text Editor

[flashjazzcat]

Some time within the next year I intend to take a look at the macro assembler I wrote (MA65) fifteen or so years ago and update it. The point of this is to have a capable Atari based compiler (NOT a cross compiler) which - coupled with a good text editor - will make for a decent programming IDE on the 8-bit. SDX, VBXE, Real Time Clock, SpeedDrive, and the forthcoming cart version of The Last Word will be the ideal combination. VBXE's 80 column text mode (as used by LW 4) makes editing large amounts of text on the Atari a real pleasure, and my intention is to create a fast macro assembler with a somewhat larger statement set than the current version of MA65. I know of a few people who still like coding up small projects on the 8-bit, and it would be nice to take advantage of high speed I/O, unlimited storage, and snazzy displays. I know we already have Action! and MAC/65, but I don't think Action's integrated text editor will work in 80 columns. Perhaps a very capable assembler with an integrated editor which works in VBXE or pseudo 80 column mode and recognizes 1MB upgrades and the like? That memory could be used to flip-flop between the editor and the running test application. Most of the software I wrote back in the day was compiler/editor oriented, and I think it should be possible to create a satisfyingly fast programming IDE by simply marrying up a lot of existing technologies.

 

The system could be on a cartridge: once we go down that road, there's barely any limit to the size of the compiler. The old 8-bit CC65 would have been almost bearable had it been cart based and written in pure 6502.

 

Anyway: thoughts and opinions welcome. I really miss programming on my 8-bit. The only thing stopping me at the moment is the fact that MA65 isn't 100% compatible with ATASM and MAC/65 source code.

[Rybags]

What's bugged me about editing Asm code on the PC... with 6502 stuff, comments aside, we only really use a dozen or so characters in each line of code. And even with these big 1440x900 displays and the like, we still only fit 50 or so lines of text in the window, white space everywhere gone to waste.

 

What might be nice is a combination of:

- multiple "views" of the file you're editing, e.g. one part of the display can scroll through your equates and comments up the top, the other part on the bit you're adding to. Same principle of how many Windows apps let you split the window to show various parts of the single file.

 

- multi-column editing. How cool would it be to have 2 columns of 40 characters or 3 columns of 26 characters, kind of like a magazine. Combine that with a special shortened character set, maybe 6 of 7 pixels high.

Suddenly, you can view almost 100 lines of your program at once instead of the 24 or 50(ish) of the traditional ways.

[flashjazzcat]

What's bugged me about editing Asm code on the PC... with 6502 stuff, comments aside, we only really use a dozen or so characters in each line of code. And even with these big 1440x900 displays and the like, we still only fit 50 or so lines of text in the window, white space everywhere gone to waste.

Tabbed editors are nice but even they don't solve the problem. Split windows are the way to go. With a good 80 column display on the Atari, we could implement something similar.

 

What might be nice is a combination of:

- multiple "views" of the file you're editing, e.g. one part of the display can scroll through your equates and comments up the top, the other part on the bit you're adding to. Same principle of how many Windows apps let you split the window to show various parts of the single file.

I like this idea. It's something I'd like to implement in the word processor, too. Even without using a split screen, it would be fairly easy to do by using another set of pointers.

 

- multi-column editing. How cool would it be to have 2 columns of 40 characters or 3 columns of 26 characters, kind of like a magazine. Combine that with a special shortened character set, maybe 6 of 7 pixels high.

Suddenly, you can view almost 100 lines of your program at once instead of the 24 or 50(ish) of the traditional ways.

Or in VBXE we could use a 400 line interlaced mode for a 640x400 display.

Edited May 8, 2010 by flashjazzcat

[landondyer]

What's bugged me about editing Asm code on the PC... with 6502 stuff, comments aside, we only really use a dozen or so characters in each line of code. And even with these big 1440x900 displays and the like, we still only fit 50 or so lines of text in the window, white space everywhere gone to waste.

 

In my opinion, if you're only using a dozen or so chars per line of assembly, you're doing it wrong. While you don't necessarily need a comment on every single line, many lines should be well commented.

 

The original Macintosh ROMs (up to the 68020/030 based sources I saw) were production assembly with comments on every single line, and they mattered. This probably matters less for video games, but you'll still thank yourself later if you leave decent comments behind. In my own Atari games (as well as in the Coin-op sources i saw) there was plenty of explaination; in my case, I had direct feedback that others had found it very helpful.

 

(The Atari 400/800 version of Pac-Man had exactly two comments. I forget the first, but the second was "HA HA" on the line that implemented the cartridge's single piece of copy protection).

[Rybags]

Fair enough, but comments are almost as readable if the line size is reduced under 20 characters.

 

Your comment reminds me of another feature request. I don't know if anyone here's familiar with ISPF on IBM mainframes, but one great feature it has... line exclusion.

 

Practically as useful as splitting edit windows, you can request that multiple lines are temporarily excluded from display.

 

So, for example, you might have huge blocks of comments that explain data structures, or subroutines that are stable and set in stone and you don't need to see or modify for a while.

 

Exclude a bunch of lines, the program suddenly becomes a lot more managable insofar as navigating and editing.

[snicklin]

I have a feature request, but it would require a tie-in between yourself and Phaeron.

 

For me, I like cross-development due to the speed involved. If you're not planning on making this a cross-compiler, it'd be nice to be able to still gain the speed required by impatient people like me when compiling.

 

I could do some development on the Atari through emulation on Altirra. When it comes to compilation, a very specific flag could be set for Altirra which tells it at certain stages (when compiling/linking) to run at full speed. Then when compilation/linking is completed, a flag is then set to tell it to go at normal Atari speed.

 

What do you think? I appreciate that it's something that hasn't been done before (I think).

[Rybags]

Another feature:

 

what would be nice is dynamically relocatable code. This would be a big thing to implement though because it'd require generation of tables for not only program jumps, but stuff like immediate stores to zero-page.

 

I think that if in future any sort of GUI extension is to be made to the A8 that becomes some sort of standard, relocatable applications would be a must if it was to have any useful kind of "multitasking" ability.

[flashjazzcat]

I have a feature request, but it would require a tie-in between yourself and Phaeron.

 

For me, I like cross-development due to the speed involved. If you're not planning on making this a cross-compiler, it'd be nice to be able to still gain the speed required by impatient people like me when compiling.

 

I could do some development on the Atari through emulation on Altirra. When it comes to compilation, a very specific flag could be set for Altirra which tells it at certain stages (when compiling/linking) to run at full speed. Then when compilation/linking is completed, a flag is then set to tell it to go at normal Atari speed.

 

What do you think? I appreciate that it's something that hasn't been done before (I think).

 

That's a good idea. For a long time, I used MA65 to compile The Last Word: I just used to hit the turbo button as soon as the assembler's splash screen came up. If the emulator had a hardware register hidden away somewhere, compilers and other software could achieve interesting optimisations. In reality, during the compilation process, the only time the emulator needs to forced to run slow is when accepting input from the user. In the case of a command-line app, that was never so the turbo flag could be switched on for the whole duration of the compilation.

 

I really like the sound of that: an inventive suggestion if there ever was one.

 

Another feature:

 

what would be nice is dynamically relocatable code. This would be a big thing to implement though because it'd require generation of tables for not only program jumps, but stuff like immediate stores to zero-page.

 

I think that if in future any sort of GUI extension is to be made to the A8 that becomes some sort of standard, relocatable applications would be a must if it was to have any useful kind of "multitasking" ability.

 

The best route would probably be to mimick the SDX style of relocatable executables. I guess that means migrating to MADS... I hadn't actually envisaged a multi-tasking GUI, but in any case having relocatable code would be bloody useful.

[snicklin]

That's a good idea. For a long time, I used MA65 to compile The Last Word: I just used to hit the turbo button as soon as the assembler's splash screen came up. If the emulator had a hardware register hidden away somewhere, compilers and other software could achieve interesting optimisations. In reality, during the compilation process, the only time the emulator needs to forced to run slow is when accepting input from the user. In the case of a command-line app, that was never so the turbo flag could be switched on for the whole duration of the compilation.

 

I really like the sound of that: an inventive suggestion if there ever was one.

 

I'm glad that you like it! The only challenge would be (if Altirra was to take on such a feature) to keep the flag so unique that the feature doesn't get accidentally switched on. Though there could be a tick box in Altirra to say that you want to enable such a feature at any one time. And also, you do not want it to affect operations when running on a conventional Atari.

[flashjazzcat]

I'm glad that you like it! The only challenge would be (if Altirra was to take on such a feature) to keep the flag so unique that the feature doesn't get accidentally switched on. Though there could be a tick box in Altirra to say that you want to enable such a feature at any one time. And also, you do not want it to affect operations when running on a conventional Atari.

I suppose it could be buried away in the hardware registers somewhere. Alternatively, the emulator could watch out for some purposeless and convoluted code sequence whose mere appearance could turn the turbo on or off (e.g. some kind of empty loop). On the other hand, the emulator could map a device onto the CIO which it monitors for XIO commands to the "M:ulator" device...

[snicklin]

I like your thinking there with the device. I was thinking more along the lines of looking for a certain sequence as you mentioned. Maybe a text string at a certain location or even some even more unlikely sequence of characters at a specific place. There may even be other flags for the emulator designed into the concept, but I'm not sure what other features could be enabled/disabled at will. Any ideas?

 

As for your feature requests, I'm not asking for a specific feature as such here, but that you make it friendly in general to the user who wishes to uses an emulator. Maybe something to do with file-transfer, ah, well, I'm not sure, it's too late, but I think you know what I roughly mean!

[atarimac]

The idea of the emulator device sounds like a good one, if we can get the feature coordinated across the emulators. I can speak of course for Atari800MacX (and am one of the authors of Atari800, so unless someone on that team objects, I can do it there as well). That would leave Altirra and Atari++.

 

It would be nice to have some read XIO functions on the device as well, you could use those to determine which emulator you were running on, etc.

 

As for the device name, we might need to be careful with the letter selection. I seem to remember M: being used for some sort of memory device, and of course E: is out. Any suggestions?

[snicklin]

The idea of the emulator device sounds like a good one, if we can get the feature coordinated across the emulators. I can speak of course for Atari800MacX (and am one of the authors of Atari800, so unless someone on that team objects, I can do it there as well). That would leave Altirra and Atari++.

 

Oops, sorry, I didn't realise that there were other emulator coders around here!!

[flashjazzcat]

Sounds great. We could always use some obscure device name like "@:", I suppose. Was there ever a "U:" device?

 

The more I think about this whole idea, the better it sounds.

 

Anyway, when I get time (in between writing a device handler and doing XM301/SIO2D conversions), I'm going to update my "MA65" assembler to be fully compatible with ATASM. I fancy doing some program development on real hardware, and this will mean I can port my smaller ATASM projects straight across to the Atari. I know I could probably use MAC/65 at a push, but MA65 is command-line driven under SpartaDOS, which is more or less essential in my books.

Edited May 18, 2010 by flashjazzcat

[flashjazzcat]

Just retrieved my MA65 source code from floppy disks in the middle of doing something else: full ATASM compatibility shouldn't be too hard to achieve. The main difference is that my assembler takes macro names from the label field of a definition: this should be easily changed.

[flashjazzcat]

MA65 assembler now compiles under ATASM and works correctly. ".bank" directive to be added, along with changes to macro processor. Feature requests appreciated.

 

Edited May 21, 2010 by flashjazzcat

[flashjazzcat]

Following a moment of clarity today, I suggest the emulator device be called "H:". Why? Because it already denotes the hard disk handler, and might as well double up as "Host". We just need a few XIO commands patched into the H: handler to turn turbo mode on and off.

 

 

 

[classics]

I have a feature request, but it would require a tie-in between yourself and Phaeron.

 

For me, I like cross-development due to the speed involved. If you're not planning on making this a cross-compiler, it'd be nice to be able to still gain the speed required by impatient people like me when compiling.

 

I could do some development on the Atari through emulation on Altirra. When it comes to compilation, a very specific flag could be set for Altirra which tells it at certain stages (when compiling/linking) to run at full speed. Then when compilation/linking is completed, a flag is then set to tell it to go at normal Atari speed.

 

What do you think? I appreciate that it's something that hasn't been done before (I think).

 

Why not use a simple code sequence that would do nothing on a real 8-bit but could trigger the emulator to change speed modes?

 

For example you could do:

 

$1A

$3A

$5A

$EA

 

To turn off the speed lock and

 

$EA

$5A

$3A

$1A

 

To turn it off.

 

On a real Atari you would just be wasting 4 NOP instructions. Its not likely this code sequence appears in any real software either, so there is little chance anything would false trigger it.

 

Steve

[flashjazzcat]

Why not use a simple code sequence that would do nothing on a real 8-bit but could trigger the emulator to change speed modes?

 

For example you could do:

 

$1A

$3A

$5A

$EA

 

To turn off the speed lock and

 

$EA

$5A

$3A

$1A

 

To turn it off.

 

On a real Atari you would just be wasting 4 NOP instructions. Its not likely this code sequence appears in any real software either, so there is little chance anything would false trigger it.

 

Steve

That's one approach and it would work well. I suppose an advantage to having special SIO commands on the H: device (or a patched CIO handler) is that it would allow for other stuff too, like interrogating the system clock, and getting info on the host file system (a bit like the extended SIO command set of SIO2IDE and others of the same ilk). Another advantage of using SIO/CIO is that it's possible for the host to return packaged information to the calling application - i.e. the assembler can say "Which emulator am I running on?" and the H:ost device can report the name of the emulator. If there's no "H:" device, of course, the assembler knows it's running on real hardware or an unsupported emu.

Edited June 10, 2010 by flashjazzcat

[classics]

That's one approach and it would work well. I suppose an advantage to having special SIO commands on the H: device (or a patched CIO handler) is that it would allow for other stuff too, like interrogating the system clock, and getting info on the host file system (a bit like the extended SIO command set of SIO2IDE and others of the same ilk). Another advantage of using SIO/CIO is that it's possible for the host to return packaged information to the calling application - i.e. the assembler can say "Which emulator am I running on?" and the H:ost device can report the name of the emulator. If there's no "H:" device, of course, the assembler knows it's running on real hardware or an unsupported emu.

 

CIO would limit the use to programs that run with DOS and the device table initialized. SIO would require the OS ROM to be present or the program to have its own SIO routines.

 

Another option would be to use a 'magic' write sequence to a unused hardware or ROM address. This would be easy to trap in a real hardware accelerator board as well, making it compatible with both.

 

Not saying its a bad idea, just exploring the limitations of each.

 

Steve

Edited June 11, 2010 by classics

[flashjazzcat]

I hadn't considered the scenarios you describe, Steve: although I imagine most productivity software will run with DOS and the OS present, the flexibility of what you suggest would be useful.

 

Perhaps we could establish an unused region in the cartridge control area; I imagine the sequence would be to write destination buffer pointers to certain addresses (for the returned data, where applicable), then the "magic" sequence which would trigger the desired action.

Edited June 11, 2010 by flashjazzcat

[snicklin]

I quite like the idea of the "magic sequence" of values which will trigger actions off.

 

I'm trying to consider what other actions a 2-way communication channel between the software and the emulator could do:

 

1) Software->Emulator: Speed up / Speed down.

2) Software->Emulator: Recommended settings ?

3) Software->Emulator->Software (a data request): Emulator Name / Version

4) Software->Emulator->Software (data request): Copy clipboard to Atari keyboard

... any other ideas anybody?

 

A 1 byte code at the end of the magic sequence can denote which action to execute.

 

What does everyone else think? These suggestions are for the emulator and not so much for the Assembler/Text Editor, though they *may* be useful.

[classics]

Being able to toggle most of the common emulator GUI features like the disk patch would be on my short list.

 

Steve

[atarimac]

Being able to toggle most of the common emulator GUI features like the disk patch would be on my short list.

 

Steve

 

I agree, that seems like a really good use of the feature to me as well. However, I would like to brink back the idea of using a new device letter in the emulator as a method implementing the interface. The earlier comment about the device table not being present without DOS is not true. It doesn't include D: devices, DOS adds support for those, but E:, S:, K:, C: etc exist as those are part of the basic OS. Now DOS does rewrite the table, and may remove it, but the emulators (at least those based on Atari800) detect this, and reset up devices they are inserting.

 

I really think this is the cleanest interface. Anything in memory space is going to have a conflict at some point or another. And it's going to be easy to tell if you are on a real machine, and IO operation to the new letter device will fail, as it's not there.

 

Mark

[classics]

I agree, that seems like a really good use of the feature to me as well. However, I would like to brink back the idea of using a new device letter in the emulator as a method implementing the interface. The earlier comment about the device table not being present without DOS is not true. It doesn't include D: devices, DOS adds support for those, but E:, S:, K:, C: etc exist as those are part of the basic OS. Now DOS does rewrite the table, and may remove it, but the emulators (at least those based on Atari800) detect this, and reset up devices they are inserting.

 

I really think this is the cleanest interface. Anything in memory space is going to have a conflict at some point or another. And it's going to be easy to tell if you are on a real machine, and IO operation to the new letter device will fail, as it's not there.

 

The meta-instruction setup using NOPs would be invisible to everything, including hardware devices. Adding a CIO device that just wraps around that would be a logical extension of the idea, that way BASIC programs and things could also access the interface, without having to resort to X=USR("Squiggly").

 

It is true thought that the OS has to be present and initialized for the CIO table to be present and functional. Things like demos and games mostly dispose of those immediately on loading and would be locked out if there were no underlying 'bare metal' interface.

 

Steve