Tyrop

Thanks, Jac! Java version says, java version "1.8.0_191" Java SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot Client VM (build 25.191-b12, mixed mode)

I wrote a simple BBS in Basic back in the day (written for an 850 interface module and Hayes Smartmodem). When a modem is connected, the BBS interfaces with the remote user using the R: device, and when a user logs on locally, it uses the E: device. Does anyone know if there is a utility that can be loaded into memory that can piggyback R: onto E: (or somehow merge the two) so that if I break into Basic or go to DOS, the operating system will use R: instead of (or in addition to) E:? If there is such a thing, I would love to be able to log into my BBS remotely, press a menu command that breaks me into Basic or DOS so I can remotely control my computer (like a gotomypc for the Atari), and then resume .

I read Jac's website and also watched the installation videos. I downloaded Jac's pre-made installation into C:\jac\wudsn. When I run Eclipse, I get this error. I tried going to the Eclipse website to download Eclipse but there are so many choices, I don't know which to download. Can someone tell me what I'm doing wrong?

That did the trick JAC! Thank you so much for showing me what to do. Your IDE is a tremendous piece of work. It and Altirra are of great help in debugging.

Thanks, JAC! I removed the space in the path, and I think it works, though not exactly as in the videos tutorials. Here is a video. Is this working right? Also, the other samples have the same issues: space in the file name. ScreenCapture_1-24-2016 11.58.49 AM.wmv

ScreenCapture_1-21-2016 10.43.49 PM.wmv Thank you, JAC! Attached is a video. I tried to show all relevant information. I can't figure out why Altirra is not breaking or giving me source level debugging.

I'm hoping someone can help me with breakpoints. I installed Jac's zero installation and I set it up as in the videos. The default compiler is MADS and the default emulator is Altirra (version 2.7). All xex, lst, lab and atdbg files are set to "source" folder, not "temporary" and they are being created. I tried adding a breakpoint to the "Hello World" sample right at line 9 (sta $d40a) and when I select "compile and run," Altirra loads and runs the program but does not break into the debugger. The program just runs in its endless loop. When I go into the debugger, the disassemble window is empty and memory windows is set to $0000. If I hit break, then the disassemble windows shows the program with labels, but no source level window opens. Console window is empty. Also, if I keep hitting F8, Altirra only seems to stop at LOOP LDA VCOUNT. I don't see any breakpoint being set. What am I doing wrong? Is there something in Altirra I need to set?

I seem to remember that Atari gave a reason for the large text modes, eg, Basic's graphics modes 1 and 2, in one of the manuals or maybe one of the books on Basic. If I remember correctly, Atari's reason was something to the effect of titles, banners and labels. I also remember an early article, maybe in Compute magazine, that explained that Atari was one of the few computer of the time (maybe the only one circa 1981) that allowed the programmer to redefine the character set to create a custom font. As someone mentioned above, this a powerful capability, particularly in the multicolor modes, to create playfields. Many games also used redefined characters as sprites.

In the early 80's, my father worked at IBM and he told me that the system engineers said that blue background with white text was known to be easy on the eyes, and many set up their terminals with that color combo. In early versions of MS Word, Edit and similar Microsoft editing environments like Quick C, they defaulted to white on blue. Incidentally, my father bought us an Atari 800, and not an IBM PC.

BTW, the SIZE command will give you 3 numbers, the first of which is the beginning of free memory (which I think is the first free byte after the end of DOS).

You can also assemble your program to an object file and then binary load it in DOS to run it. To do this in MAC/65, you need to put .OPT OBJ at the top of your program listing (note - .OPT is preceded by a period). I usually put it on line 1. Then, use the command ASM ,,#D:OBJECT.OBJ. Note - 2 commas after ASM. This will compile the source code in memory into an object file called OBJECT.OBJ which you can then binary load, and I think it will just run. Don't forget to save your source file before you edit to DOS!

On the disk version, BUG65 was a separate program. You had to exit MAC/65, go into DOS (or OS/A+ which is what came on the disk) and then go into BUG65. On the cartidge version, the debugger was DDT (Dunion's Debugging Tool) and you go into it from within MAC/65 by typing "DDT." There is a MAC/65 manual online somewhere. Try doing a google seach for "mac/65 manual." I think DDT was better than BUG65. There is also a standalone, more advanced version of DDT called EXDDT (also written by Dunion) which is more advanced.

For MADS, the .lst file with the complete listing is used. What do you mean? ATASM creates the same kind of listing only via "-v" or ".OPT LIST" and is creates it on sdtout. That's why WUDSN IDE captures the output and converts it into an XASM compatible label file (for use in Atari800Win for example). Or dou you refer to the "-l" option with is there (only) in the most recent ATASM I am referring to the -l option in ATASM. I would love to use ATASM with WUDSN and be able to do source level debugging with Altirra, but I think it is not possible unless ATASM's author adds the ability to do a listing file similar to MADS. Your previous post showed me that it may not be too hard for me to use MADS if I already know ATASM, so I may just try to convert my source listing to MADS syntax so that I can get the source level debugging. BTW, I think WUDSN and Altirra are unbelievably amazing works. Once I used that combination, I could never go back to anything else for writing and debugging Atari 6502.

There are some vendors that have replacement parts. B&C ComputerVisions comes to mind. If you search eBay for Atari 800 keyboard, you will see some new replacement keyboards. I'm not sure about the answer to your power brick question. Maybe someone else can answer. Atari disks will not work in any IBM disk drive. There was an old program called anadisk for the PC that claimed to be able to read ATari disks, but I read on forums at the time that it did not work. I tried it myself and I ruined an Atari disk. Then I read that it only worked on Atari disks formatted a certain way, possibly by a 1050 (which has the capability of formatting single density and enhanced density). However, you can copy files from an Atari to a PC over a special cable called an SIO2PC cable. You can buy one at atarimax.com. You can then create disk images on the PC, and using the software that comes with the cable, the Atari will think the disk image is just another disk in a disk drive. There is a lot of Atari software on the Internet that comes in the form of a disk image. They usually have the extension .atr.

Altirra also does that for ATASM. Is there any difference in the the way it loads the labels in MADS that is different than ATASM? Thank you for you post, JAC!, I did not realize that it was that simple to go to MADS from Mac/65.

And I also use WUDSN with ATASM and then use the debugger in Altirra. Altirra has the ability to include your own labels in the debugger window. It makes debugging much easier.

MADS is the most powerful, but I use ATASM because it is mac65 compatible. I tried to learn MADS but the manual was not in English and it was too daunting for me to try to understand the translations. There is a mac65 manual online, so ATASM was easy for me to learn.

In MaPa's example, it is adding 1 to the hi byte. The expression, "loop+2" calculates an address and the assembler treats it like a new label. It does not add 2 to the hi byte. It may be easier to visualize if you view a disassembly of it. You will see that loop+2 refers to the location of the hi byte of <address>. Therefore, inc loop+2 increments the value of the hi byte of <address>.

I am definitely an amateur assembly language programmer, but my 2cents is that your idea of a nested loop is a fine way to do it. MaPa's code is ingenious - it actually changes the actual program on the fly. Stephen's can be called from Basic. In the end, both examples still use a nested loop, and will loop through 8000 STA instructions for your application. You can also do the following, but I don't think it is any more efficient. Rather than nesting a loop, you can do one iteration of incrementing the X register from 0 to 255 and then have this: STA 32000,X STA 32000+256,X STA 32000+512,X STA 32000+768,X STA 32000+1024,X Etc... Until yo do all 8K. In this example, you are writing a lot more code, and still doing 8000 STA's, so I think nesting is still the better way to go.

I had a real hard time grasping the entire concept of assembly language for a long time. Here is my simplistic explanation which might help. Assembly is very very different from all other languages, like basic, pascal, etc. In assembler, there is no "print," no "input" or any other input/output. It does not have commands like in other languages. In my humble opinion, 90% of what you do when writing assembly code is poking and peeking. Your program almost entirely boils down to determining what to poke, where to poke it, under what circumstances are you poking it. The way you get the computer to do things (like display text, display graphics, read input from keyboard, send bytes to printer or disk or modem), is to poke data into certain designated memory locations that perform designated functions. So, whether you are writing a game, or a business program, all your logic, your branching, your comparisons, are all aimed at figuring out what number to poke and where to poke it. LDA is basically a peek, and STA is basically a poke. For instance, if you want to print text on the screen, you can poke the individual character codes into consecutive memory locations in the part of the computer's memory that is designated as "screen memory." You can also use Atari's built in input/output ROM routines for printing, and that also involves poking certain command codes into designated memory locations (including poking the address of your text) and then invoking Atari's routine via a JSR instruction. Atari's routine then does some fancy things, but in the end, it pokes your text into screen memory. To input text, you need to peek a certain location designated to keep track of the last key pressed, or you can also invoke Atari's ROM routine (also by poking codes into designated addresses and doing a JSR to the routine). To learn assembly language, you need 2 resources. Each is basically useless without the other. They are, 1) a good book on 6502 assembly language. This teaches you what each instruction does. I thought Atari Roots was pretty good. I thought Machine Language for Beginners was very good. Reading 2 books on the same subject is good because they each might clear up confusion caused by the other book. 2) you need a book specific to the Atari computer that explains what memory locations perform what functions. De Re Atari is probably the single best resource in this regard. It tells you where things are and what you have to do to get things to work. I thought a great book was Atari Graphics and Arcade Game Design. It is on atarimania. It does something the other books I mentioned don't do. It teaches you how to actually use assembly language, with step by step examples of code that actually does something. It expands on the knowledge you would get from De Re Atari. It teaches you how to do graphics in assembly language by breaking the game down into separate, isolated tasks, and it explains the concept of what each task is trying to do, and then it explains how the assembler code accomplishes the concept.

.BYTE is sort of like basic's Poke instruction. .BYTE $70 pokes $70 at the point of assembly, in your case, location $3002 receives the value $70. I could be wrong, but I think DLIST is at $3002, not $3003. In your program, the first byte of your display list is at location $3002 (not $7BA8). But, I see that your jump instruction at the end of your display list (line 420) tells the computer to jump to location $7BA8. I am sure this is not what you want. You want the end of your display list to jump back to the beginning. So, what you really want is line 420 to read .BYTE $41 $02 $30. (If you really want your display list to begin at $7BA8, then you need to add *=7BA8 right before your DLIST label, and then you leave 420 as-is.) Now, there is a little niftier way of coding this, hopefully not too confusing. You made a label called DLIST which is being assigned the value $3002. So, instead of using .BYTE $02 $30, you can use .WORD DLIST instead. .WORD takes a 2-byte number and assmbles it into two consecutive bytes with the low byte first. Hence, .WORD DLIST will poke $02 and then $30. Using this method, you would have line 420 as just .BYTE $41. Then, you would add line 430 .WORD DLIST. THis method makes for more portable coding because, if you ever change your origin (*=$3000) to something else, your jump instruction will automatically always have the correct value. By the way, LDA DLIST is the same as LDA $3002. That would load $70 in the accumulator. If you use the MAC/65 assembler, LDA #<DLIST would load the low byte of a 2-byte value, in your case, $03, and LDA #>DLIST would load $30.

The laws regarding the copying of copyrighted work are different than the laws regarding copying a trademark. Copyright law generally is aimed at protecting works of authorship. Trademark law is aimed primarily at preventing the use of someone else's trademark to gain a commercial advantage. Atari's letter did not mention trademark infringement, so I doubt they have a problem with the Fuji appearing in any of the programs appearing on the web page. In any case, it did not appear to me that pps was engaging in commerce, or that he was displaying the Fuji in such a way as to confuse the public into believing that Atari owns the programs.

Isn't this usually followed by "but I am not your attorney, and this is not legal advice"? Not , by any chance? Funny video. No, I'm just a person interested in seeing what happens. I was disappointed in Atari for harassing an Atari enthusiast who did nothing more than show his enthusiasm for a 30 year old product by posting homemade programs written by other enthusiasts. I would have thought Atari would have been flattered that such an old product still gets attention today.

I am an attorney in New York and I have had experience litigating trademark infringement claims and also assisting in copyright litigation. The "cease and desist" letter basically says that the infringing material consists of access to "unauthorized console emulation software and/or unauthorized copies of game products (software) protected by Atari's copyright rights." Simply stated, it sounds like Atari thinks the web pages make available emulators and software copyrighted by Atari. I took a quick look at the web pages, and unless I am missing something, I did not see any emulators or copies of any of Atari's games or software. Atari has no rights in software written by third parties that run on Atari computers (unless the author gave away his or her rights to Atari). Regarding emulation, you may find the following case interesting: Sony Computer Entertainment, Inc. v. Connectix Corporation. Do a search for that case and you will find some web pages that discuss it. The court held that copying a copyrighted BIOS for use in a PlayStation emulator did not constitute copyright infringement - at least under the circumstances in that case.

Thanks, everyone, for your help. Actually, I miscalculated when I said the third bit. I went back and checked and its actually AND #$8 that does the trick, so I guess its actually the fourth bit. Anyway, what I am doing is trying to get an old BBS that I wrote back in high school to reset when the carrier is lost, so I am checking the "carrier detect" line. Both David's code (with the divide-by- and Nukey's code (changing to AND #$ each worked perfectly. Since the machine language code is faster, I am using that (in a strig variable as suggested).