Jump to content

Pab

Members
  • Content Count

    157
  • Joined

  • Last visited

Everything posted by Pab

  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.
  16. Yeah, there were a few hacks of the XF551. I had three: a stock model, one with Bob Puff's 3.5" mod (not the dual drive mod Mat*Rat reviewed in your link) and one that held my hard drive. Since the XF's mechanical guts were just standard PC fare, I took the drive mechanism out and used its power supply to feed a SCSI drive connected to my Black Box by a ribbon cable out the back. Eventually I just connected the 3.5 mechanism direct to the Floppy Board and took the box off the SIO chain. By the time the XF came out, the PC and Mac had set the standards for hardware, and it was not only cheaper for Atari to use the same mechs as the "big boys" but smarter. It was so much easier to repair an XF than a 1050 since you could just chuck the mech for a new one if the heads got damaged or the motor stopped spinning. Unfortunately, Atari not only tried to save money on the hardware end but on the firmware end, which is why we ended up with the FUBAR code that ran the thing and I'm sure makes it a pain to emulate properly.
  17. Been concentrating on the RTL this week, so I'm going to post this one on its own. This is GRAPHICS.ACC, the base graphics routines. MODULE // Should always be in the main bank. USES IO BYTE Color DEFINE NOARGS PROC Graphics(BYTE mode) [$A5$A0$48$A9$53$8D$80$04 $A9$9B$8D$83$04$8D$81$04 $A9$45$8D$82$04$A2$60$A9 $0C$9D$42$03$8D$42$03$20 CIO $A2$00$20 CIO $A9$82 $8D$44$03$A9$04$8D$45$03 $A9$0C$8D$4A$03$A9$00$8D $4B$03$A9$03$8D$42$03$20 CIO $A2$60$A9$03$9D$42$03 $A9$80$9D$44$03$A9$04$9D $45$03$68$A8$D0$01$60$29 $30$49$10$09$0C$9D$4A$03 $98$9D$4B$03$4C CIO] PROC Position(CARD x BYTE y) [$A5$A0$85$55$A5$A1$85$56 $A5$A2$85$54$60] PROC Plot(CARD x BYTE y) [$20 Position $A9$06$85$A0 $AD Color $85$A1$4C PutD] PROC DrawTo(CARD x BYTE y) [$20 Position $AD Color $8D$FB$02$A2$60$A9$11$9D $42$03$4C CIO] PROC Fill(CARD x BYTE y) [$20 Position $AD Color $8D$FD$02$A2$60$A9$12$9D $42$03$4C CIO] PROC SetColor(BYTE Col,Hue,Lum) [$A4$A0$A5$A1$0A$0A$0A$0A$99$C4$02 $A5$A2$18$79$C4$02$99$C4$02$60] BYTE FUNC Locate(CARD x BYTE y) [$A5$A3$85$55$A5$A4$85$56 $A5$A5$85$54$A9$06$85$A3 $4C GetD] UNDEFINE NOARGS
  18. Quick question: Other than library functions (since the RTL is still very much a work in progress), is there any aspect of the Action language I haven't recreated in Accomplish? Considering that TYPE is replicated in object classes (in fact, TYPE is aliased to CLASS in the compiler) and the SET directive is meaningless on a cross-compiler, I think the pointers were the last big hurdle. I'd like to start clean-up on some of the things I've saved toward the end (arrays in objects, error handling during compilation) and then move on to the biggest part of this stage: implementing two-pass compilation. But before I do all that I'd like to have the language itself pretty much locked down until after release.
  19. This week's build - version 0.4.0.18 Major additions: Command line compiler - Command line version of the compiler. Syntax ACCOMP -i source -o object [-l logfile] [-c codelog] LONG variables - signed 32-bit variables. Also includes 32-bit math calls for ML routines, LONG POINTERs and LONG ARRAYs. Addition of InputSD routine to read text line from a file. Other permutations forthcoming. Support for XEX and EXE extensions when saving file. Full changelog follows: Changes in version 0.4.0.18 GUI === * Fixed bug where Tab key would take focus away from the editor instead of inserting spaces. * Added support for XEX and EXE extensions in dialog when saving object code. * Fixed bug where right-click on editor window would open menu that should have been for the tabs. COMPILER: ========= * Included command line version of the compiler. * Support for LONG variables - Signed 32-bit integer * New labels for ML code pointing to 32-bit math package: !ADD32 !SUB32 !MULT32 !DIV32 * Abandoned support for floating point variables. * Now treats ATASCII EOL as a carriage return in source files, allowing compiling of ATASCII files without conversion. * Pointer support finalized. * Added ability to define an array in code through [ ] codeblocks without specifying allocating 0 bytes as previous versions had required through an oversight of mine. Arrays defined this way are theoretically open ended. RTL: ==== * Had left "DEFINE NOARGS" out of portions of MEMORY.ACC where it should have been. This led to a lot of bytes being needlessly allocated. Fixed. * The following calls added to IO.ACC: PROC StrL(LONG l STRING POINTER s) PROC InputSD(BYTE d STRING st) PROC PrintLD(BYTE d LONG l) PROC PrintL(LONG l) PROC PrintLDE(BYTE d LONG l) PROC PrintLE(LONG l) Accomplish compiler 0.4.0.18 4-21-15.zip
  20. Hi, folks. I'd hoped to have the new build out today, but I'm adding a few bells and whistles. Expect the build by some time tomorrow afternoon.
  21. Thanks, all.. I always had a problem with the theory of binary division and while what I had worked for 16/8 bit, when I tried scaling it up I just couldn't get it to work.
  22. Here's what I've been working with, based on different routines I've seen. Using the rotate/subtract method. Complete gibberish as the result. 10 DIVISOR = $CF 20 DIVIDEND = $CB 30 REMAINDER = $D8 40 RESULT = $D4 50 SCRAP = $E0 60 DIVIDE LDA #0 ;preset remainder to 0 70 STA REMAINDER 80 STA REMAINDER+1 90 STA REMAINDER+2 100 STA REMAINDER+3 110 STA RESULT 120 STA RESULT+1 130 STA RESULT+2 140 STA RESULT+3 150 LDX #32 ;repeat for each bit: ... 160 DIVLOOP ASL DIVIDEND 170 ROL DIVIDEND+1 180 ROL DIVIDEND+2 190 ROL DIVIDEND+3 200 ROL REMAINDER 210 ROL REMAINDER+1 220 ROL REMAINDER+2 230 ROL REMAINDER+3 240 TXA 250 PHA 260 SEC 270 LDX #0 280 LDY #4 290 LP1 LDA REMAINDER,X 300 SBC DIVISOR,X ;substract divisor to see if it fits in 310 STA SCRAP,X 320 INX 330 DEY 340 BNE LP1 350 BCC SKIP ;if carry=0 then divisor didn't fit in yet 360 LDY #4 370 LDX #0 380 LP2 LDA SCRAP,X ;else save substraction result as new remainder, 390 STA REMAINDER,X 400 INX 410 DEY 420 BNE LP2 430 INC RESULT ;and INCrement result cause divisor fit in 1 times 440 SKIP PLA 450 TAX 460 DEX 470 BNE DIVLOOP 480 RTS
  23. I'm looking for a good assembly routine to divide a 32 bit integer by a 16 bit integer, leaving a 32 bit result. The only routines I have on hand are for dividing 64 bit by 32 bit to leave a 32 bit result, or to divide 32 bit by 16 bit leaving a 16 bit result. Neither quite fits my case. For example, I'd like to be able to divide $400000 by $20 and end up with $20000. Anyone have any code handy for this?
  24. Not sure it's enough of a milestone to release the build (unless you folks want it/need it badly enough), but at long last I have pointers working. If there's no outcry for an immediate release I'll start work on a few other things looking toward a build in the middle of next week.
  25. Quick poll question for future builds: Since the project is pretty well along now, and the compiler becomes more functional with each build I release, would you folks prefer that I bundle the source code separately? Say have one ZIP with the GUI compiler, the forthcoming command line compiler, and the RTL and a separate one with the Lazarus source code for those who want to play around with that?
×
×
  • Create New...