StevenLee Posted January 1, 2020 Share Posted January 1, 2020 Hi I'm new 6502 assembly programing and have a question about errors I'm getting with mac/65 version 1.00 The code starts at $3500 and has roughly 1160 lines number in it. assembling the code without .opt obj and it assembles fine, but if I add "10 .opt obj" I get an error at 290 saying scrmpl is undefine. Even though it is defined at the top of the listing? this seems to happen when the code gets too long. Why? 1 Quote Link to comment Share on other sites More sharing options...
StevenLee Posted January 1, 2020 Author Share Posted January 1, 2020 Incidentally, the error also lock up the computer. Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted January 1, 2020 Share Posted January 1, 2020 Did you do the "test assemble" first ASM ,#- this may point out any errors. To view the assemble in progress just type ASM (without the .OPT OBJ) and follow through the memory locations on screen to see if they stay at $3500 as you would expect. Pause/resume with Crtl-1. [edit] Check line 290 and see what address it thinks "scrmpl" is at, also check it in the symbols at the end of the assemble too. What is scrmpl, just a variable you are using? You said it is at the top of the listing so perhaps it is a variable and you havent assigned it to a memory address? You could add another section e.g. *=$3000 and then put it here before your *=$3500 where your existing program runs from etc. If it locked up the computer you are probably overwriting (accidentally) some memory range that is used by the assembler itself: you cannot use Page 0 locations and have the cart in so if you are doing that create an OBJect file and run it from DOS ASM,,#D:FILENAME.OBJ Have you seen the first part of my "How not to learn Assembler" colum in the latest Pro(c) Atari Mag? I'm covering primarily MAC/65 and Assembler Editor? 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 1, 2020 Share Posted January 1, 2020 With Dos 2.5 loaded you'd probably have a MEMLO around $1D00. Throw in 1160 lines at 5 bytes each would mean your source ends about $3470 Fairly sure Mac-65 work area during ASM would be straight after the program so that'd push it further. So, just about 100% chance you've overwritten the end of your program and/or the work area. Work area probably has pointers which get corrupted such that hardware and OS low memory gets hit which contributes further to the problem. 2 Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted January 5, 2020 Share Posted January 5, 2020 Yes Rybags has probably hit the nail on the head (as usual)! If you use the SIZE command the 2nd number shown is the end of your program in RAM so you can adjust things, or just run your program from DOS or assemble it to an executable etc. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 5, 2020 Share Posted January 5, 2020 End of program isn't where you can assemble to either. I'm not sure of the figure or if it's easy to estimate but the assembly process will bloat that out by some probably variable amount then release it again. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted January 23, 2020 Share Posted January 23, 2020 Further, please try the cart version 1.02: https://atariwiki.org/wiki/Wiki.jsp?page=Mac65 Quote Link to comment Share on other sites More sharing options...
tsom Posted June 22, 2020 Share Posted June 22, 2020 Hello, I'm having a similar issue, but running on an actual 800XL (with a SIO2SD as a "disk"). I have an .atr of DOS 2.5, and a Mac/65 1.01 physical cartridge. I have a very simple application I'm trying to compile, just to see it work on actual hardware. Looking at the "SIZE" values, I made sure the code is well within and above used memory (.ORG of $5000, and some small P/M data at $6000). The source is about 5539 bytes, and built code is 307, so it's not huge. If I try to build without the .opt obj compiler option, all is fine. But, if I add an .opt obj (so I can see the code in the DDT debugger), I get the same UNDEFINED errors for SOME labels, mostly ones that are forward referenced (but not all...). I tried to duplicate this, using Atari800MacX, with a DOS 2.5 .ATR, and the Mac/65 1.01 cartridge image. Oddly, I had NO issues compiled with and without .opt obj. I'm stumped! Thoughts? Thanks! Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 22, 2020 Share Posted June 22, 2020 With the emulator though, is the Dos environment the same? Another idea - assemble to an object file on disk, then BLOAD it into memory and see if anything weird occurs. Quote Link to comment Share on other sites More sharing options...
tsom Posted June 22, 2020 Share Posted June 22, 2020 10 minutes ago, Rybags said: With the emulator though, is the Dos environment the same? Another idea - assemble to an object file on disk, then BLOAD it into memory and see if anything weird occurs. As far as DOS, yeah, I'm using the same version. I even tried a couple versions (2.0s, 2.5), but emulated, it all works fine. I did try to assemble to disk, but I used the wrong command so got a bad file, and didn't have time to try again (I didn't at first realize why it wouldn't run when I tried.) I do want to try another DOS version on the hardware to see. Thanks Quote Link to comment Share on other sites More sharing options...
tsom Posted June 22, 2020 Share Posted June 22, 2020 1 hour ago, tsom said: As far as DOS, yeah, I'm using the same version. I even tried a couple versions (2.0s, 2.5), but emulated, it all works fine. I did try to assemble to disk, but I used the wrong command so got a bad file, and didn't have time to try again (I didn't at first realize why it wouldn't run when I tried.) I do want to try another DOS version on the hardware to see. Thanks I did some tests in the emulator. I loaded up the .ATR I was using in the SIO2SD into the emulator, with the 1.01 cartridge. The .ATR is formatted with DOS 2.5. When I tried to compile, I was getting the UNDEFINED errors. Then I tried loading an ATR of DOS 2.0s and loading and assembling the code, and it all worked fine. So.. it looks like it's something with DOS 2.5? Here are the values of SIZE for each version: DOS 2.5 1C6C 1E6C 9C1F - empty 1C6C 30E8 9C1F - loaded DOS 2.0s 1EFC 20FC 9C1F 1EFC 3378 9C1F Just for grins, I loaded up with DOSXL 2.3. That failed even worse, with a BUNCH of "ERROR 13, PHASE" errors on almost all labels. I guess I'll stay away from that! Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 22, 2020 Share Posted June 22, 2020 You shouldn't be hitting anywhere near the workspace with the object. If it is happening in emulation you could set some write breakpoints to see where the workspace tops out. e.g. try $4F00 and a few points -256 bytes at a time. Quote Link to comment Share on other sites More sharing options...
tsom Posted June 22, 2020 Share Posted June 22, 2020 11 minutes ago, Rybags said: You shouldn't be hitting anywhere near the workspace with the object. If it is happening in emulation you could set some write breakpoints to see where the workspace tops out. e.g. try $4F00 and a few points -256 bytes at a time. Yeah, it's a small enough program that it shouldn't be overwriting anything. I'm not sure how to do what your suggesting, however (again, I'm using Atari800MacX, not Altirra). Quote Link to comment Share on other sites More sharing options...
tsom Posted June 22, 2020 Share Posted June 22, 2020 (edited) 40 minutes ago, Rybags said: You shouldn't be hitting anywhere near the workspace with the object. If it is happening in emulation you could set some write breakpoints to see where the workspace tops out. e.g. try $4F00 and a few points -256 bytes at a time. I tried varying the starting address of the code. Somewhere between an .org of $4000 and $4100 causes the problem ($40C0 has errors, $40D0 does not) So if I'm reading the SIZE info correctly: 1C6C 30ED 9C1F 30ED is the end of where the used memory is. But after that is the symbol table info? So 30ED to around 40C0 would be the symbols? that's almost 4k for symbols for this tiny program... (this is all with DOS2.5.. I'll try the same tests with DOS 2.0s and see if I can get it to fail similarly) Ok quick testing with 2.0s, with the SIZE info of: 1EFC 337D 9C1F I can set the org to as low as $3400 and it compiles fine. So I don't know what DOS 2.5 is doing in there... That's the only difference. Edited June 22, 2020 by tsom Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 22, 2020 Share Posted June 22, 2020 The SIZE is a momentary thing. When you start an ASM that second number will grow upwards. Work area would have stuff like label names/definitions, branch and jump destinations, any addresses that need the 2 passes to resolve. Quote Link to comment Share on other sites More sharing options...
tsom Posted June 23, 2020 Share Posted June 23, 2020 Well, at this point, I’ve think the moral of the story is... stay away from DOS 2.5! 1 1 Quote Link to comment Share on other sites More sharing options...
Kenshi Posted September 26, 2022 Share Posted September 26, 2022 Man, this thread really helped me tonight. I just added some data at the end of my program, and it started giving an error that one of my branches was too far. The error had nothing to do with what I had changed and my branch was only about 30 bytes. I tried changing a few things to see if I could get it to assemble but it just caused more errors. After reading this, I moved the start of my program from page $30 to $40, and now it's fine. 1 Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted September 26, 2022 Share Posted September 26, 2022 Unless I know for certain the area of RAM is definitely free, i.e. Page 6, I always used to compile to disk. Generally the programs I wrote would be designed to either be boot disks or have a start address of $2000. So compiling to memory was always a no no, learnt the hard way like the topic starter, wrote some code, compiled it and locked the machine when assembling to memory. I still use MAC/65 a little these days, but MADS rules Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.