Jump to content

Rossman

New Members
  • Content Count

    97
  • Joined

  • Last visited

Community Reputation

69 Excellent

About Rossman

  • Rank
    Star Raider

Recent Profile Visitors

2,823 profile views
  1. Perhaps that is why there are academics and there are practitioners. Academic rules tend not to do well in real-world applications, but the theory behind the rules informs thoughtful practice. In revisiting their edict, it made me ask again why they laid it down in the first place. I still choose to follow it as a rule because it costs me nothing... well, I now know that is not true, it costs me 5 bytes. Fortunately, my code is an output of what is a purely academic exercise. And following a main() call to a single procedure where my MVC logic resides doesn't impair readability. It isn't that difficult to scroll up. Even in the Pascal editor. It's the next procedure up. In UCSD Pascal, I am effectively a rookie programmer again. I suspect that by making the call out of main(), I got to thinking about code structure and more quickly gravitated to the MVC pattern than I would have otherwise. I never implemented MVC in Pascal (AFAIK the pattern post-dates my study of Pascal). I probably would have ended up there, but I suspect this got me thinking about the structure of my code differently much sooner than I might have otherwise. Don't know, but I'd like to think so. One of my goals is readability, so that future me can pick up where past me left off. I'm sure you've all had the joy of picking up somebody else's code and cursing out a person or people you never met. I wonder what the record is for percentage of a build that is ghost code? Or for levels of nested IF statements? When I picked up my work again recently after a long hiatus, I was pleasantly surprised that I had modularized the code and made it readable enough that I could pick it up again after a day. There are no comments in the code. I have a few automated unit tests. The structure made it accessible. I hadn't thought about resource limitations of early computers as encouraging (if not mandating) use of global variables, and I can appreciate that. I remember getting the 32k memory expansion on the TI and wondering what I could possibly fill up all that memory with? And I did get to see first hand how resource abundance resulted in code bloat throughout the 80s and 90s. Excess memory and faster CPUs covered up for a lot of coding sins. No doubt I wrote code that benefited from the same, so I'm not throwing stones. Since then, I've seen unnecessary abstractness (why have 3 levels of inheritance when 5 will do?) and all kinds of goldplating that increased the intellectual density without increasing the utility of the code. I do aggressively refactor my code to reduce the number of statements, eliminate redundancies, create reusable functions and procedures. I do like the eloquence of code density for efficiency. So sure, a single statement in main() is a resource wasteful practice that at best was training wheels as I got back into programming. And no doubt, the efficiency with which the code is executed in machine-level instructions is critical, especially in environments of limited resources like the TI. Perhaps I do it because I write my code for me, and not for the machine.
  2. You are probably right. I am not a smart developer and I have not been hands-on-keyboard cutting code too much in the last decade-and-a-half. What I concluded is that avoiding verbose Main code keeps me out of lazy habits, like global variables. For reasons I no longer remember, it wasn't uncommon to see global variables in code examples that I was learning from (nearly) 40 years ago. I don't know why that was. It just was. And I wasn't smart enough to understand the benefits of good code encapsulation at the time to appreciate why things like that were just bad ideas. My conclusion is that their discipline in this area - artificial though it may be - made me a more disciplined developer. Not a good developer, but a more disciplined one. From time to time, I've had reason to look at Java and C# code in the last 20 years, and I know that encapsulation isn't a given. That can lead to conditions that defy automated testing and yield mystery production errors. When I started coding in Pascal again a few years ago, I remembered that rule. I started with that rule, specifically to understand why they had it. Perhaps it isn't much value, but after a hiatus I can pick up my code a lot easier now than I could decades ago, if only because it's got a bit more structure to it than it would have otherwise. That's worth at least 2 bytes, if not 4, of stack.
  3. Since I posted this, I've been motivated to look at my boot disk again, and am making some adjustments. I strung the aforementioned utilities together using CHAIN, plus a REDIRECT for a date prompt. I'm now consolidating the code and will post it here when I'm done. I want to stress that the value of this is in the work done by other people, I've simply orchestrated it for convenience. On the date capture. I put the user in Filer-Date which is crude but effective. I'm certain there's a POKE for setting the system date, but I'm not that familiar with the internals to know precisely how to do that.
  4. My Pascal professors in the 1980s were adamant that Main should have only one line of code. I found it frustrating at the time, but I have come to appreciate what they were trying to teach me. Among other things, a verbose Main is a short path to writing sloppy code. So in my code today, Main has one statement. In my Chemin-de-Fer game and in my Roulette game, I have implemented a crude model-view-controller in each in an attempt to separate UI from logic. I have a lot of units. That allows me to compile more efficiently and, more importantly, test code in isolation. One other thing I have learned, especially since picking up the code a couple of months ago, is that the solution need not be perfect the first or second or third try, or ever. There is great joy in making something that works, then making it work a little better, then a little better-er, and so forth.
  5. This is hugely helpful. This sentence is my next refactoring of the wager logic. Thank you, @apersson850 Probably poor on my part to admit this, but it never occurred to me that enumerated types were material to resource efficiency. I'm familiar with enumerated types and use them from time to time. They seemed like a clever thing, a nice-to-have, a self-documenting range of values. But if my code works in an array or a case, why bother? Well, what you have pointed out to me is that if I don't use them I end up with 42 words when I need 3. And the more complex the side-bets, the more the wasteful resource allocation becomes. I have 2 x UCSD Pascal programming books handy (excluding the TI manuals), I'm curious now to see how the academic tomes treat enumerated types. Thanks again. This changes my thinking about how to handle classes of input. This game (roulette) is more complex than the last for wagers. This helps.
  6. I had to dig around for it, but I posted my learning experience here: I was running an experiment with sprites, using constants to hold different character patterns. That accumulated in memory pretty quickly. In the end, it was a poor use of constants by me. And an inefficient use of resources. I don't know if it is helpful for me to post things like this, but for those who come along with an interest in Pascal development, perhaps they can learn from my mistakes. I make a lot of them every day, but I always make it a point to end on a successful build.
  7. Yikes, I did not know this. So, in the case of a range of values like this: case charval of '1' : do something 'B' : do something 'Z' : do something If I understand you correctly, the compiler will create a jump table of 41 words ('Z' has ASCII value of 90 decimal, '1' has ASCII value of 49 decimal. Not only wasteful if I only need the 3, but it risks stack overflow. I've found it not too difficult to get a stack overflow in Pascal by having too many constants. When I had the stack overflow problem a few years ago, I solved it by replacing my constants with values in arrays. I would guess that here, suppose I had a dozen or so cases (in my program, it's a user interface that allows a lot of different types of wagers - Dozen, Column, a specific Number, High, Low, Even, Odd, etc.), I'd be better off translating the entered wager into an indexed value from, say, 1 to 12 integer. That would reduce the memory footprint of the jump table.
  8. For what it's worth, I was flipping through the Pascal Compiler manual and came across an entry on page 211. It's the appendix, section 8.16, PROGRAM DEVELOPMENT WITH MULTI-DRIVE SYSTEMS. With two-disk systems, TI recommended combining the compiler and editor onto one diskette and having that in #5, with the filer in #4. Per their recommendation, source and object code should be in #4. I don't follow this recommendation as I have the Filer and Editor in disk #4, the compiler in disk #5, and source and object code in disk #9 (with code I use for reference purposes in #10, per the previous post about UNIT_10). I suspect that this is a brute force way to ensure that at both compile time and run time that SYSTEM.LIBRARY can be found. Again, hope this is helpful.
  9. There are a few things that I do to customize my p-system environment. Have a look at this post on Atariage. This was really helpful to me when I was getting started. Also, have a look at this directory on whtech. -- Disk 671 volume name PUTIL-A has some useful utilities on it. SYSTEM.STARTUP on this volume should give you an upper and lower case character set, and the volume includes some additional character sets as well. I've harvested a number of things from this volume. -- Disk 712A has the MODCOL utility which changes the foreground and background colors. I use white foreground on dark blue. -- Disk 705 is a DSDD boot disk image that provides a reference example of a customized boot disk. If you have a physical 4th disk drive or if you have Classic99, you can add a utility that @apersson850 posted called unit_10 that will make it accessible in the p-system environment. He also included code to access a ramdisk from the p-system in the same post. For what it's worth, I found that experimenting with incremental customization let me eke out a little bit more out of the p-system here and there. Hope this is helpful.
  10. First of all, welcome to the dark side! I likely ran into the same problem when I started Pascal development on the 99/4A some years ago. I've gone through my early log entries (at some point I started logging every day's worth of coding in Evernote) but I don't have a note covering this particular problem. UNITS are very useful in Pascal, especially from an editing and compiling efficiency perspective. It's worth looking at the Pascal Compiler manual from page 100, section 4.5 UNITS. I read that section some years ago (again and again) and straight-up it answered absolutely none of my questions. But a craftsman never blames his tools. I eventually worked it out and posted it in Atariage. I hope you find this useful. @apersson850 is the most knowledgeable on Pascal and has been hugely helpful to me and others in the community over the years. FWIW, I have customized my disks extensively (if you're interested, I can point you to some of the resources in the USUS library and other places).
  11. Thanks for this. CHAR and INTEGER worked fine, so I suspected as much, but I didn't want to rule out the possibility that I had an implementation problem.
  12. Yeah my intention is to try a packed array but I've not had the time in the last couple of days to do that. That's great to know about the unpacking. String made me lazy.
  13. Developing it on Classic99. I've not experienced any compiler inconsistencies between Classic99 and real iron. Plus, Classic99 is a far more efficient way for me to determine how lousy a developer I am. I've edited this post from here. My first reaction was that, ok, maybe there is a potential difference given the environment. But on thinking about it, that's not even remotely in the realm of the possible. A difference between the two environments wouldn't manifest in a logic error at compile time. If a CASE using STRING type works on real iron, it'll work on Classic99. So my question still stands as a language construct. Anybody know whether Pascal allows STRING types in CASE statements?
  14. Hi, everyone. I've used CASE statements in Pascal with CHAR and INTEGER types without a problem. But it doesn't look like I can use a CASE with a STRING type. I get "Illegal type of expression" from the compiler on the CASE statement with a string. If I redefine it to a CHAR, it compiles. But I need more than a CHAR. STRING types are valid in IF statements, but that's not the most efficient way to structure logic. It's not an intractable problem. Just wondering if anybody has run into the same. Yeah, yeah, there are 3 of us or so doing Pascal development on the 99/4A. Maybe I can use a packed array of CHAR. Maybe other development communities have run into the same on the CASE statement, that it can only resolve primitive data types. Of course, the bad news is that I'm back at it. Expect more tedious Pascal development entries in the Development forum.
  15. @Vorticon - all good points. Completely agree it was a unique time: home computer tech was powerful (it was not just a game console as @pixelpedant points out), affordable (as @InfernalKeith points out), and accessible. IMHO, accessibility was the key (which @InfernalKeith also touches on): it didn't take a lot to push the boundaries of the base machine, which fueled interest, which led to learning more fundamental things, which led to more pushing, which led to so many creative things from so many people. And the cycle repeated. Given what I do for a living, not too many days go by that I'm not grateful for having lived through that period of time. The accessibility factor is why I wanted my daughter to learn 9900 assembly. It doesn't get more real than that. The wildcard in the wake of TI's exit (and the others) was the community factor. People have formed communities around a craft or a technology for centuries, both professional (guilds) and non-professional (interest groups). While there might not have been communities that formed around computer technology prior to that time, community is a basic human need. A sociologist might have spotted this. My point (admittedly, poorly made) was simply this. Commercial logic might have dictated that the absence of a deep-pocketed investor hoping to develop a market made it irrational for individuals to continue a commitment to a technology sponsored in a proprietary manner by that investor. Sociological logic would perhaps have drawn a vastly different conclusion, even at that time. Perhaps. I'm not trying to be overly critical of the author of the original article. Or any of us in our teenage or later years reading that article when it first appeared. I'm not a sociologist by intuition or training. I missed it as well. But we are all of us in this community beneficiaries of the fact that it turned out differently than the commercial logic would have suggested it should have. And for that I am grateful.
×
×
  • Create New...