Jump to content

wahsp

Members
  • Content Count

    18
  • Joined

  • Last visited

  • Days Won

    1

wahsp last won the day on April 15

wahsp had the most liked content!

Community Reputation

26 Excellent

1 Follower

About wahsp

  • Birthday 05/09/1986

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah, it is not the most distinctive name, I guess. Here you go: https://gemini.circumlunar.space/ I suspect you may have heard about Gopher. This is kind of a recent reboot of that with some improvements, although the creators explicitly state that they are not seeking to replace Gopher (or html, for that matter).
  2. Wow! I didn't know the Commander X16 is capable of FM. I played around a lot with software synths over the years. FM is definitely one of the more interesting approaches to synthesis, if you ask me. There are so many directions you can take it in.
  3. Did you guys hear of Gemini? I have a Gemini capsule that I do way too little with. I had some fun exploring the Gemini space; it attracts an interesting crowd.
  4. Yeah, actually I think that Cyber more or less boiled down what I tried to say in a couple of paragraphs to a few sentences: And you are now illustrating that point very nicely as well. This idea, that you can actually feasibly take control of the entire thing and the entire process of development alone, is what makes it incredibly appealing to me. I've noticed a while ago that I have a kind of obsession to "do it myself", but only with software so far.
  5. Hi there! There is also an excellent video series by one of the forum members: https://www.youtube.com/channel/UCWihlGXWuyJbjP5vjzD03Rw I also watch the 8-bit show and tell channel for some assembly language pointers, focused on C64 programming. There are also some good books on writing machine/assembly language on the C64 from back in the 80s, like Jim Butterfield's book: https://archive.org/details/Machine_Language_for_the_Commodore_Revised_and_Expanded_Edition. Actually, there is someone who uploaded scanned copies of a shitton of books on the C64, including Butterfield's one: https://commodore.bombjack.org/commodore/index.htm. That is all C64-focused, and I use emulators to work through the examples (I have theC64 maxi and I occassionally use the Vice emulator). Actually, I came across the Commander X16 when I was looking for C64 stuff. Anyway, I heartily recommend going through some of these books (I just finished working my way through Butterfield's book). The C64 uses a chip from the same family as the Commander X16, and I think a possible benefit of the C64 is that a relatively large group of people have been coding in machine language with it over the past decades, so it is maybe easier to find resources on it.
  6. I think that some of the things you describe do not just apply to younger generations. When I tell my parents about how I mess around with computers, they often respond that for them things really need to be 'plug and play'. I think that, generally speaking, the more advanced a technology gets, the more 'black boxing' of that technology occurs, and the broader the audience that is willing and able to use the technology. To some extent I think it is true that the number of people interested in opening the black box of the technology shrinks, because understanding the technology takes more effort and at some point it becomes unfeasible fit the amount of time required for this in your hobby time. However, I also think that to some extent it only seems like this group is shrinking as a result of them quickly becoming a minority amid a much larger group of people that only became activated as soon as the technology was sufficiently black boxed to no longer have to care about 'what goes on under the hood' to use it. In a book on social practices I have, the authors make the argument that when cars were still relatively new, you had to be somewhat of a mechanic to drive one. You had to know how to do at least basic upkeep and repair, because otherwise you wouldn't get much use out of cars. This also meant that you had to know more about how cars worked than you need to know today. Actually, that was probably part of the fun of it for the first groups of people that drove them (the authors of the book actually explicitly make the argument that driving a car was considered a bit adventurous at the time, while today's motivations for driving a car are overwhelmingly pragmatic). Nowadays, the vast majority of people driving cars don't understand exactly how they work. Also, they have become much more complex, so you really need to have a particular kind of interest in these things to still care enough to try to understand them. I am probably oversimplifying some things here, but I have the impression that computers follow a similar trajectory. In their early stages you had to know more about them to understand how they worked and how you could fix something if they stopped working. Over time, computers have become increasingly black boxed (and therefore more attractive to a broader audience) and overall more difficult to wrap your head around. Is this something to be cynical about? I think to some extent yes, because I feel that the more we lose understanding of the technologies we work with, the more we lose our independence and become passive consumers. I should stop rambling. What were we talking about again?
  7. Not sure if the rambling below is very helpful, but well... I think the others have already pointed out some possible pitfalls in the idea. There won't be the same sense of nostalgia (although, as I have mentioned in other posts, the same goes for me and that is not necessarily a barrier to getting into retrocomputing). I think you could draw in people with the idea that they can "learn to program their own games", but I expect they'd rather learn to use the more recently developed tools for that. I expect that the young of today would want learn to how to code something like the next PUBG, rather than something like boulder dash. Yet, maybe you could make use of (1) the fact that things like pixel art and such indeed seem to have grown in popularity and (2) that you can actually feasibly create a retro-style game by yourself (even though that point is of course flawed, because you can equally well develop simple games with more recent tools). Another thought: Maybe the focus should not be on the 'retro-ness' of computers but on their relative simplicity. Because of their relative simplicity and their limitations, it is actually more feasible than with more recent machines to get to a point where you get close to "understanding everything about your machine". Coding "to the metal" is part of that, and with simpler, more limited computers it is much more of a necessity (and therefore more inviting) than with today's highly overpowered machines and compilers that probably do a much better job than an enthusiast could ever do. I don't have hands-on experience with Raspberry Pi or Arduino, but I imagine that on that front they have an appeal that is similar to that of retro-computers, while having a more 'modern edge'? Affordability is also a nice benefit of something like Raspberry Pi.
  8. I was born in the 80s, so I'm too young to be nostalgic about retrocomputers. Yet, I feel a kind of vicarious nostalgia (is vicarious the right term?). I have been fascinated with computers from a young age, and I was always interested in the idea of hacking, although it is an interest I didn't actively pursue until much later (while I was doing my PhD). What I like about retrocomputers is that they invite you to get to know them better. For example, when I am booted into a BASIC environment instead of a point and click GUI, I feel a stronger encouragement to develop a good understanding of how the machine operates, so that I can interact with it. I am now learning how to code in assembly language on a C64 emulator (the64 maxi), which also gives me a strong sense that I am getting more closely acquainted with the machine I am working with (even though it is a bit of a facade in this case, since it concerns an emulator ;)). I am not even sure what I want to eventually do with that knowledge, but it is how I currently spent most of my evenings, because I find it entertaining and it gives me a great sense of accomplishment. I don't have this sensation with my high-end laptop (which I love for other reasons); There, I don't even really know where to start to get acquainted with the machine in the same way I do with the C64. Another reason is that I like the people in the retrocomputing community that I've encountered so far. Yet another reason: Although I was not into retrogaming until recently, this also struck a chord with me. I was an avid gamer when I was younger, but I can no longer bring myself to playing these highly elaborate games that I used to play (think GTA, Red Dead Redemption, Elder Scrolls). The investment of time is too big, which just stresses me out, because I always have the sense that I never really get to see the end of the game anyway. The few games that I was still playing on my PC were usually smaller indie-games, preferably roguelikes where I usually die within 5 minutes anways, because I I am terrible at them. What is nice about these games is that it doesn't matter that you die so many times, because there's not necessarily this elaborate story that you have to see through, alongside $FFFF side-quests that you could pick up; it is more about the gameplay mechanics. I didn't buy the C64 Maxi because I wanted to play games (I was interested mostly in using it to learn machine language), but I do find myself playing games much more than I did. I think this is for similar reasons. Also, retro graphics are just cool.
  9. Hi Karl, That is an impressive programming CV! I was wondering how big the leap is from learning how to write machine language on 6502 variants to learning how to write machine language on X86_64 and arm chips. Could I ask for your ideas on that? Thanks in advance! Wouter
  10. I hadn't considered that yet. I'll keep that in mind. I caught myself making the same mistake today, so knowing about it already helps. It is actually a bit different than I typo. It's more like a fault in my memory. That is also why it happened more than once, I think. Labels would definitely solve that.
  11. Anyway, I am pretty sure your analysis was spot on. I made the mistake deliberately in a 'test', and it does exactly what I described. I guess I have the unfortunate habit of typing $fd22 instead of $ffd2. At least now I know what to look for when it happens.
  12. Thanks for looking at this more carefully than I apparently did. I should say that I quickly typed in this example yesterday because I hadn't saved the code. 1) Yes, I forgot the RTS there, but it was there on other occassions I had this problem. 2) The $fd22 thing: I am now wondering how often I make this typo, because it is indeed a typo. I had the behaviour I described on multiple occassions, so I will keep an eye on this, but it is very possible that I made this mistake more than once. Thanks again! I feel a bit stupid now, but that is what happens when you do stupid things.
  13. I am not sure if this is best forum to ask, but I don't have an account with any other retro-computing forums yet. I have been learning some basic assembly language. I am currently working my way through Jim Butter's book on machine language and doing the various exercises on Vice and my the64. I was working on an exercise where I encountered a strange problem, and I was wondering if this is a common thing. I was using turbo macro pro (although I believe the same problem occurred with snapshot's ml monitor), and the code I wrote is in the attached screenshots (note that screenshots 2 and 3 overlap a bit). The problem that occurs is that with this example (and I've tried this multiple times), the call to jsr $ffd2 does not work anymore at some point (it gets stuck somewhere in the "main program" part). On Vice, I get a report that the cpu jammed at $fd24. I just checked on the64 with Snapshot's ml monitor, and there it seems to get stuck at the same point. I found out in the meantime that $ffd2 points to $f1ca via $0326. So I replaced some of the jsr $ffd2 calls with $f1ca calls, and then it works! Weirdly enough, when I change them back to $ffd2 afterwards, it still works! By the way, I thought something might have gotten messed up in the jump table, but if I disassemble $fd22 (after getting stuck), I can see it still jumps to ($0326) and if I do a memory dump of ($0326) I see it still contains the $ca and $f1 bytes. I am pretty sure that I am overlooking something, as I am still more or less at the beginning of learning to write assembly language, but is this just a quirk of the C64, or perhaps the emulators, or is it an unintended side-effect of what I am doing in my code?
  14. This website is gorgeous. Excellent job!
  15. I found your Youtube channel a few days ago and that is how I got to know this project. Your channel is absolutely great!
×
×
  • Create New...

Important Information

Please review our Terms of Use