Jump to content

Ed Minchau

Members
  • Posts

    342
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by Ed Minchau

  1. Yes,.and it isn't a single point of failure anywhere if they can help it. Multiple processors have to agree. Updating is non-trivial, particularly when it's the software that aims the antenna. I said before that vger is basically a C64, but it's a 22 bit system IIRC and a lot of that is devoted to error correction.
  2. Voyager is basically equivalent to a C64, but a lot harder to program.
  3. Hmm... I wonder if I can get Bil Herd to sign my VIC-20...
  4. No, I avoided logs. I initially tried using an 8 bit log method for division and the error bars were huge and bimodal.
  5. If you've got the value in A, and you've already determined that it's negative (bit 7 = 1), then that works. The FABS table just avoids having to do the compare and branch, saving a few cycles.
  6. 65c02 only, because I'm using the BBR/BBS commands. And although there are 50, quite often there's only small differences, such as a 2d vector version and a 3d vector version.
  7. Version 2 has been uploaded here: I've shuffled some things around and managed to add 14 new subroutines. Two of them are for saving and restoring the data in zero page addresses F0-FF, so that FASTMATH doesn't stomp on BASIC. Four of them are for type conversions between 2 or 3 byte integers and the fractional notation used by FASTMATH (which on reflection is really a sort of floating point notation without the logarithms). There's also a new Clamp function, Determinant, and 4 functions for adding or subtracting 2d or 3d vectors. I also rewrote the ATN function and modified the lookup table it used significantly, and now there are three arctan(x,y) functions available, with precisions of 8, 9, or 10 bits. I've got something special coming soon to demonstrate this in action.
  8. Version 2.0.0

    11 downloads

    When programming in assembly language, quite often you will need to do calculations that would normally require floating point math. Those subroutines are available, the same ones that BASIC uses, but they are very slow. And if you're programming in assembly, you're doing so because it's much faster than BASIC, so using those routines can defeat the purpose, particularly if you need to do a lot of such calculations. Ideally in assembly language you want to have most of your variables consisting of single bytes, not the five used for floating point. It's having to move all those bytes around and doing calculations involving all of them that makes the floating point subroutines slow. And if you're going for speed, you can make a tradeoff: increased speed at the expense of accuracy. A function involving a single byte can just be a lookup table. Over the last several years I have developed a number of lookup tables and subroutines that enable some very fast math on the 6502 and now 65c02. FASTMATH.BIN is many of them compiled into a single 8kb file that can be loaded into banked RAM. These lookup tables and functions will work on all revisions of the X16 emulator, and indeed will work on any 65c02 system as long as the file is loaded at $A000. The functions are all called through JMP redirects in page BF, and those JMP table locations will not change if I do revisions on the code. I'm pretty sure I killed all the bugs, but some might have slipped through. This is probably going to be the final revision of FASTMATH, barring some sneaky bug hiding in the code. There's only 6 bytes left anyhow. The file fastmath.txt contains detailed information about each lookup table and function and how to use them. The file FASTMATH.BIN is the binary that must be loaded into banked RAM.
  9. FASTMATH View File When programming in assembly language, quite often you will need to do calculations that would normally require floating point math. Those subroutines are available, the same ones that BASIC uses, but they are very slow. And if you're programming in assembly, you're doing so because it's much faster than BASIC, so using those routines can defeat the purpose, particularly if you need to do a lot of such calculations. Ideally in assembly language you want to have most of your variables consisting of single bytes, not the five used for floating point. It's having to move all those bytes around and doing calculations involving all of them that makes the floating point subroutines slow. And if you're going for speed, you can make a tradeoff: increased speed at the expense of accuracy. A function involving a single byte can just be a lookup table. Over the last several years I have developed a number of lookup tables and subroutines that enable some very fast math on the 6502 and now 65c02. FASTMATH.BIN is many of them compiled into a single 8kb file that can be loaded into banked RAM. These lookup tables and functions will work on all revisions of the X16 emulator, and indeed will work on any 65c02 system as long as the file is loaded at $A000. The functions are all called through JMP redirects in page BF, and those JMP table locations will not change if I do revisions on the code. I'm pretty sure I killed all the bugs, but some might have slipped through. This is probably going to be the final revision of FASTMATH, barring some sneaky bug hiding in the code. There's only 6 bytes left anyhow. The file fastmath.txt contains detailed information about each lookup table and function and how to use them. The file FASTMATH.BIN is the binary that must be loaded into banked RAM. Submitter Ed Minchau Submitted 06/23/22 Category Productivity Apps  
  10. Based on that, I'd say the extra cost of 3 more RAM ICs to make a 2Mb system the base model is worth it. There are PCB production houses that can put together a board, even through hole, for a lot less than that. I know, I used to work at a couple such places doing just that, and operating the SMT production line. And if we get to the point of making a surface mount version, then we're looking at a lot less than I paid for my VIC 20 back in the 80s.
  11. I'm using something like that for Asteroid Commander. The tokens are used as lookups to a table in low RAM; the table contains a pointer into VRAM, and individual words or phrases ("would you kindly ") are stored there. The last character in the string has bit 7 set to 1, so BPL allows a loop back to get the next character. I have the strings in VRAM because I'm just moving stuff from one part of VRAM to another, but there's no reason the address pointers couldn't go into a RAM bank instead.
  12. What is the cost difference for 3 more 512x8 SRAM ICs? 20 bucks US? If it's 10% of the total cost, I'd say it's worth it to make them all 2Mb machines, and make that the lowest common denominator, because the LCD is what programmers will write for. Quadruple the embarrassment! Having said that, here's some assembly language code to determine the max RAM bank number: LDA #FF STA 00 STA A000 SEC SBC #40 CMP #FF BNE #F4 STA 00 CMP A000 BEQ #07 SEC SBC #40 CMP #3F BNE #F2 RTS
  13. It really depends on the total life cycle of the software. For an operating system, those old pieces of sloppy code and kludges are in many cases the source of the security holes that later take orders of magnitude more man-hours to fix, distributed over the customer base. For something like 2048, there isn't much chance of that code being a dependency for other code. What I'm really going on about here is "technical debt" and the compounding problem when the code is a dependency for other software.
  14. There is a flip side of course: code that just barely works is a lot faster to write than optimized, correct code. Faster to write means it costs less, and fixing it can be some other guy's problem.
  15. I believe programmers have been spoiled by Moore's Law. "Program runs slow? No problem, new computers next year means the program will run twice as fast!" But it isn't actually running the software faster, just the hardware. And so poor code stays, and becomes a dependency for other code, and you end up with a geometric expansion of code that not only runs poorly, but cannot be fixed because that will screw up other code for which it is a dependency. So you end up with technical debt that never gets paid, kludges and cruft, and Windows Vista is the result.
  16. This isn't quite the way it would be done on the X16 but is very informative:
  17. I don't. I just have things that need to happen at some multiple of 1/60 second instead happen shortly afterwards. I break long sections of code up into multiple sections ( each should be much less than 1/60 of a second), and then in between those sections call the HandleFlagsAndEvents subroutine, a very short chunk of code that checks for things like the ClockRisingEdge flag (which is set by my IRQ). If that flag is 1, then any events that need to use the VERA channels or RAM banks are free to do so. These events need to be very short, such as pushing a 64 byte buffer into the PSG memory. After events like that are handled, control goes back to the long subroutine. Ideally HandleFlagsAndEvents is called many times every 1/60 of a second, does almost nothing most of the time and returns quickly.
  18. Well, I have a couple of routines that take a really long time. The subroutine that redraws the asteroid if you move or rotate your view takes about 2 million cycles. When it's in the middle of doing its thing it's using both VERA channels and bouncing around in various RAM banks. I have that subroutine broken up into 22 parts, though I could break it up further if necessary. Each time it's starting a new part of the asteroid to draw, it sets the VERA channels. So, in between each of these 22 (or 44, or whatever I eventually decide) parts, it checks the flag bits set by the IRQ and does whatever (very short) subroutines it needs before returning to the next part of the Draw routine. My IRQ just alerts the rest of the program that an event needs to take place, and regular checks of those flags in the rest of the program allows those VERA channels to be switched to different addresses without affecting other subroutines, and without the dance of addresses required if doing things within the interrupt subroutine.
  19. That works for some of them. PRINT# is pR, but PRINT is ?.
  20. Try using the FETCH kernal subroutine; that lets you read data from another bank.
  21. I had this in mind when I was making FASTMATH. I think I can find a way to do really fast conversion from 16.8 fixed point to the fractional notation and back so you can take full advantage of it.
  22. Version 1.3.41.0712

    22 downloads

    The META/L editor is a direct assembly language editor. It shares some features of a Monitor program, with extensive use of metadata to take it well beyond anything a Monitor can do. Unlike a text editor that later compiles your code, META/L interprets it as assembly language opcodes as you type it. Unlike a Monitor, you can do things like copy and paste code, move it around, or insert or delete bytes in the middle of your code; the metadata allows the editor to adjust parameters as labels move. Every byte of RAM and ROM is accessible to you on the fly. Download the zip file, unzip it somewhere, and copy everything into the same folder as your r41 emulator. Full documentation is in the file docs/edit.html This software is released under an MIT license. There are also a number of videos in the forum here
  23. META/L assembly language editor View File The META/L editor is a direct assembly language editor. It shares some features of a Monitor program, with extensive use of metadata to take it well beyond anything a Monitor can do. Unlike a text editor that later compiles your code, META/L interprets it as assembly language opcodes as you type it. Unlike a Monitor, you can do things like copy and paste code, move it around, or insert or delete bytes in the middle of your code; the metadata allows the editor to adjust parameters as labels move. Every byte of RAM and ROM is accessible to you on the fly. Download the zip file, unzip it somewhere, and copy everything into the same folder as your r41 emulator. Full documentation is in the file docs/edit.html There are also a number of videos in the forum here Submitter Ed Minchau Submitted 05/28/22 Category Productivity Apps  
  24. I took the month of March off from programming altogether, and then at the end of March r39 dropped with some breaking changes. So I've updated the editor to accommodate those changes, and while I was at it fixed a bunch of minor bugs and added some new features. The download is here:
  25. If the only time you access VERA is during the VBLANK, then great, access it then. But if you're using VERA to store sequential data, like @Jeffrey did with the Wolf 3D wall images, then changing any parameters in VERA can really screw things up in a hurry. So I guess it all depends on how you want to use VERA. Asteroid Commander uses lots of sequential data stored in VRAM for various purposes. If I try updating the screen every VSYNCH or even every third one, it'll stomp all over a whole bunch of things. But if the only time you're accessing VERA is to push data to the screen and PSG/PCM, like I was doing with the Balrog video demo, do it all in the VBLANK.
×
×
  • Create New...

Important Information

Please review our Terms of Use