Jump to content
IGNORED

introduction to the USR and XIO commands


Recommended Posts

let me get this out of the way: i am a firm believer in Machine code's ability to make better games. my problem is that there is no machine code monitor for Atari800win and there is only the USR and XIO commands. i have no idea how to use them. can someone help me?

Edited by Jackel192
Link to comment
Share on other sites

You need to write the assembly routines elsewhere (Mac/65 Atari Assembler/Editor, etc.), load them into memory on the Atari, then call them from BASIC using USR().

 

I did a series of tutorials around making simple Assembly language USR() routines supporting Atari BASIC. The last sections are specifically about what's wrong with XIO and how to use the OS CIO routines successfully (with and without XIO.)

 

 

 

http://atariage.com/forums/blog/576/entry-13175-part-1-of-11-simple-assembly-for-atari-basic/

 

 

Part 1: Intro

Part 2: Overview of common Assembly instructions

Part 3: The environment inside a USR() call.

Part 4: Implement DPEEK() (16-bit, two-byte PEEK()).

Part 5: Implement DPOKE (16-bit, two-byte POKE).

Part 6: Implement several bit-wise operations.

Part 7: Implement conversion from integer to hexadecimal text

Part 8: Implement conversion from integer to bit string/text

Part 9: Implement memory copy

Part 10: The problems with XIO, and using CIO (part I)

Part 11: The problems with XIO, and using CIO (part II).

Edited by kenjennings
  • Like 7
Link to comment
Share on other sites

let me get this out of the way: i am a firm believer in Machine code's ability to make better games. my problem is that there is no machine code monitor for Atari800win and there is only the USR and XIO commands. i have no idea how to use them. can someone help me?

 

You can use Altirra instead, it has a great monitor built in which includes a mini-assembler, so you can try out little pieces of code and even step through them in the emulator. Also have a look at WUDSN, a plugin for Eclipse that allows for Assembly development right on your PC, including testing on an Emulator after compiling.

 

If you need to get into non-Atari-specific assembly programming, this is a nice online 6502 simulator that allows to try things live.

  • Like 1
Link to comment
Share on other sites

You need to write the assembly routines elsewhere (Mac/65, Atari Assembler/Editor, etc.)...

 

Also have a look at WUDSN, a plugin for Eclipse that allows for Assembly development right on your PC, including testing on an Emulator after compiling.

 

Ditto that.

 

Natively building on an Atari has a number of inconveniences to enjoy from the 80s (line numbers, limited editor, limited memory, limited disk space, slow assembly time, etc.) In the 80s that's all there was and we liked it (uphill, in the snow, in both directions.)

 

Today I use Eclipse/WUDSN with atasm and the Atari800 emulator on linux for writing, building, and testing 6502 assembly.

 

atasm is Mac/65 with all the joy and none of the line numbers.

Edited by kenjennings
  • Like 2
Link to comment
Share on other sites

If you need to get into non-Atari-specific assembly programming, this is a nice online 6502 simulator that allows to try things live.

 

That's a good page if you have low 6502 experience. The page includes a very simple snake game (and a link to an expanded version with more documentation).

Learn how that works and then figure out how to make it to work on an Atari.

  • Like 1
Link to comment
Share on other sites

Natively building on an Atari has a number of inconveniences to enjoy from the 80s (line numbers, limited editor, limited memory, limited disk space, slow assembly time, etc.) In the 80s that's all there was and we liked it (uphill, in the snow, in both directions.)

No, we didn't. I was a part of a pretty large (100+ people) local Atari club with weekly meetings and I never ever met anyone liking the limitations of writing assembler code straight on Atari.

 

We all (well, dozen or so people) did it, as there was no other choice, but we all hated it, especially if you only had a tape, no floppy.

 

Having spent about a year fighting limitations of ATMAS II in 1989 was the single reason why I eventually went through the effort of first writing a monitor (e.g. dump, disassembler, jump, ...) and then a self-relocating assembler editor&compiler that coder could instruct to place at any place in RAM, thus gaining a huge uninterrupted block of memory - which was impossible with ATMAS as it was located roughly in the middle of RAM). The compiler was extremely fast, as it was doing first pass upon hitting Return (and compressing source code via tokens), so the final pass needed to only check labels and branches (which was very quick).

Unfortunately, it was September, I just started high school, and discovered the world of PC AT with Turbo Pascal & VGA gfx cards, so Atari stood no chance after experiencing that :)

 

 

Today I use Eclipse/WUDSN with atasm and the Atari800 emulator on linux for writing, building, and testing 6502 assembly.

Eclipse is a huge step forward, yes.

 

For a generic 6502 code (e.g. not much gfx&audio), there's even option today of quickly writing your own simple 6502 VM, directly using C++ (or .NET) and then you can use Visual Studio's awesome debugger (with Edit&Continue).

Of course, for things like PMG and DLIs (or indeed, specifics of A800) it's far from good, but almost all other uses are more comfortable from within a proper debugger that allows Edit&Continue (feature that I personally hold in extremely high regard, as it saves incredible amount of time in long run, and allows fixing all bugs during first step through the code, without having to re-run whole thing).

 

 

There's simply no comparison between productivity you can have from Visual Studio and something like ATMAS II...

  • Like 1
Link to comment
Share on other sites

There's one exception to the productivity when coding on Atari, though.

 

tschak909 had recently a thread about Corvus drive and compiling from harddrive (which just blew my mind).

 

It's amazing something like that was technically available on 8-bit Atari, but I can't help but wonder if there was at least 0.01% of A800 coders worldwide that had a set-up like that at home...

  • Like 1
Link to comment
Share on other sites

David Small wrote a series of articles about developing for the 8-bits on the 8-bits, printed in Antic, where he talked about tools, both hardware and software. For example, using a Bit80 card for debugging (showing real-time information while the main screen was showing graphics); high-speed floppies tied in through the OS board; and other techniques. Very interesting stuff.

 

Links:

 

http://www.atarimagazines.com/v2n7/nightmare.html

http://www.atarimagazines.com/v2n8/missionaccomplished.html

http://www.atarimagazines.com/v2n9/Missionredux.html

http://www.atarimagazines.com/v2n11/nightmaredetour.html
http://www.atarimagazines.com/v2n12/nightmare.html

  • Like 4
Link to comment
Share on other sites

David Small wrote a series of articles about developing for the 8-bits on the 8-bits, printed in Antic, where he talked about tools, both hardware and software. For example, using a Bit80 card for debugging (showing real-time information while the main screen was showing graphics); high-speed floppies tied in through the OS board; and other techniques. Very interesting stuff.

 

Links:

 

http://www.atarimagazines.com/v2n7/nightmare.html

http://www.atarimagazines.com/v2n8/missionaccomplished.html

http://www.atarimagazines.com/v2n9/Missionredux.html

http://www.atarimagazines.com/v2n11/nightmaredetour.html

http://www.atarimagazines.com/v2n12/nightmare.html

Incredible read, sir ! Thanks! The options you guys had in America at those times were truly boundless (though at a cost, of course)...

 

The following quote is however brutally teeth-screeching:

Anything having to do with disk drives on the ATARI is very slow

 

One can only wonder how they would describe the assembler workflow with the 600-baud cassette deck (which is what I had at my disposal) :)

  • Like 1
Link to comment
Share on other sites

One can only wonder how they would describe the assembler workflow with the 600-baud cassette deck (which is what I had at my disposal) :)

Cassette deck is slow, but assembling programs to tape is not impossible. It however requires patience. This is how I began programming in assembly, working source on one tape, backup source on another tape, assemble object to yet another tape.

 

The procedure is troublesome, so I got myself a disk drive (1050 Top Drive, second hand). Then around 1994 I convinced a friend of mine (login Simius on this very forum) to build a HDD interface for ATA/IDE drives. A parallel one, to be sure.

 

The HDD since that time has remained my main data storage on Atari. This is why, perhaps, I like to write programs on Atari to this day. The MAE assembler provides a full screen editor and it uses ext RAM to keep the source being edited, so programs may be large. Then you can assemble to the hard disk and run instantly, from the DOS.

Edited by drac030
  • Like 3
Link to comment
Share on other sites

No wonder RAMDISKs were so popular well into the PC age.

 

I think the guy who did Caverns of Mars used a 400/410 with Atari Assembler cart. And some other APX programmers Kevin Savetz interviewed had similar tales.

 

I wrote myself a monitor with mini-assembler so I could quickly try out stuff without going through assembly, loading, testing.

 

MAE was my first assembler but I must admit that I would have liked MAC/65 better then (those orange carts alone make it look like a serious tool). For assembler code line numbering imho is less of a hassle as you can auto-renumber without potentially breaking code (except your mental picture of what line numbers to list when looking for something) and use auto-numbering while coding.

 

Navigating through long source files without scroll bars wasn't that comfortable either. Action! used tags for that but you had to memorize or jot them down as they were not displayed.

 

I did a couple hundred lines of dBASE II coding with edlin in the military, now that was stone age to someone used to coding Atari BASIC with a full-screen editor...

 

 

Gesendet von iPhone mit Tapatalk

  • Like 1
Link to comment
Share on other sites

A ramdisk is good, but a hard disk is better: bigger, faster and non-volatile.

 

I used MAC/65 for years. It is truly a great assembler, one of the greatest programming tools ever created for Atari, I would suppose. It has two weak points, though: 1) the editor, 2) the fact that when assembling to disk you have to specify the target file name, each damn time.

 

The point 2 is much worse than you would think, because after many hours of LOAD#D:PROG.M65, SAVE#D:PROG.M65 and ASM,,#D:PROG.OBJ you finally mixup the filenames and overwrite the source. Maybe there is a way to define the object filename permanently (in the source), but I did not know it at that time (I had no manual for MAC/65).

 

Therefore when MAE appeared, I switched to it almost instantly. I had a contact to the author, so I suggested to him few changes and improvements which seemed missing in that version of MAE when compared to MAC/65 (f.e. he added the directive .fl i.e. .float).

 

It is a great pity that he is not working on it anymore AND does not want to release the source code.

Edited by drac030
  • Like 2
Link to comment
Share on other sites

  • 2 years later...
On 9/9/2017 at 4:29 PM, kenjennings said:

You need to write the assembly routines elsewhere (Mac/65 Atari Assembler/Editor, etc.), load them into memory on the Atari, then call them from BASIC using USR().

 

I did a series of tutorials around making simple Assembly language USR() routines supporting Atari BASIC. The last sections are specifically about what's wrong with XIO and how to use the OS CIO routines successfully (with and without XIO.)

 

 

 

http://atariage.com/forums/blog/576/entry-13175-part-1-of-11-simple-assembly-for-atari-basic/

 

 

Part 1: Intro

Part 2: Overview of common Assembly instructions

Part 3: The environment inside a USR() call.

Part 4: Implement DPEEK() (16-bit, two-byte PEEK()).

Part 5: Implement DPOKE (16-bit, two-byte POKE).

Part 6: Implement several bit-wise operations.

Part 7: Implement conversion from integer to hexadecimal text

Part 8: Implement conversion from integer to bit string/text

Part 9: Implement memory copy

Part 10: The problems with XIO, and using CIO (part I)

Part 11: The problems with XIO, and using CIO (part II).

Thanks for taking the time to write this interesting and fun document!  I was searching for a good summary of how XIO relates to CIO, but I also found your assembly introduction (a refresher, as I dabbled in it as a kid) very well written.

  • Like 1
Link to comment
Share on other sites

I have just started using cc65 and as a simple project to get me going I wrote the attached .XEX file,

what it does is load a binary file that you want to use in a USR call previously assembled to disk and

creates a file with DATA statements that can be "ENTER"ed into your BASIC program.

 

You can set the starting line number, line increment and also if you want the file as .BYTE statements for use

in Assembler/MAC65, this I used to add Sprite and Display List data to Assembler Programs.

 

I think it catches most input/output errors and also allows you to abort if you need to.

 

Hope this helps entering USR routines into you BASIC Programs

autodata.xex

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...