scrottie

Oh, and same thing... no hardware registers unless I implemented, and the only thing I implemented at all was the timer.

Absolutely. I was doing something similar for https://github.com/scottwalters/2600lava before wound up working too much and not being able to work on fun things. In that case, making sure that computations checked the timer frequently enough to not overshoot was critical, so I was doing my own cycle counting in the single-stepper callback of the 6502 emulation. But that also made it a lot easier to get every kind of game logic right. Highly recommended.

LiveJournal won't finish loading on the cell data connection, and my pattern has always been to blog in out of the way places (Advogato, whose admins gave me a cookie I saved in a text file when I lost my login info, use.perl.org, ...). I'm rolling in to Davis, CA, where a bunch of exceedingly tiny houses in a row are connected via some duct-like overhanging facade in the front. They look like they might have a living room with a bed nook jutting out. Leaving, there are electric third rail warning lines. I followed the shore line down to Amtrak Emeryville after essentially riding to Rebecca's boathouse, then wound up on the wrong side of the tracks, fobbling down a few blocks trying to get around a mysterious one way street, then a street that only dumps into a shopping complex parking garage, then heads towards freeway interchange before turning around and spotting a ped overpass on the GPS. It has stairs and elevators, and the elevator on the far side dropped me right where I'd be boarding after removing protrusions from the bicycle. The Richmond station is another case of popping out of an elevator and finding yourself on the train platform. As a kid, I at some point became aware of bicycle of bicycles without kickstands. Maybe it was in the small-town Schwinn dealer. I don't know. It seemed alien and impragmatic even though my cousins and I would often pick our bikes up from the ground crashing them, or perhaps because of that. The bike comes up off of the ground because you wiped out, and picking it back up is associated with doing a quick mental injury check. The Amtrak baggage dude who was being super-helpful and asked me if I had ever done that before -- package a bike into an Amtrak bike box. "No, but I have packed it into my own bag in the past when riding Amtrak". He told me yeah, they started getting serious about the bike boxes after someone's self packed bike popped a kickstand out while being handled, and the kickstand lodged in the handler's shoulder. Ouch. There's a jackrabbit running along the tracks. We're stopped again, this time in Sacramento. There's a jackrabbit running along the tracks. There's something about getting on a train, or getting ready for a long trip. You have to make peace with where you're leaving from. I read an article once a long time ago that attempted to to answer the question of why you forget what you were doing when you go into another room to do something (or, alternatively, why sometimes old people will walk into the supermarket and the step dead as soon as they've planted foot inside). Temporary changes in context help break life up into chapter.

In response to http://blog.builtinperl.com/post/must-read-books-for-perl-programmers, with apologies: Perl programmers, in my experience, tend to know Perl very well. They don't need to know more Perl. However, having often come from self-taught background, the larger field of CS seems to be what's missing, and they tend to take refuge in the Perl camp. So here are my profoundly biased picks. Hardening Linux by James Turnbull -- http://www.apress.com/9781590594445 There's a mindset that Linux is secure if you keep it up to date, but if you pay attention, major company after rmajor company (and government) gets taken out. Linux is configured very soft by default. Defaults of allowing root ssh logins, runlevel, and so on are designed for low security desktop systems. Those are some obvoius ones, but Turnbull has a list of easily 100 similar things to harden on your public facing server. Perl programmers traditionally came from a paranoid sysadmin background, but if you didn't, this book will get you half way there (then watch DEFCON talks online and feel your parania continue to grow as you realize that nothing, nothing is safe). The Cyberiad by Stanislaw Lem "Fables for the Cybernetic Age" -- a series of shorts with the same characters that explores machine intelligence, unintended consquences, arrogance of creation, and personality in technology in a wonderful quirky but academically informed way. After reading the works of AI pioneers like Marvin Minsky, this book is relavent, accessible, and a treat. Just as everyone should but already has read The Mythical Man Month, also must we think of personality and human fooble while working in technology, and this book teaches that. Object-Oriented Design Heuristics by Aurthur Riel I can't say enough good stuff about this book. One summer in the early 90's when I didn't have Internet access, I spent a lot of time camped out in the St. Thomas University library reading CS books and decided I wanted to read books on OO and discovered this gem. Design Patterns and others can't hold a candle to this. The author gets you spiritually in touch to the complexity of the topic, and the uncertainty and trade off and conflicting rules of thumb. In my experience, Perl programmers dissmissively claim to know OO, but have divorsed the concept of polymorphism from the enormous body of work from the C++ era on architecture of large systems. This is like claiming to know your maths because you've mastered your addition tables. Exposure to a solid treatment of OO Design/Analysis would do more to improve the quality of Perl out there and improve Perl programmers than any other single topic, and this is the best treatment. The SNOBOL4 Programming Language, 2nd ed, by Griswold, Poage, Polonsky Perl prides itself on its pattern matching, but SNOBOL4 mixes pattern primitives with the core language, allowing programmers to easily write goal-directed, back-tracking, capturing *code*. Pattern match (full stop) is a first class data type that other functions can operate on. Until Perl successfully steals this (which would be hard to do -- just as its hard to simply bolt OO onto a language), it'll be good for Perl programmers to kno where their language actually stands with respect to one of its main claims to fame. It's also fun to marvel at how much of the modern Perl stuff we have existed in the 60s (user defined operators, for one). Like Perl, SNOBOL4 was used for text processing, relied heavily on its built in hash type, and its programmers enjoyed golfing. There are undiscovered roots here that need to be connected with. The UNIX Programming Environment, Kerningham and Pike We praise the modular, tool approach of Unix, but with stuff like systemd and apt (which doesn't understand major/minor versions, a fundamental and important concept in Unix library design), we're getting further and further from Unix roots. Modern Unix code is increasing looking like Windows code. Writing effective Web apps and busines slogic requires understanding and making effective use of the appropriate OS primitives. Without a grasp of what all of those primitives are and how they work, a programmer is going to throw more and more abstraction at it, and often the wrong abstraction, and write expensive, inelegant solutions to problems. The Structure and Interpretation of Computer Programs by Ableson, Sussman, Sussman (or alternatively Higher Order Perl by mjd) Teaches problem solving of a much higher level. There are programming tasks that are hard because the code that is the mess and there are hard programming tasks because the task requires novel CSy problem solving. This keeps the latter from turning into the former and still failing. 'nuff said. Old home computing magazines, such as http://www.atarimagazines.com/ ... back from when computing was new, exciting, and fun, and any little idea was worth exploring and playing with. This is the mindset that programmers need to be in: courisity and joy. Rediscover that. You won't get far in anything unless you give yourself permission to take interesting parts of the system and play with them and explore them. Curiosity is an important and natural instinct, guiding us towards what we don't fully understand and leading us to master it. Play is easily half of work. Knowing how to do that effectively makes us productive workers. IBM mainframe camps, Microsoft camps, and other overly seriously sometimes get too far away from this and become rigid, risk adverse, shallowing in ability or willingness to explore, and just plain stale. Look for the small to medium sized program listings and skim through the explainations of a lot of them. Take the ideas of exploring -- and sharing your explorations -- with you.

I'm all for curbing abuse, but is someone who disagrees with you abuse? What about persistent dissenting opinion? Is it your obligation to silence persistent dissent? I'm not trying to actually accomplish anything with my Twitter feed, just vent, so there's no incentive to keep anyone around with a conflicting viewpoint. If someone likes something that I don't, that's plenty of reason for me to block their messages. We don't like to be reminded that we make mistakes or even that our decisions and likes and wants might possibly be a mistake and we especially don't like it when our possible mistakes are consistently pointed out. It's easy to take that personally. But taking things personally is a defense mechanism. We've all dealt with roommates who won't do their own dishes or coworkers who won't do their job. No matter how nicely you ask, they arbitrarily decide to take it as a personal challenge and then over-react to a simple request (likely one you wouldn't have had to make in the first place). They misrepresent the request to do dishes as an attack on them and lash out and use that as a rationalization to ignore you. So then you have an escalation. I'm not active on p5p and can really only speak as an outsider, but I did follow it for a long time, almost entirely in silence. When you have persistent dissent, you're eventually going to move on anyway and do what you need to do move Perl forward. One of those debates in the past was pseudohashes. It had to be done, for reasons. It was going to be done. We've decided it's going to be done. Except that the one person doggedly pointing out problems with it was proven absolutely correct, and attempting to do this and then trying to back out of it created an enormous amount of work. At what in the discussion about the idea of pseudohashes, the discussion of the idea, the implementation, fixing fall out, removing it, or dealing with fallout from removing it should MJD have just shut up and left it alone? Should he have made one comment and stopped? Should he have done his best to represent his insights throughout the whole process? Please don't assume that just because one person is alone in their view that they are automatically wrong and therefore a liability to progress. There are no shortage of large pieces of software (the Netscape browser comes to mind, and probably everything written inside Microsoft after the 80's) where commonly held opinion was not the sane one. Something happened in TBAG while I was out of town. One man, J, who had been doing a lot of work -- organizing rides and events, doing graphic design work, screen printing stuff -- had a guest behave badly and steal beer. This guest, M, was warned that he could leave with the beers he was trying to steal, but "you and I won't be cool" (you won't be welcome at future events I'm organizing). At a future event, sure enough, M turns up, and demands free entry. He is ejected. ... but there's a problem. M has friends. So (I'm not clear on the details here), he turns around and complains about how he is treated and gets J kicked out of the organization. Wham. This makes me grieve for an organization I helped shape. Some strange reading of the code of conduct I wrote and worked hard to get ratified by the board was used to justify this. The CoC was twisted away from its intent and spirit to play favorites. With skirmishes like this, it too often becomes a matter of who is better liked and who has more friends. When I first drafted the TBAG CoC, I left room for dissent and conflict resolution, because I'm often the dissenting opinion. Everyone wants to do the normal, predictable, safe, expected thing. Being on the board of a bike advocacy organization is already wild and wooly enough for them, they're certainly not going to get on the board and then make any sort of waves. But I want to make waves and I want the organization to make waves. And doing some crazy ass shit worked. While I was on, we doubled our membership and radically altered the political landscape of Tempe. I don't know if J was told about conflict resolution mechanisms and offered them. I'm guessing not. J wasn't 86'ing M from the organization, only from events J coordinator, so M getting J axed was an escalation of the use of force. Doubtless J was offended by M's actions too. The difference is that M had power to retaliate from the offense while J was denied even reasonable, modest levels of power that an organizer should have. Various Perl 5 Porters feel attacked and offended -- but exactly how justified is this? "It's been an albatross round perl5's neck ever since" was said to Reini about a feature that his employer, cPanel, critically needs (the compiler toolchain). cPanel donated a ton of money for core development, and a feature they critically need, the compiler toolchain, has been under constant attack. I feel some empathy there. I know everyone hates the Perl 5 compiler toolchain, but doing server-based game determination for the Las Vegas gaming market, the Nevada Gaming Commission absolutely 100% required that code be compiled. Even if the compiler isn't as good as other language's, we needed it, just like cPanel does. Reini isn't asking anyone to maintain it for him -- cPanel is paying him to maintain it. But he can't, because they're actively trying to deny access to the needed APIs. Core maintainers feel compelled to make the needed internal APIs private to stop people from trying to use them. At least that's the story I've gotten (please correct me if you know otherwise). Never mind just declaring them "internal, use at your own risk" (see the famous Wallism, “Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun”). B modules needed for this are repeated and recklessly being broken by the auctions of core maintainers. "If I could travel back in time and stop [person], I would in an instant." "failed experiment". I feel that those could be considered personal attacks just as much as Reini complaining that someone's commits are "bad" because they're breaking things. I'm sorry, but while I empathize with rjbs' annoyance, I think Reini is equally entitled to annoyance in this case, if not more so. And I think Reini has been conducting himself equally as well as the Perl 5 Porters on the list. The difference is power and who has the most friends. Does it really make sense to expunge the porter paid by cPanel who is representing cPanel's interests because his dissent is causing offense? Reading through other Perl 5 Porters posts, Reini has been helpful and approachable. I don't think it's possible to pull the March Lehmann argument here. Reini is not assigning motives; he's only accusing people of breaking the compiler, which as far as I can tell, they are. Other people are accusing Reini of "trying to drive people away", which is an assigned motive. Not cool. I'm reasonably certain that Reini's goal is simply to keep the compiler toolchain working for his employer, while volunteering to make Perl fast and sane and helping other people on the list. If someone is legitimately attacking other people, you don't need to assign motives and demonize them. Their bad behavior speaks for itself. Should other people have to put up with Reini? Should the board have had to put up with me? Or people "put up" with J? Or M? Or MJD, when he was railing against pseudohashes? In the case of Marc Lehmann, I was arguing for handling him a certain way to attempt to avoid triggering bad behaviors, but I don't argue (and I don't think Marc would either) that there were anti-social behaviors. Yes, Reini could have conducted himself better. I think there's some German/Austrian directness there that dictates that things be said plainly and words not minced. If the CoC (I haven't read it in this case) states "no personal attacks", I find it ambiguous whether "this is bad for the same reasons as other things he did [that I've pointed out before]" (paraphrased) is a personal attack. It references a person, but talking about an ongoing perceived problem with their code. I'd like to have seen Reini do as rjbs suggested and remain unfailingly technical and specific even though R considers the larger problem to be someone else's approach to code. Another resolution would be for rjbs, and other people offended that Reini is upset that their changes are breaking his stuff, to ignore Reini. Keeping breaking his code and simply ignore his protests. Unless this is conclusively a CoC violation, being annoyed at someone in retaliation for them being upset at you is not legit banhammer material. There's no moral imperative to kill dissenters merely for dissenting. TBAG's CoC considers it the case to be the opposite -- to create a process for dissent. Another resolution would be to be explicit that drastic steps to control discussion are the purview of the current pumpkin. Let the pumpkin say "I've decided, we're moving ahead [even if this proves to be a pseudohash situation and you were right], so we're stopping conversation and booting you if you persist". Don't twist motives and create hyprocrtical double standards about what's an attack to turn it into a CoC violation if it isn't one. Just be honest about exactly what you're doing. Part of that honesty needs to be that this person isn't being ejected from the community, only from discussion in a release cycle. Finally, some conclusion: Without safety and justice for everyone involved, organizations turn into closed little clans. It should go without saying that this is bad. Non-trivial efforts need to be larger than a few friends who like each other. This was an explicitly stated goal for mine for TBAG and apparently one I've failed in realizing. Will TBAG get another ride coordinator who actually puts on big hyped events with professionally produced promo videos, merch, PR, venues, ride leaders, and the whole wall of wax? Maybe, but based on past experience, someone like this comes along maybe once every three years, so we've likely got two years that we've fucked ourselves unless people can see each others points of views, appreciate some over arching sense of justice than personal annoyance, and reconcile shit. It is unhealthy to twist technical disagreement into personal disagreement and then twist that into CoC violation and I think both organizations I'm talking about could have done a better job on that front.

Bump. The ravenlist links are dead. I can host the files if needed. I'm looking at picking up an SIO2SD and it would be good to see this back online again. Thanks!

One request we've had for years is to put WebGUI on CPAN, but we always reached the conclusion that we had to get rid of Image::Magick first. I think the discussion went along the lines of, yes, we could put it on CPAN, and we want to, but first we need to get rid of Image::Magick. For many years, virtually all WebGUI installs were on top of the WRE (WebGUI Runtime Environment), a pre-built binary self-contained Apache, MySQL, perl, mod_perl, etc environment for Linux. A tree of etc, usr, bin, etc directories lived under /data/wre. This is how pesky system dependencies were handled. The WRE contained the Image::Magick perl module, correctly configured, built, and linked against the correct version of the system ImageMagick library. Having a pre-configured system like that was a huge boon for users who got up and running quickly, but it presents problems if you're already have a web server or proxy running on port 80, or you're already running mysql. It also took considerable resources to maintain against new versions of various Linux distros and to patch. For as tricky as it can be to configure mod_perl, it turns out that setting up Image::Magick is far more difficult. This is the point where most people seemed to fail on the source install instructions. Getting it to work requires having precisely matching versions of the system library and Perl module, and even then, it's finicky and fragile. The API changed constantly, it regressed constantly, and, in general, defensive programming doesn't seem to be a priority. The concern about putting it on CPAN was that there were too many dependencies, Image::Magick not the least of them. Someone pulling the code from CPAN would still have to go through the entire Source Install process: http://www.webgui.org/wiki/source-install Frankly, we wanted to encourage people to just use the WRE. Besides, we said, wG is on github, and has been for ages. Previous work on wG8 removed Apache/mod_perl as a dependency. Running on plack, it's much closer to a stand-alone Perl application. Graham (haarg) started the work of migrating away from Image::Magick. I just got tests passing again. WebGUI::Storage knows how to thumbnail things. That's used by photo galleries and file uploads in general which may be attachments to various things. wG also generates its own captchas. Graham's work started there. He picked Imager, which is an XS module, bundling the C code with the Perl together in the CPAN distribution. I continued with that, mostly. Besides getting tests passing again, the larger part of this was the Poll asset, which has three different flavors of image based plots it'll generate: a pie chart, a line graph (I'm not sure what the point is of this one, honestly; I guess it makes sense if the poll's questions represent contiguous values), and a bar chart. Here's more information on the Poll asset from the WebGUI Content Manager's Guide: http://www.webgui.org/content-managers-guide-wiki/poll wG's pie charts were really pretty in 7. Check out the pictures in there. Line and bar charts translated pretty directly from Image::Magick to Imager, but I'm punting on the pie charts. Image::Magick takes SVG Path syntax strings for describing fancy arcs, lines, and so on. Imager doesn't know how to plot a proper arc, only sections of circles. My attempt at translating pie charts resulted in something pretty... special. WebGUI::Image::Graph::Pie is now implemented on top of GD::Graph::pie, which look like the examples in https://www.safaribooksonline.com/library/view/perl-graphics-programming/9781449358280/ch04s01.html GD is at least an optional dependency now, only required if you want pie charts. I'm hoping that someone wants to fix up wG7's pie chart logic and releasing it as a stand-alone Perl module that does not depend on Image::Magick. As for packaging, there have been a lot of requests for a Docker container, and that's something I hope to look into. The main direction I took was a semi-portable installer script based on xdanger's old installer script for Debian: https://raw.githubusercontent.com/AlliumCepa/webgui/master/installer/webgui_installer.pl Most of the automated failure reports I've been getting from webgui_installer.pl have been... yup, Image::Magick failing to build. Doug, Colin, and the crew were right from the start. This still leaves MySQL as a dependency, but I feel like we're within the realm of WebGUI being a reasonable Perl module. SQLite support would be nifty, but I have no plans to veer into yet another internals rework project without really good reason, and wG performance is largely limited by database performance, so the marriage to MySQL is mostly beneficial (even though some of us like Postgres a lot better). Here's the bug ticket for replacing Image::Magick: http://www.webgui.org/community/webgui-8/issues/11849 As a footnote, I've also gotten automated install failure messages about Imager::File::PNG not installing cleanly. If I have work-around that, I swear I'm translating the C in Imager to Perl and making an Imager::PP. Or perhaps we need a perlcc to automatically compiled C to Perl, joining the ranks of a2p (awk-to-perl) in Valhalla. Footnote 2: The Poll asset unit test was using the API incorrectly, and never actually registered any votes in the poll. When it went to plot things, it created empty plots. And no one noticed, until now.

I've only looked at bAtari Basic a bit. I read through https://github.com/e-cooper/Atari2600-Portal for example. This person did a mini version of Portal for the 2600. That would be fun to just to sit there and start adding levels and features to. Turrets, momentum translation, etc. AtariBASIC for the 600XL was my first programming language. I got started doing assembly just mixing in a bit with my BASIC games. AtariBASIC let you do a lot of stuff (often very slowly, which at least isn't a problem for bAtari BASIC... in Atari BASIC, all numbers are floats, and the float library was not optimized for speed at all, for example) but in order to do a vblank handler or hblank handler, you had to do assembly. So for me, at first, it was just inserting tiny little routines. Moving a player between scanlines required assembly, for example. I think that was a good way to learn. So now I'm curious if bAtari BASIC lets you do that. Anyway, I'm happy to share what I know.

Thanks for the link! I try to watch every 2600 demo I can but I missed that one for some reason. They're both extremely excellent demos. When dealing with few pixels, animation becomes so important. I'm seeing people take sprite animation to high art in other threads. So much fun to watch that unfold. Whether one piece of platform would ever appear in front of another was definitely something I all thought about. Like your boxes, they all have to be the same width (before perspective rendering) so that a smaller one never winds up in front of a larger one.

Thanks =) Yeah, just for me. I've been begging and begging for years. Wouldn't leave him alone, really.

Yeah: https://www.youtube.com/watch?v=Ulcq0pVlQ1c It was a YAPC (Yet Another Perl Conference) talk last year. I was unhappy about how it came out. I kind go deer-in-headlights and forgot a bunch of important background and I wasn't very organized. I also completely forget that data projectors take a minute to sync to video, and I'm used to just mashing buttons on my de-modulator to get VGA output from the (hacked on) composite from the 2600. Failing to get video from the 2600 up flustered me. The buttons on the thing cycle between cable input, composite input, s-video input, etc. If I had brought the remote, I could have just pushed the right button and waited for video to come up. I'm pretty happy about the unit testing 6502 machine code stuff though. I think that made debugging a lot easier for me. One of the unit tests for example makes sure that when it renders a platform, it starts and ends where it's supposed to on the screen. Another makes sure that the filling logic worked and there are no gaps. Another makes sure that things rendered in front of other things actually work, and another that platform rendered behind other platforms don't show up at all, and then it tests cases where one platform partially obscures another. So I can instantly find out if a change broke the code. I didn't have to test collision detection in-game at all, because I able to verify it with the unit tests first. Then when I did test it in game, it worked. The files name 01_this and 02_ that in the github repo are the tests.

Thanks! Yeah, as I continue to steal memory away from the "frame buffer", that becomes more and more necessary. Adding a second enemy will take away another six bytes, unless I do something to reduce the memory that each enemy uses (eg only use 4 bits each for fractional position and momentum in Y and Z). Not to mention if I want a score or objective (that needs to be tracked) of any type. The middle of the screen needs more resolution than the top and bottom, so I've also thought about using two different display kernels that doubled lines on only the top 1/3rd and bottom 1/3rd, and having warped arctan etc tables to compensate, but the thought of all of that extra work kind of stresses me out.

I'd love to play with stuff the bus with an ARM, or an FPGA. Maybe my next effort will revolve around that. I've got some simple shading going on the platforms, but this demo (I forget which I grabbed that screenshot from) has way better shading, and texturing. I'd love to steal that, but they've got two colors going on the same line and I'd need three, and enemy birds might wind up in PF*, which wouldn't be all bad since then they could potentially be much larger. Not sure how I'd juggle that. Stuff people do blows me away.

Done. I figured that adding a direct link would be easier. I keep reading stuff here, not being logged in, and then failing to download attachments =P

Done. I figured that adding a direct link would be easier. I keep reading stuff here, not being logged in, and then failing to download attachments =P