Tyrop

Thanks for all the responses. So what I gather is that there is no “put” or “get” record in any Basics because DOS was not originally designed that way. But later DOSes were designed to use a FAT so it is possible to write routines to accomplish something similar. So if someone wanted to write a program back in the day that had some database functionality, it would have been much more tedious to do on an Atari versus other computers that had Microsoft Basic? I had gotten an Atari 800 in mid 1981, wrote a simple BBS for it in Atari Basic, then got an IBM PCjr in late 1984 when I started college, and rewrote my BBS on the PCjr in Microsoft Basic using random access files for the message data. That was when I really learned just how much Microsoft Basic differed from Atari Basic. With Microsoft Basic, I was able to do much more, and I wrote a more robust BBS. But I always wondered if the Atari could do Basic just as well as the best of any other computers of the time, and that I just wasn’t using the right Basic.

Are there any versions of Basic for the Atari that have the ability to do random access files similarly to Microsoft Basic (where you can read and write records that are composed of fields)? Atari Basic’s Note and Point are cumbersome. For that matter, are there any other languages that can do random access files where you can have records that are composed of fields that are strings and fields that are numbers?

Ahhh! There was my misunderstanding. I thought once the carry is set, it will remain set until it is cleared. I didn't realize that a new ADC will flip the carry back to 0 if there is no carry. Thank you!

Thank you for the explanation. But there will also be a third ADC because I am counting to 65536. If I do a third ADC and the carry bridges over to the third ADC, won't the third byte increment prematurely, and won't it increment every time the first byte goes past $FF?

Thank you for the responses. So in Rybags’ first example, there are 2 ADC’s but 1 CLC. Wouldn’t I have to put a CLC before the second ADC?

I am wondering if there is a niftier way to do this than using a lot of branching based on the carry flag, say using ADC?. Or maybe that is already the most efficient way? I am looking to use 3 bytes so the end result will be 3 memory locations reading 00 00 01.

Thank you all. Now I understand. That's a nifty shortcut using $1C00 as pmbase for player 0. Kills 2 birds with 1 stone. I now see that STA #>MYPMBASE to pmbase actually results in ANTIC seeing a $18 there. Simultaneously, MYPMBASE is already 1024 bytes after PMBASE. There is so much for me to learn ...

Thank you all for the help, and thank you Matosimi for taking the time to make some code for me! But now I am confused about something. Matosimi's example does not match the instructions in the various books, but it works. I don't know why. The books say that you have to add 1024 to PMBASE to get to the beginning of the player 0 bitmap. But Matosimi didn't do that. Matosimi placed #$1C into PMBASE, and then simply placed the bitmap 64 bytes up from $1C00 (i.e. $1C40) . How is this able to work? If I follow the books, and if I put #$1C in PMBASE, then my bitmap for player 0 would need to start at $1C00 + 1024 (i.e. $2000). Incidentally, I am not using BASIC at all, this will all be machine language. Don't know if that makes a difference.

Newbie question here. I am trying to learn player/missile graphics in assembly language. I am using Altirra 4.0 and WUDSN IDE. I am trying to write a simple program for now just to put a player on the screen. I cannot even get past the initial setup. I subtracted 8 from RAMTOP, getting a $98 in the accumulator, and I am doing a STA $D407. However, $D407 remains locked with a $FF. Even debugging in Altirra, if I use the debugger to write a number to $D407 (for example: e $d407 $98), nothing happens. Can anyone let me know what I am missing? Much appreciated!

Thank you for the detailed response. Do I need to have a ##TRACE statement somewhere? I am not using ##TRACE. I think what is happening is that the .lst file is not being created correctly for this program. I tested with a small program, and it worked perfectly (with the .lst file being populated by the listing and with Altirra showing me the source window). But with my longer program, the .lst file is only one line long, and just has "mads (generated by atasm)" on the first line, but no other lines. This is my command line: atasm.exe -ocent36.xex -lcent36.lab -gcent36.lst "cent36.asc" I am executing the command line in the correct folder, which is: F:\Atari\ATasm, and all the source files are in that folder, and all the created files are also in that folder. I put the breakpoint at line 221 in the WUDSN IDE editor. And this is the .atdbg file: .sourcemode on .echo .echo "Loading executable..." .echo bc * .onexerun .echo "Launching executable..." bp "`F:\Atari\ATasm\CENT36.ASC:221`" Altirra ignores the breakpoint. I have to press F8 in Altirra. I see the disassembly window with the correct labels, but no source listing window. The Altirra console says that it loaded the .lab file, the .lst file and the .atdbg file. It then says (among other things), Deferred breakpoint 0 set at F:\Atari\ATasm\CENT36.ASC:221. My program has .INCLUDE's in it. Could that be a problem?

I am using ATasm 1.11 with WUDSN IDE and Altirra 3.90 to try to do source level debugging. I don't think the breakpoints inserted in the WUDSN IDE are working. ATasm makes the .lab and .lst files, but the .lst file is only one line long and says, "mads (generated by atasm)". My program is about 3000 lines of code with many labels and equates, so I'm thinking that the .lst file is not being created correctly. Altirra does not give me the source code window and instead says that my breakpoint is "deferred." Any help would be appreciated. Altirra never breaks into the debugger until I manually hit F8. This is what the Altirra console window says when I manually break: Altirra Debugger 3.90 Automatic symbol loading is enabled. Use .help for a list of commands and .help <cmdname> for help on a specific command. _______ Loaded symbols F:\Atari\ATasm\CENT36.lst Loaded symbols F:\Atari\ATasm\CENT36.lab Loaded debugger script F:\Atari\ATasm\CENT36.atdbg Source debugging mode is now on. Loading executable... 0 breakpoint(s) cleared. Deferred breakpoint 0 set at F:\Atari\ATasm\CENT36.ASC:221. EXE: Loading program 0006-0007 to 02E0-02E1 EXE: Loading program 000C-0026 to 1F03-1F1D EXE: Loading program 002B-0037 to 1F36-1F42 EXE: Loading program 003C-003E to 1F5D-1F5F EXE: Loading program 0043-0045 to 2000-2002 EXE: Loading program 004A-052B to 2051-2532 EXE: Loading program 0530-0541 to 2534-2545 EXE: Loading program 0546-0557 to 2547-2558 EXE: Loading program 055C-056D to 255A-256B EXE: Loading program 0572-07C3 to 256D-27BE EXE: Loading program 07C8-07D9 to 27C0-27D1 EXE: Loading program 07DE-07EF to 27D3-27E4 EXE: Loading program 07F4-0805 to 27E6-27F7 EXE: Loading program 080A-0A03 to 27F9-29F2 EXE: Loading program 0A08-0A19 to 29F4-2A05 EXE: Loading program 0A1E-0A2F to 2A07-2A18 EXE: Loading program 0A34-0A45 to 2A1A-2A2B EXE: Loading program 0A4A-0D4E to 2A2D-2D31 EXE: Loading program 0D53-1C67 to 3000-3F14 EXE: Launching at 2000 (145:248, 0) A=AE X=0A Y=03 S=F4 P=30 ( ) 2243: B1 C1 LDA (MISCL),Y [$37AB] = $37

Thanks Jac! I will try to find his contact info.

I see ATasm's change log now says it can make the .lab AND the .lst files that Altirra uses for source level debugging. I first downloaded ATasm 1.09, but when run, it says it's version 1.06. Then, I saw a link on the sourceforge page to a github page that has version 1.11. That version creates a list file, but its contents are only a single line that says "mads (generated by atasm)". I am using the WUDSN IDE to compile an xex file and send it to Altirra. WUDSN has the parameters set to create the .lst file, the .lab file, and .atdbg file (which it does create in the same folder as the source and the xex file) but Altirra, executes xex file without loading the labels or the breakpoints. WUDSN has the correct path to Altirra, and it is Altirra version 3.90. I searched on this forum before I posted. Anyone get this working?

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 .