Rossman

Hi, @apersson850. It has been a long time. I am so glad to see your post. I have naïve questions, as you have come to expect from me. "Or rather with a replacement." p-code is interpreted, so there must be an interpreter in ROM for compiled Pascal code, as well as to act as the system OS (? maybe not, maybe executing p-code is just a switchable mode of a flexible OS?). Do you mean p-code embedded in ROM on a cartridge? Or some other form of ROM injection? Is there a clear path forward from the 99/8 architecture that incorporated p-system IV in the form of motherboard ROMs? I suppose a cartridge is an advantage over having a PEB, but availability of ROMs is one of several problems to solve. Pascal was resource intensive for its day. On the TI it required a PEB and memory expansion, as you point out. (Sidebar: I'd argue that resource intensity of Pascal carried forward in the successor language Java. The JVM footprint, the #includes with the standard compile... by 2012 a simple service written in Java had a gig-plus footprint. Admittedly most of these were language defaults of convenience, which can be overridden. Still, it can be argued that Java resource bloat was no small contributor to the success of Python, but ... ok, sidebar, I'll stop, you haven't missed this dribble.) "uses some tricks" Not uncommonly on the TI and similar systems of yore, we ran out of core and we had to write memory swap routines. We swapped to disk because that was where the storage was. It was a humbling moment in the early 80s when I told my dad of all of these memory expansion techniques I'd figured out for the TI (reality check: they were just crude disk I/O) when he told me of the stuff he did on an IBM 1401 and later a first generation System/360 to accomplish the same, and more. That's great, kid. Let me tell you how the world works. In your opinion, is the Pascal memory management sufficiently optimized or is there a memory management optimization worth embedding in Pascal code on the 99/4 and /4A? I believe your post describes what makes a p-system ROM a good citizen, but is there a "what makes a Pascal program a model citizen"? Again, my questions are just naïve and interpretations of what you posted, Anders. They may not be worth answering. But your post got me thinking just the same. Best regards, R.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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?

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.

@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.

If memory serves - and as we all know, memory doesn't serve, it double-faults - that article appeared in the first edition of Home Computer Magazine, the reboot of the 99'er Magazine helpfully expanded to include coverage of home computers conveniently not discontinued (at least, at that time) by their manufacturers. I seem to recall quite a few months passed between receiving the last edition of 99'er and the first edition of HCM. And I recall reading that article many times over. With the benefit of hindsight, the ironic thing about that article is that it describes TI's exit from the home computer business in almost funeral-like terms. It missed even the slightest hint of what would eventually happen, of what would turn out to be a vibrant homebrew and small-commercial-firm story that has not just preserved but advanced the core product, a story arc that has lasted 36+ years.

This is so cool. It's been a joy watching you iterate on this as you've demonstrated at the annual TI Faires. Well done, Walid. This is just so cool.

Hi, Retrospect. With mizaph's help some months ago I was successful at getting multiple disk drives working on the 99/8 emulation. In case it helps you at all, my mame command line is: mame64 ti99_8 -ui_active -uimodekey PGDN -hexbus hx5102 -hexbus:hx5102:d1 525dd -flop1 [path_to_first_diskette.dsk] -flop2 [path_to_second_diskette.dsk] -cartridge diskman3 Good luck, and I hope you are able to sort it out. Best regards, R.

Hi, Retrospect. One habit that has been effective for me is that I log the night's work experience - what I've tried, done, learned, discovered - before calling it a night. It's not an abstract of lessons learned, it's just a raw dump of tried-failed-tried-worked-researched-learned-tried-succeeded. (Yes, I try to end every night's work on a success.) Compile time being what it is, I can update the log while I'm working. Helps me to record context, priority, conclusions, available information, questions, doubts, ambitions, etc. I have found this log helps when resuming a project. It puts me back into my frame of mind at the time I did something. Recreating my frame of mind in a cumulative fashion helps me to recapture a substantial portion of the body of understanding I had acquired at the time I suspended work. That, for me, is the most valuable thing to the log. I picked up Pascal development a few weeks ago after a half-year hiatus. A few weeks into it, I realize there was a standard (such as it is) I was driving to last year that can only be achieved through more than banal familiarity with language syntax. A few weeks ago, I logged "Now I know why Boston's second album was so bad compared to their first album." My formulaic approach to development was a function of me treating this exercise as an obligation rather than a learning exercise. "Beginner's mind" is so much more rewarding, especially in a hobby. There is joy in capturing it at the time, and value in capturing it to future you. And I most certainly do not want to be on a path to creating the Pascal equivalent of Boston's third ablum. Should that happen, it will be time to sell the p-code card. I use Evernote as my logging tool, but obviously there are many choices. Best regards, R.

This is awesome. Thank you for posting your code. I was able to harvest the unit_10 code and it works. I now have 4 disk drives on my p-system. This will help me with developing my new project and refactoring my old project. Thanks again! Edit to the original post: Made a simple copy of my work disk. Seeing "Warning units 9 & 10 have the same name" in the filer after an Extended Directory operation was very satisfying!

Hi, Videofx. I set out to re-learn Pascal a little over a year ago. I broke the problem down into two parts. The first part of the problem are Pascal basics: conventions, structures, etc. To do that, I bought a used copy of the text I used at university, Oh! Pascal! It's quirky, but I liked it in the 1980s, and I like it today. You can also look through the USUS library disks for example code. I also found it useful to explore the turtlegraphics code. apersson850 created a package a long time ago that largely works, and I posted about my experience getting it to work somewhere in Atariage. You may find the same a useful exercise as you get familiar with the environment. The second part of the problem are the TI extensions, things like Sprites and what not. The TI documentation (in the PDFs in the TI development resources) is pretty good. Supplement that with your own trial and error, and the occasional question to the Atariage forum, and you should be just fine. I find Pascal to be a fun and satisfying language. I hope you find it so as well.

I always enjoy your posts because you make me realize there is so much I am not doing that I could be, and therefore I have that much more to learn. UCSD Pascal is an operating system, and I do not know it very well in this regard. I have started another small game project on Pascal. I want to harvest from last year's project (chemin-de-fer), but the combined codebases will exceed a single disk. At some point, it would be nice to have common code units for things like screen i/o so that they could be distilled to a single disk. But that is a big refactoring project and for now I want to work on a small refactoring project. It would be a convenience to have a fourth floppy drive. I've never tried this before. Are you modifying SYSTEM.MISCINFO to do this? Is that in the p-code firmware? I'm curious to know anything you can share about modifying that (or other) OS files.

Welcome to the small but dedicated p-code community. There is a collection of useful p-code disk images on whtech. This directory contains Pascal programming disk images as well as TI-Pilot and the Freeform spreadsheet. There is another directory on whtech with some other Pascal related resources. And don't forget to look at the TI Development Resources page in Atariage. If you didn't get the manuals, you can get them in PDF format here. I use a combination of 705.dsk and 712a.dsk as my boot disk. It has both the Filer and Editor on it, as well as some other useful utilities such as a character set mapping for true lower case characters, and a utility for changing the default screen colors. These are modest but nice touches for customizing your programming environment. If you have just the standard disk drives from TI, boot the Filer disk. I do most of my development using Classic 99. I use a modified version of 712a in drive 1 (#4:), the standard Pascal compiler disk in drive 2 (#5:), and my work disk in drive 3 (#9:). This works very efficiently. Again, welcome to the p-code community.

These are interesting. I loaded these as user carts in Classic99 and got the following menu options: 1 FOR TI BASIC 2 FOR PASCAL TIBUG 3 FOR PASCAL DOWNLOADER 4 FOR PASCAL BOOT LOADER (Sorry for not posting an image, Atariage and my browser are not cooperating just now.) No idea what these are, or what the system requirements are to run them, or what the right configuration is for them. But they are certainly something fun to investigate as they appear to be UCSD Pascal goodies on a cartridge. I know that over the years, there have been posts in Atariage about p-code implemented as a cart. Perhaps this is it? Or what somebody suspected it might be? Best regards, R.