Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by bugbiter

  1. cool! I never knew that! Thanks 🙂 .. I mean the ctrl-F8 trick described in post #2324..
  2. Is there a way in Altirra to disable / enable PM display? I would like to see where Rasta pictures use the PM bits..
  3. I guess that's about the same as the ones that had been put on the power board 40 years ago 🙂 Anyway, I now have a blue (!) power- on light and a faint orange glow to it when the HDD is accessed. That's fine for me!
  4. Orange LED is in and flashing almost brightly enough...
  5. At the moment I'm going for an orange one which seems to be the brightest one I got and is NOT red 🙂 I'll put in a higher resistor R201 (660 ohm instead 330) to dim down the now super bright red power led..
  6. I wish it were like that - all the LEDs I have here are either so weak you barely see it flash (1,8 Vf) or they don't light up at all (3,0 Vf) with the incognito board I guess I'll go looking specifically for LEDs with the lowest forward voltage I can find. (most likely red ones)
  7. I found that the old red LEDs have a forward voltage of 1.6 volts - the new ones I got have more (1,8 or 3,0). Does the incognito really work with that low voltage? Or is there a series resistor on the incognito board already that could be removed/bypassed? It's a bit of a bummer really, that the only solution would be to use the low voltage LEDs, which are quite dark of course.... Flashjazzcat - where are you? Which LED did you use?
  8. Hi, I just tried to replace the default LEDs of the 800 with new and brighter ones. I wanted to have a red one as the power-on light and a green one for the CF card activity, so that when busy, my newly made glass button on the Atari would give yellow when green and red are on. When the default LEDs were still in place the busy light on the left LED was going ok, but of course it was not very noticeable. Well, I have only rudimentary electronic knowledge so I thought any LED would do... After resoldering the red one on the right the result is great - really bright power-on light! Now the problem - The green one (left) does not blink at all when the internal SMD LED on the incognito board is flashing. Polarity is correct and soldering is also ok. I tested it by applying voltage to the led lines to the connector I made between the power board and the incognito. It might be that the threshold voltage of the LED is too high and the voltage from the incognito is too low. However, it is very difficult to measure the voltage of the LED line with a multimeter when there are only short impulses. I used two types of green LED. At first I tried a VF 3.0 - 3.2V one and then VF 1.8-2.0V after that. Both did not work in the left place on the board. Does anybody know what is the voltage on the incognito busy line, so I can choose the right type of LED? Or is there something else I missed?
  9. Here's a loader for Turbo Basic that I did in the 80s. IIRC I took the descrabling routine out of the original Basic code of Strip poker.. STRIPLAD.rar
  10. The filename on the source says graphics.a65 is that a known format? I guess it isn't the A65 Atari assembler.. But surely it should be possible for us to translate that Lucasfilm code into a usable assembler format??
  11. Boy, I would read that through all the way!
  12. Nice! If I only knew how to solve this 'combing' problem...
  13. with the ballblazer grid each tile is two pixels wider each line as you go down. That's why it wraps (with a colour flip) when the bottom line has moved for the amount of #c_lines*2 pixels which is the tile width at the bottom line. c_lines itself is the number of lines counted from the imaginary central point [Fluchtpunkt] to the bottom. We actually see less lines to achieve the effect of the over-the-horizon-curve. 'lines' is the number of visible lines on the screen. If both were the same the top line would be in the central point and would not move at all, the tiles woild be infinitely small in width and the diagonals in the checkerboard geometry would look very curved near the horizon. The halving of the horizontal border's Y positions is just an approximation of the correct function and that curved error is already there if you look closely... Try to count the visible playfield lines in Dimension X and set Lines to that value. Then look if there is a central point above the first playfield line (where would the line be that has tiles which would be zero pixels wide) and take that for c_lines. Then the field should move right. For the wrapping just look at how wide the tiles are at the bottom and wrap with that number of pixels. Just put a fixed value instead of #c_lines*2 for the wrapping routines. I hope that helps a bit.
  14. hmm what could that be? NES? I coded the gfx data by hand :-) the lines are different in length, the topmost needs only to be about 45 bytes as it doesn't move much, the bottom line must be about 90.. not sure. yeah, dimensionx could look better!
  15. Yessss!! Thank you! What platform?
  16. Hah! at first I thought you got me, but here in this case I wanted to get bits 7 and 6 shifted right to position 1 and 0. So instead of lsr lsr lsr lsr lsr lsr lsr I did it the other way round through the carry bit. The ASLs won't help me here :-) But thanks! I am sure there are hundreds of places in my code where there could be speed improvements. I love to hear hints from you demo coders! There is a 24 bit division routine that I use to calculate the slope of the center line between the tiles (step). Maybe I could use a bresenham algorithm instead... Or lookup tables.. At the moment the lineloop routine that puts all the values into the color and hscrol tables is finished just 3 or 4 scanlines befor the Kernel has to start! Way too slow!
  17. The original Ballblazer engine does that too - If you go from bottom to top each horizontal split position's distance to the horizon is halved with a simple ror instruction. The halftone line color is then determined by the upper 2 bits of the low byte of the vertical split line position, the 'remainder' But I changed the colour scheme to a brighter light green and a darker dark green, so there are more brightness steps inbetween compared to the original. I guess so it looks even more smooth with that.
  18. Yes I did! Embarassing, isn't it? I was just too lazy to do a generator - I was afraid the lineup and chopping off the borders would get too complicated, so I just copy pasted the .byte lines and mofified them.. Thanks for the generator, I'll take a look at it. :-)
  19. yes, I'm a bit slow .. :-) Tell me more about fastmul - how does that work?
  20. Thanks! there's only horizontal finescrolling each line individually and color changes for each line during the Kernel. Absolutely no changes in the graphic data of the so called 'framebuffer'
  21. I recently did a remake of the playfield grid just to see it move full screen with 50fps. It's PAL only. Maybe it's useful for your discussions.. BBgrid02.asm BBgrid02.xex
  22. you forgot to save and restore the accumulator pha .... .... pla
  23. I just discovered an old PM with the sources that I sent you about a year ago. Check it out - I'll gladly repost it if necessary
  24. You are right. 88max with apac and twice that with cin. I should correct that. Thanks!
  25. Hello Stephen, There is an Excel file with the format specs for both APAC and CIN type in the folder in that post #302. - sorry I can't attach it directly right now. What else would you need? Maybe some explanations about algorithms?..I found the CIN conversion is quite more complex than apac.. did I give you the source codes yet at all ?
  • Create New...