Jump to content

thorfdbg

Members
  • Content Count

    985
  • Joined

  • Last visited

Community Reputation

418 Excellent

1 Follower

About thorfdbg

  • Rank
    Dragonstomper

Recent Profile Visitors

10,796 profile views
  1. Bad memory, or bad delay line. Try to swap parts from a known good system.
  2. You can have access to it, obviously, and it's part of Atari++, you find it on its home page: http://xl-project.com/ I'm not sure what you mean by "you won't get anywhere with stock FP rom". You get exactly what Atari Basic delivered, and it does what it does. That's based on a couple of poor decisions made back then, but you cannot undo history. Thus, I'm not hiding anything, but in the type of tone you responded, I'd suggest you probably test yourself.
  3. That's what I did above, this is from your image. Actually, Basic++ is there tested with the Os++ math pack, which is *another* math pack. But, frankly, what's so complicated about that forbidding you to run the tests yourself? You can also cross-compare Atari-Basic/Os++, Basic++/Original math pack if you like, all these combinations work just fine.
  4. Right. There you go. There is a dependency between the mathpack entries in the original(!) unaltered(!) math pack and Basic++. If other math packs use different/other entries, not a Basic++ fault. Actually, the entries Basic++ are using are those that are also used by other carts....
  5. Of course it can. You must have made something very wrong. It's really that easy: Insert Basic++ as cartridge, start the system (actually, this was probably too obvious?)
  6. What's "Bench64"? There is no Bench64 in the github repo you quoted.
  7. That would surprise me. Where's the image to test with ("above" is probably not precise enough). From the github repo: AHL: 9.699E-03 / 5.170723 / T=45.5 Broucke: 503.543595 / 1.23 / T=7.68333333 Dolkus: 1000003 / T=9.35 RG1: T=1.1 RG2: T=3.76666666 RG3: T=11.9666666 RG4: T=13.4833333 RG5: T=14.9533333 RG6: T=22.7533333 RG7: T=31.7166666 RG8: T=9.17166666 Sieve: 1899 / T=142.33333 Thus, it seems everything is in fine working order. Details, please?
  8. Hi Simius,

     

    if there is still a Sophia2 available, and shipment to Germany is an option, I'd be interested in one. Please let me know.

     

  9. There are certainly Atari Basic variants where these problems were addressed. Basic++ is one of them. The two causes for the slowness were the rather inconvenient BCD arithmetics of the MathPack, and the line number search which was just a linear search from start to end.
  10. The traditional, old-timer approach: A compiler/assembler/linker (CA65 for the Atari projects), an Editor (emacs) and a Makefile.
  11. Capture the Flag and Wayout use a very specific algorithm to draw the maze that is not so easily adapted to more complex games. It only computes the "top edge" of the maze walls, always taking the "topmost" Y position of all the walls in your view port, then draws only the upper edges (fast), and uses a super-fast unrolled self-created program to fill the walls with solid color from top to bottom. The lower edges of the maze aren't drawn at all, but rather reflected by ANTIC by using a smart display list with a LMS instruction in each line. Hence, in specific, this algorithm cannot: Draw texture on the walls, or draw enemies with a different shape then that of the walls. A similar algorithm was used in the Encounter! game which also only draws the upper edge of the enemies and poles, then fills downwards, and reflects the upper part of the screen downwards. It is also very restrictive in what it can draw and display. Fully texctured walls and scaling of the texture and the wall requires much more computing resources and would prevent real-time performance.
  12. I doubt it. The mechanical wear is identical no matter whether the whole track or only a single sector is read. I would guess it rather depends on how often the drive head seeks, and how long the disk rotates.
  13. The boot sector does not matter unless you attempt to boot from the disk. The boot sector is only read from the bootstrap Os code, but not by the filing system. The file systems of Amiga and Atari are completely different. However, as long as the sectors and tracks of the first file system are marked "occupied" for the second file system, it does not matter. I do not assume that the file systems are identical (they are not). On which side of the disk the "other filesystem " tracks are does not matter. The Amiga uses both sides, interleaved. Hence, it does not help to isolate the alien file system on one side of the disk.
  14. This is because the Amiga does not have a floppy controller, it is all encoding and decoding by software and the custom chips. Rewriting the entire track is usually not a problem. The Amiga does have a boot sector in track #0 for booting, thus bootable disks that boot off the boot sector without a file system cannot be shared with the Atari ST. The latter uses FAT as file system and hence uses track 0 for the FAT and the MBR. However, the Amiga file system (OFS/FFS) has its directory in the middle of the disk at sector 880, and this does not interfere with FAT. Thus, in principle, one could create "dual-play" ST/Amiga disks as well, provided the Amiga version uses a custom "startup-sequence" type of boot procedure.
  15. The MathPack log10 algorithm is not so complicated, really. First of all, log10(a*10^x) = x+log10(a), so the decimal exponent can be removed. Then log10(x) with x normalized is approximated by log10(x) = p(((x-a)/(x+a))^2) where a = sqrt(10) and p is a suitable polynomial. If I recall, Atari just uses the Taylor approximation as polynomial, but that is definitely a bad choice. For Os++, I replaced it by the minimax polynomial, i.e. the polynomial that minimizes the maximal error. Atari also uses a 10th order polynomial, which is total overshoot. The 8th order minimax polynomial is better, and faster. The minimal polynomial is just that: (from my sources) ;;; The following is the minimax polynomial for the log approximation: ;;; 0.8685889625 + (0.2895298827 ;;; + (0.1737063251 + (0.1243413535 + (0.09348240142 + (0.09879885753 + (-0.004411453333 + 0.18 06407195 ;;; x) x) x) x) x) x) x ;;; ;;; It causes an approximation error that is as small as 4^-11. ;;;
×
×
  • Create New...