From xxxxxxx@xxxxxxxxx.xxx Fri Jan 28 19:02:17 2000 Date: Fri, 28 Jan 2000 06:41:11 -0600 (CST) To: Steve Judd Subject: Sirius Well I tried the latest copy of Sirius and...well... I've got some complaints... 1) I can't save anything from it. Or more to the point, it acts like it's saving, but what I get back is garbage. It is able to load other source code files just fine, provided I convert them to PRG. I know my Super RAM is in good shape, as I tested it just a few minutes prior by running DMAgic's "SuperCPU Kicks!" demo. If that demo can run, then just about anything can. :) 2) Why on earth did you limit the program to loading only PRG files?? Source code is 7-bit text, and should be saved in SEQ format. When doing a normal LOAD command, it is possible to force-load a SEQ file by appending a ",S" to the filename, e.g. LOAD"sourcefile,S",8. 3) Is there No End-of-File function?? That's gotta be a pain with big files. The Bookmark feature of the program isn't sufficient to replace this, since you can only define one bookmark (one must have a way to get to the top of the file if already at the bottom, after all). 4) No end-of-line function either? I find this very handy when editing code. It's especially handy when one needs to make changes to variable references; when changing a table+1 reference to table+2 in several places, for example. 5) Perhaps you should also explicitly enable the Kernal's Key-repeat feature, so one can hold, for example, Control-M to page down continuously. This is done by storing $80 to location $028A, if I remember right. 6) Is there a way to tell the assembler NOT to list the data as it assembles? This will greatly speed up the assembly process if it doesn't waste time displaying something the user can't even read anyway. 7) Shift-Backarrow most definitely does NOT exit from the program, as the dox say. How does one exit nice and cleanly from the program? Preferrably in a way that does NOT trash JiffyDOS and it's function key settings. A cold reset seems to be the only way to get out clean (Run/Stop-Restore leaves the system trashed to the point that I can't even get a directory listing from RamLink) 8) Why did you leave the documentation in ASCII format? It's a Commodore program after all. Since it's for the SCPU, that means JiffyDOS is available, and hence @T could be used to read the dox, if they were in Pet-ASCII format. 9) If a label is not defined and the assembler runs across a reference to it, it returns a silly error like "address mode not supported" instead of a more sensible "undefined label" error. Nice source of confusion, that. 10) In the Disk menu, some of the keys need aliases, particularly the Directory and Change-Device functions. These should be $ and #, respectively. Seems more natural than d and c. 11) Pseudo-op codes should allow for leading periods, as used in some assemblers, and should be case-insensative. Thus, org ORG .org and .ORG should be equivalent. Case-insensativity should also apply to regular opcodes (e.g. LDA). 12) Where the hell are the known, standard BYTE, WORD, and BUF commands?? A person should NOT have to read the documentation to find out the assembler doesn't support them, in favor of the more cryptic DFB, DW, and DS. Why not just make the program accept both? 14) The label and argument fields should have customizeable widths. Sometimes it's useful to use long lable names, for descriptive purposes (when writing code to be used as example code for larger projects, for instance). Sorry for all the nit-picks, but if people are gonna use the program, the gotta have features that make using the program simple and efficient. I'll let you know if I run into any other problems. Why did I try using Sirius? I need a better assembler, one that can handle 65816 opcodes natively. I'm trying to re-write Modplay 64 (I'm going SCPU- only with it), and Ace's assembler just isn't up to the task (using .BYTE to include '816 opcodes is cryptic at best, and difficult to read).