Jump to content

tokumaru

Members
  • Posts

    289
  • Joined

  • Last visited

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Rio de Janeiro - Brazil

Recent Profile Visitors

12,182 profile views

tokumaru's Achievements

Moonsweeper

Moonsweeper (5/9)

90

Reputation

  1. I haven't had any issues myself, because I mostly use old CRTs for my retro gaming needs, but I've heard of cases where capture devices and modern TVs/monitors would have a hard time locking to non-standard video signals, sometimes refusing to display anything. I can't recall of any sources for this though, so take it with a grain of salt. Sorry if I can't be of much help, hopefully someone more knowledgeable on video signals can give you a better answer.
  2. That's a really good idea! Definitely the best so far! The explanation is that each digit in the BCD number has its worth: the top one is worth 0.1 and the next one is worth 0.01. So instead of converting the BCD number to a large binary number (which requires a large lookup table to to be converted into a fraction), we convert each digit of the BCD to a fraction first, according to their worth, and then we add the two fractions for the final result. It's pretty fast and uses much smaller look-up tables, since the input only goes up to 9. The first table contains the binary representations of 0.00, 0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08 and 0.09. The second table contains the binary representations of 0.00, 0.10, 0.20, 0.30, 0.40, 0.50, 0.60, 0.70, 0.80 and 0.90. EDIT: The scr means "score". It's the byte containing the 2 decimal digits in BCD format.
  3. I wouldn't deviate much from the standard, specially now that we rely heavily on digital devices to process these video signals, and most of these decoders aren't as tolerant as analog TVs were back in the day.
  4. That's quite the optimization of the / 16 * 10 part, good job!
  5. If that's the case, then one of two things must happen: 1- The fractions look-up table needs to have "holes" in it, for all $xA-$xF values, which are skipped in BCD. OR 2- The BCD value has to be converted to binary before it can be used as an index into the look-up table: binary = (bcd & $f0) / 16 * 10 + (bcd & $0f)
  6. Time to do some debugging, I guess... can you trace through the program in a dubugger to see when exactly things don't go as you expect them to? I noticed that your table goes straight from the value for 9 to the value for 10, so I assume that the original number is not in BCD format... How are you calculating that (the look-up table index, I mean)? EDIT: If the input digits are separate, you'd need to do tens * 10 + ones in order to calculate the index to use with the look-up table. For example, if the user selects 2.67, and you have the values 2, 6 and 7 in memory, you have to do 6 * 10 + 7 to calculate the index. If the multiplication is an issue, another small table can be used to multiply values 0 through 9. If you did it like this, preparing the fractional part in assembly would be super easy: ldx tens lda times10, x clc adc ones tax lda fractions, x sta speedlow ;this is the bottom of the 8.8 Sorry if I can't do the bB equivalent from the top of my head, but if you show me what you have, maybe I can help.
  7. It's one less because you're rounding them down for display, but before rounding, during physics calculations, the numbers are closer to the ideal values. You said that the user inputs fractional numbers that you then need to encode to binary. Due to lack of precision and rounding errors, the values will indeed be slightly off if you try to convert them back, so this kind of round trip should be avoided.
  8. Oh, so you do want to go from decimal to binary! The user can pick anything between .00 and .99 for the decimal part and you have to convert that to binary to do the physics calculations, is that it? I don't have any experience with bB, so I don't know how exactly the source number is stored (is it BCD? 1 byte per digit?), but the math would go something like this (with an example input of 2.52) 1- Convert the fractional input from decimal to binary (52 -> $34) and save this as the integer part of an 8.8 number. 2- Divide the 8.8 number by 100, so the integer part becomes a fraction and the integer part becomes 0 ($3400 / 100 = $0085). 3- Convert the integer input from decimal to binary (2 -> $02) and use this as the integer part of the 8.8 number. The final result is $0285 (with bB using it as $02.$85). In decimal, $0285 is 645, which divided by 256 is 2.51953125. Pretty close to the 2.52 input by the user, as close as can be in binary, and probably precise enough for any math you need to do. The trickiest part of this conversion is the division by 100. I don't know if bB has built-in division or if you'd need to write your own dedicated subroutine. The faster alternative, again, would be to use a look-up table to directly convert all possible inputs (0 to 99) into their fractional binary equivalents: 00 * 256 / 100 = 0 -> $00 01 * 256 / 100 = 2.56 -> $02 02 * 256 / 100 = 5.12 -> $05 03 * 256 / 100 = 7.68 -> $07 04 * 256 / 100 = 10.24 -> $0A 05 * 256 / 100 = 12.8 -> $0C (...) 98 * 256 / 100 = 250.88 -> $FA 99 * 256 / 100 = 253.44 -> $FD You may opt to round the results to the nearest integer instead of down (e.g. so that 7.68 becomes $08 instead of $07), but I don't think this will affect the results much.
  9. I'm not sure I understand what you're doing here, sorry...
  10. The fractional numbers that you can represent precisely using 8 bits are those that are multiples of the smallest number you can represent, which is 1 / 256 = 0.00390625. In other words, you can do numbers from 0 to 0.99609375 (which is 255/256) in steps of 0.00390625 (which is 1/256).
  11. Another option for displaying the number would be to multiply it by 100 so you get 2 integer digits out of it, discard the fractional part and display the integer part as you would any other integer, doing a binary to decimal conversion. For example, say that the fractional part is $86 (134). Multiply that by 100 and you get $3458 (13,400). Get rid of the fractional part and you're left with $34 (52). Which is correct, since 134 / 256 is 0.5234375.
  12. Fractional numbers in fixed-point math work pretty much like integers at the binary level: each bit position represents a value, and if you add all the values for the bits that are set you get the final value. The bits in an integer, from high to low, are worth 128, 64, 32, 16, 8, 4, 2 and 1, and with combinations of those you can represent numbers from 0 to 255. The fractional part is just the continuation of that: from high to low, the bits are worth 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128 and 1/256. To represent the number 0.75, for example, you need the bits that are worth 0.5 and 0.25, so that's 11000000 in binary. The thing about the numbers being multiplied by 256 is that if you look at it as if it was an integer, the value 1/256 is 00000001 in binary, the same as the integer decimal 1. You may have noticed that since there are only 8 specific fractions that can be added together to form values, not all decimal numbers can be represented precisely. Your example (.52) is one of them. 0.52 times 256 is 133.12 but with 8 bits you can only represent the 133 part, the .12 part will be truncated. So the closest you can get to 0.52 is 133 / 256, which is 0.51953125. The next one you can do is 144 / 256, which is 0.5234375. As you can see, you can get close, but not quite reach certain decimal numbers. But if you're going from binary to decimal, and not the other way around, this shouldn't be a problem. As for displaying fractional numbers, that's actually something I've never done myself. The fastest method would obviously be a look-up table, where each input byte would map to an output byte containing 2 BCD digits, so the table would only be 256 bytes long. I know that in Atari 2600 land this is a huge amount of space, but if this is an important part of your program it might be worth it.
  13. There are legitimate reasons for having equivalent tables in multiple banks with different contents though, even though it turned out that this was not what the OP needed. If that was the case though, you'd just need to make sure that the tables started at the same addresses in every bank, and that all the lengths matched. Only one set of tables would need labels. For the others, you could optionally write code to have the assembler validate their positions (i.e. compare the PC at the position where the label would be to the label of the original table and stop assembly in case of a mismatch).
  14. This is really good! Man, I missed this thread!
  15. It just occurred to me that Atari 2600 graphics drawn exclusively with playfield pixels look a lot like SNES graphics... in mosaic mode! It kinda looks like the game is in the middle of a scene transition (à la Super Mario World), and my brain keeps waiting for the animation to finish and the final graphics to appear. Not that the graphics look bad or anything, it's just that rendering detailed backgrounds is far from being one of the things the 2600 excels at. I love all the mock-ups posted in this thread, especially because they're so unconventional.
×
×
  • Create New...