Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

42 Excellent

About stepho

  • Rank
    Star Raider

Contact / Social Media

Profile Information

  • Gender
  • Location
    Perth, Western Australia
  • Interests
    Old cars, computer history

Recent Profile Visitors

439 profile views
  1. From work I have done on other embedded devices (not Atari), you can double the amplitude of the output waveform and it will not sound like double the volume to our ears. That's because the device is using linear values but our ears work on logarithm values. Most TV's with digital volume also suffer from this (ie volume 10% sounds okay but to double the perceived volume you need to go way up to 30% or more) For my device (which only needs simple buzzer-like sounds at various, fixed, frequencies), I set the amplitude according to the crude formula: amplitude = (vol^2)/100 where: volume is the desired volume 0..100 % amplitude is the amplitude of the output waveform 0..100 % Not truly logarithmic but parabolic is close enough. With this, the user can double the desired volume value and the perceived sound also appears to double.
  2. Both look good. I suspect the buggy version is due to round off errors due to the trig functions not being evenly spaced. Eg, sin(1)-sin(0) is a lot larger than sin(90)-sin(89) where 90 degrees is a right angle, not radians. I worked through the original algorithm and the maths is fine - assuming infinite precision. I tried to think of other variations but none were as fast (theoretically) as yours.
  3. For Total Commander, I found I had to enable passive mode in the FTP connection settings. Haven't used FTP for years, so not sure if it makes any difference today.
  4. Rodney Zaks "Programming the 6502", courtesy of the Internet Archive. https://archive.org/details/Programming_the_6502_OCR Zaks "programming the Z80" was my second book for learning assembler back in the day (PDP-11 assembly handbook was the first).
  5. Sorry, by motion blur I meant that for the fall back position (ie no repeated frame was found) of just grabbing the last X frames and then blending/averaging them, then anything that moved would show up in both old and new positions. Like the red box in your last image. The system would do it's best to look for repeated frame(s). If it can't find repetitions then it just takes the last 10 frames (or whatever number you deem best). Manual splicing is always an option - we just try to let the computer do as much of the work as possible. My day job is designing automated equipment that can go for months in the field without human intervention. So I naturally try to make it as self sufficient as possible. I hadn't thought of showing phosphor fading in the final static image. If you took multiple snapshots then there is no guaranteeing the same first frame in each snapshot - which means the fading could be different for each snapshot. But it might be a nice option in the GIF. Each final frame in the GIF would contain a weighted average from the other frames - with special care taken so the first few frames contain faded info from the last few frames. I have a few thoughts on how to do that but I'll wait a bit in case I've gone an option too far.
  6. It's nice that it is possible to get an image but requiring the user to slice and dice it by hand kind of goes against the whole idea of having computers in the first place. Whenever a human is doing work for the computer, then something is wrong. A key point that I mentioned above is for the tool to watch for recurring frames. If it sees frames like ABABABABABA (ie a 2 frame kernel) then it grabs A, grabs B, grabs another A, notices that the 3rd frame is identical to the first and then blends the first 2 frames. But this doesn't capture flickering stuff like ABACABACABAC and could miss the C frame. So we look for 2 consecutive frames. It grabs A, grabs B, grabs A (no AB match yet), grabs C (no AB match yet), grabs A (no AB match yet), grabs B, notices that last 2 frames match the first 2 frames and then blends the 4 frames (ie every frame minus the last 2 matching). If the player is moving around then it may take a few cycles before it finds a set that don't have movement. We are hoping that the game is not having things move at 50 or 60 times a second (or at least that it does so cyclically) otherwise no player could keep up with a screen that screams by in a flash. Fall back is that after say 10 frames it just blends all 10 and just accept some possible motion blur. The above could be coded with a single parameter n. n=1 means just look single frame identical to a previous frame. Handles AAAA, ABABABA, ABCABC, ABCDABCD type cases n=2 means looks for 2 identical frames in sequence., Handles ABACABACABAC type cases n=3 means look for 3 identical frames in sequence. Handles more complex cases but I can't think of examples. Might have trouble with motion blur.
  7. I'm curious about how you do the phosphor fade. Do you store n raw frames in a sliding window and then do a weighted average for the display? Or do you use a simple signal filter? eg: frame=getNewFrame(); frame = ( (oldFrame * k) + frame) / 2; // where 0<k<1 display( frame ); oldFrame = frame;
  8. Perhaps Gopher could capture frames until it finds a frame identical to one that it has captured before (with an upper limit of say 10 if the screens have objects that move around a lot). Then the user could choose to save that as either: a single frame formed by averaging all the frames an animated GIF showing each captured frame in turn, using the same timing as they were captured. Should work for ABABAB (captures AB), ABCABCABC (captures ABC), ABCDABCD (captures ABCD). Would still fail for ABCBABCB but do many games do that? If need, could make it stop when it sees 2 successive frames that are identical to 2 previous success frames. Ie, ABCBABCB would capture ABCB because AB was seen before.
  9. Any bits that are not explicitly defined should always be masked out. Otherwise you will find that some implementations will give %xx000001 but you may also find some other implications give other numbers. Or even the same hardware under different conditions (temperature, timing, previous operations). Never trust what isn't fully documented (and only partly trust what is documented ).
  10. True, I should have said "global variables".
  11. It's not my code either but I can answer some of your questions. Most C compilers initialise variables to 0 (unless some other value is specifically given for a specific variable). So all the borders are initialised to have no border walls and are later modified to have bit 0 and/or 1 turned on via |= RIGHT or |=BOTTOM. Macro function can usually be converted to ordinary function in a mechanical fashion. static int GoodDir( int Cell, int Dir ) { return (g.Maze[Cell].Border & Dir) == 0; } Called by bool flag; flag = GoodDir( Cell, Dir );
  12. You are probably thinking of https://en.wikipedia.org/wiki/Bresenham's_line_algorithm
  13. I thought I knew IBM PC history and Atari history quite well but that was a new one for me. Found some more info at http://forum.6502.org/viewtopic.php?f=3&t=5256
  • Create New...