Jump to content

neglectoru

Members
  • Posts

    77
  • Joined

  • Last visited

Recent Profile Visitors

6,519 profile views

neglectoru's Achievements

Star Raider

Star Raider (3/9)

35

Reputation

  1. Does anyone know what happened to the git repository mentioned in the first comment? https://github.com/atari800/Kaverns.git returns a 404
  2. Great collection! I noticed in the screenshots that the 86Box version was 4.0. I thought the most recent version of 86Box was 3.11. Are you using a nightly build?
  3. 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.
  4. 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!
  5. 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.
  6. 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.)
  7. 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.
  8. 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.
  9. 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.
  10. Zoom Pascal bears W Kusche's name. Didn't he also later work on Kyan Pascal?
  11. 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
  12. (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)?
  13. 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?
  14. 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.
×
×
  • Create New...