Jump to content

Pab

Members
  • Content Count

    157
  • Joined

  • Last visited

Community Reputation

74 Excellent

About Pab

  • Rank
    Chopper Commander

Recent Profile Visitors

4,369 profile views
  1. I only had to make one minor change to tebe's code. In Sparta a Print statement without an EOL will be immediately overwritten by the command prompt when control returns to DOS. I had to try it under AtariDos to make sure it was outputting and I didn't have a new bug on my hands. Anyway: here's proof of the fix.
  2. Had to go back reading through this thread to figure out where I had left off. Shocked to see how close I actually was when things fell apart.
  3. I'll try to have an updated build out this week.
  4. So today I finally got back into the code to try and figure out what was going on. I spent the better part of a month trying to track this down while distracted with everything else before laying it aside. I was ready to gut my expression evaluation code and start over. So today I updated to the newest build of Lazarus, thinking some bugs in that compiler might be causing problems with my stepping through and tracking down the bug. I was right. Once I was able to step through the execution without it bombing back for some reason, I found the problem. All this time planning to pull out and replace the entire expression evaluation system and rewrite it? All I had to do was change: s := AnsiRightStr(st,Length(st) - LinePosition); to s := AnsiRightStr(st,Length(st) - LinePosition + 1); What happened with tebe's code is that instead of parsing and compiling "x+5" the compiler only saw "+5" and added 5 to the current value: 0. ... Months of trying to find the problem and then two years of worrying about it on top of everything else and it was STARING ME RIGHT IN THE FACE. tebe's code now shows the correct result. I need a drink before I get back into this.
  5. Hello, folks. Well, I spent the last two years fighting foreclosure and losing. We then needed to find a new house. So we found a cheap one in Western New York near my mother. Then right after we closed on the house my mother died. Anyway, I've been distracted. Update will follow.
  6. I looked at Effectus a while back. I didn't think it was still being worked on. However, it looks like he and I are both using the same language to develop (Free Pascal is the core of Lazarus, which I'm writing in), so maybe we could benefit with cross-pollination.
  7. I will say that the problem is obviously in the code that parses a mathematical expression. Nowhere near my home machine at the moment, but I will bet that if you replaced the assignment with "x=78+5" or "x==+5" (which compiles differently) it would work. This portion (in the source program it's the procedures EvaluateMathExpression and CompileMathExpression) has plagued me since day one. I'm tempted to rip it out and replace it with something else. Help would be appreciated.
  8. Will investigate. Can you post your object code?
  9. Yeah. Very little is handled at run-time. About the only time the CPU has to figure out what memory it should be working with is within object methods themselves. Otherwise, it's all on the compiler. One feature of OOP I'm not sure I will be able to pull off, and might not even try, is abstraction. Allowing the overriding of methods or creation of virtual methods would require the CPU to figure out what routines to call at runtime. That is theoretically possible, but would require memory (three bytes for every method in every instance of a class) and time (looking up the addresses to call for a particular instance) so it might not be worth implementing, At least not yet. 32 bit math, by the way, is basically done and working in the last build I released, along with LONG 32-bit integers. The only part of math (both 16 and 32 bit) that isn't working right now is signed division because I'm too lazy to write those routines. At least right now. The interview was recorded in February, so I've made a lot of progress since then.
  10. At this development stage, the banking code is in every compiled program, but that will change. Once I have things stable and just about everything implemented the last big step will be implementing two-pass compilation. That means that any code (routines INCLUDEd or USEd in libraries, micro-runtime, and banking code) that isn't used by the actual program will not be compiled.
  11. I always thought that the "I/O Sounds" thing was a side effect they eventually adopted as a "feature." Remember that SIO was controlled by POKEY, which was also responsible for sound. As for why the cassette warbled, what you heard with the cassette was the actual analog data being read. The Atari cassette drives were four-track with two per side. One channel (I think it was the "Left" channel in audio production terms) read the data into the computer. The other channel was what would play through the TV speaker. The idea was that a developer could set it up so that while the cassette loaded, the user could hear instructions, information, or some other audio track associated with the program. I only know of one series of programs that actually used this feature. The "learn a language" software from Atari (forget the series name) used the cassette audio tracks for actors speaking the words that were shown on the screen. The program would start the cassette, and play as long as there was a carrier signal on the data track. When the data track ran out, the program would stop the cassette. This is how the program "knew" how long to play the audio. And made it really easy to adapt the program for different languages. Just for fun, I "converted" the first few lessons into "Conversational Esperanto" just as a proof of concept. Since the 410 just wrote the same sound to both tracks, most users only ever heard the "warbling."
  12. Paying work has kept me busy. Will be updating soon.
  13. Update: If there is a build this week, it's going to be a maintenance one instead of adding anything big. I've been struggling with two major bugs that presented themselves. First is one that keeps WHILE loops from ever executing. They would immediately bomb out to the code after the loop. I've already got this one fixed. Second is a glitch that is causing local variables to also be defined as global variables with the same name. I actually discovered this while trying to debug a program I wrote to test my joystick routines. The local "x,y" variables I was trying to use were being confused with the x,y arguments in one of the functions in the GRAPHICS unit, and since those weren't allocated but just placeholder names, boom crash. This is a serious enough bug to shut down everything else I was working on to sort out, and as soon as I have it working properly I will rush out the build to fix it.
  14. Thank you. It's been a chore, but a labor of love at the same time. It's nice to know it's appreciated, and that it might be useful to some folks.
  15. It was pretty much the same case with me. When I had enough to buy the cart I was disturbed to discover that it was just as much to buy the Runtime Library. or else I would never be able to distribute my stuff. Then I discovered the PD Action Runtime Library and was finally able to put stuff out in the world. Thank you. I had the idea years ago and it's only now that I can work on it. Emulation was still very crude in 2006 and I didn't really have the tools needed to properly debug the output from a compiler. Now thanks to Altirra I can see the resulting code, single-step through it, and then figure out where I screwed up in my code to create such a monstrosity. Not at all! It's what I'm hoping for, really. I'm going to open a GitHub repository for the Runtime Library and hope to have others join in the effort. Especially when it comes to fixing the bugs I know I'm not catching. I've started down that road. The compiler now has 32 bit math built in (although I need to do some rewrites to support signed division) and long integer variables. I've abandoned native floating point but I imagine a class could be written to support it for those that need it. The beginnings of memory management can be found in the MEMORY.ACC unit and I would welcome people who could expand on that. One of my inspirations for this project has been the SpartaDOS X project: a bunch of people taking an existing product and moving it to the next level as a collaboration. I would love to see other people get on board both on the Atari side and eventually on the PC side debugging and improving the cross-compiler. Although I haven't given up on my dream of a native compiler that would run on an XE, it's just that I'd need a team of volunteers for that.
×
×
  • Create New...