Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

47 Excellent

About stepho

  • Rank
    Star Raider

Contact / Social Media

Profile Information

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

Recent Profile Visitors

504 profile views
  1. Stacked Pokeys might have heat issues and current draw issues. As Rybags said, it might be interesting to use a single new CPU (AVR or ARM) to emulate a bunch of them. To the bus it would only be driving a single chip instead of many but could use the address space of the many. Does mean that the many emulated Pokey outputs would be merged to 1 or 2 physical outputs. I assume some of the voices would change slowly - eg bass lines. Which lessens the CPU overhead a little. Some voices might even be continuous rumble (eg engine noise on car/plane simulator) which would have no CPU overhead after it is set-up.
  2. Agree that over commenting is a waste. Disagree on the other points. The closer it looks like line noise then the more likely there will be a typo that the eye will gloss over and that the compiler happily accept. I'll take verbose but obviously correct code any day over short but potentially wrong code. You are in a maze of twisty syntax that all look the same.
  3. I always mentor my junior colleagues to not do that in their C/C++ code. It leads to the next guy thinking that c=1 is also conditional when it isn't. Of course, when trying to bum every byte then you do what you need to do - but it's still gross.
  4. Try: 45 Y=25-Y:X=X+80: REM MAKE X AND Y POSITIVE TO FIT SCREEN 50 PLOT X,Y Should give the same results for one less calculation.
  5. Using different words: If there is something in the code that is very easy to break, then it should be documented in the code itself - ie right next to the part that breaks easily. I've lost count of the number of times that the previous programmer just "knew" that certain things had to be done or not done. But the knowledge wasn't passed on to me and I broke things that needlessly took me ages to find out why. When I eventually fixed them I put a comment in the code about why something had to be done in a certain way. Thinking ahead for the next guy to modify the code is what separates the hackers from the professionals.
  6. Always document caveats. Otherwise someone will modify it later and it will crash for an unfathomable reason.
  7. For the few games that don't work on real hardware, you still have the option of using an emulator. Maybe a different experience than real hardware but at least you can play the games.
  8. My own experience (35 years embedded) is similar. Get the algorithm right (eg, an O(n) search routine is not as good as an O(log(n)) search routine). Beware of C++ habits where the values get transparently translated back and forth with each layer. Eg, object A stores a figure as a int. Object B wants that figure as a string - luckily object A has a interface that translates it to a string. Object C wants that figure from B (with operations done to it) but wants it as a float - luckily object B has a interface that translates it to a float. Object D wants that figure from C (with operations done to it) but wants it as a int - luckily object C has a interface that translates it to a int. More time spent on wasteful conversions instead of the actual operations. Write the code with an eye towards the platform. Saw a colleague write an 8-bit AVR program using 32-bit signed ints throughout. Changed it to 8-bit unsigned ints and it was dramatically smaller and faster. But do not optimise it to death so that it is unreadable and unmaintainable until after the critical parts are identified by a profiler. Replacing code like x*8 with x<<3 is just making life hard for the maintenance programmer. Modern compilers usually do this far better and lets you leave the code far cleaner. Leave these "tricks" in the 80's where they belong unless timing is super critical or your compiler is old.
  9. I would modify that slightly - do hand optimisations only when they are needed. The compiler should be free to do automatic optimisations whenever possible. Although some hints from the author can change which optimisations the compiler can choose from. Eg, in C, the volatile keyword on a variable disallows a pile of optimisations but allows the variable to read from a hardware location. Some other hints from the author also tell the compiler to optimise for speed or size - usually as a global option via command line flags. This reflects a basic tenant of mine - let the machine do the work.
  10. Thanks. I still don't understand but at least I'm in good company. Perhaps it's something to do with how fast the TIA can change the signal level or how fast a typical TV can follow the change. After all, TV's are designed for continuous tone images rather than sharp edges. Cleverly exploited though.
  11. ok, but I still don't know what's happening. Can you go into more details.
  12. This is new to me. I can see that the pics have wall steps of 4 dots and sometimes 1 of those dots is turned off to make the vertical black lines. Can you explain (or point to an explanation) how this works? Thanks.
  13. 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.
  14. 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.
  15. 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.
  • Create New...