Jump to content

neglectoru

Members
  • Content Count

    75
  • Joined

  • Last visited

Everything posted by neglectoru

  1. I won't pretend to understand the day of week magic, but I think it would be magical in any language. This is neat library! I hope I motivated something useful.
  2. Thanks @TheBF for your examples, and for tinkering with my toy problem! I'll definitely check out the examples in more detail. I think you put it well. The Algol-like languages are all very different than Forth, and I think they've influenced (poisoned?) my thinking for much of my adult life. That said, I think Forth's minimalism and low-level nature may contribute to its difficulty to read. In my example of having an event structure, I invented getter methods for the structure, and didn't know about ANS forth structs which solve basically the same problem. Things that are common in other languages (strings, objects, structures, literals) are up to each Forth environment to re-invent. Every C implementation "agrees" on some concepts (structs, pointers, function calls, etc.). The only thing that Forth implementations really agree on is that every word evaluates left to right. Much of the time they operate on the parameter stack (or return stack), some of the time they define new concepts. Forth systems agree on some common vocabulary (:, DUP, SWAP, +, etc.) but then differ widely when you leave this minimalistic set. This means that either your problem should be well suited to the minimalistic set (doing things easier than you would in an assembler, like a device driver), or you need to create your own custom language, or you need to rely on what your particular Forth environment gives you for higher level problems, or you need to build your own Forth interpreter that can address the kinds of problems you want to solve. Since it's so much easier to write a Forth interpreter than a C compiler, that happens a lot. But it does mean that if you make poor choices of what your interpreter should look like, or what your new vocabulary should feel like, you will get yourself into a very deep pit. That's why I wanted to see examples of successful big forth systems, and see what they do right. So thanks again for the examples and the discussion!
  3. Thanks for the detailed examples! I will definitely study them in more detail. My big question is often about design, which just feels so foreign to me. Here is a concrete example of a toy problem, and where I run into issues. Not game related, but easy to explain quickly. The concrete problem: You have a list of calendar events. Given a date (year, month, day), print all the events on that day. A calendar event is a string (event name), date/time (year, month, day, hour, minute), a duration (minutes), a "repeating flag", and an end date. For simplicity, if repeating flag = 0, no repeat, flag = 1, every day, flag = 2, every week. the end date (year, month, day) is ignored if e.g., a simple 30 minute non-repeating event: ("E1", 2021, 11, 23, 16, 30, 15, 0, 0, 0, 0) = An event that starts on 2021-Nov-23 at 16:30 and ends at 16:45 ("E2", 2021, 11, 23, 16, 30, 15, 1, 2021, 11, 27) = An event at 2021-Nov-23 16:30, 2021-Nov-24 16:30, ... 2021-Nov-27 16:30 ("E3", 2021, 11, 23, 16, 30, 15, 2, 2021, 12, 15) = Same idea, 2021-Nov-23, 16:30, 2021-Nov-30 16:30, 2021-7-Dec 16:30, 2021-Dec-14 16:30 The algorithm is straightforward to describe Given a target date: For each event: If event flag is 0 and target date is event date, print it If event flag is 1 and target date >= event date and target date <= end date, print it If event flag is 2 and target date >= event date and target date <= end date and day-of-week(target-date) equals day-of-week(event date), print it I know exactly how I'd implement this in C, or Javascript, or Python, but Forth? Let's start with representation. For both C and Forth, we can have a count of events, and each event can be a fixed size number of words (10, plus however you represent the event string) My first problem is that every Forth system handles strings differently, so let's drop that problem for now. Problem 2, how do you get fields? In C, this is straightforward: int[] allEvents = [........] // so year(event[2]) is allEvents[event * 10 + 0), month is allEvents[event * 10 + 1], etc int getDay(int event) { return allEvents[event * 10 + 2]; } in Forth, I suppose you'd do something similar : GET-DAY (event-id -- day) 10 * 2 + allEvents + @ ; or something like that. I find that hard to read, but maybe you get used to it. Problem 3, you need to compare dates. As this point, I'm somewhat lost. int equalDates(int y1, int m1, int d1, int y2 int m2, int d2) { return (y1 == y2) && (m1 == m2) && (d1 == d2); } in Forth, that becomes : EQUAL-DATES (y1 m1 d1 y2 m2 d2 -- f) (I have no idea) ; Plus, consider the fact that we need to compare dates more than once, so the stack will always have the target date on the bottom, so you need to do something like 3DUP before you consume a date, because you need to preserve the date. As for the final algorithm, my resulting C code would ultimately look like the description I gave above) void printAgenda(int targetYear, int targetMonth, int targetDay) { for (int i=0; i < numDates; i++) { if ((getFlag(i) == 0) && equalDates(getYear(i), getMonth(i), getDay(i), targetYear, targetMonth, targetDay)) { // print the event ... ... } Is that pretty? It's not great. I could do better, but I can sit down and understand what it does later. In Forth, I'm not at all sure how I'd write this in a way I could read it. I definitely, for example, need a Forth FOR loop because I need to access "I" all the time ... i GET-YEAR I GET-MONTH I GET-DAY (now stack has year, month, and day) .... but what now? How do I get targetYear, month, and day to the top of the stack so I can compare them? Again, maybe it's my Algol-language training, but I'm pretty sure I could write this in a few more minutes in C, and Forth would take me hours.
  4. I've written several forth interpreters, I've read Brodie's books, and I have a lot of experience in the traditional Algol world of languages (Java, C, Pascal, etc.) I have even used my forth as a scripting language in games I've written (small interaction scripts for an RPG, for example.) I understand forth, but I honestly don't feel like I "get" it. I wrote some games for the Jupiter Ace, but the result was a mess I couldn't follow when I came back to it weeks later. Every time I try to write something big in Forth, I feel like I hit a wall. I think part of that is that I've gained so much from reading code, which is in abundance in the above languages, and really isn't for Forth. I've studied far more forth interpreters than programs written in Forth! Maybe Forth is better for radio telescopes or device drivers or firmware, which is not really the kinds of programs I'm drawn to. Are there good, idiomatic, substantially sized Forth programs that the experts recommend? I'd really like to see some non-trivial games, but really any highly interactive program would be interesting. I feel like if I read some good Forth programs, mine wouldn't be so awful. (I'm definitely not trying to troll here. I love programming, and I'd love to try to take advantage of what Forth has to offer.)
  5. Thanks for the info. It's a shame that none of the packages are working. An original, or a fixed interpreter would be awesome. I'll check out the forum64 thread to see if constructing a new interpreter would be possible.
  6. I loved the sheet metal aesthetic and keyboard of the pet 4032, which this is not. If someone could make such a beast with a real high quality CRT, I'd consider it. I don't see the appeal of the Pet as a machine, truth be told. Why not just use a subset of the features of a C-64? I don't say that to be nasty. I'm honestly curious what the Pet has going for it.
  7. First off, I'm super excited about this project. I've watched the previews for years and can't wait to play this game. I wish the developers all the success in the world. With regard to the kickstarter, though, I'm worried that emphasizing "feelies" will distract from the development of the game. I want the team's time spent on shipping the game, not trying to figure out who can make the best colored boxes or cloth maps at scale. It's hard to ship a well balanced, quality story, robust computer RPG. I wish we could fund these software production efforts without the potential distractions of physical production and shipping.
  8. Zoom Pascal bears W Kusche's name. Didn't he also later work on Kyan Pascal?
  9. Thanks for putting this together! It is fascinating stuff. Do you have a sense how much is shared between the Apple II and C-64 versions? I got the sense that the engine might be similar, and now I can compare. Stuart Smith's lead platform, I think, might have been the Atari 800, for which (I think) the first of his adventure games were released. I wonder if the Apple II or C-64 versions were the original for ACS
  10. (Inspired by the recent Antic interview about Pascal)... Long before Abacus teamed with Data Becker for their pascal, Arnie Lee (of Abacus Software) was porting Tiny Pascal from the Z80-based computer to the Apple and Commodore machines: Does anyone have a working version of this Tiny Pascal for any of the 6502 machines (Apple / C-64 / PET)?
  11. The APh tech doc "Your Friend The Exec" used to be available on intellivision.us, but, sadly, seems to no longer be there. Does anyone have a scan of this important historic document? On a related note, on Intellivisionaries episode 7, David Rolfe indicated that he'd make the original source code / listing for the Exec available. Did this ever happen?
  12. Heh, indeed. When I was a kid, I followed the typical path. I scrambled the cube, managed to get all the colors back on one side, and got stuck. I bought a book, and could use the instructions to solve the cube in about an hour. Fearing another hour long solve, the cube gathered dust. Fast forward 30 years, and I decided I wanted to actually learn how to solve it, in part by understanding what on earth was going on. With a better math background, I learned how to actually solve the cube myself (without instructions), I can now solve the cube in a few minutes (one can indeed teach an old dog new tricks), and it is a lot of fun. I probably could write my own cube solver now, but I'm curious how folks did it on the 8-bits. It would especially be interesting if they used some of the fancy techniques to solve the cube closer to the optimal solution of 20 or less moves, rather than the dozens and dozens a basic solution takes.
  13. Atarimania seems to believe that there was a "Rubik's Cube Solver" for the Atari 8-bit. I've recently become a bit fascinated by these. Does anyone have this, or any information about this, or other Rubik's cube solvers for the Atari 8-bit?
  14. Apple Logo was my first programming language, many years ago. I did the typical turtle geometry stuff, but moved on to core computer science stuff with the help of a teacher. I never dabbled with music on the Apple. Since the machine could do little more than beep, I'd be curious what it sounds like. If my school had a utilities disk, I never saw it...
  15. Thanks for the resources! It is amazing to me how similar Pokey Player is to their later SID offering (see attached screenshot) I'm considering starting a research project / blog about the early computer music creation software, which would be limited in scope from first home computers, and ends with the first Amiga trackers (after which music creation exploded and would probably be too much to cover). Any interest?
  16. A comprehensive set of type-ins from Compute would be really cool.
  17. That is encouraging news! Any code would be super exciting. Keep us posted...
  18. Atarimania has an entry for Pokey Player, a music editor written by Craig Chamberlain and Harry Bratt. The two later went on to create a C-64 music editing solution (sidplayer), which was very popular in the Commodore 64 BBS music scene. Their Atari product, according to sidplayer.org, was created in 1982, but I can find little other information about it. Atarimania has a 1984 entry, but no disk / manual / other materials. Does anyone have any more information (or perhaps a disk image) of this product? I think it is probably a very early example of music creation software. Other interesting early music editors out there?
  19. I feel like there is another issue floating around. Boulder Dash for the 2600 is a massive technical achievement, pushing the 2600 far beyond what it was ever intended to do. Here too, we have a relatively modern game, one for which the source code is probably not yet lost to the sands of time, like so many 2600 resources. The sources that make up the game (including the levels which are arguably derived works of FSS) are an extremely important technical and historical artifact. However, with no ROM release or source code release (for understandable reasons, to be sure), this piece of (modern) Atari 2600 history is in great jeopardy of not being preserved in the fidelity it deserves. A release to the Internet Archive is probably undesirable to both the authors and FSS, but would preserve things far better than they would in the current state of the world.
  20. Does your remix of "the wall" work in Altirra? I tried it, and when I press Start, all I get is a screen full of random characters.
  21. Thanks for this reference! I tried to use these versions under Altirra, and ran into problems (that I suspect have to do with Altirra's arrow key handling, not the program) When I run this in Altirra, I was unable to use the arrow keys to move around the spreadsheet. Does anyone know the proper keys / Altirra settings to get navigation working?
  22. A few months back, I remember reading about someone's project to make graphics hardware out of TTL chips. The result was similar to the Duo Adept, but with much fancier color graphics. The YouTube video featured the complex prototype, running Amiga style demos. Does anyone remember this project?
×
×
  • Create New...